P2145R0
Evolving C++ Remotely

1. Introduction

Due to the ongoing global health crisis caused by the novel coronavirus, the ISO C++ Committee’s planned June 2020 meeting in Varna, Bulgaria was called off. During this uncertain time, our priority must be the safety and well-being of the committee and the public at large.

The postponement of the 2020-06 Varna meeting and the broader impacts of the novel coronavirus on society will be disruptive. At times like these, family and personal well-being comes first, and work comes second. No one can be as productive in these times as they normally would be. However, the ISO C++ Committee can and will do our best to adapt to these disruptions and carry on our work remotely in these trying times.

Our plans for C++23 and beyond ([P0592R4]) have not changed, but the way that we execute on those plans will have to change. This document lays out plans for how we will conduct Library and Language Evolution work remotely.

This proposal covers plans for remote operations until the schedule New York meeting in November 2020 [N4848]. We will revisit our plans should the 2020-11 New York meeting also be delayed.

2. Calendar

The telecon calendar is as follows:

• Holidays: no telecon, schedule for adjacent day.
• LEWG Library Evolution meetings: 8:00AM Pacific on Mondays.
• LEWG Library Evolution meetings: 10:00AM Pacific on Tuesdays.
• EWG Language Evolution meetings: 8:00AM Pacific on Wednesday.
• EWG Language Evolution meetings: 10:00AM Pacific on Thursday.
• CWG Core Language: 2020-04-20 at 17:00 UTC (1:00 p.m. EDT) for 2h of issue processing.
• SG1 Concurrency & Parallelism: 8:30-10:30AM Pacific on Mondays, start date not yet set.
• ABI review group: no scheduled meetings
• SG10 feature testing: no scheduled meetings
• SG16 Unicode and text processing: 12:30-2:00PM Pacific on the 2nd and 4th Wednesday of each month.

The topics for each telecon can be found here:

• Remote Library Evolution GitHub Project.

• Remote Language Evolution GitHub Project.

Details about how to join the telecons will be distributed through the Library and Language Evolution email lists and wiki. If you do not have access to these and are interested in participating, please contact the authors of this paper.

We will also provide a Google Calendar that people can subscribe to if they wish, and we will be emailing calendar invites to the language and library reflectors. Those will contain the link to the teleconference.

3. The Short Version

• Library and Language Evolution consists of three activities:

  • Information Distribution.

  • Review.

  • Decision-Making.

• We have three main mechanisms for remote collaboration:

  • Mailings.

  • Email List Discussions.

  • Telecons.

• Starting in April 2020 Library and Language Evolution will have a weekly 1.5 hour telecon.

  • Each will have two time slots which alternate each week.

    • Library on Monday 8:00AM Pacific / Tuesday 10:00AM Pacific.

    • Language on Wednesday 8:00AM Pacific / Thursday 10:00AM Pacific.

    • Modulo holidays, where we’ll defer the meeting by a day.

  • We will use Zoom, the official ISO telecon platform.

• We will make decisions on these telecons using straw polls.

  • Decisions made on telecons will be "Tentatively Ready", which means:

    • They are sent to the Library Evolution or Language Evolution email list for feedback.

    • They are marked "Tentatively Ready" on GitHub.

    • They are briefly reviewed for affirmation at the next face-to-face meeting.

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

• Use email list discussions for review 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 Library or Language Evolution Incubator meetings.

4. Work Performed at Face-to-Face Meetings

First, we need to understand what exactly we’re losing with the postponement of the 2020-06 Varna meeting. What exactly do we do at face-to-face meetings, and how much time do we spend doing it?

4.1. Amount of Work Performed at Face-to-Face Meetings

At a typical ISO C++ Committee face-to-face meeting, Library Evolution and Language Evolution meet for 33.25 hours each. Library Incubator meets for 24.8 hours. Language 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.

4.2. Kinds of Work Performed at Face-to-Face Meetings

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.

• Decision-Making, where the committee answers open questions and we determine consensus on particular matters.

5. Mechanisms for Remote Collaboration

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 decision-making as it can be hard to determine consensus. Email list discussions are asynchronous, so everyone can participate when it is convenient for them.

• Telecons, which are good for information distribution, review, and decision-making. However, they are synchronous by nature, which introduces scheduling constraints that limits participation and makes them a scarce resource.

6. Telecons

Because telecons are the only good option for decision-making and they are a scarce resource, we should try to use them for decision-making 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.

6.1. Telecon Duration and Cadence

As mentioned earlier in § 4.1 Amount of Work Performed at Face-to-Face Meetings, we spend ~174 hours per year on Library and Language 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, Library and Language Evolution will meet ~1.5 hours per week, from April 2020 until at least November 2020.

This is about 50% of time commitment that we would have made to the 2020-06 Varna meeting. If this cadence and duration proves to be too much, we will adjust by scaling back and cancelling meetings.

6.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 § 9 Field Experience With Remote Work using this platform to hold telecons.

6.3. No Separate Incubator Telecons

The primary reason that Library and Language Evolution Incubator meets separately and concurrently with Library and Language 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.

6.4. Telecon Decision-Making

We will make decisions on telecons via straw polls, just as we do at face-to-face meetings.

Any decisions made on telecons will be considered "Tentatively Ready".

For forwarding of proposals to other subgroups, this means that the paper will be forwarded on the ISO C++ GitHub for paper tracking, but marked with the "Tentatively Ready" tag. At the start of the next face-to-face meeting, we will briefly go through the list of "Tentatively Ready" proposals that were forwarded to see if anyone has new information or new perspectives that warrant revisiting those proposals.

For all "Tentatively Ready" decisions made on telecons, after the telecon a message will be sent to the relevant email lists with a summary of the decisions, to give anyone who did not attend the telecon a chance to voice their opinion.

6.5. 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 Library Evolution and Language Evolution. Typically, attendance in Library Evolution is between 15 and 30 people and attendance in Language Evolution is between 30 and 50 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 Library or Language Evolution telecon, it will be difficult for us to make meaningful decisions. In such a circumstance, we would avoid decision-making and instead use our time for review and information distribution.

6.6. 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.

6.7. 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. As with face-to-face meetings, we can always revisit decisions if we have new information.

7. 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.

7.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.

7.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.

7.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.

8. 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.

8.1. High-Priority Library Work

8.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.

8.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 overlapping. 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 decisions and guidance.

8.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.

8.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.

8.2. High-Priority Language Work

8.2.1. Pattern Matching

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

8.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 Language Evolution after the Reflection study group has forwarded them to us.

8.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 Language Evolution after the Contracts study group has forwarded them to us.

9. Field Experience With Remote Work

We are not in completely uncharted waters here. The ISO 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 replicate these effects in remote meetings.

10. 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 Library Evolution GitHub Project.

• Remote Language Evolution GitHub Project.

11. Appendix

11.1. Typical Library and Language Evolution Face-to-Face Schedule

11.2. Historical Library Incubator Face-to-Face Schedule

11.3. Historical Library Incubator Face-to-Face Attendance