Firefox OS/ProgramManagement

FXOS Engineering Program Management Office (PMO)

Click the program on the graphic to view further information

• FxOS Portfolio Management
• 2.5 Program Manager
• NSEC (New Security Model)
• Foxfooding
• Project Alopex
• Kill Switch
• Firefox OS Cloud Servies
• Privacy Description
• Late Customization
• Marketplace TV
• Pin the Web
• Add-ons Description
• Aha Admin
• Hackability
• Bugzilla Lite
• Wikis
• TV
• Marigold
• RTL (Right to Left)
• Emulator
• Voice
• Data Sync
• Cloud Storage
• Geolocation Description
• Bluetooth
• Red Tai/Red Square
• OTA (Over the Air) updates
• Performance Description
• DRM (Digital Rights Media)
• FirefoxOS/NGA
• Metrics Description
• Web Components
• Web Components Performance
• Data
• Engineering Quality Program
• OWDCRB

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 is being proposed for this release"
• feature b2g- version#+ is define as "this feature has been committed (by the engineering team(s)) 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

EPM Toolbox

Wiki: Link