Bugzilla:RFC Process

This page documents a new (and experimental) process by which work on the Bugzilla project can be managed. It is inspired by similar RFC processes among other open source projects, but is also unique to Bugzilla.

1. A bug is filed on bugzilla.mozilla.org, in the Bugzilla product (and appropriate component) describing a single feature using the User Story field.
2. Interested parties comment on the bug. Comments and needinfo? should be used to raise concerns, ask for clarification or provide alternate ways of achieving the desired outcome.
3. The reporter should update the User Story as they deem appropriate.
4. Offtopic comments are tagged as such, this includes "me too!" posts and the like
5. After a suitable period (a week or two) the approval flag should be set to ?, at which time a Bugzilla approver will decide if this is a feature that would be accepted, if implemented per the description in the user story field. The approval flag is set to either + or -.
6. The approver can set a- and leave the bug open, which means that the requirements/description need more work, or can set a- and close the bug as WONTFIX. RESOLVED WONTFIX is an indication that the project refuses the feature and will not accept it.
7. If the approver sets a+, the bug stays open until the feature is implemented, and then it can be resolved as FIXED.

dkl comments:

1. Set a rfc keyword on the bug for easy searching when it is filed or afterwards during a bug triage.
   1. maybe just put [RFC] in the summary? thoughts?
2. We should have a rfc-approval flag separate from the old approval flag currently used for checkins.
3. question: Should a separate bug be filed for the actual work or sufficient to just continue using the rfc bug?

dylan replies:

1. Okay, [RFC] instead of keyword sounds reasonable. The keyword can be removed.
2. agree on rfc-approval, I will add that the bugzilla product
3. as for separate bugs -- I think we can leave that optional, a recommendation but not required?