evolving_cpp_remotely.bs

<pre class='metadata'>
Title: Evolving C++ Remotely
Shortname: D2145
Revision: 2
Status: D
Group: WG21
Audience: WG21
Editor: Bryce Adelstein Lelbach — Library Evolution Chair, NVIDIA, brycelelbach@gmail.com
Editor: Titus Winters — Library Evolution Chair Emeritus, Google, titus@google.com
Editor: Fabio Fracassi — Library Evolution Vice Chair, CODE University of Applied Sciences, f.fracassi@gmx.net
Editor: Ben Craig — Library Evolution Vice Chair, ben.craig@gmail.com
Editor: Billy Baker — Library Evolution Incubator Chair, FlightSafety, Billy.Baker@flightsafety.com
Editor: Nevin Liber — Library Evolution Incubator Vice Chair, Argonne National Laboratory, nliber@gmail.com
Editor: JF Bastien — Evolution Chair, Apple, jfbastien@apple.com
Editor: David Stone — Evolution Vice Chair, Uber, david.stone@uber.com
Editor: Botond Ballo — Evolution Incubator Chair, Mozilla, botond_ballo@yahoo.ca
Editor: Erich Keane — Evolution Incubator Vice Chair, Intel, erich.keane@intel.com
Editor: Tom Honermann — SG16 Unicode and Text Processing (SG16) Chair, Synopsys, tom@honermann.net
URL: https://wg21.link/P2145R2
!Source: <a href="https://github.com/brycelelbach/wg21_p2145_evolving_cpp_remotely/blob/main/evolving_cpp_remotely.bs">GitHub</a>
Issue Tracking: GitHub https://github.com/brycelelbach/wg21_p2145_evolving_cpp_remotely/issues
Metadata Order: Author, This Version, Source, Issue Tracking, Project, Audience
Markup Shorthands: markdown yes
Toggle Diffs: no
No Abstract: yes
Boilerplate: style-syntax-highlighting off
</pre>

<style>
pre {
  margin-top: 0px;
  margin-bottom: 0px;
}
.ins, ins, ins *, span.ins, span.ins * {
  background-color: rgb(200, 250, 200);
  color: rgb(0, 136, 0);
  text-decoration: none;
}
.del, del, del *, span.del, span.del * {
  background-color: rgb(250, 200, 200);
  color: rgb(255, 0, 0);
  text-decoration: line-through;
  text-decoration-color: rgb(255, 0, 0);
}
math, span.math {
  font-family: serif;
  font-style: italic;
}
ul {
  list-style-type: "— ";
}
blockquote {
  counter-reset: paragraph;
}
div.numbered, div.newnumbered {
  margin-left: 2em;
  margin-top: 1em;
  margin-bottom: 1em;
}
div.numbered:before, div.newnumbered:before {
  position: absolute;
  margin-left: -2em;
  display-style: block;
}
div.numbered:before {
  content: counter(paragraph);
  counter-increment: paragraph;
}
div.newnumbered:before {
  content: "�";
}
div.numbered ul, div.newnumbered ul {
  counter-reset: list_item;
}
div.numbered li, div.newnumbered li {
  margin-left: 3em;
}
div.numbered li:before, div.newnumbered li:before {
  position: absolute;
  margin-left: -4.8em;
  display-style: block;
}
div.numbered li:before {
  content: "(" counter(paragraph) "." counter(list_item) ")";
  counter-increment: list_item;
}
div.newnumbered li:before {
  content: "(�." counter(list_item) ")";
  counter-increment: list_item;
}
</style>

# Introduction # {#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.

## Summary ## {#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 <a href="https://wiki.edg.com/bin/view/Wg21PersistentInformation/CommitteeSharedCalendarInformation">shared calendar</a>.
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.

## Related Work ## {#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.

## Work Performed at Meetings ## {#work-performed-at-meetings}

At a typical Standard C++ Committee face-to-face meeting,
  [[#appendix-typical-evolution-f2f-schedule|Evolution and Library Evolution meet for 33.25 hours each]].
[[#appendix-historical-library-incubator-f2f-schedule|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:

* <dfn>Information Distribution</dfn>, where knowledgeable parties
      educate the committee about a subject.
* <dfn>Review</dfn>, where the committee identifies open questions
      and places where we lack clear consensus.
* <dfn>Consensus Building</dfn>, where the committee answers open
      questions and we determine consensus on particular matters.

## Field Experience With Remote Work ## {#field-experience}

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.

# Remote Collaboration Mechanisms # {#remote-collaboration-mechanisms}

We have three primary mechanisms for remote collaboration:

* <dfn>Mailings</dfn>, which are regular distributions of committee
      proposals.
    Mailings are a good way to
      [=Information Distribution|distribute information=].
* <dfn>Email List Discussions</dfn>, 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.
* <dfn>Telecons</dfn>, 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.

# Telecons # {#telecon}

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
  [=Information Distribution|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.

## Telecon Duration and Cadence ## {#telecon-duration-and-cadence}

As mentioned earlier in [[#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.

## Telecon Platform ## {#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 <a href="https://zoom.us">Zoom</a>, the official ISO [=telecon=]
  platform.
Zoom supports most of these features and the committee has field experience
  [[#field-experience]] using this platform to hold [=telecons=].

## No Separate Incubator Telecons ## {#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.

## Telecon Quorum ## {#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.
[[#appendix-historical-library-incubator-f2f-attendance|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..

## Telecon Chairing ## {#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.

## Telecons Aren't Mandatory ## {#telecons-arent-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.

<b>Missing a [=telecon=] does not prevent your voice from being heard.</b>
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.

# Email List Discussions # {#email-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.

## What Email List Discussions Are Good For ## {#what-email-is-good-for}

As discussed earlier, email list discussions are an excellent medium for us to
  [=review=] proposals and [=Information Distribution|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.

## What Email List Discussions Aren't Good For ## {#what-email-isnt-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.

## Summarize Email List Discussions ## {#summarize-email-list-discussion}

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.

# High-Priority Work # {#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.

## High-Priority Library Work ## {#high-priority-library-work}

### Networking ### {#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.

### Executors ### {#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.

### Modularizing the Standard Library ### {#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.

### Coroutine Library Support ### {#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.

## High-Priority Language Work ## {#high-priority-language-work}

### Pattern Matching ### {#pattern-matching}

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

### Reflection ### {#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.

### Contracts ### {#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.

# Deadlines # {#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](https://github.com/cplusplus/papers/projects/23).
- [Remote Library Evolution GitHub Project](https://github.com/cplusplus/papers/projects/21).

# Appendix # {#appendix}

## Typical Evolution and Library Evolution Face-to-Face Schedule ## {#appendix-typical-evolution-f2f-schedule}

<table>
<thead>
<tr>
<td>Day
<td>Hours
</thead>
<tbody>
<tr>
<td>Monday
<td>5.25
<tr>
<td>Tuesday
<td>7
<tr>
<td>Wednesday
<td>7
<tr>
<td>Thursday
<td>7
<tr>
<td>Friday
<td>7
<tr>
<td>**Total**
<td>**33.25**
</tbody>
</table>

## Historical Library Incubator Face-to-Face Schedule ## {#appendix-historical-library-incubator-f2f-schedule}

<table>
<thead>
<td>Meeting
<td>Hours
</thead>
<tbody>
<tr>
<td>2018-11 San Diego
<td>22.75
<tr>
<td>2019-02 Kona
<td>26.25
<tr>
<td>2019-07 Cologne
<td>24.5
<tr>
<td>2019-11 Belfast
<td>30
<tr>
<td>2020-02 Prague
<td>20.5
<tr>
<td>**Average**
<td>**24.8**
</tbody>
</table>

## Historical Library Incubator Face-to-Face Attendance ## {#appendix-historical-library-incubator-f2f-attendance}

<table>
<thead>
<td>Meeting
<td># of Polls
<td>Average Attendance
<td>Minimum Attendance
<td>Maximum Attendance
</thead>
<tbody>
<tr>
<td>2018-11 San Diego
<td>62
<td>14.6
<td>11
<td>19
<tr>
<td>2019-02 Kona
<td>75
<td>14
<td>11
<td>22
<tr>
<td>2019-07 Cologne
<td>49
<td>19.2
<td>12
<td>26
<tr>
<td>2019-11 Belfast
<td>50
<td>17.8
<td>12
<td>24
<tr>
<td>2020-02 Prague
<td>46
<td>20
<td>12
<td>25
<tr>
<td>**Average**
<td>**56.4**
<td>**17.12**
<td>**11.6**
<td>**23.2**
</tbody>
</table>

<pre class=biblio>
{
  "P2195R0": {
    "authors": [
      "Bryce Adelstein Lelbach",
      "JF Bastien",
      "Hal Finkel",
      "Fabio Fracassi",
      "Ben Craig",
      "Billy Baker",
      "Nevin Liber",
      "Titus Winters",
      "Jeffrey Yasskin",
      "Ville Voutilainen",
      "Tom Honermann",
      "Inbal Levi",
      "Antony Polukhin",
      "Corentin Jabot",
      "David Stone"
    ],
    "href": "https://wg21.link/p2195r0",
    "title": "Electronic Straw Polls",
    "date": "25 August 2020"
  }
}
</pre>