Feature-b2g flag

• The idea is to have feature-b2g:version#? and feature-b2g:version#+ is to have a better process to propose features and sign-off what engineering teams agreed. So, once a feature is proposed to be included in a specific version of FxOS, feature-b2g:version#? will be assigned. Then, engineering team could try to break down the feature in details and estimate if the proposed feature can be included in a given release during planning stage. We can have review meetings just like triage, to review these bugs, and have a final agreed scope of features that then, will be tagged with feature-b2g:version#+.

• During the planning stage, some discussions will be happened back and forth, with this flow, we can make sure these discussions can be happened within correct group of leads in an efficient way. We expect all or most engineering bugs related to user story bugs should be created, reviewed and estimated before a release starts. Some parts might be negotiated with product teams and can be agreed to be out of the scope. To make sure we have accurate agreed scope of features, to mark what we all agreed with feature-b2g:version#+ could be something we can do. Since Bugzilla is the place where engineering teams feel comfortable to work, it's a good choice for us.

• When a FxOS version starts, all feature-b2g:version#? should be considered to move to the next version of FxOS, because it means, we haven't got the agreed or accurate estimation from engineering teams(meaning, we are not sure if we can land the features in this release), or it means, some parts of the features / requirements are not clear enough. Therefore, at that time, it's easier to collect all what we have confidence to land from Bugzilla queries(with feature-b2g:version#+) for the product team to communicate externally. That could be very detail for product team. So, of course, product team(or anyone who needs to communicate about this) may still have a simple version of agreed feature sets, that they can discuss with partners.

• Feature-b2g means what we plan to land in a release, and blocking-b2g means issues that blocks the release. So, in the ideal situation, we are expecting the number of feature-b2g:version#+ bugs to be zero at feature-landing milestone, and the number of blocking-b2g:version#+ bugs to be zero at feature-complete milestone.

• We can start to have product management team, engineering project management team, engineering managers and technical leads to have the access to nominate the flag, and let's see how it goes. Then, we can improve in the future.

Statistics for feature-b2g:2.2+

304 Total; 0 Open (0%); 180 Resolved (59.21%); 124 Verified (40.79%);