Keeping proposals productive and increasing mailing list efficiency

[Mark]

Bob Myers makes a great point in the following message he just recently
posted on a totally unrelated thread. And I’d like to open a discussion up
about it because I share his sentiments tremendously. I’ve been on this
mailing list for quite a while now and while I do think its an awesome
channel to discussed proposed solutions, I do see a large number of
proposals and threads constantly being created that have already been
discussed many many times.

The points below are great, however, I think its a partial solution to the
real problem. I think the real problem includes the following:

   1. *there is no easy way to access some sort of prerequisite or criteria
   before creating new threads*. Does one even exist other than in people’s
   minds? I see there is an about page <https://esdiscuss.org/about>, but
   it doesn’t really have any checklist or recommendation of things to
   consider before opening a new thread. But even if it did, there is still
   the issue of accessibility which I identify in my next point….
   2. *previous related conversations are not being considered because they
   are not prominent or easily found*- they are kept in an archive that is
   totally separate from the email clients being used to facilitate these
   mailing list discussions. This means it is not likely that a person making
   a proposal, who is new to this mailing list format (which is mostly the
   case with new proposals), will even see the archives.

Another point: there are plenty of alternative solutions out there that
would make this list much more usable and efficient (discourse, slack,
GitHub etc), which have wide support and are reliable. Is there a reason
why this list hasn’t embraced any of these newer technologies? Although not
necessary, they offer strong feature sets that will make it quite easy to
provide solutions to the above points.
​

On Sun, Jul 1, 2018 at 2:03 AM Bob Myers <rtm at gol.com> wrote:

> It seems odd that after all these years of discussions and
> meta-discussions about ES feature proposals, some people are still saying
> things like:
>
> * there really needs to be
> * I'd really like
> * I'd love to have
>
> often without addressing a single one of the relevant questions:
>
> 1) *Is it sugar?* Is it "mere" syntactic sugar (which is not
> disqualifying in and of itself), or something that requires (or benefits
> from) being baked into the language?
> 2) *How much sugar?* If it is wholly or partially syntactic sugar, what
> the degree of syntactic optimization?
> 3) *Frequency of benefit?* What is the frequency of the use case?
> 4) *Expected improvement*? If it is something that would benefit from
> being baked into the language, what is the degree of the benefit (eg, in
> terms of performance)?
> 5) *Userland implementable?* Can it be implemented in userland code? If
> so, what's the downside of that?
> 6) *Implementable?* Does it present potentially difficult or intractable
> implementation challenges?
> 7) *Consistent?* Is it consistent with existing syntactic and semantic
> practices in the languages?
> 8) *Holistic?* Does it fill in some obvious logical gap in the current
> language design?
> 9) *Understandable?* Does it place an unsustainable new "cognitive
> burden" on learners and users of the language?
> 10) *Library?* Is is something that would be better provided as part of
> some kind of future standard library?
> 11) *Intrusive?* Does it take over real estate that might be useful for
> future features no one has thought of yet, the obvious example being using
> special characters?
> 12) *Readability?* Is it something that results in a distinct improvement
> in readability or visible semantic correctness of code?
> 13) *Prior art?* Has this or a similar feature already been proposed, and
> if so what was the reaction, and how is your proposal different from that,
> or from a similar features existing in other languages?
>
> I'm sure there are cases where simply throwing out an informal idea and
> seeing how people react is useful to get a discussions started, but most
> reactions will be that the proposal does not meet one or more of the above
> criteria, so proposers could save themselves and other people lots of time
> in advance by explaining HOW their proposal satisfies these points, not all
> of which are relevant to every proposal, but those which are.
>
> Bob
>
>
> _______________________________________________
> 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/20180702/53a7fc54/attachment.html>