Skip to content

Latest commit

 

History

History
73 lines (53 loc) · 6.23 KB

bugzilla_guidelines.md

File metadata and controls

73 lines (53 loc) · 6.23 KB

Guidelines for the https://issues.isocpp.org/ Bugzilla

Anyone should feel free to file feature requests or design-scale bug reports in https://issues.isocpp.org/, even if you're not on the C++ committee. File wording-level bug reports according to the instructions in the LWG issues list instead. If the issue isn't given a status within a couple days, ping the [email protected] or std-proposals mailing list. We won't necessarily discuss issues without wording or a paper, but they can help gauge interest. You can use the issue tracker to point out questions that need discussion, but please try to keep the discussion itself on a mailing list.

Shortly after each mailing, we update or file an issue on https://issues.isocpp.org/ for each paper.

Before each meeting, we need to find presenters for each paper. We track the presenter by assigning the bug to them. If you're assigned a bug but won't be at the next C++ meeting, it's your responsibility to find someone to present it.

We also need to collect issues into the C++ wiki. The queries below can help with that.

During a committee-meeting session, the person taking notes should record the gist of what people say into the wiki. The person running the meeting should collect the URL of the notes, and any action items and straw polls into a comment on the issue. It can be helpful to project the comment containing the straw polls while you're taking them, since that makes sure everyone remembers the wording.

Useful queries

Status meanings

Status Meaning
UNCONFIRMED/CONFIRMED new, uncategorized bugs
NEEDS_DISCUSSION LEWG should discuss this, but it's not a concrete proposal.
NEEDS_WORDING Someone needs to propose wording that would fix the issue before LEWG discusses it.
NEEDS_PAPER Someone needs to write a paper about this issue before LEWG discusses it.
SG_REVIEW There's a concrete proposal, and the SG idenfied by a keyword should review the design.
DESIGN_REVIEW There's a concrete proposal, and the LEWG should review the design.
WORDING_REVIEW LEWG is happy with the design of the proposal, and LWG should review the wording.
READY LWG is happy with the wording.
ADOPTED This got into the standard or became an official policy somewhere.
CLOSED This didn't get into the standard.

An issue will go through these roughly in order, although any issue created for a paper will skip straight to DESIGN_REVIEW.

Keyword meanings

The keywords are described at https://issues.isocpp.org/describekeywords.cgi and summarized here.

needs_X_input, where X is the name of another WG or SG, means that the X group needs to have a chance to weigh in on the proposal before it's proposed to a plenary session. The X group doesn't necessarily need to get to weigh in before LEWG or LWG discusses and/or approves the paper, although getting their input early may save time.

sgN_Name with a status of SG_REVIEW or earlier means that SG N owns the issue's domain. It will take the first look and then forward the issue to the LEWG.

needs_updated_proposal means the issue has been discussed and won't be discussed again until a new paper or wording is published that responds to feedback. This is used at the SG_REVIEW, DESIGN_REVIEW and WORDING_REVIEW stages.

postponed means everything is set to discuss the proposal, except that we've decided for some reason to wait until the next meeting to do so. For example, maybe the author isn't present or we don't have time.

Polls

We're using the Bugzilla flags system to run polls for tentative status changes.

Flag Proposed transition
tentative_good_design DESIGN_REVIEW -> WORDING_REVIEW
tentative_ready WORDING_REVIEW -> READY; LWG isn't using this poll
tentative_nad Any -> CLOSED

To start a poll, add a + mark to a flag, and announce the poll on [email protected]. If the poll gets 5 + votes and no - votes, it passes, and will be listed on the LEWG consent agenda at the next meeting.