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 02:41:42 UTC 2016


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/30a1a620/attachment-0001.html>


More information about the es-discuss mailing list