On Fri, Jun 26, 2020 at 11:03 AM Vinnie Falco via Boost < boost@lists.boost.org> wrote:

On Fri, Jun 26, 2020 at 10:43 AM Zach Laine via Boost wrote:

...

I want to standardize something like the interfaces there for C++23

Why are you targeting a particular release date? Is your development strategy going to be different because you want to "get something in to C++23" versus "I want to standardize something after it has achieved sufficient field experience and maturity?"

I was going to ask the same question. Nothing should be standardized that isn't already the defacto standard. It isn't likely that between what's left of 2020 and 2023 this library or any other will become the defacto standard. I know this fails on deaf ears but it needs to be said.

On Fri, Jun 26, 2020 at 6:05 PM Jeff Garland via Boost wrote: [snip]

And now I'll say some fairly radical things. To me this just says that as an organization we should consider alternate paths to boost adoption. For example, perhaps if a library is proposed for the standard it should automatically be allowed to become a boost 'experimental library' that would ship with releases. The library might not be maintained by the paper authors, but maybe we could coax more authors into realizing there's a benefit to shipping here in the form of massive user exposure. And we could still have a review -- but maybe the experimental acceptance wouldn't hinge on the results.

I don't know how this would work exactly, and I find it concerning that we would essentially have a lower bar for stuff that is targeting the standard, where it will eventually be chiseled into stone. However, where we might improve would be in lowering the bar to entry required just to submit a library for review. These hurdles currently exist: - This list is not very welcoming. One committee proposal I know of that is exactly the right kind of thing for Boost did not submit to Boost because they felt this list was rude and combative. I don't know the details, so I don't know if this particular complaint is warranted. More generally, this list is hard for outsiders to penetrate; pretty good evidence for this is the fact that we have posts here mostly from the usual suspects, and new voices don't appear very often. I have no suggested fixes for this, unfortunately. - It can be hard to figure out how to submit to Boost, and once you do, the process is pretty involved. We've addressed part of this by having a list of names of Boosters who have volunteered to act as review managers for stuff targeting the standard. Having yet more people volunteer to walk people through the process, and/or better document the process, would help here. As one example, is getting endorsements actually necessary? The submission process page says that it is, but that step seems to be skipped pretty often from what I can tell. Maybe I'm just not paying enough attention. - The build system and other infrastructure is unlike anything anywhere else, and super obscure, because it is not documented well enough to do anything but copy/paste from an existing Boost lib. We could of course use something that is used more widely. I want to see more std lib proposals come through Boost first, and I think a lot of you do, too. However, for that to happen at a larger scale than what we're seeing today (which is me alone as far as I can tell), we would need to sand off those rough edges I mentioned. The status quo is that it's simply so much easier to submit straight to LEWG that only a crazy person would do otherwise (again, that would be me). I'm not willing to do this work. I have too many irons in the fire as it is working on committee stuff and Boost libs. Perhaps someone here will be sufficiently motivated to address some of these things. Zach

On Fri, Jun 26, 2020 at 7:02 PM Zach Laine via Boost wrote:

I don't know how this would work exactly, and I find it concerning

I don't either, but I think we should ponder it. At a basic level maybe some folks would volunteer to help an author 'boostify' a library. Maybe summer of code projects.

that we would essentially have a lower bar for stuff that is targeting the standard, where it will eventually be chiseled into stone.

As you know, that is exactly the opposite of what I think -- if anything we should raise the bar. Part of that is on the committee itself to learn how to reject. And yet, it's clear that Ranges and Format aren't some half baked idea -- and yet not via Boost. Of course, Networking will likely be the next big addition from Boost -- let's see adopted int Boost 1.36. We're running out of decade+ old libraries to influence the standard.

However, where we might improve would be in lowering the bar to entry required just to submit a library for review. These hurdles currently exist:

- This list is not very welcoming. One committee proposal I know of that is exactly the right kind of thing for Boost did not submit to Boost because they felt this list was rude and combative. I don't know the details, so I don't know if this particular complaint is warranted. More generally, this list is hard for outsiders to penetrate; pretty good evidence for this is the fact that we have posts here mostly from the usual suspects, and new voices don't appear very often. I have no suggested fixes for this, unfortunately.

Yes, this is unfortunate, and I likewise have no solution. - It can be hard to figure out how to submit to Boost, and once you

do, the process is pretty involved. We've addressed part of this by having a list of names of Boosters who have volunteered to act as review managers for stuff targeting the standard. Having yet more people volunteer to walk people through the process, and/or better document the process, would help here. As one example, is getting endorsements actually necessary? The submission process page says that it is, but that step seems to be skipped pretty often from what I can tell. Maybe I'm just not paying enough attention.

idk if this is the main issue, but certainly might play a role.

- The build system and other infrastructure is unlike anything anywhere else, and super obscure, because it is not documented well enough to do anything but copy/paste from an existing Boost lib. We could of course use something that is used more widely.

There seems to be in progress at some level toward cmake -- but really it's not that hard to adapt.

I want to see more std lib proposals come through Boost first, and I think a lot of you do, too.

Not a question in my mind on that.

However, for that to happen at a larger scale than what we're seeing today (which is me alone as far as I can tell), we would need to sand off those rough edges I mentioned. The status quo is that it's simply so much easier to submit straight to LEWG that only a crazy person would do otherwise (again, that would be me).

I'm afraid you are correct, which is why I brought it up. Maybe I'm channeling Dave A and Beman here -- but I think self reflection is in order. I'm not willing to do this work. I have too many irons in the fire as

it is working on committee stuff and Boost libs. Perhaps someone here will be sufficiently motivated to address some of these things.

I agree -- you're one of the few doing it right. I'm only opening a discussion here so that maybe the dynamic can change. Jeff

On Fri, Jun 26, 2020 at 11:28 PM Vinnie Falco wrote:

On Fri, Jun 26, 2020 at 7:02 PM Zach Laine via Boost wrote:

...

This list is not very welcoming. that is exactly the right kind of thing for Boost did not submit to Boost because they felt this list was rude and combative.

Yes well this is what happens when you encourage everyone to play the part of victim. Its a larger problem and not one that is specific for Boost to solve.

I really don't know if that is the right characterization or not, because I don't know all the details.

...

this list is hard for outsiders to penetrate ... I have no suggested fixes for this

I agree. I think the mailing-list format is an anachronism. I would like to rebrand Boost and the website to be a more comprehensive social media site with an emphasis on C++. Instead of a mailing list, it should have a forum. And reviews would take place there. For example each reviewed library would be its own sub-forum to hold the review (and subsequent discussion and support if the library is accepted), using a threaded discussion format.

I've been thinking the same thing for a number of years. Zach

On Sat, Jun 27, 2020 at 12:40 PM Andrey Semashev via Boost wrote:

I don't mind having a forum as an additional communication platform, if there is demand, but it should not replace the ML.

Mailing list sucks. People that are not subscribed can't search through messages, and even people who are subscribed do not have access to messages from before they subscribed. Google doesn't index the mailing list, unless there is a mirror. In the case of Boost, the mirror is controlled by third parties and cannot be leveraged to generate traffic for boost.org and raise interest. The barrier for joining a mailing list just to ask one question is high. Right from the beginning you have to wait to get approved, and then you need to wait for approval to post. In a forum, you can post a message, get the URL of the message you just posted, and then share that with your friends out-of-band (for example, on Slack or in a reddit post) and get attention with possible replies right away. You can't do that with a mailing list. With a forum, information can be grouped in a top down fashion for everyone. For example, we could create a subforum for each library being reviews, have the review take place entirely in the forum, and the forum is then locked and archived, available permanently through boost.org (and associated with the library as part of its social media history). At any point in the future someone could look through the original review for the library including everyone's questions and comments. They can share a link to the review subforum with their friends. Someone can write a blog post years later about the review and describe their experience, or lessons learned, or tout the great value of the Boost Review Process, and so on. These things are not possible with a mailing list. We absolutely should move to a forum on boost.org for all things, import as much as we can from the mailing list (as far back as possible) into the forum, and then cease the use of the mailing list forever. Anyone who emails the list should get an automated reply that says "Please register for the wonderful forums at boost.org" etc Thanks

On Sat, 27 Jun 2020 at 22:57, Vinnie Falco via Boost wrote:

Mailing list sucks. People that are not subscribed can't search through messages, and even people who are subscribed do not have access to messages from before they subscribed. Google doesn't index the mailing list, unless there is a mirror. In the case of Boost, the mirror is controlled by third parties and cannot be leveraged to generate traffic for boost.org and raise interest.

The barrier for joining a mailing list just to ask one question is high. Right from the beginning you have to wait to get approved, and then you need to wait for approval to post. In a forum, you can post a message, get the URL of the message you just posted, and then share that with your friends out-of-band (for example, on Slack or in a reddit post) and get attention with possible replies right away. You can't do that with a mailing list.

Link to the archive once the first message gets through?

With a forum, information can be grouped in a top down fashion for everyone. For example, we could create a subforum for each library being reviews, have the review take place entirely in the forum, and the forum is then locked and archived, available permanently through boost.org (and associated with the library as part of its social media history). At any point in the future someone could look through the original review for the library including everyone's questions and comments. They can share a link to the review subforum with their friends. Someone can write a blog post years later about the review and describe their experience, or lessons learned, or tout the great value of the Boost Review Process, and so on. These things are not possible with a mailing list.

Same thing, link to the archive.

We absolutely should move to a forum on boost.org for all things, import as much as we can from the mailing list (as far back as possible) into the forum, and then cease the use of the mailing list forever. Anyone who emails the list should get an automated reply that says "Please register for the wonderful forums at boost.org" etc

Not that this is my concern really, I'm not a boost regular, but I have an email system that beats the living daylights out of any forum that has ever been suggested to me. While I can't search the messages that were there before I subscribed, for the ones that are in my mail folders post-subscription the search I have is vastly superior to any forum. So are the filtering and other things. Forums may be an attractive option. But they don't hold a candle to some existing email systems.

On 2020-06-27 22:56, Vinnie Falco wrote:

On Sat, Jun 27, 2020 at 12:40 PM Andrey Semashev via Boost wrote:

...

I don't mind having a forum as an additional communication platform, if there is demand, but it should not replace the ML.

Mailing list sucks. People that are not subscribed can't search through messages, and even people who are subscribed do not have access to messages from before they subscribed.

There is an archive: https://lists.boost.org/Archives/boost/ I can't say it is as easy to search as Google, but there is no reason to believe a forum search would be better. Many forums I've seen simply don't have search at all.

In the case of Boost, the mirror is controlled by third parties and cannot be leveraged to generate traffic for boost.org and raise interest.

I'm not sure why boost.org traffic needs to be increased. But then again, I probably don't know enough about how Internet works these days.

The barrier for joining a mailing list just to ask one question is high. Right from the beginning you have to wait to get approved, and then you need to wait for approval to post. In a forum, you can post a message, get the URL of the message you just posted, and then share that with your friends out-of-band (for example, on Slack or in a reddit post) and get attention with possible replies right away. You can't do that with a mailing list.

Well, you can, with an archive, but I admit this is probably easier with a forum.

We absolutely should move to a forum on boost.org for all things, import as much as we can from the mailing list (as far back as possible) into the forum, and then cease the use of the mailing list forever. Anyone who emails the list should get an automated reply that says "Please register for the wonderful forums at boost.org" etc

As I said earlier, as a participant I would prefer to keep using the ML as it is simply more convenient for me.

On Sun, Jun 28, 2020 at 5:03 AM Sergey Popov via Boost wrote:

I'd say forums are now anachronism too. I'd prefer if boost used some ActivityPub compatible platform like Mastodon or Pleroma instead.

No idea what that is. Can you provide a link to this as an example? Thanks

On Sat, 27 Jun 2020 at 18:48, Edward Diener via Boost wrote:

You have raised a bunch of hackles here. The LEWG, along with all other C++ standard committees, seems to me so much less open to debate than Boost is that it is hard to know what to say about your assertion that "This list is not very welcoming". Nor can anything ever be found out from the C++ standards committee why such and such was accepted or rejected, or what the arguments were about after the fact.

Have you tried asking a committee member, or just asking on std-discussion? It also seems to me that there tends to be a multitude of meeting trip reports that cover why such and such was accepted or rejected.

poobahs of the C++ standard committee I have often found to be largely unfriendly and closed in their determination that only they really know what is good or not for C++.

Sure; some of them need a fairly strong rationale to be convinced otherwise. :)

On Sat, 27 Jun 2020 at 23:06, Andrey Semashev via Boost wrote:

On 2020-06-27 20:55, Ville Voutilainen via Boost wrote:

...

On Sat, 27 Jun 2020 at 18:48, Edward Diener via Boost wrote:

...

You have raised a bunch of hackles here. The LEWG, along with all other C++ standard committees, seems to me so much less open to debate than Boost is that it is hard to know what to say about your assertion that "This list is not very welcoming". Nor can anything ever be found out from the C++ standards committee why such and such was accepted or rejected, or what the arguments were about after the fact.

Have you tried asking a committee member, or just asking on std-discussion?

Asking a committee member requires personal interaction, and you have to know who to ask in the first place. Personal interaction is understandably a strong barrier for some.

Well, for future reference, I am happy to entertain reasonable requests for "why was this thing accepted/rejected, can you outline the discussion and the arguments?".

Asking on std-discussion or std-proposals is a possibility. I have tried that a few times, with mixed success. I suspect, a lot of proposal authors don't actively monitor these lists for questions or comments regarding proposals beyond the initial discussion phase, and committee members are either too busy, or not involved in the proposal, or don't reply for any other reason.

The signal/noise ratio of those discussion forums is unfortunately not very good.

As someone who haven't attended the committee meetings personally, but prepared a proposal with a representative, I can say that even obtaining the results of discussion of your own proposal is difficult.

That's unfortunate; you should be able to get that information from the representative. I can slap^Whelpfully guide them what their job as proposal champions is, if you wish.

It is a very reasonable request to have a public searchable access to the result of review and discussion of a given proposal, if only to be able to learn from it or point to when another person comes up with a similar proposal. It may be difficult to implement, but the demand is there.

It's not a question of implementation difficulty, it's more a question of how visible the comments made in a discussion are. There's a difference in discussing technical matters with an open crowd, and with a less open crowd.

...

It also seems to me that there tends to be a multitude of meeting trip reports that cover why such and such was accepted or rejected.

Trip reports do not provide that information beyond the general results of the most prominent proposals. They do not contain the discussion results on every proposal. Besides, a trip report is a perspective of a single person, who may have not even participated in the proposal you're interested in. You'd have to search multiple personal blogs to find such reports, among other posts, from multiple persons, with no certainty you'll find the information you need in the first place.

Fair enough. I merely wonder whether "nor can anything be found" is an accurate/correct statement to make. I am all in favor of improving the communication of feedback to proposal authors. To the general public, I find it non-obvious that there should necessarily be more openness about it. P.S. I'm a Free Software developer, I contribute to GCC and libstdc++ on a fairly regular basis. The virtues of open collaboration are not foreign to me. They aren't necessarily virtues in all situations.

On Sat, Jun 27, 2020 at 1:55 PM Andrey Semashev via Boost < boost@lists.boost.org> wrote:

No, I didn't mean to complain about the champion. I'm just saying that this information should be easily accessible as an open resource, like a bug tracker or something, rather than asking the champion or a random committee member. And besides, Internet has better memory than most people. :)

So ISO has rules about the attribution of comments to people that we have to follow. This is intended to allow for candid discussion amongst participants. So there are notes and resources about discussions that are not open to the public -- you have to have attended a meeting to get access. Same applies to some committee mailing lists. Note that you can attend a meeting for free and participate in the technical discussion without 'joining the committee'. But yes, this is all the more reason for public reviews on boost first as much as possible. All that aside, we try to be as open as possible. As an author of a proposal you should be getting all the feedback, hopefully from the chairs of the groups doing the review. And we have now cleared the point where direction votes are recorded on Github (one issue per paper).

On Sat, Jun 27, 2020 at 4:19 PM Vinnie Falco wrote:

On Sat, Jun 27, 2020 at 4:10 PM Jeff Garland via Boost wrote:

...

This is intended to allow for candid discussion amongst participants.

Are you saying that the discussions on the Boost mailing list are not candid, since they are public?

No I'm not -- it's ISO's rule/theory not mine. I really doubt the committee benefits from that rule, but it's not up for negotiation. That being said, I've submitted private reviews to the author and review manager -- and yes you can do that. So the assumption that all the conversation about boost is public isn't true either. Why did I do that? Mostly because I had an opinion about a library and not enough time to fully review and post. Or maybe I'm using the library in a production system and I'd like it in Boost, but maybe I'm not free to share that publicly. Jeff

On 6/27/2020 7:10 PM, Jeff Garland via Boost wrote:

On Sat, Jun 27, 2020 at 1:55 PM Andrey Semashev via Boost < boost@lists.boost.org> wrote:

...

No, I didn't mean to complain about the champion. I'm just saying that this information should be easily accessible as an open resource, like a bug tracker or something, rather than asking the champion or a random committee member. And besides, Internet has better memory than most people. :)

So ISO has rules about the attribution of comments to people that we have to follow. This is intended to allow for candid discussion amongst participants. So there are notes and resources about discussions that are not open to the public -- you have to have attended a meeting to get access. Same applies to some committee mailing lists. Note that you can attend a meeting for free and participate in the technical discussion without 'joining the committee'. But yes, this is all the more reason for public reviews on boost first as much as possible.

Proposal xxxx was rejected in year nnnn. Please tell me where I can find the C++ standards committee discussion of proposal xxxx, and the differing opinions and comments of those discussing the proposal, as well as the current contact information for those discussing the proposal who are still members of a C++ standards committee. Finally I should not need to be the author of proposal xxxx to have that information since I may well be someone who is interested in xxxx and has something important to say about it. In Boost you can do all that without being anybody special. For the C++ standards committee, you can not do any of that, probably even if you are a C++ standards committee member much less an outsider. Therefore I vastly prefer Boost over the C++ standards committee when it comes to discussing or promoting C++ ideas, C++ libraries, or library design.

On 6/27/2020 1:55 PM, Ville Voutilainen via Boost wrote:

On Sat, 27 Jun 2020 at 18:48, Edward Diener via Boost wrote:

...

You have raised a bunch of hackles here. The LEWG, along with all other C++ standard committees, seems to me so much less open to debate than Boost is that it is hard to know what to say about your assertion that "This list is not very welcoming". Nor can anything ever be found out from the C++ standards committee why such and such was accepted or rejected, or what the arguments were about after the fact.

Have you tried asking a committee member, or just asking on std-discussion? It also seems to me that there tends to be a multitude of meeting trip reports that cover why such and such was accepted or rejected.

I do not find that the reasons why a proposal is accepted or rejected, as well as the differing opinions of those reviewing the proposal, are available for C++ Standard committees. Yet anyone can search Boost archives for discussions regarding a library submitted to Boost, since they are all part of the Boost developer mailing list. Therefore while I respect the expertise of those on the various C++ standard committees, and while I understand that those who are on the various C++ standard committees change over time, the lack of historical information regarding proposals is a huge negative IMO. I am not against experts making decisions in any field, but I am always against those decisions not being open so that other people can see the reasons, even after the fact, for decisions being made. This is especially true in our age, where digital records can provide information much more easily than libraries of printed information could in the past. I believe everyone has a right to protect personal information, but at the same time I believe public information should be open to anyone.

...

poobahs of the C++ standard committee I have often found to be largely unfriendly and closed in their determination that only they really know what is good or not for C++.

Sure; some of them need a fairly strong rationale to be convinced otherwise. :)

I think it is more like some of them are too egotistical to even listen to others who do not have their own reputation. But that is true in any field and while I have encountered some who were like that I have also dealt with some others who were pretty open to technical arguments. Nonetheless I find that even if the debates in Boost get fairly contentious sometimes, it is always better to have the debate rather than avoid argumentation out of some preconceived notion of "niceness".

On Sun, Jun 28, 2020 at 9:16 AM Jeff Garland via Boost wrote:

there's a summary related to LEWGI and SG10 feedback.

I think the entire ISO process is wasteful, inefficient, and loaded with bureaucracy and politics. Meaningful discussion should take place in durable, electronic, archived, and eternally available form visible to the public. Mailing lists sort of work but forums are better (using whatever software). Face to face discussions where valuable decisions and knowledge evaporate into the atmosphere, leaving behind only a stutteringly imperfect and incomplete record by a beleaguered note-taker do not give the proper respect that the C++ standard and its attendant community deserve. Thanks

On Sun, Jun 28, 2020 at 9:46 AM Edward Diener via Boost < boost@lists.boost.org> wrote:

My point is that the history of what is said about a proposal by those either voting to accept or reject a proposal is not available in any form unless it is added to the proposal itself by someone. In your link I do not see the discussion about acceptance or rejection of the proposal by anyone, and if I look up most any given proposal, going back nnnn years ago I see nothing in the proposal itself explaining why it was accepted or rejected. Is it really too much to ask that the C++ standards committee keep a record of the discussion for a given proposal which tells why a proposal is accepted to rejected ?

It's a proposal that is under revision and not complete. It's a newer development in the committee process, but for this paper you can see most of the relevant vote history on github: https://github.com/cplusplus/papers/issues/511

I became concerned about this not as just a theoretical problem because an idea I had which I thought would improve C++ was proposed in an even better way 17 years ago and rejected, and yet there is zero information why the proposal was rejected. But I am trying not to focus on my idea but on the general issue that the reasons a proposal are accepted or rejected by the C++ standards committee is completely lost to anyone who was not there at the time when the proposal was "debated". I found this very poor in an age of digital information.

If you want something more than the votes, then that might fall into the 2% that needs a committee member to answer. And hopefully from this discussion, you know who to ask.

On Fri, Jun 26, 2020, 5:22 PM Emil Dotchevski via Boost < boost@lists.boost.org> wrote:

On Fri, Jun 26, 2020 at 11:03 AM Vinnie Falco via Boost < boost@lists.boost.org> wrote:

...

On Fri, Jun 26, 2020 at 10:43 AM Zach Laine via Boost wrote:

...

I want to standardize something like the interfaces there for C++23

Why are you targeting a particular release date? Is your development strategy going to be different because you want to "get something in to C++23" versus "I want to standardize something after it has achieved sufficient field experience and maturity?"

I was going to ask the same question. Nothing should be standardized that isn't already the defacto standard. It isn't likely that between what's left of 2020 and 2023 this library or any other will become the defacto standard. I know this fails on deaf ears but it needs to be said.

Unicode is an actual standard. The std::ranges library is too. Not de facto standards, actual standards. The Unicode layer of the proposed Boost.Text packages the Unicode algorithms into a std::ranges-style API. There is very little invention going on here. The text layer is a different matter. That *is* an invention. It is also controversial, as the review demonstrated. That is precisely why I was not going to attempt to standardize any of it in the C++23 timeframe, even when my plan was still to get it into Boost right away. It needs time for evaluation and revision -- perhaps several years. I understand the concerns you have both raised, and I share them. I'm one of the few people in LEWG consistently asking "How many users does this have?" and "Why didn't this go into Boost first?". If I thought that either the Unicode standard or the std::ranges work were not fully baked, I might have reservations about the Unicode layer of Boost.Text. The only thing that might need baking is the exact subset of Unicode algorithms that one needs to do useful work. The review has pointed out some weak spots, but if you look at the review, you'll notice that they're all additive. I expect all future changes to be additive, too, because there are not variations of the Unicode algorithms. There's a fixed set of them. If we were to standardize the existing Unicode layer today, we'd be able to use it for a very, very long time. You cannot say that with any certainty about most proposals to the standard library, but then most such proposals are not based on an existing international standard. That's why the Unicode layer (and *only* the Unicode layer) should be standardized in the C++23 timeframe. Zach

On Jun 27, 2020, at 10:57 AM, Phil Endecott via Boost wrote:

Zach Laine wrote:

...

The status quo is that it's simply so much easier to submit straight to LEWG that only a crazy person would do otherwise [i.e. to Boost]

I'm surprised by the suggestion that it's easier to work with the standards committees than with Boost. For a start, literally anyone can subscribe to this list and engage with discussions free of charge. According to isocpp.org/std/meetings-and-participation, the policy for access to the WG21 email lists is they are open to:

* Any member of a national body that participates in WG21, including any employee of a company that is already a member of a national body. [Cost: $1,950 per year in the US.]

* Any person who has already attended a face-to-face meeting in the past. This requirement helps preserve the signal-to-noise ratio by limiting access to people who have demonstrated they're serious about participating. ["Serious about participating", or "rich and like intercontinental travel and don't believe in climate change"?]

* (new) For a Study Group email list, the SG chair may also at their own discretion add any new expert who wants to participate. In particular, SGs are especially designed to be open and inclusive to experts in their field. [So if I were an "expert" in Unicode - which I'm not! - I could ask the Unicode SG chair to add me, which they may or may not do at their discretion.]

I chair the WG21 SG16 Unicode and text study group. SG16 is open to any collaborators. No demonstration of expertise is required. In fact, we need non-expert participation to ensure that what we design will be usable and adopted; otherwise we risk creating expert-only features. The SG16 mailing list, Slack channel, telecon information, meeting summaries, and proposal status details are all publicly available at https://github.com/sg16-unicode/sg16. We are very welcoming! Within the ISO, the term “expert” has connotations that probably differ from what you would colloquially consider an expert; it often simply refers to the representative of some organization. That person may or may not be an expert in any particular topic. Tom.