Subject: Fwd: [SC 22 Convenors] Document Access Testimonials Needed

From: Steve Lionel <[email-masked]>
Date: Mon, 4 May 2026 14:33:13 -0400

If you can provide a reason why WG5 documents should become public (and 
from David's note this would apply only to working drafts and CDs, all 
other WG documents would be considered private), please send your 
organization's justification to David ([email-masked]) by June 4.

Steve

-------- Forwarded Message --------
Subject: 	[SC 22 Convenors] Document Access Testimonials Needed
Date: 	Mon, 4 May 2026 07:45:35 -0700
From: 	David Keaton <[email-masked]>
To: 	
CC: 	

Dear SC 22 Convenors,

I am attending this week's JTC 1 Plenary via Zoom; it takes place in São 
Paulo, Brazil. JTC 1 continues to fight for public availability of some 
of our documents, and wants us to submit additional testimonials to 
support this. They want these additional testimonials to come from 
companies and open-source organizations. Please ask members of your WGs 
if they can submit these kinds of testimonials. The details follow.

JTC 1 is only asking for the following documents to remain public:

* New Project Proposals

* Working Drafts (the interim drafts prior to CD ballot)

* Committee Drafts (the drafts submitted for CD ballot)

SC 22 lobbied for much more than this, but JTC 1 believed that they 
could only win the fight in the long run if they narrowed the request to 
these three categories.

JTC 1 submitted a standards-organization-centric justification for 
retaining document openness. The portion they took from SC 22 is 
appended at the end of this message. Now they are looking for companies 
and open-source organizations to explain why openness is important to 
them. Companies that participate in the standards process already have 
access to these documents themselves as a result of that participation, 
so I would imagine that openness would largely affect a company by 
affecting its customers.

Open-source organizations are different. For the most part, their 
developers are not employees of the open-source organization, so they do 
not have access to these documents even though their open-source 
organization participates in standards activities.

I would appreciate it if you could send me any testimonials by Thursday, 
June 4th, so that I can collect them all together and forward them to 
the JTC 1 chair. Please let me know if you have any questions.

By the way, even though the scope of public documents will narrow 
regardless of whether JTC 1 wins this fight, the JTC 1 chair has assured 
me that documents made public under the old rules will remain public; 
only new documents will be affected.

David

P.S. Below is the justification that JTC 1 has already submitted from SC 
22. New testimonials should focus on the impact to companies and 
open-source organizations, as opposed to standards committees. The below 
is pretty old at this point, and came from a time before JTC 1 decided 
to narrow its request to NPs, WDs, and CDs.

---

Examples of the utility of Open access from JTC 1 SC 22, Programming 
languages:

SC 22 uses the relative permissiveness of the current SD 23 as a 
high-bandwidth communication mechanism with its stakeholders to achieve 
a higher quality product. For example, the Fortran working group 
recently held a successful solicitation of comments from their 
community, which they were able to do because they opened up all types 
of documents that were allowed to be open, and outside experts were able 
to gain a clear picture of the direction that development was headed, 
commenting on what they liked, what they did not like, and what issues 
were not being addressed but should be.

Likewise, the C and C++ working groups have a constant flow of 
productive feedback resulting from opening up their documents as much as 
allowed. Some of the feedback comes from people who can eventually be 
persuaded to join the working groups. Other feedback comes from one-time 
contributions that are nevertheless highly useful.

The Programming Language Vulnerabilities working group is tasked with 
documenting an enormous breadth of knowledge in at least ten different 
languages, some of which are outside of ISO/IEC, using a small group of 
people. They depend even more on high-bandwidth outside collaboration to 
achieve a quality result, which requires sharing open-access documents 
as much as allowed.

In the programming language community, an ISO/IEC standard already 
carries the stigma of a closed process that is out of touch with the 
openness that stakeholders demand today. This inhibits new languages 
from joining. If the relative permissiveness of STANDING DOCUMENT 23 is 
lost, even the established areas of SC 22 will no longer be able to 
produce high quality standards that serve the community.