Firefox OS/ProgramManagement

Who

• Candice Serran
• Michael Treese
• Kevin Hu
• Joe Cheng
• Ivan Tsay
• Wesley Huang
• Howie Chang
• Jenny Liu
• Erin Lancaster
• Shell Escalante
• Chris Peterson

How

TODO: fill in details below

• Description of functional teams goes here
• Description Bugzilla process goes here
• Communication
  • List the mailing lists
  • List the weekly reports and sprint reports, etc

Functional Teams

The functional teams were designed to cover specific areas of FirefoxOS development. Some teams work solely on FirefoxOS and other teams support all of Mozilla's products but work on a few key feature areas for FirefoxOS.

Function team details: FirefoxOS/functionalteams

• Productivity
• Media
• Performance
• Comms (Dialer, SMS, Contacts)
• Systems (Notification, Apps Install, Customizations)
• System Platform (Keyboard, Settings, Lockscreen)
• Multi-media platform (Audio/Video Encoding)
• WebRTC (Audio/Video P2P connections, Get User media (gUM))
• RIL (Telephony, Network)
• GFX, Layout, Audio
• Devices
• Services

Bugzilla Flags

The team will be using the following whiteboard text for tracking user stories and their priorities in Bugzilla.

Overview

• ONE bug per user story. Implementation tasks and bugs should be marked as blocking the user story bug.
• ALL user stories that are either committed or targeted to a release must have a bug filed.
• If a bug is not a user story it will NOT have any of these flags in the whiteboard.

Data

• The user story id, as found in the Product backlog spreadsheet, is written in the bug whiteboard as "ucid:{id}", eg: "ucid:Browser326".
• The functional team that is responsible for the implementation of the user story is written as "ft:{teamname}", eg: "ft:media".

Format

• Grammar: [ucid:{id}, {release-version}, ft:{team-id}]
• The entire block is contained within square brackets
• Case-insensitive. UCID and ucid are both valid.
• Key and value are separated by a colon (no spaces).
• Key/value pairs are separated by a space and comma.

Examples

• [ucid:System26, 1.3, ft:systems-fe]
• [ucid:Comms27, 1.3, ft:comms]

feature-b2g Flag

The purpose

• The feature-b2g flag is intended to be used to help define scope for a particular release.
• The feature-b2g flag enables us to isolate the particular engineering tasks that make up the completion of the feature in a release time frame.
• feature-b2g version#? is defined as "this feature has been agreed upon to be in scope for this release"
• feature b2g- version#+ is define as "this feature has been scoped and committed for this release"

How to tag

• [meta] bugs features and all dependencies targeted for a particular release should mark feature-b2g flag.
• The feature-b2g flag should assigned to engineering tasks falling under the user stories AND the user stories themselves.
• feature-b2g should flag to feature work only, not polish, enhancement or refactor work. Unless there's a user story dedicated for those work in a particular release. This gives us a more stable feature-b2g bug number and better prediction/tracing.
• You can only mark the flag for engineers assigned on your team - not partner teams.

Who has the permission

• PM and EPM, engineer managers and partner peers have the access