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

Kevin Smith zenparsing at gmail.com
Fri May 27 14:42:55 UTC 2016

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:

1. 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.
2. 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 https://github.com/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!

On Thu, May 26, 2016 at 8:06 AM G. Kay Lee <
balancetraveller+es-discuss at gmail.com> wrote:

> (This is a continuation of [a previous discussion](
> https://esdiscuss.org/topic/tracking-proposals-should-be-standardized-with-issues
> ))
> 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](
> https://esdiscuss.org/topic/tracking-proposals-should-be-standardized-with-issues#content-17
> ).
> * 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
> _______________________________________________
> 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/20160527/92c8f107/attachment-0001.html>

More information about the es-discuss mailing list