Firefox OS/ProgramManagement

From MozillaWiki
Jump to: navigation, search

FXOS Engineering Program Management Office (PMO)

Click the program on the graphic to view further information
Connected Devices Portfolio Management2.5 Program ManagerHackabilityBugzilla LiteFlyWebAndroid PortsB2GdroidNSEC (New Security Model)FoxfoodingProject AlopexTVMarigoldRTL (Right to Left)EmulatorKill SwitchTask Continuity DescriptionVoiceData SyncCloud StorageNSEC (New Security Model)Geolocation DescriptionBluetoothEngineering Quality ProgramOTA (Over the Air) updatesPrivacyLate CustomizationMarketplace TVPin the WebPerformanceDRM (Digital Rights Media)Add-ons DescriptionFirefoxOS/NGAMetrics DescriptionDataEPMPortfolio1.png
About this image


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