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 <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
