P2145R1
Evolving C++ Remotely

1. Introduction

Stakeholder engagement is essential to the success of any standardization effort.

Historically, to participate in C++ standardization, individuals had to attend three week-long face-to-face meetings a year to remain engaged. While we have accomplished a great deal with this model, it does disenfranchise certain types of stakeholders and no longer reflects best practice in the industry.

The time has come for the Standard C++ Committee to enable remote participation, in part due to the ongoing global pandemic. The Committee will not meet again face-to-face until it is possible to do so without putting peoples' lives at risk and we do not know when that will be. By enabling remote participation, we will be able to continue our work and improve our process long-term by engaging a larger number and greater diversity of stakeholders.

This document lays out plans for how we will conduct C++ standardization remotely.

1.1. Summary

We propose that all subgroups will hold regular telecons in lieu of face-to-face meetings for the forseeable future. All telecons are posted to our shared calendar. If you are unable to access this calendar and want to participate, please contact Bryce or JF.

• C++ standardization consists of three activities:

  • Information Distribution.

  • Review.

  • Consensus Building.

• We have three main mechanisms for remote collaboration:

  • Mailings.

  • Email List Discussions.

  • Telecons.

• Telecons drive consensus building. They provide feedback and guidance, and identify open questsions that need to be resolved.

  • Missing a telecon does not prevent your voice from being heard.

• Email list discussions are used to review proposals whenever possible to minimize the amount of work that must be done on telecons or at future face-to-face meetings.

  • Chairs will start curated email list discussions of certain papers.

  • Try to summarize email list discussions that you start or participate in.

• There will be no separate Evolution or Library Incubator meetings.

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.

• [P2195R0] describes how we should determine consensus electronically.

1.3. Work Performed at Meetings

At a typical Standard C++ Committee face-to-face meeting, Evolution and Library Evolution meet for 33.25 hours each. Library Incubator meets for 24.8 hours. Evolution Incubator has similar numbers. For both the Library and Language tracks, we spend a total of ~58 hours per meeting and ~174 hours per year at face-to-face meetings on Evolution and Incubation.

A lot of voluntary and informal, but important, work also occurs during meals and at in the evening hours.

When in session at face-to-face meetings, we typically perform three activities:

• Information Distribution, where knowledgeable parties educate the committee about a subject.

• Review, where the committee identifies open questions and places where we lack clear consensus.

• Consensus Building, where the committee answers open questions and we determine consensus on particular matters.

1.4. Field Experience With Remote Work

We are not in completely uncharted waters here. The Standard C++ Committee does have field experience working remotely. A lot of important inter-meeting discussion happens on email lists. The Tooling and Unicode study groups, among others, have successfully and regularly met and made decisions via telecons.

The main benefits of a face-to-face meeting over remote meetings are:

• The informal, spontaneous, and serendipitous interactions between committee members in hallways, at meals, etc.

• Sequestration, which limits distractions and increases focus.

• Discussions happen consecutively, which keeps them "in cache".

We can’t easily replicate these effects in remote meetings.

2. Remote Collaboration Mechanisms

We have three primary mechanisms for remote collaboration:

• Mailings, which are regular distributions of committee proposals. Mailings are a good way to distribute information.

• Email List Discussions, which are good for information distribution and review. They are not as effective for consensus building as it can be hard to determine consensus and work through differences of opinion. Email list discussions are asynchronous, so everyone can participate when it is convenient for them.

• Telecons, which are good for information distribution, review, and consensus building. They excel at resolving misunderstandings and working through differences of opinion. However, they are synchronous by nature, which introduces scheduling constraints that limits participation and makes them a scarce resource.

3. Telecons

Because telecons are the only option that truly excels at certain aspects of consensus building (resolving misunderstandings and differences of opinion) and they are a scarce resource, we should try to use them for consensus building as much as possible. That means we should do as much distribution of information and review outside of telecons as possible. It is important that participants read the proposals that will be discussed on a telecon before the telecon, and utilize email list discussions whenever possible.

3.1. Telecon Duration and Cadence

As mentioned earlier in §1.3 Work Performed at Meetings, we spend ~174 hours per year on Evolution and Library Evolution at face-to-face meetings. This is an average of ~3.3 hours per week (~4 months per committee meeting equivalent).

~3.3 hours per week is a slightly larger commitment than reasonable, especially given that other parts of the committee will also be meeting remotely. If some part of the information distribution and review that occurs at face-to-face committee meetings can happen via email list discussions message platforms instead of telecons, it should not be necessary for us to make up all of the time of face-to-face meetings via telecons.

There are tradeoffs in selecting a duration for individual telecons. Longer telecons can be harder to schedule and can strain the endurance of participants. Shorter telecons are easier to schedule and may draw greater attendance, but disrupt the continuity of discussions.

Given the committee’s global nature, it is difficult to find times that are convenient for all committee members. Instead of always holding weekly meetings at a single time, we should either meet multiple times per week or meet once per week but have two time slots which alternate each week. This will give us additional scheduling flexibility.

Given all of this, Evolution and Library Evolution will meet ~1.5 hours per week. Most other subgroups will meet for 1 to 1.5 hours every other week.

3.2. Telecon Platform

Our telecon platform needs to be able to support the following:

• Supports video chat.

• Supports audio over internet or via phone line.

• Works on Windows, Mac, Linux, and mobile devices.

• Attendee hand raising.

  • The hand queue should show the order in which hands were raised.

  • The telecon organizer should to be able to lower raised hands.

• Attendee polling.

  • Multiple types of polls should be supported: at least 5-way and 3-way polls.

  • The telecon organizer should be able to clear votes.

• Attendee renaming by telecon organizer.

• Meeting recording.

We will use Zoom, the official ISO telecon platform. Zoom supports most of these features and the committee has field experience §1.4 Field Experience With Remote Work using this platform to hold telecons.

3.3. No Separate Incubator Telecons

The primary reason that Evolution and Library Evolution Incubator meets separately and concurrently with Evolution and Library Evolution is due to the time constraints of our physical meetings.

For remote meetings, we do not have the same kind of time constraints that force concurrent sessions of Evolution and Incubator groups. As such, there does not seem to be much value in holding separate telecons.

All telecon discussions will be considered joint exercises of Evolution and Evolution Incubator.

3.4. Telecon Quorum

We expect to have lower attendance on telecons than we would have at face-to-face meetings.

We do not have readily accessible data for attendance in Evolution and Library Evolution. Typically, attendance in Evolution is between 30 and 50 people and attendance in Library Evolution is between 15 and 30 people. Average attendance in Library Incubator is 17 people. Language Incubator has similar numbers.

Quorum is not merely a function of the quantity of people in the room. For quorum, we need to have both the right people and the right quantity of them.

That said, if we have fewer than 15 participants on any given Evolution or Library Evolution telecon, it will be difficult for us to make meaningful progress..

3.5. Telecon Chairing

Running weekly telecons is not a small amount of effort. Fortunately, we have multiple chairs available for each track (Evolution chair, Evolution vice chair, Incubator chair, and Incubator vice chair), so we can distribute the burden amongst ourselves.

3.6. Telecons Aren’t Mandatory

If you are a stakeholder on a particular proposal or subject, you are strongly encouraged to attend telecons on that proposal or subject. However, telecon attendance is encouraged but not mandatory.

Missing a telecon does not prevent your voice from being heard. If a decision is made on a telecon and you feel you have a new perspective or new information that was not considered, you should make the committee aware via email list discussion. We can always revisit decisions if we have new information or new perspectives.

4. Email List Discussions

We have always made use of email list discussions for inter-meeting work, but they are more important than ever now, and we should strive to do more work via email.

To help drive email list discussions and minimize the need for telecons, chairs will start curated discussions of papers on a regular basis. This is something Library Evolution has done in the past to help address backlogs.

4.1. What Email List Discussions Are Good For

As discussed earlier, email list discussions are an excellent medium for us to review proposals and distribute information. They are asynchronous, which means people can participate in email list discussions when it is convenient for them to do so.

Review over email likely works best when the discussion is very targeted. If you want to start an email list discussion of a proposal, it’s probably best to begin with a focused set of questions that you are seeking answers for.

Here are some examples of questions that are probably well suited to an email list discussion:

I was writing Proposal X and ran into Specific Problem Y. Can anyone suggest some solutions?

I was writing Proposal X and I was wondering how Specific Thing Y came to be in the standard. Does anyone know?

I noticed Perceived Problem X in the standard, and I was thinking about writing a proposal to fix it in Specific Way Y. What do y’all think about my solution?

I was considering proposing Feature X. Do y’all think this is worth standardizing?

I was reading Proposal X and I noticed some downsides to Approach Y in the proposal. I spoke with the author and he mentioned that we have to select between Approach Y (which has Specific Downsides A) and Approach Z (which has Specific Downsides B). The author and I wanted to know what the committee thought about these tradeoffs.

Decision X was made on Telecon A; I’m not sure I understand the rationale, can someone explain?

Decision X was made on Telecon A; was Specific Thing Y considered during the discussion?

Attached is an update of Proposal X, with the following changes based on discussion from Telecon A: List of Changes B. I’d like to call particular attention to Part Y and Open Question Z - please let me know if you have any thoughts or new information.

4.2. What Email List Discussions Aren’t Good For

However, email list discussions have downsides. The signal-to-noise ratio can be quite bad and it can be difficult to identify the consensus of an email list discussion and leave with clear outcomes.

Additionally, sometimes email list discussions are not effective due to lack of participation. This can happen when the discussion doesn’t have a clear scope or goal.

You shouldn’t necessarily expect someone else to guide the discussion for you; chairs will help to do so whenever possible, but we don’t always have the bandwidth for that. If you want to start an effective email list discussion, you should take responsibility for scoping and guiding it.

Here are some anti-patterns for email list discussions.

Let’s discuss Proposal X. What do you think about it?

Alternative: If you want to discuss the proposal, you’ve read it and probably have specific things in mind that you’d like to discuss. So, write a concise, thoughtful email summarizing the specific matters or questions that you think ought to be discussed.

[Very, very long wall of text on a subject.]

Alternative: Consider writing a paper.

Please don’t do Approach A and Design Choice B in Proposal X.

Alternative: Explain yourself! Make sure to describe your thought process and rationale, so that others understand your thinking. Instead of saying "don’t do A and B", suggest alternatives that the authors might explore.

4.3. Summarize Email List Discussions

Because email list discussions have bad signal-to-noise ratio and can be difficult to follow, it’s often hard to identify the outcomes of said discussions.

It is invaluable for someone to step in at or around the end of a discussion and write up a short email summarizing their understanding of everyone’s position and any outcomes. You can then send this summary and ask if everyone agrees with it. This can help bring much needed closure to discussions.

5. High-Priority Work

At the 2020-02 Prague meeting, the committee adopted a plan for C++ standardization, [P0592R4]. That plan contained seven high-priority items; four library items for C++23, and three language items for C++23 or later.

This section describes specific plans for these high-priority work items.

Once this material has been addressed, we will prioritize bug fixes, performance improvements, integration fixes for/between existing features, and issue processing.

5.1. High-Priority Library Work

5.1.1. Networking

The Networking study group has been reactivated to drive standardization of networking. This group will set the direction for work on networking; once they have consensus on a direction, they will bring that direction to Library Evolution.

We have an existing, large proposal for networking: the Networking Technical Specification ([N4734]).

In Fall 2019, we conducted an inter-meeting review of the Networking TS. We created a number of review groups, each of which was tasked with looking at a particular aspect of the Networking TS, resolving whatever issues they could, and identifying open questions that required broader review. Each group was asked to summarize its findings.

Approximately half of these groups presented their findings at the 2020-02 Prague meeting of the Networking study group. The Networking study group was able to reach consensus on some matters, and identified others that will eventually need review in Library Evolution. Each of these groups has been asked to prepare a paper containing their summary, to presented to Networking study group and Library Evolution.

Once all of these summaries have been produced and the Networking study group decides they are ready for Library Evolution, we will begin reviewing them in Library Evolution.

5.1.2. Executors

For executors, we have an existing, large proposal, [P0443R13] which is ready for Library Evolution review.

Given the scope of this proposal, we believe the best route to reviewing it is to form a number of review groups and ask each group to review a particular aspect of the proposal, resolve whatever issues they can, and identify open questions that require broader review. Each group will then prepare a paper summarizing their findings. Each group will consist of a number of executors authors and a number of Library Evolution regulars who are not involved in the executors proposal.

Given the nature of the executors proposal, the work of each group will be Each group will not be reviewing a specific section, but instead reviewing the proposal from a particular perspective with a specific design facet in mind.

We have already started speaking with some of the executors authors about how we will structure this review. More details will be shared on the Library Evolution email list in the next few weeks.

Once all of the review groups have completed their work and prepared their summary papers, we will discuss the results in a series of telecons over the summer and work towards resolution of any open matters that need direction.

5.1.3. Modularizing the Standard Library

Modularizing the standard library is a goal for C++23, but we have not yet decided on a concrete direction or scope for this work.

We are aware of the following papers on this topic:

• [P0581R1]: Standard Library Modules

• [P1212R0]: Modules and Freestanding

• [P1453R0]: Modularizing the Standard Library is a Reorganization Opportunity

• [P1502R1]: Standard Library Header Units for C++20 (historical)

The following papers related to freestanding are also applicable:

• [P1105R1]: Leaving No Room for a Lower-Level Language: A C++ Subset

• [P0829R4]: Freestanding Proposal

• [P1376R0]: Summary of Freestanding Evening Session Discussions

The first few big questions we have to address to help scope this work are:

• What are our goals for standard library modularization?

• Do we want to reorganize the standard library while modularizing it?

• How granular should standard library modules be? What are the tradeoffs of fine-grained modules versus coarse-grained modules?

• Do standard library modularization and freestanding reorganization need to be linked together?

We will hold telecons to reach consensus on these and other questions and define the scope of what we want to pursue.

5.1.4. Coroutine Library Support

Richer coroutine library support is a goal for C++23, but we have not yet decided on a concrete direction or scope for this work.

We are aware of the following papers on this topic, some of which are quite dated. They are grouped by subject:

• [P0975R0]: Impact of coroutines on current and upcoming library facilities

• [P1341R0]: Unifying Asynchronous APIs in the Standard Library

• [P1288R0]: Coroutine concepts and metafunctions

• [P1056R1]: std::lazy<T>

• [P1681R0]: Revisiting the allocator model for std::lazy<T>/et al

• [P1171R0]: std::sync_wait

• [P1316R0]: std::when_all for coroutines

• [P0286R0]: A networking library extension to support co_await-based coroutines

• [P0055R1]: On Interactions Between Coroutines and Networking Library (historical)

• [P0162R0]: A response to P0055

Additionally, the desire for the following coroutine library features have been expressed multiple times. However, we lack a proposal for these features:

• std::generator<T>

We need to identify what exactly we want here. What are our goals for coroutine library support? What features do we desire?

We will discuss scoping of this work on an upcoming telecon. Ideally we need a paper proposing what the scope and goals should be.

5.2. High-Priority Language Work

5.2.1. Pattern Matching

Evolution will continue to review [P1371R2] as it gets updated.

5.2.2. Reflection

We will let the Reflection study group pursue all work related to reflection. We will only start looking at matters pertaining to reflection in Evolution after the Reflection study group has forwarded them to us.

5.2.3. Contracts

We will let the Contracts study group pursue all work related to contracts. We will only start looking at matters pertaining to contracts in Evolution after the Contracts study group has forwarded them to us.

6. Deadlines

One of the biggest impacts of losing the face-to-face 2020 summer meeting is the loss of a major deadline. This is compounded by the transition to monthly mailing deadlines. It is now a lot easier for a paper author to "miss" a deadline; you can always publish it next month and have it discussed on a telecon.

We must be careful to avoid allowing this flexibility to lead to procrastination. Hard deadlines, even arbitrary ones, fight mission creep and ultimately produce deliverables.

In the absence of physical meetings, there are two types of deadlines we can use to drive work:

• The monthly mailings.

• Scheduled telecons.

Telecons will be most effective if the schedule is known well in advance, but leaves some room for flexibility, just as the schedule is for a face-to-face meeting. Chairs will try to have a tentative agenda for the next 4 to 8 weeks of telecons. The tentative agendas can be found here:

• Remote Evolution GitHub Project.

• Remote Library Evolution GitHub Project.

7. Appendix

7.1. Typical Evolution and Library Evolution Face-to-Face Schedule

7.2. Historical Library Incubator Face-to-Face Schedule

7.3. Historical Library Incubator Face-to-Face Attendance