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.
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 Monday - immediately after the QA meeting - so long as there is at least one proposed blocker, but special review meetings can be scheduled at other times when necessary. They are always announced to the test-announce mailing list, which is CC'ed to devel. The $TYPE 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.