P2195R1
Electronic Straw Polls

Published Proposal,

Source:
GitHub
Issue Tracking:
GitHub
Project:
ISO/IEC JTC1/SC22/WG21 14882: Programming Language — C++
Audience:
WG21

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:

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

🚂 C++Next 🚄 ¼ 🚄 ¼ 🚄 ¼ 🚄 ¼ 📧️ 📧️ 📧️ 📧️ 📧️ 📧️ 📧️ 📧️ 📧️ 📧️ 📧️ 📧️ 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞 📞

The following proposals address topics related to this proposal:

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:

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:

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:

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:

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.

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

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.

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:

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:

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:

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,

3. Electronic Straw Poll Specification

Electronic straw polls shall be conducted through either a:

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:

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

Strongly For Weakly For Neutral Weakly Against Strongly Against

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:

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:

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.

Index

Terms defined by this specification

References

Informative References

[P0592R4]
Ville Voutilainen. To boldly suggest an overall plan for C++23. 25 November 2019. URL: https://wg21.link/p0592r4
[P2138R2]
Ville Voutilainen. Rules of Design<=>Wording engagement. 15 June 2020. URL: https://wg21.link/p2138r2
[P2145R0]
Bryce Adelstein Lelbach, Titus Winters, Fabio Fracassi, Billy Baker, Nevin Liber, JF Bastien, David Stone, Botond Ballo, Tom Honermann. Evolving C++ Remotely. 21 April 2020. URL: https://wg21.link/p2145r0
[P2145R1]
Bryce Adelstein Lelbach; et al. Evolving C++ Remotely. 25 August 2020. URL: https://wg21.link/p2145r1