P2195R1
Electronic Straw Polls

1. Introduction

The Standard C++ Committee is starting to conduct more and more of our technical work in a virtual environment (see [P2145R0]), in part due to the current global pandemic. This switch to remote work has required us to make changes to how we meet and collaborate.

To have effective virtual meetings, we need to evolve our consensus building process, because it has traditionally been face-to-face only. We will not meet face-to-face again until it is possible to do so without putting peoples' lives at risk, and we do not know when that will be.

We therefore propose that the Evolution and Library Evolution chairs be able to conduct straw polls asynchronously through either email or an electronic polling service run by the Standard C++ Foundation.

1.1. Summary

We propose:

• Continuing virtual teleconferences, which hone design and provide non-binding design direction.

• Begin holding quarterly asynchronous electronic polls for evolution groups either via email or an electronic polling service run by the Standard C++ Foundation.

• Separate polls into two categories: Direction Straw Polls and Decision Straw Polls.

• Anything that is judged ready for a binding decision poll is put on the next applicable quarterly poll.

• Polls can be added to the quarterly list up to a month before the quarterly poll is closed.

• A teleconference is held one week before polls close to hold technical discussions which haven’t been addressed over email or at prior teleconferences.

• The impact and effectiveness of all the above should be monitored and changes should be proposed to improve the process as needed.

In a way, this is a mini-train model embedded into C++'s larger 3-year release train schedule:

• Releases every three years (status quo).

• Evolution groups decision polls every quarter.

• Mailings every month (status quo).

• Teleconferences every week.

1.2. Related Work

The following proposals address topics related to this proposal:

• [P0592R4] establishes our priorities for C++ evolution.

• [P2138R2] explains how proposals should move through the committee.

• [P2145R1] describes processes and procedures for remote meetings.

1.3. Scope

We focus on the evolution groups because, so far, study groups and the core groups have been able to advance work without too many issues. In large parts, this is because study groups are focused interest groups who forward to evolutions groups. Similarly, core groups are smaller and have more focus, and controversial design discussions tend to occur prior to reaching the core groups.

1.4. Prior Art

Historically, consensus building within the Standard C++ Committee has been synchronous and has occured at face-to-face meetings:

• Straw Polls: Evolution groups and study groups have used informal polls during face-to-face meetings to decide whether to pursue proposals, provide directions for future revisions of proposals, make policy decisions, and forward proposals to other groups or plenaries. Anyone physically in attendance when a straw poll is taken is allowed to participate, including those who are visitors and do not yet have formal membership in a National Body. Typically, chairs discourage those who were not present for the discussion preceding the poll from voting, but they are not disallowed from doing so. Decisions made in this way are not strictly binding; if new information or new perspectives are discovered, decisions can always be revisited.

• Plenary Polls: More formal polls are taken during plenaries at face-to-face meetings. Only formal Committee members may participate in plenary polls. Plenary polls are used to approve changes to the working draft of the C++ International Standard or a C++ Technical Specification, create or advance work items to the next stage in their publication cycle, and make Committee-wide policy decisions. In the past few years, we have avoided technical discussion on the subject matter of a plenary poll during the plenary itself; technical discussion is supposed to happen in the applicable study groups prior to plenary.

Some of the decisions made at plenary meetings, such as the creation and advancement of work items through their publication cycle, lead to asynchronous electronic polls at the ISO level which then trickle down to our National Bodies, each of which uses their own consensus building process. Typically these ISO polls are open for a few weeks or months, giving ample time for stakeholders to consider the subject matter and make up their mind.

The parent organization of the US National Body, INCITS, builds consensus asynchronously through electronic polls or calls for comments which are open for a few weeks or months.

Another ISO programming language committee, the Standard Fortran Committee, makes synchronous decisions at face-to-face meetings. However, many of these decisions are considered preliminary and are followed up with an electronic polls within the Committee to determine consensus. The below excerpt describes their process for one particular type of poll:

The rules for interpretation handling by which we operate say:

• J3 votes on the answer at a J3 meeting; a simple majority vote marks the answer as "passed by J3 meeting".

• Between J3 meetings the chair of /interp sends a J3 letter ballot to J3 to approve interp answers that have been "passed by J3 meeting". The letter ballot runs for 30 days. An interp answer passes by a 2/3rds vote; a no vote must be accompanied by an explanation of the changes necessary to change the member’s vote to yes. J3/interp reserves the right to recall an interp answer for more study even if the answer passes.

1.5. Consensus Building Mechanisms

Our consensus building is defined in SD-4.

Synchronous Consensus Building is a process for building consensus in which those involved meet at an appointed time (face-to-face or via telecon), discuss the subject matter, and then work to reach a consensus position before the end of the meeting.

Asynchronous Consensus Building is a process for building consensus in which a deadline is set, those involved discuss the subject matter (email, face-to-face, and/or telecon), and then work to reach a consensus decision before the deadline.

One of the main motivations for synchronous consensus building is that it attempts to ensure that those voting on a poll are informed on the subject matter, as they were present for the discussion of it. However, despite our best efforts, we cannot force participants to be engaged and follow the discussion, even if they are present.

There are a number of downsides to synchronous consensus building:

• It limits stakeholder involvement to those who can present at the meeting. For face-to-face meeting, this requires participants to travel to the meeting location. For telecons, it is almost impossible to avoid excluding some stakeholders due to time zone constraints.

• It often forces stakeholders present at meetings to choose which decisions they wish to be involved with. At the last few face-to-face meetings, we have had seven concurrent group meetings for most of the week; it is almost impossible to avoid conflicts. For telecons, it is almost impossible to avoid excluding some stakeholders due to schedule constraints.

• It limits the amount of discussion that can proceed making a decision. Synchronous meeting time is a precious and limited resource.

• It does not leave time for reflection and reconsideration. Synchronous consensus building asks us to make a decision immediately after a discussion. While we can almost always reconsider decisions in light of new information or new perspectives, it is often wise to give stakeholders more time than a synchronous meeting can last to think about the decision and investigate open questions they may have.

Asynchronous consensus building addresses many of these shortcomings. It allows more stakeholders to be involved in consensus building, equalizing the field by removing barriers to participation. It removes the pressure and hastiness of trying to determine consensus before the end of a meeting, giving stakeholders more time to contemplate and decide their position. This ensures that all opinions are ensured equally in the consensus building process, resulting in a better standard.

However, asynchronous consensus building does have downsides as well:

• It may make it easier to participate in making a decision without participating in the discussion or knowledge of the subject matter.

• Discussion and decision making are not temporally tightly coupled, which may make it harder for participants to remain informed on the subject matter at the time of the poll.

• The lead time for making decisions is greater, which means it is harder to revisit decisions or make additional decisions based on earlier results.

We recognize that these may be issues, but we’ve taken steps to mitigate them and we believe the upsides outweigh the downsides. It is important to note that we make decisions by consensus, not majority vote.

Ultimately, there is a trade-off between synchronous consensus building and asynchronous consensus building; we believe that using a combination of both mechanisms is the right choice for C++ today.

1.6. Consensus Determining Mechanisms

It is the responsibility of the chair of the technical committee or subcommittee, in consultation with the secretary of his/her committee and, if necessary, the project leader, to judge whether there is sufficient support.

• ISO/IEC Directives, Part 1, 2.5.6

The responsibility for assessing whether or not consensus has been reached rests entirely with the leadership.

• ISO/IEC Directives, Part 1, 2.5.6

The notion of "concerned interest(s)" will vary depending on the dynamics of the committee and shall therefore be determined by the committee leadership on a case by case basis.

• ISO/IEC Directives, Part 1, 2.5.6

Within evolution, study, and core groups, we do not make decisions using polls. We make decisions by consensus not by vote. Chairs often use polls as a mechanism to help them determine consensus. The chair’s determination of consensus is authoritative, not the straw poll.

If a chair states that the result of poll does not have consensus, then results should not be cited as a representation of the position of the group.

For example, a chair may have reason to believe the poll is not an accurate representation of the stakeholders in the group for a variety of different reasons:

• Lack of participation by certain stakeholders in the group.

• Disproportionate participation by participants who are not regular participants and stakeholders in the group, even if they are stakeholders on the particular matter at hand.

• Disproportionate participation by the authors of the proposal under consideration.

• Large disparities between the positions of regular stakeholders and others participating in the poll.

• Complexities of stakeholder positions that cannot be accurately expressed in a poll.

For example, suppose we had this result:

POLL: Use electronic straw polls in the Ponies and Unicorns Study Group.

Strongly For	Weakly For	Neutral	Weakly Against	Strongly Against
8	0	5	0	2

This poll result might appear to have weak consensus. But, suppose also that:

• All 8 of the people who voted strongly or weakly for the poll were authors of the proposal who are new to the committee and who are not regulars in the group.

• Most of the 5 people who voted neutral were regular attendees of the group, and noted in their poll comment that they voted neutral because they felt they did not understand the proposal.

• 1 long time regular member of the group voted strongly against because they read the proposal very thoroughly and provided a lot of feedback to the authors, and mentioned in their comment that they felt no steps had been taken to address their feedback.

• Another long time regular member of the group voted strongly against because they are knowledgable about the subject matter and believe the proposal is a mistake.

In this circumstance, a chair may determine that there is no consensus on this matter. Most importantly, the proposal hasn’t achieved absence of sustained opposition. The chair would inform the authors and the group that the poll was inconclusive and would have to be retaken after another round of discussions. They would also provide the authors with some guidance on what steps they might take to improving understanding and increase consensus.

The electronic straw poll mechanism makes it easier for chairs to detect irregularities in polling; polls will be recorded with greater accuracy, voters will be asked to provide a comment with their vote, and chairs will be able to identify who voted and how they voted. If irregularities are observed, they will be corrected and adjustments to our process can be made if needed.

2. Proposed Changes

Today, the purpose of meetings is to give formal feedback to help proposals progress and to make decisions. Work on proposals is largely done outside of meetings. At meetings, we review proposals, identifying where additional work is needed before a decision is made, and, when sufficient information is available, making decisions about how and if a proposal should proceed.

We propose a new model, where the purpose of meetings is to give formal feedback and to drive decision making, but not require that the decision making happen at the meetings themselves. Meetings would continue to be used to review and refine proposals and identify open questions. However, instead of focusing on making decisions at meetings, we would instead focus on identifying the decisions that need to be made.

We propose that language and library evolution chairs have the option to conduct straw polls asynchronously through either email or an electronic polling service run by the Standard C++ Foundation.

Henceforth, straw polls should be divided into two categories:

• Direction Straw Polls: These polls are taken to reaffirm a proposal’s direction, or suggest direction changes that a proposal should pursue in the next revision that comes before the study group taking the poll. These polls will usually be taken on younger proposals, where there are still many open questions and areas for additional investigation. Direction straw polls can only be taken on proposals that will return to the same group before proceeding further. Dissent should be recorded, so that authors know what work needs to be performed to increase consensus in the next revision of their proposal. The results of these polls can always be revisited if new information or new perspectives are discovered. Direction polls do not change the status quo and can be revisited whenever we encounter new information or new perspectives.

• Decision Straw Polls: These polls are taken to make decisions regarding a proposal once the group is confident that all applicable and relevant aspects of the decision have been discussed. These polls will typically be taken on proposals that have been in the group for a few revisions, but can also be taken when a proposal is an obvious one to approve, or when a proposal clearly has no chance of gaining consensus and should not be pursued further. Decision straw polls may forward proposals to other evolution groups, study groups, or to core groups, as well as halt the progress of a proposal. Traditionally, only core groups forward proposals to plenary. Decision polls set the status quo. Changing the status quo requires a stronger consensus with a clear rationale.

We propose that the following guidelines should be followed when determining whether a poll should be taken synchronously or asynchronously:

In Evolution and Library Evolution, at the chair’s discretion,

• decision straw polls shall be conducted either:

  • synchronously at face-to-face meetings, but not virtual meetings, (status quo), or

  • asynchronously via electronic straw poll.

• direction straw polls shall be conducted either:

  • synchronously at face-to-face or virtual meetings (status quo), or

  • asynchronously via electronic straw poll.

3. Electronic Straw Poll Specification

Electronic straw polls shall be conducted through either a:

• A service hosted by the Standard C++ Foundation, or

• Via email.

3.1. Poll Structure

Electronic straw polls shall support five-way polls.

A five-way poll consists of an arbitrary statement, determined by the applicable chair. The polarity of the poll shall be that voting "in favor" means changing the current status-quo. Poll statements shall not be changed after the poll has begun.

Polls shall only be conducted on published P- or N-numbered papers. Polls shall provide:

• A summary of the discussion.

• A summary of notable implications for different outcomes of the poll.

• Links to:

• Relevant published P- or N-numbered papers applicable to the polls.

• Relevant minutes for those papers, prior polls.

• The GitHub issue for said papers.

In a five-way poll, voters may select a stance on the statement being polled from these five options:

Other types of polls may also be supported.

3.2. Eligibility for Voting

An individual is eligible to participate in an electronic straw polls if they are any of the following:

• A member of a National Body that participates in the Standard C++ Committee, e.g. someone who is in the ISO Global Directory.

• Any person who has attended one of the past three face-to-face meetings.

We will revisit these criteria as we gain field experience.

3.3. Voting

Each voter may participate once on each poll.

Voters shall leave a comment in addition to their vote.

Each voter may change their vote and comment at any time prior to the closing of a vote.

Each voter should be prompted to confirm that they have read the proposal and are familiar with the topic.

3.3.1. Voting (Email Specific)

If email is used to conduct an electronic straw poll, voters shall submit their votes by emailing the chair who created the poll. The subject of the email shall be specified by the chair.

Chairs shall send a confirmation email that the vote has been received. Voters are responsible for ensuring that they have received a confirmation prior to the close of the poll; only votes that have been confirmed by a chair will be counted.

3.3.2. Voting (Service Specific)

If a service is used to conduct an electronic straw poll and a voter is unable to vote using the service for any reason, they may submit their vote by emailing the chair who created the poll.

3.4. Creation of Polls

Chairs may create polls.

3.5. Withdrawal of Polls

The chair who created a poll may withdraw or extend the duration of a poll.

If a poll is withdrawn or extended, the chair shall make a comment explaining why the poll was withdrawn.

3.6. Modification of Polls

The chair who created a poll may modify the poll after the start of the polling period. Polls shall only be modified to correct mistakes in the poll wording, not to change the intent of the poll.

If a chair modifies a poll, all eligible voters shall be notified and informed that they may request the poll be withdrawn. If any eligible voter requests the poll be withdrawn, the poll shall be withdrawn.

3.7. Discussion Prior to Polling

The subject of a poll shall be discussed either at a meeting or via the applicable mailing list prior to the start of a poll.

3.8. Poll Notifications

A new mailing list, polls@lists.isocpp.org, shall be established. This mailing list shall be used for notifications regarding polls, but not for discussions of polls or poll results.

Once a poll has been scheduled for an upcoming quarterly poll, chairs shall notify the applicable mailing lists and polls@lists.isocpp.org.

At the start of any teleconference meeting, if that group has open polls, the chair shall notify the group of said polls.

3.9. Poll Duration

Polls are open for no less than a month before a quarterly poll closes.

3.10. Poll Results

The position and comments of all voters shall remain hidden, until the poll closes. When the poll closes, the position and comments and their attribution to specific voters shall be made available to C++ Committee officers only. to WG21 officers only. An anonymized summary of comments shall be made available to all C++ Committee members.

Once a poll closes, the chair who created the poll shall receive an email notifying them that the poll is over. Then, the chair who created the poll shall distribute their interpretation of what consensus is based on the poll results via the applicable mailing lists, minutes pages, and/or GitHub issues.

No one shall share the identities and positions of voters with those who are not eligible voters without the explicit permission of said voters. Poll statements, vote counts, and the chair’s interpretation of the results may be shared with anyone.

4. FAQ

Q: Do you think we should stop having face-to-face meetings entirely?

No.

Developing processes for collaborating remotely and electronically does not mean ceasing our face-to-face collaborations. Face-to-face meetings have value and we believe face-to-face meetings should be held in the future. We do believe that enabling remote participation in such meetings is important.

Q: Won’t electronic straw polls allow people who weren’t involved in discussion at a meeting to vote?

Yes.

In synchronous decision making, we discourage those who were not present for the discussion prior to a poll from voting because they do not have time to familiarize themselves with the discussion before the poll is taken. In asynchronous decision making, those not present for a discussion will have ample time to familiarize themselves with the discussion and background.

It is true that some people may choose to not familiarize themselves with the subject matter and prior discussions and still vote. However, synchronous decision making is also susceptible to inattentiveness. The presence of an individual at a particular meeting does not imply that they were paying attention during the meeting.

The best we can do is what we have always done: encourage people to either familiarize themselves with the subject matter and discussion or choose to not vote. It is important to expect and assume that all Committee participants are acting professionally and in good-faith.

Additionally, unlike at face-to-face meetings, chairs will have a list of everyone who voted in the poll and how they voted. If any sort of voting irregularities appear, the added transparency will make it noticeable. If such irregularities do occur, we can correct them and adjust our process.

We make decisions by consensus, not majority. If the chair has reason to believe the results of the poll do not reflect the consensus of the group, the poll can be discarded and the subject matter revisited.

Q: Will my vote and comments on a poll be publicly attributed to me outside of the committee?

No, unless you choose to make them public yourself.

Poll results will follow the same rules we use for minutes today:

• The poll statement, numeric results, and chair’s interpretation of consensus of a poll can be made publicly available.

• Anonymized summaries of comments can be made publicly available.

• Attribution of votes or comments to specific individuals, companies, or National Bodies without their express permission is forbidden.

Q: Shouldn’t voting be anonymous?

It’s never been anonymous in person, we just never or rarely record who voted which way. Polling within ISO is never anonymous either, with the exception of personnel matters.

Anonymous voting would be detrimental to the purpose of polling. Polling is a mechanism for chairs to determine consensus. The numeric results of the poll are not important themselves, what’s important is gathering the positions of everyone involved.

If we don’t have consensus on a particular matter, it would be very difficult to attempt to reach consensus if we were unable to identify who held differing opinions. Ultimately, our goal is to work together to reach an outcome that is acceptable to everyone. That would be harder to do if voting was anonymous.

Q: What about plenary and plenary polls?

This proposal is about evolution groups' polls only.

This proposal does not suggest any changes to our plenary process at this time. We believe incremental change is safer than drastic change. We suggest that the Standard C++ Committee start pursuing electronic straw polls for evolution groups and assess the effectiveness and ramifications of this change in a few months before considering further process changes.

There is no pressing need to hold a plenary meeting for the next few months. We do not need to advance any Standard C++ work items to the next publication stage in the immediate future.

In the future, if we decide to electronically conduct plenary polls, there are already systems in place to handle electronic polling of formal individual members within an ISO committee. ISO provides a electronic polling system which we could use to poll the individual membership. ISO polls for creating or advancing work items to the next publication stage are voted on by National Bodies, not the individual members. However, ISO provides another type of poll, Working Group consultations, which the formal individual members of a Committee vote on.

Given that technical discussion is already discouraged for plenary polls and is intended to happen disjointly in evolution and study groups prior the plenary, electronic voting for plenary polls seems like a natural fit.