Bugzilla:RFC Process: Difference between revisions

Latest revision as of 01:19, 5 March 2018

Delete this page

@@ Line 1: / Line 1: @@
-This page documents a new (and experimental) process by which work on the Bugzilla project
+Delete this page
-can be managed. It is inspired by similar RFC processes among other open source projects, but
-is also unique to Bugzilla.
-# A bug is filed on bugzilla.mozilla.org, in the Bugzilla product (and appropriate component) describing a single feature using the User Story field.
-# 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.
-# The reporter should update the User Story as they deem appropriate.
-# Offtopic comments are tagged as such, this includes "me too!" posts and the like
-# 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 -.
-# 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.
-# If the approver sets a+, the bug stays open until the feature is implemented, and then it can be resolved as FIXED.
-dkl comments:
-# Set a rfc keyword on the bug for easy searching when it is filed or afterwards during a bug triage.
-## maybe just put [RFC] in the summary? thoughts?
-# We should have a rfc-approval flag separate from the old approval flag currently used for checkins.
-# question: Should a separate bug be filed for the actual work or sufficient to just continue using the rfc bug?

Bugzilla:RFC Process: Difference between revisions

Latest revision as of 01:19, 5 March 2018

Navigation menu

Search