Use issues to track NB comments in response to ballots.
Rules:
- Most meeting discussion goes on the wiki, not the GitHub issue.
- GitHub issue comments: When a group has discussed a paper or NB comment, that group’s chair adds a comment to the corresponding GitHub issue reading something like: “LEWG in Belfast: Needs revision.” or “EWG in Belfast: Approved for C++20.” or “SG99 in Belfast: Recommend to reject.” Adding a link to the wiki page is appreciated. As per ISO guidance, do not quote discussion details. Quoting numeric poll results is far less important than clearly stating the net outcome.
- GitHub issue labels: When your group is done with an issue, de-assign your group’s label and, if it was not rejected for further progress, assign the label(s) of the next group(s) to look at the paper. (SGs never reject, they always progress.) If a paper needs revision and then needs to come back to your group, leave your group's label. In short, every open issue should have at least one group label.
- GitHub issue milestones: When your group is done with an issue, feel free to delete the milestone so that "label:group milestone:2019-11" actually shows the issues remaining on the group's plate for that meeting. When your group asks for revisions, assigning the "needs-revision" label is also fine.
- GitHub issue closing: If an issue was rejected for good, close the issue. Do not change any labels, so that we can discover which group rejected the proposal.