Hello, We control enabling many features and changes to Firefox using preferences.
Program and Release management as well as PI need a better view of this. We've written a new policy which you can read on our nascent bug-handling mini-site: https://github.com/mozilla/bug-handling/blob/master/policy/feature-flags.md To summarize, when you are releasing a feature that "rides behind a flag", on the bug for the feature: * set the behind-pref flag to + * set the qa-verify flag to ? * note the bug in the Firefox Feature Trello board We expect qa-verify to be set to + before enabling prefs on features. We'll be going over this at two upcoming meetings, with Reese's and JoeH's teams. There are two, known open questions to resolve on the policy: * Features developed over multiple releases with individual patches not verifiable by external testing (passing unit tests, but not integration tests) such as Hello and WebRTC * Features are often turned on in Nightly, ignoring prefs using compiler directives, and kept off in Beta and Release. Is this the right thing to do, or should we be flipping prefs from on to off when going from Nightly to Beta and forwards? The bug handling documentation is a GitHub repo to enable web publishing, please follow up there, using Issues and PRs, rather than to this email. I want to acknowledge and thank: Liz Henry, Ritu Kothari, Resse Morris, Erin Lancaster, Ryan VM, Thomas Elin, and Adam Roach for their comments and feedback on this. Thank you! -- Emma Humphries _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
