A plan to help TC39 become more open up to community contributions and participations

G. Kay Lee balancetraveller+es-discuss at gmail.com
Sat May 28 03:10:58 UTC 2016

@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:


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

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.

On Sat, May 28, 2016 at 10:41 AM, G. Kay Lee <
balancetraveller+es-discuss at gmail.com> wrote:

> 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](
> http://www.ecma-international.org/memento/Ecma%20IPR%20policies.htm)***,
> 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](
> http://wiki.ecmascript.org/doku.php?id=strawman:relationships),
> [ArrayBuffer.transfer](
> https://gist.github.com/lukewagner/2735af7eea411e18cf20)); 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.
> On Fri, May 27, 2016 at 11:50 PM, Michał Wadas <michalwadas at gmail.com>
> wrote:
>> 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.
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160528/b5f796a1/attachment.html>

More information about the es-discuss mailing list