SmartPhone Code Transition
Program Description
A team led by Gregor Wagner and Fabrice Desré conducted the analysis necessary to determine what changes should be made and the level of effort those changes would take to move us closer to being able to run on generic gecko to reduce its maintenance cost. The results of the analysis has led to the final version of the Firefox OS Code Transition Plan, and the plan has been approved to proceed with the following as its primary goal:
To transition the Firefox OS for smartphone code to reduce its maintenance cost and get it into a state where the volunteer contributor community can successfully take the lead and ownership for the future direction of the b2g for smartphone code Description
Requirements:
There were four areas analyzed for inclusion in the code transition plan (shown below with their owners):
- Packaged apps (b2g features), perhaps the most important piece (Fabrice)
- Removal of security model and wait for platform team to give us new security layer. (Paul)
- Process model - abandon ours and move to the one desktop has (Kan-Ru)
- Graphics/media (Kan-Ru)
It was decided that the focus of the transition would be on the first two of these areas. In addition, an effort has begun to reduce code duplication by merging the 2 separate system apps.
User Stories and Acceptance Criteria
| Title | BUG ID | User story | Acceptance Criteria |
|---|---|---|---|
| Title Goes Here | Bug ID | User Story 1 | Acceptance Criteria 1 |
| Bug ID | User Story 2 | Acceptance Criteria 2 | |
| Help/Onboarding | Bug ID | User Story 3 | Acceptance Criteria 3 |
Program Status
| Milestone | Date | Status | Status Notes |
|---|---|---|---|
| Gather feedback on the plan after discussion at 2/9 Engineering Program Review. | 2/12/16 | Done | 2/9 review was well attended and lots of feedback was shared in the Transition of Firefox OS Code Base Proposed Plan. 2-3 additional reviews were held via videoconf. Participation was good. |
| Identify engineers to work on the code transition plan | 2/12/16 | Done | Identified engineers' names have been inserted into the plan. We've documented which components of the plan they'll each work on and for how long. |
| Hold a final review of the proposed plan with the engineering team | 2/12/16 | Done | Final reviews held via email. |
| Present plan at weekly Engineering Program Review | 2/16/16 | Done | Wasn't ready by the 2/16 review but plan was submitted to Faramarz 2/19 via email. |
| Present plan at All Hands | 2/25/16 | Done | |
| Public wiki created | 3/4/16 | On Target | Public wiki has been started. Need to break down code transition work so that all milestones for eng. work can be posted |
| Develop execution plan for the code transition | 3/4/16 | On Target | Meta bug created for the entire project. Have also entered bugs for some, but not all of the major components of the work. Next, need to identify milestones and target dates for tracking the progress of the work. |
| Document requirements for build and test support for re-architecture effort. | 3/11/16 | On Target | Need to identify requirements now that the code transition plan has been finalized and approved. Work breakdown will help in identifying the requirements |
| Identify who will set up branch, build, and test environment. | 3/11/16 | On Target | Dependency: requirements from engineering team |
| Set up branch, build, and test environment. | Not Started | ||
| Identify milestones for code transition work and develop schedule | Not Started | Development milestones will be established once the work breakdown has been completed. | |
| Code Transition Milestones | TBD | Not Started | Development milestones will be added as milestones once they're identified. |
Status Key
| Color | Status | Key |
|---|---|---|
| On Target | The project or deliverable is expected to meet its due date. | |
| Challenged | The project or deliverable is facing an issue that might cause it to miss its due date, but a “get well” plan has been developed to get it back on track. | |
| At Risk or Late | The project or deliverable is blocked or facing an issue that might cause it to miss its due date, and there’s no “get well” plan to get it back on track, or it is already late. | |
| Done | The project or deliverable has been completed. | |
| On Hold or Not Started | The project or deliverable has either not been started or has been placed on hold. |
Program Timeline
MVP Scope
Querying by 2.6+ features
(please add correct bug tracking number)
No results.
0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);
Dependency Tracking
Detailed Program Plan
| Action Item | Engineering Owner | QA Owner | UX Owner | Bugzilla ID | Planned Done | Actual Done |
|---|---|---|---|---|---|---|
Program Stakeholders
| Role | Name | IRC |
|---|---|---|
| EPM | ||
| EM | ||
| PM | ||
| TL | ||
| UX | ||
| QA |
- EPM = Engineering Program Manager
- EM = Engineering Manager
- PM = Product Manager
- TL = Tech Lead
- UX = User Experience
- QA = Quality Assurance