Doc No: ISO/IEC JTC1/SC22/WG21/SD-4
Date: 2023-07-01
Project: JTC1.22.32 
Reply To: Herb Sutter
          Convener, SC22/WG21
          Microsoft Corp. 
          1 Microsoft Way Redmond WA USA 98052 
          Email: hsutter@microsoft.com

WG21 Practices and Procedures: The "How We Work" Cheat Sheet

Purpose and audience
Code of conduct
Consensus
Proposals and papers
Subgroup responsibility and polls
Closing plenary session responsibility and polls
Technical specifications
Working draft handling
Ballots and comments
How to report a potential technical concern, at any level of severity
Escalating a serious "cannot live with" objection, or significant new information
Other topics

Purpose and audience

This document contains important information that applies to all active WG21 participants, meaning accredited national body experts and especially those who attend our face-to-face meetings. Although this document is also useful to new participants to get up to speed, the material herein covers important procedures and situations that arise regularly in our meetings, email lists, formal ballots, and other participation, and everyone who participates in WG21 is expected to be familiar with this information.

This document summarizes some of WG21's current practices and procedures, in addition to the requirements of the ISO/IEC Directives and JTC 1 Supplement available at the ISO Directives and Policies page.

This document will call out with "ISO" or similar where states clear rules, and otherwise documents our WG21-specific practices for implementing the ISO guidance and organizing our meetings

Note: This document does not repeat the basic material already covered in the following:

The committee: Our organization, including the names of all of the officers and subgroup chairs.
Meetings and participation: How WG21 meetings and teleconferences work; how to get involved and participate at face-to-face meetings; and what the committee email lists (aka "reflectors") are and who can join them.
How to submit a proposal: How to get initial feedback to explore an idea and craft a proposal; whether an implementation is required; what ISO intellectual property rules to keep in mind; and how to present a proposal at a face-to-face meeting.
The life of an ISO proposal: From 'cool idea' to 'international standard'
SD-3: Study group organizational information.
Meeting wikis: Contains meeting-specific wikis that contain all the meeting's agendas, detailed schedules, and discussion notes, as well as a meeting-nonspecific wiki containing timeless information such as how to join the mailing lists and manage your own list subscriptions.

Code of Conduct

We follow the ISO Code of Ethics and Conduct (March 2023) and IEC Code of Conduct -- together, the Code. (See also: ISO Code of Ethics and Conduct - Implementation (March 2023))

To report a concern about a potential Code of Conduct violation, follow the steps in the ISO document "Guidance and Process For Addressing Misconduct and Breaches of the Code of Conduct."

At the start of every meeting, we display the following ISO/IEC JTC 1 slide:

Key ISO and IEC Messages on Ethics and Respect for the Attention of JTC 1 Committees

Escalate & resolve disputes

Identify & escalate disputes in a timely manner for rapid resolution

Uphold the agreed dispute resolution processes

Behave ethically

Act in good faith & with due care & diligence

Avoid collusive or anticompetitive behavior

Promote a culture of fair & ethical behavior

Respect others in meetings

Be professional

Respect others & their opinions

Accept group decisions

Ensure that all views are heard & understood

Be tolerant of different cultural practices

Avoid metaphors, irony & be aware that jokes and humor may not translate

Respect others on social media

Be respectful & not abusive

Don’t say anything that you might regret or don’t want your friends, family or colleagues to see

Consensus

Consensus is defined as follows in the ISO/IEC Guide 2:2004, as quoted in the ISO/IEC Directives:

consensus: General agreement, characterized by the absence of sustained opposition to substantial issues by any important part of the concerned interests and by a process that involves seeking to take into account the views of all parties concerned and to reconcile any conflicting arguments.

NOTE Consensus need not imply unanimity.

Importantly, note what consensus is not:

Consensus is not a tyranny of the majority. The majority cannot just say "we have enough votes" and refuse to listen to the concerns of the minority. The ISO Code of Conduct requires the majority to 'ensure that the views of all are heard and understood.'
Consensus is not a tyranny of the minority. The minority, once they have had opportunity to be heard, cannot just say "we still object so you can't proceed" and refuse to accept the consensus of the majority to pursue a different direction. The ISO Code of Conduct requires the minority to 'accept group decisions.'
Consensus does not preclude judicious escalation ("throwing an exception"). In rare cases, where the minority still believe that a serious error of judgment is being made, escalation can be appropriate in accord with the Escalation procedures covered later in this document; note that the key words are "rare" (not regular), "still" (it was raised before), and "serious." The ISO Code of Conduct encourages 'escalating disputes in a timely manner' with an 'agreed dispute resolution processes.' Escalation can become inappropriate in two ways: (a) when a serious objection is not raised "in a timely manner," such as being withheld until plenary session or formal ballot time rather than being raised consistently throughout the process starting as early as possible; or (b) when a participant or national body regularly uses the escalation process to express a pattern of strong disagreement on topic after topic, which erodes their credibility and is not the purpose of the escalation resolution process (like exception handling, escalation handling is for hard errors, and is not designed for expressing less serious conditions or for what should be ordinary control flow).

Proposals and papers

If a proposal doesn't have a paper, it doesn't exist. Any significant proposal requires a paper, including every proposal that is a design addition or change.

Note: A paper is not needed for minor issues that are about improving standardese wording to implement the decided design. Those do not affect the design itself, and can be put on issues lists only.

High-quality proposal papers. A proposal paper is much more than an "idea" that is written down. A good proposal paper should:

Be example-based: Demonstrate motivating examples of how the code we have to write today is problematic and needs improvement. Show specific examples of how the proposed feature is intended to be used, including how those motivating examples would look if we had the new proposed feature.
Be principle-based: Articulate the design principles for the proposed solution. Show how the proposed solution fits with the rest of the language’s principles and design philosophy (note: explicitly not with the language’s quirks). Ideally include citations of principles/philosophy articulated in The Design and Evolution of C++ (D&E).
Show design alternatives considered: along with concrete examples showing why they were not pursued. The author should demonstrate that they have considered the problem reasonably thoroughly, and are not just running with the first idea that occurred to them.

These three points are the main things that make the difference between "someone's cool idea" (which may be interesting but is procedurally unuseful) and "a real proposal" (that can be seriously evaluated and progressed).

Note: For additional details about writing proposals, see also:

How to submit a proposal: How to get initial feedback to explore an idea and craft a proposal; whether an implementation is required; what ISO intellectual property rules to keep in mind; and how to present a proposal at a face-to-face meeting.

The life of an ISO proposal: From 'cool idea' to 'international standard'

On-time papers. All papers to be considered at a meeting must be received before that meeting's pre-meeting mailing deadline. The agenda for each meeting includes all papers in mailings since the previous meeting (from the post-meeting mailing of the previous meeting to the pre-meeting mailing of this meeting, inclusive), as well as possibly selected earlier papers that were not sufficiently addressed at a previous meeting in the judgment of the subgroup chair. Requiring papers to be received on time ensures that national body experts have sufficient time to consider the proposals in advance and arrive at the meeting prepared to participate in a productive discussion.

Late papers. A proposal that does not have an on-time paper published since the previous meeting is not actionable and will not be considered during official meeting time; the author is encouraged to submit a revision as an on-time paper for a future meeting. (Note: Followup papers to an on-time paper, such as late or in-meeting rebuttal/elaboration/update papers to an on-time paper, can of course be considered; they are part of considering the on-time paper.)

Corollary: If a topic does not have at least one on-time paper, the whole topic is not on the meeting agenda. Sticking to the published agenda, including the topics of papers published in the pre-meeting mailing, is essential to ensure all stakeholders have full opportunity to be present so that we have orderly progress. Per ISO rules, if a WG meeting were to take action on a topic that was not mentioned on the agenda (including in the topics of on-time papers), a national body could formally escalate an objection in SC 22 and JTC 1 to the entire WG meeting on the grounds that the national body had insufficient notice so as to be able to send any (or the right) participants to participate in that technical discussion topic.

Prepared presenters. A proposal that does not have one of its authors, or another qualified and prepared presenter, to present it is not actionable and will not be considered during official meeting time. There are several reasons we insist a real proposer be present:

The purpose of a presentation is for a person who is an expert in the paper's domain (including in constraints as well as design alternatives considered) to educate a group of general C++ experts. This requires that the presenter be qualified to answer detailed questions about design constraints in the problem domain, design alternatives considered and how they worked out, and so forth at a level that the group as a whole does not already know.
A major outcome of the subgroup discussion is to give feedback and direction to the author regarding how to improve their proposal to create an updated revision for the next meeting. The presenter must be someone who is invested in the proposal and will ensure feedback will be used, which means the presenter will personally produce a new revision of the paper based on feedback or else will communicate feedback to the author to do so. Otherwise, the group's time to generate the feedback is meaningless.

Note: In the past, sometimes the subgroup chair has tried to help find a presenter. This is not useful and is actively discouraged, because in practice it results in a presenter who is at best semi-familiar with the topic and who is not personally invested in working on the paper.

Delay vs. bird in the hand. We cannot act on ideas without papers, and we do not significantly delay progress on concrete proposals in order to wait for alternative proposals we might get in the future. If we have an active proposal that is making progress, and an objection is raised that a different competing approach would be better but that other approach does not yet have a paper, the EWG or LEWG subgroup chair may elect to delay the progress of the active proposal by one meeting to give the objector(s) opportunity to bring an on-time proposal paper. Otherwise, if a competing alternative does not have a paper, it does not exist and will not block progress of a proposal that we do have before us.

Note: At early discussion phases, subgroup chairs have discretion to allow limited exploration of alternatives to an active proposal to decide whether a second paper is warranted, or to discuss broader prerequisite topics that are exposed by a paper under discussion.

Using the 1-2 year TS lag effectively. If a proposal has consensus to be in a TS, but does not yet have consensus to be in the IS, that means its progress is delayed by approximately 1-2 years; that is the time it takes to publish the TS, and then wait for usually one year before the TS is proposed to be merged into the IS with any changes based on the TS experience. That window is a limited "grace period" wherein any participants who prefer a different approach than the one in that proposal should be actively working on developing their own alternative proposals. Do not wait, thinking that two years is a long time; it isn't. If by the time the TS is ready to be considered for merging into the IS we do not have alternative proposals actively progressing, the default action to is to move forward with the proposal we have, we will not wait indefinitely for something better.

Subgroup responsibility and polls

Subgroup chairs. Subgroup chairs are appointed by the convener, and are selected to match the current needs of the subgroup. They have no fixed term.

Subgroup discussion. Discussion is orderly. Those who wish to speak raise their hands and are recognized by the chair. The chair is encouraged to keep a visible list when multiple people are in the queue.

Subgroup polls. In subgroup polls, each person in the room can cast one vote. The subgroup chair may take any polls they choose. Typical kinds of polls include the following:

Unanimous consent, where if there are no objections then it is known that everyone is either in favor or neutral, without having to count hands. This is typically used to save time when there may already be broad agreement.
"5-way" polls, where the choices are Strongly Favor, Weakly Favor, Neutral, Weakly Against, and Strongly Against.
Multiple polls, where multiple alternatives are polled (e.g., by 5-way poll) in order to see which has most consensus. This is encouraged so as not to lose the option that has the most consensus because of the order in which polls are taken.
Approval polls, where there is a list of alternatives and the chair takes a single show of hands for those 'not opposed' to each alternative. Typically there is then a runoff approval poll among the most popular options. This is typically used to bikeshed naming.

Notes:

Subgroup polls, especially in design subgroups, should favor progress. A proposal normally advances if there are more than twice as many in favor of a proposal as against, after discussion of the concerns of those voting against and possibly a re-poll to see if opinions have improved. This is true even if a large number vote Neutral, though it can be concerning if a majority of all those voting vote Neutral.
Not everyone in the room needs to vote (even Neutral). Not everyone is interested in every proposal, and participants who are not familiar with the material of a particular poll (did not read the paper and/or were not closely paying attention to the discussion) typically do not vote on that poll.
Anyone voting Against, especially Strongly Against, may be asked for their reasons by the chair. They should be prepared to articulate their rationale, including either what change(s) would address their concern and change their position, or else that they are opposed to pursuing the proposal in any form and no change would change their position.

Direction group. The direction group is a small by-invitation group of experienced participants who are asked to recommend priorities for WG21. Currently, that group consists of: Howard Hinnant, Roger Orr, Bjarne Stroustrup, Daveed Vandevoorde, and Michael Wong. Their charter includes setting forth a group opinion on:

Evolution direction (language and library): This includes both language and library topics, and includes both proposals in hand and proposals we do not have but should solicit. The direction group maintains a list of the proposals it considers the most important for the next version of C++ or to otherwise make progress such as in a TS, and the design group chairs use that that list to prioritize work at meetings. Typically, work on other topics will occur after there's nothing further left to do at this meeting to advance the listed items.
Providing an opinion on any specific proposal: This includes whether the proposal should be pursued or not, and if pursued any changes that should be considered. Design group participants are strongly encouraged to give weight to an opinion that the design group feel strongly enough about to suggest.

Study groups. Study groups (SGs) own "incubating" to produce an initial proposal that can then enter the usual design group processing. An SG is formed by the convener at the recommendation of a design subgroup chair when there appears to be broad interest in a topic, there is not yet a unified initial proposal to bring to the design subgroup (typically because proposals are immature, incomplete, and/or competing), and there is a strong candidate to chair the SG to ensure it operates productively.

Note: For additional information, see SD-3: Study group organizational information.

Design subgroups. The design subgroups (EWG and LEWG) own selecting and recommending feature designs and ship vehicles (TS or IS). Notes:

Discussion should be constructive, help achieve a broad understanding of the proposal within the design subgroup, and to result in polls that give the proposal author meaningful and actionable feedback on whether and how to improve the proposal. Both positive and negative comments are welcome, but should always be constructive and respectful.
If anyone has a concern that a particular new proposal should not take up extended subgroup time (e.g., is not well thought out, is in a direction that previously did not get interest or consensus, or is otherwise unlikely to progress in its current form), they should share their concern privately and in advance with the subgroup chair. The subgroup chair may choose (based on such requests or just on their own judgment) to expedite the proposal's initial handling to make sure a representative overview is heard but then determine whether it has enough subgroup interest before spending extended time exploring the details; for example, the chair might time-box initial discussion and then poll whether the subgroup is interested in discussing the proposal's details further.
The proposal author is expected to participate in the design subgroup to present the proposal, answer questions, participate in design discussion, and implement any changes directed by the group, typically for subsequent revisions of the proposal to be considered at the next meeting. In rare cases, if the proposal author chooses not to implement a change directed by the group, the author should be prepared to defend that decision and bring new information to the next meeting as part of the paper revision; proposals that do not implement design subgroup direction harm their own chances of gaining consensus within the design group and/or in plenary.
When a proposal's design achieves a general consensus of the design subgroup, as determined by the subgroup chair, for its design and ship vehicle, it is forwarded to the specification subgroups. The proposal author is expected to work with the design subgroup chair and the specification subgroup chair to find a wording expert to help them draft high-quality standardese wording before the specification subgroup review begins.

Specification subgroups. The specification subgroups (CWG and LWG) own the recommendation of the "standardese" specification (aka "wording") that implements the intended design. Notes:

The proposal author is expected to be available in the specification subgroup to make specification changes.
If the specification subgroup has design questions or suggestions, those questions are referred back to the design group.
The proposal author is expected to participate in the specification subgroup to answer questions and implement specification changes directed by the group.
When a proposal's specification achieves a general consensus of the specification subgroup, as determined by the subgroup chair, that its specification correctly expresses the intended design, it is forwarded to the closing plenary (whole-WG21) session.

Notes:

The meeting's Straw Polls wiki page will be updated by 8:00pm local time the night before the closing plenary session to show all these polls (to be added in the main text by the specification subgroup chairs only — no one else should edit that page) and all final P- and N-numbered papers referred to in those polls (to be added as attachments to that page by their proposers).

For additional convenience, the specification subgroup chairs will endeavor to start filling in the Straw Polls wiki page on a best-effort basis during the week. However, this is not guaranteed, and anyone who wants the most current information should read the wiki notes of each specification subgroup to see current progress, including which items are planned to be brought forward to plenary. For example, on the CWG wiki, typically searching for "Ready for vote on Saturday" will show you all the items are they are approved.

Work prioritization at meetings. Subgroup chairs prioritize first papers that are related to one or more of the following: Direction priorities recommended in P0939; work the committee is aiming to include in the next IS; and work that can make plenary progress at this meeting. After that they get to things on a best-effort basis as time allows.

Closing plenary session responsibility and polls

Presentations. The main subgroup chairs present their progress for the week:

Design subgroup chairs present the proposals whose designs were approved at this meeting, including to solicit all present to express any serious design concerns that may not have been discovered in subgroups so that these can be known and addressed before extensive wording effort is invested. The list of approved designs will also be added to an update of the Proposal Designs Approved paper in the post-meeting mailing. (Note: This is a new procedure, doesn't yet exist. With each update, it will create a cumulative list of the proposal designs approved at each meeting.)
Specification subgroup chairs present the polls to be brought forward.

Plenary polls. In plenary polls, each person present whose nameis listed in the ISO LiveLink global directory can vote. The Convener may take any polls they choose; however, typically the most frequent polls are "3-way" polls where the choices are Favor, Against, and Neutral. Notes:

The default is to ask if there is objection to unanimous consent. (Unanimous consent means that all participant positions are either Favor or Neutral, and that none are Against). Most polls pass by unanimous consent.
If there is an objection to unanimous consent, the Convener takes a 3-way poll as described above. If there is significant opposition, the Convener will usually ask whether the Against votes are personal positions or national body positions, typically by asking the national body panel chairs who are present, or by taking a two-stage U.S. poll (one vote per INCITS company to determine the U.S. position, followed by one vote per national body to determine overall national consensus).

Closing plenary session. The WG21 closing plenary session owns approval of adding a proposal and its specification wording to a working draft (TS or IS). The plenary session's responsibility is to decide whether there is consensus, as determined by the Convener, to adopt each proposed change that is recommended by the design and specification subgroups. The plenary session does not actively change the design or entertain extended design discussion, which always happens in the design subgroups. However, the plenary session participants may ask questions like: "does this handle case X?" and "did you consider alternative Y?" For such questions, the meeting chair will ask the appropriate subgroup chair (who may invite comment from the proposal's author) to answer whether that item was considered and to summarize the result of the discussion and the reason for the decision of the subgroup.

Plenary session polls also include recommendations to ship a document for a formal ballot or for publication. If such a poll gets consensus, the document is considered to represent the consensus of WG21 for its current stage of development.

Technical specifications

A TS is an experimental branch. In ISO, a TS is for a feature that does not yet have consensus for an IS. A TS is a separately published "experimental branch" that can ship separately to gain experience — either with an experimental part of the design, or to get enough overall experience so that participants are comfortable that the overall design works as well as hoped. We usually do not put work into a TS unless WG21 likes the general direction the feature is exploring, and would entertain merging it into the IS in some form (possibly after significant further transformation) if it turns out to work out successfully; features we know we do not intend to put in the IS are not worth shipping in experimental form either.

Note: A good example is the Reflection TS. There, we knew from the outset that we intended to radically change the surface interface from a template metaprogramming style to a value style. The goal of the TS was to get feedback on the core reflection capability under the hood of that "skinnable" interface.

Note: The only exception so far is the Transactional Memory TS. In that case, WG21 was asked to take an existing industry specification and republish a refined version as an ISO TS without an expectation of merging it into the IS because the material was known to be experimental.

Proposal vs. TS: A TS is a shipped product, not just a proposal. Unlike a proposal paper (which is maintained by the author independently), a TS:

is owned by the committee;
is changed only as directed by full committee approval polls;
has higher quality wording requirements;
is shipped as an official ISO publication; and
unblocks early implementers and users.

TS vs. draft IS: A TS is an experimental product, not a draft-standard feature. Unlike a feature in a draft C++ standard, a TS:

allows us to unblock the progress mentioned in the previous paragraph even when there is not yet consensus on the design, when people and national bodies typically still have strong technical concerns but are temporarily willing to publish without making the changes suggested by those concerns in return for knowing the consensus gap will be addressed later based on TS experience;
is labeled by ISO as "non-normative" because conformance is not required and the contents are subject to change; and
asks implementations/users to give feedback to identify shortcomings and puts them on notice to expect breaking changes (they typically should not rely on the feature in production code).

Starting a new TS. We can initiate a new TS project once material (one or more related proposals) gets to the stage where the committee wants to pursue turning it into an initial TS working draft, and the subgroup chair has identified an appropriate project editor acceptable to the convener that the convener will appoint to maintain the draft. This is initiated by a plenary session poll to turn the document(s) into a new working draft and direct the convener to issue a New Project (aka New Work Item) ballot to request a new ISO project number for the TS; these two steps are done simultaneously in order to ensure we never have an open project without a working draft (the reverse is okay).

Note: The wording of the plenary session straw poll is as follows.

Move to direct the Convener to request a New Work Item for a Technical Specification on "C++ Extensions for [Topic]" and create a working draft with [PxxxxRnn "Title X" and PyyyyRmm "Title Y" and ...] as its initial content.

Listing specific goals. The TS should list known specific questions on which feedback is desired, including:

What are we hoping to learn through this TS?
What are the exit criteria (especially, the list of must-address controversial issues) before we can consider merging this TS into the IS?

A TS is not an open-ended fishing expedition. It starts with a specific design and aims at answering specific questions. To help potential users, the goals section should outline the extent to which the initial design is considered is considered "firm" (as opposed to a simple strawman outlining the problem space) and what questions the committee would like users to help answer. This should help users estimate the degree of risk incurred using an implementation and help implementers estimate the effort involved in an implementation (e.g., if understanding of "performance" is part of the desired results of a TS effort the implementation effort might differ from a TS goal related to "teachability").

Breaking changes. A major reason to put a feature in a TS is to permit taking further breaking changes before it is standardized. Once a feature is in an IS, it is essentially cast in stone and much more difficult to update with breaking changes. WG21 has never adopted a TS into the IS without significant change.

Merging TS to draft IS. When considering merging a TS into the draft IS, there are typically two sets of issues:

post-merge issues, where we have a consensus to merge the TS into the IS working draft and then addressing these issues afterwards; and
pre-merge issues, where we do not have a consensus to merge into the IS working draft until this specific set of issues is first addressed.

Post-merge issues are likely, but not guaranteed, to be addressed before the IS ships. Pre-merge issues are issues where many participants would "rather not have the feature in the IS at all than have it without those issues addressed." We encourage all participants to keep the second set as small as possible, for real make-or-break concerns only, so that we can merge a TS early to permit better "integration testing" as we refine it further in the full context of the IS, and permit other parts of the standard to adapt to the new feature. Issues that people and national bodies were willing to hold in abeyance with provisional resolutions for the TS are expected to have to be addressed, possibly pre-merge; however, people are encouraged not to rehash decisions that already had consensus when the TS was started unless new information has emerged.

TSes can fail or remain TSes. Some experiments don't work out, and sometimes a TS can fail or succeed only as a TS. For example, the Array TS was abandoned for lack of concensus, and the Transactional Memory TS was not integrated into the IS because it was not obvious that a sufficiently large part of the C++ community would benefit from it being in the IS rather than in a TS.

Working draft handling

Approving updated working drafts. In the opening plenary session of each meeting, we routinely adopt the updated working drafts generated after the previous meeting as described in the next paragraph. During the meeting, the wording for all new proposed changes is written against these adopted drafts as the meeting's baseline.

Approving changes to working drafts. In the closing plenary session of each meeting, we have a series of polls each asking to approve applying changes specified in a given wording paper or issues list entry to update a specific working draft.

Note: The wording of the plenary session straw poll is as follows.

Move to apply [paper or issue number(s)] to the [Topic] working draft.

Applying changes to working drafts. After the meeting, each project editor produces an updated candidate working draft that applies all the changes approved for that draft, and generates an editor's report summarizing those changes and any other comments that arose while applying and merging them. The updated draft typically appears in the post-meeting mailing, but no later than the pre-meeting mailing for the next meeting. Project editors may make editorial changes at any time, but may only make technical changes approved by plenary.

Sending drafts out for ballots. If a working draft is also ready to be sent out for ISO ballot, and there were changes approved to the draft, then the poll to direct the convener to send the document out for ballot also includes naming an editing committee to verify that all approved changes were applied correctly by the project editor before the document is transmitted for ballot.

Note: The wording of the plenary session straw poll is as follows.

Move to appoint an editing committee composed of [...] to approve the correctness of the [Topic] working draft as modified by the motions approved at this meeting, and to direct the Convener to transmit the approved updated working draft for [PDTS|CD|DIS|FDIS ballot or publication].

When the specification subgroups reviewed an updated draft with changes applied in situ. Occasionally, if the specification subgroups have already reviewed an entire new working draft paper with changes applied, rather than a change paper describing wording diffs, then the plenary polls are adjusted as follows:

To approve the change, instead of a poll to apply a paper to the working draft, we have a poll to approve the changes in the form already applied to the new working draft paper. (Note: For procedural simplicity, we still re-adopt the same working draft at the beginning of the next meeting as usual.)
To send the draft out for ballot, an editing committee is not needed since it has already been verified that changes were applied correctly.

Ballots and comments

National bodies and participation. All ISO JTC 1 / SC 22 "P" (Participating) national bodies can send accredited experts to participate in person at WG21 meetings and can vote on ballot documents. National bodies are expected to send experts to participate in person in WG21 if they want to affect the direction of the standard.

Note: Typically that means regularly sending representatives to attend WG21 face-to-face meetings. In the rare case that an NBs is an SC22 P-member but is unable to send representatives to attend WG21 meetings (typically due to severe economic hardship whereby they can participate by remote ballot review but not in person due to travel costs, or due to force majeure such as unexpected changes in governmental travel restrictions), they are still strongly encouraged to participate in WG21 email lists and raise concerns there instead of waiting for ballot comments.

Ballot purpose and structure. An ISO comment ballot is a request for national bodies (NBs) to provide specific feedback on the material that is in the balloted document. It has two components:

Vote for general approval/disapproval: Essentially, "do you want to see this work progress (possibly with changes), yes or no?" A Disapproval (No) vote should be used only to express that the national body does not want the work (TS or IS) to progress at all in any form — to block further progress on all parts of the work item.

Note: In the past, ISO used to have ballot resolution meetings (BRMs) where resolving key comments by a national body could turn a No into a Yes, and national bodies would report whether they changed their vote. We no longer have that procedure or any formal mechanism to change a vote after the ballot. Therefore, No should mean "No, we don't want this TS or IS at all," because sufficient No votes have that effect — most ballots fail if more than 1/3 of NBs vote No, so voting No only to try to give the NB's comments a higher priority is ineffective (we consider all NB feedback at all times, not just on ballots, and regardless of the Yes/No vote on a ballot) and counterproductive (could actually cause the whole project to fail).

Comments for specific feedback: Regardless of the approval/disapproval vote, most ballots can contain comments. All editorial and technical comments on the content of that document are in scope. A comment is expected to contain a proposed resolution with sufficient detail to be actionable; if more detail is required than fits easily in the comment form, referencing or attaching a paper is encouraged.

Note: Ballot comments are treated by ISO, and therefore by WG21, as national body positions. Confusion arises when a national body submits comments without first vetting that the national body as a whole supports all the comments. In the past, some national bodies have included all comments from their members without vetting, which leads to receiving comments that a majority of the national body's own members did not support, or that contradict each other. To aid orderly comment handling, national bodies are encouraged to vet that the comments they submit are indeed national positions.

Inappropriate ballot comments. Two specific kinds of comments are therefore not appropriate:

A ballot comment that requests adding an additional feature that is not already in the document is out of scope. New feature proposals are encouraged, but the correct way to bring them to WG21 is by presenting a proposal paper and working to build consensus to add the feature.
A ballot comment that requests a change that was already considered and decided otherwise at a WG21 meeting, and comes from a national body that was present at the meeting and had an opportunity to have their objections be heard and considered, is out of harmony with the ISO Code of Conduct's commitment to 'accept group decisions.' Once the WG has consensus to send a document for ballot, to repeat as an NB comment an objection that previously failed to carry the day is actually making, not a new technical objection, but an objection to the consensus of the WG.

Note: There are two exceptions:

If sufficient new information came to light since the last discussion that it is reasonable to believe enough people could change their opinions to affect the previous consensus. That information, of course, requires an on-time paper for the ballot resolution meeting, and ideally that paper would be available early and referenced directly in the ballot comment.

If the national body really strongly objects to a specific item so much that they are willing to vote No on progressing the whole TS or IS that it's in, and have informed the committee all along of the strength of their feeling (see "Escalation..." below). If WG21 were to ballot a document over those objections, they would know that a No With Comments could happen; but the No vote, and negative comments, would be regarding a previously discussed and decided matter, they should never arise for the first time as a surprise No vote on a ballot.

Ballot comment resolution improves consensus. Any technical changes made during ballot comment resolution have one goal: to improve consensus. In the case of a successful final approval ballot, where after ballot comment resolution the document will be sent directly to ISO for publication without another ballot, any design change made between the ballot and publication will be expected to have near-unanimous consent in subgroups and in plenary. This is because we need to have strong confidence that the design change is not reducing the existing consensus, and we do not have another ballot to find out whether the change would affect the opinion of any NBs who are not represented at the meeting where ballot comment resolution is being done.

How to report a potential technical concern, at any level of severity

If you notice a potential problem, please follow these steps:

Keep the mindset that it's a "potential" problem. Very often, even experienced participants find that a potential problem they spot turns out to be a misunderstanding or to have a well-considered rationale. Keeping the view that it's a "potential" problem greatly improves the tone and productiveness of all discussions.
Describe the problem, and ask whether it was considered. If the concern is about a feature proposal (whether already adopted or still underway) include the proposal authors; as the feature's designers they will be among the best experts about the issue.
If it was considered, and you think you have disagreement with the decision, explain how and why, and based on what (implementation/deployment/user experience are useful points).
If it wasn't considered, again explain how and why there's a problem, and based on what.
Discuss whether it can be handled as an issue or whether a paper is needed.
File the issue or write the paper, or otherwise make sure such a follow-up happens. Ensure the feature's designers (proposal authors) are aware of the follow-up issue or paper.

Please:

Consider beforehand how severe the problem is. Is the house on fire, or is it just a minor gaffe/inconvenience? To whom? Based on what?
Listen to what other people say, and consider their viewpoints on the matter. Even if people disagree with your viewpoint, remember to read/listen what they say, and consider why.

In general, these steps should happen:

As early as possible, inform the EWG and LEWG chairs and the proposal's authors: They need to be aware of your concern, are trained in triaging and prioritizing issues and concerns, and can offer calm advice on how to proceed.
As early as possible, inform the subgroup: preferably during the discussion in a meeting, even more preferably before a meeting on a reflector. This is in accord with the ISO Code of Conduct's "timely manner" expectation.
If you didn't notice it then, before the straw poll.
If you didn't notice it then, after the meeting on a reflector.

Escalating a serious "cannot live with" objection, or significant new information

If you feel that a subgroup decision is making a serious mistake so severe that you feel you cannot live with the result, and/or you learn of significant new information not considered in the subgroup discussion that could reasonably change the view of the other participants:

As early as possible, make the EWG and LEWG chairs aware of your concern. If it is a subgroup decision made during the week and that will be brought forward to plenary that week, you should proactively raise it during the week:

On the committee email lists: Ideally the issue should be raised on the relevant subgroup's email list immediately following the subgroup discussion to which the objection appertains, but in no case any later than the deadline of 5pm the evening before the closing plenary session (and posting much sooner than that is strongly encouraged, ideally right after the subgroup decision they feel is wrong, is strongly encouraged).
Within your own national body: This is so that the national body chair has opportunity to caucus with their members and determine whether the position may be a national position (normally the default is no, not a national position, unless it was discussed before or during the meeting to determine that it is a national position).

That way, when we come to plenary, everyone has had opportunity to be informed of the serious concern with time to consider it, and when the Convener asks your national body's chair whether the objection is a personal or national position, they will be equipped to answer. Objections that are not so escalated, but are raised or re-raised in plenary, should not be given weight in plenary. (In the rare case of new information that is found 'just the night before' plenary, it has still passed the cutoff for plenary participants to be able to give it informed and prepared consideration in time for plenary, and it is a race condition that we linearize by saying it has failed to be raised before the cutoff, and should be handled per the next bullet including with a followup paper.)

If it is new information found after the deadline (including between meetings), they should raise it:

On the committee email lists.
As a national body ballot comment. If a participant does not raise the concern within their national body, and succeed in convincing enough people in their caucus to make it a national body position (by whatever internal rules that particular national body panel uses to determine such), it won't become a national position.

In both cases, it should be raised with a discussion paper containing detailed information (at least a draft paper if a final one is not yet available).

SD-4: WG21 Practices and Procedures