From Fedora Project Wiki

(create template for another shared section of the blocker/FE processes)
 
(tweak a bit for genericism)
Line 2: Line 2:
== Reviewing {{{type|$TYPE}}} bugs ==
== Reviewing {{{type|$TYPE}}} bugs ==


Proposed {{{type|$TYPE}}}s are reviewed and either ''accepted'' or ''rejected'' as {{{type|$TYPE}}}s in collaboration between three stakeholder groups: [[QA]], [[Development]] and [[ReleaseEngineering]]. This is mostly done during weekly meetings for the express purpose of reviewing {{{type|$TYPE}}} bugs: the procedure followed during these meetings is documented [[QA:SOP_{{{typecamel|$TYPECAMEL}}}_Bug_Meeting|here]]. {{{typecamel|$TYPECAMEL}}} review meetings usually occur every Wednesday during release periods, but special review meetings can be scheduled at other times when necessary. {{{typecamel|$TYPECAMEL}}} review meetings are public, and reporters who propose a bug as a {{{type|$TYPE}}} are allowed and indeed encouraged to attend the meeting where it is reviewed.  
Proposed {{{type|$TYPE}}}s are reviewed and either ''accepted'' or ''rejected'' as {{{type|$TYPE}}}s in collaboration between three stakeholder groups: [[QA]], [[Development]] and [[ReleaseEngineering]]. This is mostly done during weekly meetings for the express purpose of reviewing blocker and freeze exception bugs: the procedure followed during these meetings is documented [[QA:SOP_Blocker_Bug_Meeting|here]]. {{{typecamel|$TYPECAMEL}}} review meetings usually occur every Wednesday during release periods, but special review meetings can be scheduled at other times when necessary. {{{typecamel|$TYPECAMEL}}} review meetings are public, and reporters who propose a bug as a {{{type|$TYPE}}} are allowed and indeed encouraged to attend the meeting where it is reviewed.  


When appropriate, proposed {{{type|$TYPE}}}s may also be reviewed between meetings by Bugzilla comment discussion, or during the [[Go_No_Go_Meeting|''engineering readiness meeting'']] (also known as a ''go/no-go meeting'') which is convened to decide whether a release candidate should be approved as a final release. In these cases, consensus between the three stakeholder groups should still be reached in order to accept or reject a bug as a {{{type|$TYPE}}}. However, review should not be done as part of [[QA/Meetings|QA meetings]]. If {{{type|$TYPE}}} review is required or desirable at the time of a QA meeting, a proper {{{type|$TYPE}}} bug review meeting should be convened immediately following the QA meeting. Bugs which are rejected as {{{type|$TYPE}}}s can be considered for the [[QA:SOP_freeze_exception_bug_process|freeze exception bug process]].
When appropriate, proposed {{{type|$TYPE}}}s may also be reviewed between meetings by Bugzilla comment discussion, or during the [[Go_No_Go_Meeting|''engineering readiness meeting'']] (also known as a ''go/no-go meeting'') which is convened to decide whether a release candidate should be approved as a final release. In these cases, consensus between the three stakeholder groups should still be reached in order to accept or reject a bug as a {{{type|$TYPE}}}. However, review should not be done as part of [[QA/Meetings|QA meetings]]. If {{{type|$TYPE}}} review is required or desirable at the time of a QA meeting, a proper {{{type|$TYPE}}} bug review meeting should be convened immediately following the QA meeting. Bugs which are rejected as {{{type|$TYPE}}}s can be considered for the [[QA:SOP_freeze_exception_bug_process|freeze exception bug process]].

Revision as of 20:14, 24 September 2014

Template documentation [edit]

This documentation is transcluded from Template:Blocker freeze exception reviewing/doc. It will not be transcluded on pages that use this template.
This template is used to share very similar content between the QA:SOP_blocker_bug_process and the QA:SOP_freeze_exception_bug_process, for efficiency and consistency.

Reviewing $TYPE bugs

Proposed $TYPEs are reviewed and either accepted or rejected as $TYPEs in collaboration between three stakeholder groups: QA, Development and ReleaseEngineering. This is mostly done during weekly meetings for the express purpose of reviewing blocker and freeze exception bugs: the procedure followed during these meetings is documented here. $TYPECAMEL review meetings usually occur every Wednesday during release periods, but special review meetings can be scheduled at other times when necessary. $TYPECAMEL review meetings are public, and reporters who propose a bug as a $TYPE are allowed and indeed encouraged to attend the meeting where it is reviewed.

When appropriate, proposed $TYPEs may also be reviewed between meetings by Bugzilla comment discussion, or during the engineering readiness meeting (also known as a go/no-go meeting) which is convened to decide whether a release candidate should be approved as a final release. In these cases, consensus between the three stakeholder groups should still be reached in order to accept or reject a bug as a $TYPE. However, review should not be done as part of QA meetings. If $TYPE review is required or desirable at the time of a QA meeting, a proper $TYPE bug review meeting should be convened immediately following the QA meeting. Bugs which are rejected as $TYPEs can be considered for the freeze exception bug process.

Bugs that are accepted as $TYPEs for the relevant release will be marked with the Whiteboard field Accepted$TYPECAMEL. Bugs which are rejected as $TYPEs will be updated to no longer block the relevant tracker bug, and have the Rejected$TYPECAMEL Whiteboard field added so that if they are proposed as $TYPEs again, it is clear they have already been considered and rejected. Therefore, a bug which has been proposed but not accepted or rejected can be identified by the lack of a relevant Whiteboard field. All changes to $TYPE status should also be documented with a comment. The comment should explain the rationale behind the decision and should link to the summary or logs of the meeting at which the decision was made.