A plan to help TC39 become more open up to community contributions and participations
Thanks for pointing out some issues with the current state of things. While, in general, having more people directly participate in the committee is probably a good thing, I don't think that will fix the problem. I think you'll find yourself running into the same troubles that the current members face. Specifically, there is more work to be done than there is time to do it. There are more things to reach consensus on than there is time to discuss. Also, there is also the risk of perpetuating an unhealthy "us-vs-them" mentality which seems to underly this plan and this post.
Instead (or perhaps simultaneously while you explore this plan) why don't we try to address the community involvement problem?
The big problem, I think, is that community members are directed to es-discuss and yet es-discuss has been largely been abandoned by TC39 committee members. Why has es-discuss been abandoned? There are a couple of reasons I think:
- Github (and their "issues" feature) has turned out to be a much better platform for working out design details on particular proposals. Community members have successfully and productively participated in the design process in this way.
- The signal-to-noise ratio here is really bad these days. Let's be honest: most of the strawman proposals that are brought here are pretty terrible. It takes time to review and comment on even the worst ones, and that's time that I (for one) would rather spend doing other things, like working on observables, or cancel tokens, or private state, or async generators, or drinking eine bier.
The other problem that I've heard mentioned is that certain high-profile proposals (like that function-pipe one) aren't getting any traction.
First, there are very few proposals that fit into that category. Claude Pache's claudepache/es-optional-chaining is great! In general though, if a proposal isn't getting picked up it's probably because either it has significant issues that committee members don't like, or the time for it just isn't right. Time is a limiting factor and we have many proposals working through the process already.
I'll spend some time thinking about how we can improve the es-discuss involvement problem. Thanks again for bringing attention to it!
Maybe also a factor: JS has changed a huge amount in a short time. Developers, browsers, tools need to catch up, digest the changes, decide what real problems remain. We have enough new for now.
To be honest - I can rather see complaining about how small is the standard library, and how many basic functions have to be provided by third party, not by standard library (famous left-pad case).
And I think these complaints are right and justified - newly introduced classes like Set are painfully limited. We don't have a set.filter method, .map method, .intersect method, .union method, .difference method - everything have to be reimplemented by every developer.
How long we had to wait for Object.entries? How long we will have to wait for someone to propose Object.fromEntries? Tuples, named tuples, counters, functional Date, deque, cryptography primitives, advanced marshalling, parallelism, structs, UUUIDs, weak references - all these basic functionalities are lacking in JavaScript... And these are not an "ultra high level" functions, but rather a basic building blocks.
Yesterday I have think about idea of "official staging library" - a set of modules that are staging for inclusion in the official specification. Faster release cycles, better feedback, community-driven, better implementation, lesser worry about backward compatibility. If some feature is getting a positive feedback from community it becomes part of the next standard.
First - thanks for everyone who chipped in; any comment is of immense value here.
@Kevin
The "us-vs-them" mentality: IMHO the mentality kinda came into existence precisely because of the aforementioned fact that the current experience for community participation is not a smooth and - more importantly - transparent one for those "not in the loop".
Since you've mentioned the obvious I dared not to mention that es-discuss has been largely marginalized, I believe you can also imagine that the most likely way for average ECMAScript users out in the wild nowaday to gain insight into the progress of TC39's works is by following certain high-profile representatives' Twitter and GitHub activities. This is rendering the community on the totally passive end of things. And this doesn't work well when occasionally the community is trying to drive something when people have come to realize they really want it.
I've mentioned inside the original discussion thread that the proposer of that pipe operator would have a far better luck gaining attention and finding a champion if the proposer went on to pitch-off representatives on Twitter one-by-one. Which is impossible, and would lead to the inevitable that people would just start pestering certain most visible champions like ljharb, rwaldron, and perhaps zenparsing :-p
The thing is - if we disregard those "I have an idea..." or "I want this thing from language X..." type of threads and only count those with a dedicated GitHub repo as a proposal - the good-n-bad ratio is kinda half-half. It's not as low as you depicted because many of these are recurring proposals trying to address some long-standing language issues since eons... But most of the "good" (ie. worthy of further works) ones simply died a slow death they did not deserve without any reason being revealed - taking on the example of that pipe operator again, it's dying right now because of some reason that's yet to exist. They were told to come to es-discuss to seek for champions and then the journey simply stopped. Whether it's due to something bad about the proposal or some bad timing, no one really knows. The community is just being left in the dark to guess on things.
Good proposals that did gain attention from representatives do exist, like Claude's Optional Chaining you've mentioned (which surprised me because I was thinking about working on the same thing and unaware of any quality community effort already in progress), but it's undeniable that Claude's long-time participation on the list has helped a lot in this regard. While trust is also a factor, I'd hope that representatives can have more faith in contributions from not-so-familiar names. There are still good ones out there.
All these clues are hinting toward one direction - that we need a place to collaborate on community-driven efforts, a place we can list out all past and current community proposals - who's working on what already, how things need to be improved, why things were being turned down, and most importantly: get transparent feedbacks on how these proposals fare inside TC39.
***Due to Ecma International's IPR policies***, such endeavor will be extremely difficult to be initiated from TC39's side, and that's why I reached the conclusion that the only way to possibly address this whole community involvement issue is by installing a member organization that represents the community itself, thus "hacking" through the restrictive structure that Ecma International abides by.
So the plan is trying its best under the rules of Ecma International to put an end to the already existing "us-vs-them" sensation - not the other way around.
Time is not enough: Yes, just like, always, no? ;-) With a more organized community at your side, we can help tackle existing proposals, too. Some proposals have been stranded for quite some time (eg. Relationships, ArrayBuffer.transfer); it's not very obvious to the community at all that whether they need more works, more debates, or the background and situations have changed and that they're no longer that important, etc.
A well-organized community can help with logistics and maintenances to make the information more readily available, so efforts can go where they need to go, and you (and people who'd like to wholeheartedly devote to drafting up proposals) can have more time to focus on things you're really interested in.
@John @Michał
ES6 expanded the language greatly indeed, but the expansion is incomplete with lots of glaring holes.
I happen to be researching into the crazily deficient Map/Set APIs recently as well, and found a few documents - only from 1.5 years ago but apparently are quickly falling out of people's memories - that hold the answer:
esdiscuss.org/topic/map-filter-map-and-more, esdiscuss.org/notes/2014-11-19, esdiscuss.org/notes/2014-11/Map.prototype-extensions.pdf
We wanted a generic Iterator prototype but (again) we didn't have the time, so we just left a giant hole in there without a timeline on patching it, and everyone who'd like to use Map for collections now have no choice but to turn to some 3rd party solutions like Immutable.js - which totally replaced ES6 Map/Set implementations with its own. This is kinda ridiculous honestly.
I think with enough community involvement being enabled, we can see some positive changes such as information on why some previous proposal has been turned down can become more transparent and organized; the need of some essential, hole-patching proposals can become more apparent with a clear direction, and potentially see some good ones from the community. Again due to Ecma International's IPR policies, we need a community member inside TC39 itself to enable this possibility.
This organization is definitely needed and is a laudable effort; the language has made great strides, but it's still in a state where utility libraries fill in gaps in basic functionality, and the current rate of improvement is very uneven, with certain issues that hold the language from becoming 'batteries included' not even being on the radar.
I'd suggest also having a wiki to document the results of discussions without the additional noise; this would promote research, since there would be a more visible venue for its results, and reduce duplicate efforts by different people researching a topic.
I'll add that after much contemplation, it might not be a wise idea to delegate anyone who wish to attend a certain TC39 meeting as the nonprofit's representative; I cannot tell whether the advantages it brings could outweight the problems that would also come as a result. So perhaps we'll hold this part off for phase I.
By the way, judging from the information I've collected so far, forming such a tax-exempt nonprofit legally in my country would take at least half a year, so we have much time to debate on the details.
I think this is a very interesting idea. TC39 has put a lot of effort into community transparency over the last decade but Ecma International (really most international standards organization) is organizationally not structured or naturally inclined to directly accept “contributions” from individual. Changing this within Ecma has been and will continue to be a slow and sometimes frustrating process. The idea of a NFP joining Ecma as a community surrogate is an interacting way to approach the problem. I think it could work.
However, while the idea is simple enough the actual process of building and sustaining such a NFP is not so simple. Kevin Smith has already raised some very valid cautions about this. In particular, his cautions about the amount personal time required of you (or any other individuals sharing leadership respondability of the NFP) should not be ignored.
But, I think this really could be a viable solution if you and other organizers of the NFP are sufficiently motivated and committed.
I’d happy to act as an adviser as you try to get this organizers.
Allen
PS, you might find this provides some useful background
thanks for extending your support :-D
My observation as well as belief is that, if a community effort has turned out to be successful, than volunteers will flock together and the movement / organization will be able to self-sustain for quite long enough. So the issue has always been how to make sure a community effort is on the right track toward success from the get-go.
For this specific effort, at this specific stage, I think what we need right now is to add more credibility to this whole endeavor (since I'm not a familiar, high-profile figure), so I'm going to spend some time doing research to put forward a more concrete plain written down in plain text, and just go ahead with it. I believe with each progress we'll eventually attract more interested parties and once we garner enough attention and participation, we'll solve the "not-enough-time" problem. Hopefully. We'll see ;-)
Again, very glad to receive your support. Will keep you posted whenever there's some new progress.
Excuse my ignorance, but why do we need the legal organization, why to not simply do the GiHub part?
Just an educated guess (I'm not actually involved in any part of this effort - just a random person subscribed to this list), but I think it's because of ECMA itself. Granted, TC39 has already noted that this one doesn't exactly fit well with the rest of their framework, because of the constant and frequent input, and because the software industry moves a lot faster than the hardware and electrical engineering industries (that's most of what ECMA deals with).
On Jun 6, 2016, at 3:21 AM, Salvador de la Puente González <salva at unoyunodiez.com> wrote:
Excuse my ignorance, but why do we need the legal organization, why to not simply do the GiHub part?
en.wikipedia.org/wiki/Standards_organization, en.wikipedia.org/wiki/Standards_organization may provide some useful background.
Ecma international is a recognized SSO and as such it has policies and rules it operates under (www.ecma-international.org/memento/policies.htm, www.ecma-international.org/memento/policies.htm). Most relevant are the Ecma membership categories www.ecma-international.org/memento/members.htm, www.ecma-international.org/memento/members.htm and the Intellectual Property policies (www.ecma-international.org/memento/Ecma IPR policies.htm, www.ecma-international.org/memento/Ecma IPR policies.htm).
As it currently stands Ecma does not have a membership category for individuals. Instead, only organizations can be members. It’s possible that this could be changed in the future, but it might take a long time to do so. So, an alternative approach may be to have an separate organization that can be a Ecma member and that individuals can join.
For some background on why IP issues (particularly patents) are of concern to SSOs see www.wipo.int/patent-law/en/developments/standards.html, www.wipo.int/patent-law/en/developments/standards.html and ec.europa.eu/growth/industry/intellectual-property/patents/standards/index_en.htm, ec.europa.eu/growth/industry/intellectual-property/patents/standards/index_en.htm .
Finally, note that working through a recognized SSO helps companies avoid antitrust issues that might arise when developing standards: www.venable.com/legal-issues-affecting-standard-setting--antitrust-and-intellectual-property-04-01-2004, www.venable.com/legal-issues-affecting-standard-setting--antitrust-and-intellectual-property-04-01-2004
On Jun 14, 2016, at 8:57 PM, Isiah Meadows <isiahmeadows at gmail.com> wrote:
Just an educated guess (I'm not actually involved in any part of this effort - just a random person subscribed to this list), but I think it's because of ECMA itself. Granted, TC39 has already noted that this one doesn't exactly fit well with the rest of their framework, because of the constant and frequent input, and because the software industry moves a lot faster than the hardware and electrical engineering industries (that's most of what ECMA deals with).
Note that Ecma has a long history of developing software related standards. In fact the second standard issued by Ecma was for a programming language. www.ecma-international.org/publications/standards/Standardwithdrawn.htm, www.ecma-international.org/publications/standards/Standardwithdrawn.htm
Didn't know that. Nice to know! :-)
If you are referring to the standard ECMA-2 for a subset of ALGOL 60, this
was not a "standard for a programming language", but rather for a
particular ill-advised crippling of ALGOL, which not only removed own
(sort of static) variables, but much more importantly removed the key
feature of recursion, and bizarrely made identifiers unique only up to six
characters (!), probably at the behest of some manufacturer that had 6-byte
words, allowing them to claim that their implementation was "conformant" to
this truncated "standard". Hardly one of their best moments.
I have fond memories of ALGOL, in which I wrote a symbolic differentiation program one summer during high school, on a B8500 machine at Case Institute of Technology.
I will leave it up to historians to confirm that ALGOL was never standardized by a standards body; there was just the iconic "Report on the Algorithmic Language ALGOL 60".
-- Bob
On Jun 15, 2016, at 2:12 PM, Bob Myers <rtm at gol.com> wrote:
If you are referring to the standard ECMA-2 for a subset of ALGOL 60, this was not a "standard for a programming language", but rather for a particular ill-advised crippling of ALGOL, which not only removed
own(sort of static) variables, but much more importantly removed the key feature of recursion, and bizarrely made identifiers unique only up to six characters (!), probably at the behest of some manufacturer that had 6-byte words, allowing them to claim that their implementation was "conformant" to this truncated "standard". Hardly one of their best moments. ...
Yup, all true. but my point was simply that Ecma working with software (and in particular programming languages) is not new or unusual.
Thank you very much for this complete response.
From a curious on-looker: has there been any update on this plan?
(This is a continuation of a previous discussion)
So, to summarize, while rules and platforms currently in place do allow for community contributions, they are hardly friendly ones. A few issues:
The mailing list is a really awkward platform for community participants to collaborate, especially when debates and discussions can span months, even years; threads, reasonings, and important conclusions tend to become buried over time, resulting in a never-ending reincarnation of dead ideas and, more importantly, lose of precious lores and insights.
Self-contradictory rules about the processing of community proposals in official documents, because these rules were authored by a few different individuals without a definitive source.
The most widely circulated version of these rules demands community proposals to find "champions", ie. member representatives willing to serve as lobbyists; the real story, however, is that member representatives are very busy and, when they do have time, they will almost always lobby for proposals that their organizations or themselves are interested in. No blaming here because this is just the way human society works, which brings the conclusion that this requirement is simply antihuman.
In the previous discussion, Allen mentioned that a lot of efforts have already been put in place to make TC39 as open as possible under the bylaws and rules of Ecma International, for which I am sure every non-member participant of the standardization process is really appreciated. But I think there is still room to do better.
For that reason I intend to form a nonprofit organization and apply for Ecma membership to help further opening up the standardization process of ECMAScript to interested participants who currently do not enjoy the privilege of becoming member representatives.
I've been in contact with Secretary General Istvan and apparently this is doable as long as the General Assembly vote in favor of my application, so I think it's a good thing to raise this plan here and see if anyone has any good feedbacks or concerns, so we can iron out these issues during the early stage - or put an early end to it if there are some good reasons. A legally registered nonprofit with an official "tax exemption" status is the acceptance criteria for Ecma NFP members, but also requires me to go through a hell lot of bureaucracy and legal works and hold a few physical meetings with the presence of government dudes, so I'd really like to make sure we all like the idea (especially if you're a representative of an Ordinary member organization) before I'll go ahead.
The plan is (roughly) like this:
Once formed, this nonprofit organization will help TC39 by voluntarily overseeing and shepherding community participations. There will be a single set of clear rules on how to contribute.
Community proposals will be asked to be formatted as GitHub repos and be submitted in the form of GitHub issues to the nonprofit's GitHub project, and all discussions are expected to take place on GitHub. Dupes will be closed, related topics can be easily referenced, and past discussions can be easily searched.
Everyone can become a member of this nonprofit as long as an image copy of passport is provided (required by my home country's law). Members can rightfully become the nonprofit's representatives to TC39, and present their own proposals (or others' if they would) in official TC39 meetings. No longer do we need to force other member representatives to become "champions" or lobbyists - proposers will be their own best advocates.
In order to prevent TC39 from being flooded, some throttle mechanism will also be installed. Only 3 community proposals for one TC39 meeting at most. In case of more than 3 pending community proposals, we'll decide the priority of presentation by their GitHub stars. We'll also have a threshold on minimal star counts to weed out really bad proposals.
The nonprofit will delegate anyone who wish to attend a certain TC39 meeting as its representative to help make the standardization as open as possible; these representatives can help by participating in the discussions and providing more diverse insights to topics at hand; they will not however bring in additional proposals for that specific meeting.
This is still a rough plan, and everyone's feedback is welcomed so that the plan can be adjusted if needed to make this thing work as intended.
Again, if you're a representative of an Ordinary member organization, your input will be more than valuable.
Let's see if we can make things work even better for the community and the language.
G. Kay Lee github.com/gsklee