Currently the triage guidelines say:
"The priority of stalled bugs should be ‘–’ but other keywords may apply to them."
which is a little bit surprising depending on your point of view.

As an example: if we have a P1 sec bug which gets stalled. Why should it loose it's P1 marking (for sec bugs mostly based on the sec level rating) "just" because it's stalled for now? It's rather unlikely that when new information arrives the sec-rating of the bug has changed and therefore the priority needs to change.

On the other hand I see it as a possible advantage if resetting the priority results in stalled bugs to get triaged again after new information arrives.

Maybe another option would be to leave the priority as is when adding the stalled keyword. But if new information arrives removed the stalled keyword and reset the priority at the same time to enable/trigger re-triaging.

Triage Priorities and Bug Types

Documentation says "New" bugs, queries contain "Unconfirmed" bugs.

Make this consistent.

RelMan and product management decide if the feature will be enabled in Nightly, then:

• The patch to flip the pref on should be attached to the "Make Tabby Cats the new default tab experience" bug

This explanation does not say that what will be done by RelMan or product management when they decide the feature can be enabled in Nightly and/or Beta/Release.

Does a developer who works on implementing the feature should file a bug to enable the feature when he/she wants to enable it in some channels and does it become additional review request for RelMan and product management?

Or, after QA moves the bug which implemented the feature behind the pref to VERIFIED, does that mean that RelMan and product management decide the feature can be enabled in Nightly?

What's the reasoning behind this requirement?

• Any bug controlled by the behind-pref flag must be added to the Firefox Feature Trello board

The purpose of the Firefox Trello board is to track significant changes/impacts across the delivery of the product. While many of these significant features have a pref process involved. Not every feature that lands behind a pref is significant enough to warrant this level of exposure/tracking.

I'd ask that we punt this requirement out of the policy for now and re-assess once folks have adopted the process. That way we'll have data around what/how many cards we're talking about adding and what value it would bring to the Firefox Trello.

https://bugzilla.mozilla.org/show_bug.cgi?id=1461492 requests a 'regressed by' field.

Just wondering how this process would work when a feature is enabled by default in Nightly but set to auto-disable in Beta/Release? The Layout team commonly uses this tactic to test new features in Nightly and gather feedback.

When the feature is ready they then land a bug that removes the auto-disable and let's the feature ride the trains pref'd ON by default.

Example; Shapes outside
layout.css.shape-outside.enabled
Bug to enable in Nightly only (https://bugzilla.mozilla.org/show_bug.cgi?id=1353631)
Bug filed to remove auto-disable in Beta and Release (https://bugzilla.mozilla.org/show_bug.cgi?id=1457297)

See https://github.com/mozilla/release-mgmt-projects/issues/153

• If you back out a commit that causes a regression you don't need to mark the related bug as causing a regression
• If you see a commit that has caused a regression 'in the wild' then you should mark the related bugs
• If you don't know what caused a regression in the field, update the regression bug with the regression and regressionwindow-wanted keywords, and add a list of the likely bugs as a comment or see also. Set a needinfo for the triage owner(s) of the suspect bug(s) to investigate

At the moment, behind-pref is set up as a simple flag. This presumes that features will ride trains, but we may want to enable features in Nightly for a number of releases, but not turn them on in Beta or Release (see #3).

Using a status flag (with multiple values) allows us to specify where a feature is active. This flag would be set on the bug for the feature (if there's a single feature) or the [meta] bug for the whole feature.

One set of values to use could be:

---: not a feature that should be controlled by a pref
?: is this a feature that should be controlled by a pref
planned: this is a feature that should be controlled by a pref, but code has not landed yet (the value of target milestone on the bug would be future)
in-progress: this is a feature that should be controlled by a pref, code has landed but the feature should not be enabled
nightly: the feature should be enabled in nightly
beta: the feature should be enabled in nightly and beta
release: the feature should be enabled in nightly, beta, and release
esr: the feature should be enabled in in nightly, beta, release and esr
inactive: the feature has been disabled in all version

I don't want to have a flag per numeric version of this flag because it's a version management headache

I'm confused by the feature-flags policy on a couple of points:

• Myself and other engineers have always been told to set qe-verify+ to request QE to verify a bug. qe-verify? is a "this might need verification, give us details". QE would then come along to a qe-verify+ bug and mark it as verified when complete. This appears to match the original intent.
• The policy seems to imply that all the work for initial landing of, and then enabling the pref, is done in one bug. We generally land only one set of patches per bug, so this would be in conflict.

I would have expected something like:

• Meta bug for the work, which will end up enabling the pref. This would have the behind-pref+ flag set.
• Individual bug(s) blocking the meta that implement the new feature & fixing issues as they are found. One or more of these bugs would be marked qe-verify+ and QE would then verify them.
• Once the work is "completed", maybe some form of final verification option, or verify after the pref turn on is actually landed.
• The meta bug then gets the patch to enable the pref, and lands as normal.

The main triage doc promises some information on GitHub practices. But there is no link, PR, or open issue (well, there is now).

I'm mostly interested in the equivalent queries for bugs-needing-triage in GitHub. I don't think the query language for issues is rich enough to translate the Bugzilla queries, and suspect some additional label may be needed.

As of January 1 2019, Mozilla requires that all GitHub projects include this CODE_OF_CONDUCT.md file in the project root. The file has two parts:

1. Required Text - All text under the headings Community Participation Guidelines and How to Report, are required, and should not be altered.
2. Optional Text - The Project Specific Etiquette heading provides a space to speak more specifically about ways people can work effectively and inclusively together. Some examples of those can be found on the Firefox Debugger project, and Common Voice. (The optional part is commented out in the raw template file, and will not be visible until you modify and uncomment that part.)

If you have any questions about this file, or Code of Conduct policies and procedures, please see Mozilla-GitHub-Standards or email [email protected].

(Message COC001)

This is similar in spirit to #2: we have occasionally had features that are not enabled on any channel, but are pref-controlled, so that brave users can flip the pref and provide feedback. Or perhaps developers would like to incrementally land features that are known not to work, but it makes work on the feature more convenient: Nightlies can be used for testing, and the patches can be reviewed incrementally without building a huge patch stack. Pieces of Quantum DOM were landed under this model, and I believe some bits of WebRender and Stylo were as well.

What would the policy require in such cases? Would the process need to be followed for flipping the feature on by default in Nightly, or just when the feature is deemed ready to ride the train from Nightly to Beta?