Will the community's dissent ever be considered valuable? #253
Comments
|
@bakkot My question wasn't about me as a 1-shot dissenter, but rather about what happens if/when the community, in some significant part, decides that the features of this proposal come at too great a cost, that the trade-offs give away more than they get back in value from the proposal given the interruptions to their well known, tried-and-true coding practices while trying to use the new features. As I've stated many times before, I understand well that the decisions that are so highly contested mainly came down to the mere subjective opinions of the TC39 members involved. I understand that the valuations in question were done with the best of possible intentions. What I do not understand is the process by which the community is to be given a meaningful chance to weigh in on decisions that will greatly affect how they use the language. |
|
I hope it's OK to interject briefly here...For starters, I assume TC39 would need to receive more negative feedback than positive overall, and not just in the GitHub repo for the proposal. Based on comments from committee members, I'm under the impression that the feedback here is not representative of the overall feedback (although there are certainly a lot of people with concerns, both here and in the community and large). |
|
@mbrowne I agree. Hence the question. How exactly is it that they expect to receive this feedback? I wasn't even consciously aware of TC39 until a few years ago when a search about So the reality is that it's likely, even though there may be a large population of developers who will be willing to give feedback about this proposal (be it good or bad), few if any will know how to do so. The few who do are likely people who follow various members of TC39 through social media. My question is about the official channel for submitting such feedback. |
That's the problem right there. That would require a blog post about every single angle. Also being able to transcribe the spec lingo in layman's terms is not a small feat. Personally that would take me days of research. Moreover, writing technical articles is quite hard in the first place. tl;dr: @rdking if you are really serious about this you will have to post a series of blog post on some platform like medium or/and create a competing proposal. Either way you will have to invest time and effort. |
Where can I find that "overall" feedback? Sorry if that sounds a bit silly, but I'm new here (studying the future language proposals) and I'm just not sure where else I should look at. I've seen SO and reddit questions, and to me, the overall feedback is negative and things like "That's the only way it could be done" and "I hope they know what they do (TC39)", and, honestly, that leaves me with many doubts about whether this should be implemented at all... |
|
@Mouvedia I'm preparing a follow up article to the one I already created on Medium. Just like before, I'm going to be a fair as I possibly can with the new article, but I'm going to dive into the nuts and bolts of the proposal, as well as expose details the alternatives that were presented but "failed to gain consensus". I've been investing time already. I just don't feel it to be of much use since it doesn't appear that TC39 is interested in any of the dissenting opinions since they've already "discussed those arguments to death". I also can't find where TC39 has put any mechanism in place for receiving feedback about the existing language beyond spec bugs. If ECMAScript were still a privately controlled language, this would make sense. In the end, while I'm grateful that they've put so much time and effort into trying to make this a good proposal, I believe their evaluative process has failed to take into full account how ES developers use the language. The result is something far more disruptive than it needs to be. If TC39 could just make it crystal clear how they intend to receive the community feedback that's supposed to be necessary after implementations have been released and before the proposal hits stage 4, then that would answer the question of this thread. |
You can't, at least not if I understand what I've been told thus far. This so-called "overall feedback" is the result of the various TC39 members meeting with various collections of people, walking them through the proposal, explaining the highlights, and generally getting a feel-of-the-room from that. Not a very rigorous process, and impervious to scrutiny. Statements like
are patently false. Without changing any of the developer-visible semantics, I produced a proposal that doesn't contain any of the problems inherent in class-fields. I also produced 2 other proposals beyond that. Several other members of the community, including some TC39 members, also produced proposals. All of them should have been received as viable candidates. However, only 1 ever did as the developer could serve as his own champion. |
|
@madroneropaulo The committee members can speak to this better than I can, but I was referring to the kinds of feedback @rdking alluded to, which also includes outreach to various open-source communities, discussing the proposal at conferences, feedback from prominent tech companies, etc. as well as implementation feedback from browser vendors and the node.js team. I assume that TC39 is continuing to receive such feedback, and if it were to suddenly turn significantly more negative now that it has shipped, then they might have to reevaluate some things. But the risk/benefit of making changes at this point is very different than it was when the proposal was stage 2. It would have to be something pretty severe and unexpected at this point to warrant changing the proposal in any big way, considering that people have been waiting for private fields for decades and this particular proposal has been under intense discussion and vetting for a few years. But anyway, let's give the committee members a chance to weigh in. |
|
It hard to talk about "community", because we are talking about millions of developers of varying skill levels and engagement. Also, with no hard numbers to prove it and only personal experience through the interviewing - unfortunately, large part of "community":
Now, the number of people who actually write JS engines (or transpilers) is very low. AND most of them are on TC39. This creates a situation, where people who implement tools and people who use tools - talk to each other less and less. Is this bad ? yes. How bad it is ? "its normal". Look at java9, http1, css3, xhtml, es4 and many other examples. JS is not unique and not the worst. I don't think we will get anyone to listen at this point of time, but failures of few new additions in a row will maybe serve as an examples (and learning experience) for current generation of TC39 leaders so they will become better at language design. p.s.: in theory, anyone can go an write Babel plugin or a sweetjs macro for new syntax, but somehow we don't see it happening. Most people (like me) like to wait till someone makes a proposal, and then p.p.s: most of discussions had really ended months (or years) ago, and - naturally - developers are busy people, they don't see the point of explaining same thing over and over again. and finally: when "community" repeats the same objections, and starts spamming other channels - then even less discussion will take place. Lets all be more constructive - and maybe future will get better. |
Babel, in the interest of not encumbering the development team with support of things they want to deprecate or rewrite, has no plugin API for new syntax parsing. This means it has a fairly high learning curve and requires a considerable time investment. Since, as you said, developers are busy people, it's no wonder you don't see it happening. As for sweetjs, I hadn't heard of it until just now so... |
(OT) A Babel plugin can provide its own parser, which could ba a fork of |
|
@nicolo-ribaudo That's good to know. However, it sounds exceedingly cumbersome, and it still requires learning the ins and outs of the existing parser. So there's really no time savings or learning-curve advantage there. In either case, I took the time to learn about sweet.js. Seeing as how I can use this to completely circumvent the design issues in both this proposal and As for the main topic: |
First, macros?
You will have to do that in the span of a few months. I don't think they are gonna rush it, after all it has the potential to split the community à la WHATWG vs W3C. Language design is hard, I wish they would listen and recognize the risk. |
SweetJS describes itself similarly to the macro preprocessor in C++, compiling their usage down to regular JS. It's got Babel under the hood and essentially provides the missing API for parsing plugins, but as a separate compiler. The point is to quickly provide a running implementation. I get that it would be essentially a different language. ES would also have been a different language than it is if the decisions regarding its features had been carried out in a more community-conscious way. So yes, macros first.
Why do you think I said:
? I avoid Babel like the plague in most projects. However, if it was as impractical as you claim, then Typescript would not be as big of a consideration in this process as it is. IMHO, it shouldn't even be a consideration at all! JS should lead TS, not be constrained by it. But oh well.
I know. Given that FireFox now has an implementation of this proposal, there's nothing at all preventing them from shoving this undesirable proposal into the spec and then forgetting its there. Regardless of the timing, I still want someone from TC39 to define a definitive means of allowing the community to tell them when they've screwed up, despite the best of intentions. It's in their documents that this is a pre-requisite to reach stage 4, yet the method of collecting that feedback is not defined. This is obviously a contentious and controversial proposal. None of them can deny this with any sincerity. As a public committee working on a public project, I just want them to be more forward about having a well defined process so that issues like what happened with this proposal can't easily be repeated. If "1 bad apple spoils the barrel", then the bad trade-offs in this proposal are spoiling it. If it becomes a permanent part of the proposal, it may become one of the bad apples that spoils the language. |
|
@rdking https://developers.slashdot.org/story/19/07/21/026232/go-abandons-try-function-proposal-citing-overwhelming-community-response I don't have an opinion on the matter but it seems like with enough backlash, it can be done. |
|
Sadly, I think it's probably already far too late. TC39 already has its opinion set and seem to be ardently against any reason that differs from their opinion. Short of having a board member feel the pain this proposal threatens to bring first hand on a major project within a relatively short amount of time, it is unlikely that this proposal will be rolled back. |
|
Yeah, everything about the way that this has been handled has been very disheartening. |
|
That's the reason I opened this thread. There are so many things that are a part of TC39's proposal process (if I am to believe the documentation) that are so non-descript as to leave the reader thinking it's up to dumb luck to even get anything started. Yet these are supposed to be important steps in the process. I know they mean well and their intentions are good, but I feel as though they proved the cliché with this proposal. |
|
I'm really grateful for all of the energy people inside and outside of TC39 have been putting into feedback on this and other language feature proposals. It is really helpful for us in all aspects of development to have this information, and has really positively influenced this proposal over the years. Inevitably, there are some "one or the other" decisions to make. Not everyone's preferred option will be chosen, since sometimes that's just logically impossible. (And not doing the proposal is also a dispreferred option for some.) In these situations, I hope folks can understand that we do the best we can with the information we have, and try to make reasonable tradeoffs. I hope we can improve community and inclusion to make better tradeoffs over time. Efforts here are best focused on Stage 2 and earlier stage proposals, where champions are especially interested in figuring out where to land on these big decisions, rather than Stage 3 proposals where the committee has made a lot of particular calls based on the accumulated input. |
|
Thanks for making it perfectly clear that community opinion no longer matters after a proposal reaches stage 3. That little bit of knowledge alone may save TC39 a great amount of time fielding dissent when it's already too late. On the whole, I agree with what you've said, but there's a small albeit important problem with it.
There were a great many of these in this proposal. Recognizing that earlier, I asked on several occasions for a summarized list of constraints that were used to guide the decisions on what was chosen, only to discover that at no point in the process is this information ever collected. While I understand that committee design is a living process, a requirements document should also be a living document. The FAQ does not cover this, despite the many additions and clarifications. Another point to make is that many of what TC39 considered to be "one or the other" type decisions weren't. My suggestion to you is simply this: when you encounter "one or the other" type decisions in the future, treat it like a mathematical singularity and change your coordinate system until the singularity disappears. "One or the other" decisions are often only so do to choice of perspective. |
|
Community opinion always matters. However, that it “matters” does not guarantee that anything will change - it means that it is considered thoughtfully, and taken seriously. |
|
By "no longer matters", I am saying that dissenting opinions regarding such a proposal are no longer enough to sway TC39 from pushing forward with the proposal unless it comes packaged with proof of a sufficiently damaging flaw. Even in that case, the proposal will continue to be forwarded unless the flaw is considered individually crucial enough without being able to be reasonably corrected. Before stage 3, dissenting opinions delivered in enough quantity from the community may still have enough chance of swaying the outcome. However, at stage 3, only a major flaw can derail the proposal, so community opinion no longer has sway, i.e. no longer matters. Is this not the case? If it is not, please elaborate. |
|
Same here, looking for an elaboration. To me, saying fixing something matters and, at the same time, completely ignoring the issues, without even addressing them/documenting them, doesn't seem like something someone/organization in the position of leading a language should be doing. And I hope we don't have deadline to release a proposal. |
|
Dead silence on this thread for a full month. Is this confirmation that my previous post did indeed describe the situation accurately? I cannot help but believe so since this is also how TC39 reaches consensus, by lack of open dissent. |
|
I would also argue that community opinion hardly mattered at stage 2 either in this case, since the private fields portion of this proposal was merged in at stage 2 and it was only a few months before it was moved to stage 3 after that. Which I still don't believe anyone in TC39 has addressed any of the comments stating this. |
|
Wouldn't it be possible to split the current class fields proposal into one about public fields and another about private fields, and then demote the private fields proposal back to stage 2? In that case, discussion could actually be had on the specific feature of private fields while public fields (which most people seem to be fine with) can actually go on and become a part of the standard. It doesn't make sense that one controversial feature is being lumped in with another relatively accepted feature. Edit: I just found tc39/proposal-private-fields#113. Unmerging them would have the immediate benefit of allowing public class fields to continue while allowing more discussion on private class fields. |
|
@iczero no. they were previously split - first publics vs privates, then statics vs instances (or perhaps the other way around, I can't recall) - and they were explicitly merged by committee consensus along with their getting stage 3. I can only speak for myself with certainty, but there would not be consensus to demote any of it nor split any of it at this point. Why it makes sense is because public field choices and private field design choices constrain one another - they can't really be conceptually split apart. Whichever one advanced first would constrain the later one, and these sorts of cross-cutting concerns are typically identified in stage 1. Sometimes, resolving them are preconditions for consensus to advance to later stages without parallel advancement of related proposals. |
|
@ljharb For the most part, I agree with @ljharb on that. But as always, I have a question. Isn't it natural for a public member definition design to constrain a private member definition design when the language doesn't directly support private members yet? It seems to make more sense to design the shortcut for adding public members (something that is already possible to do) well in advance of designing for private members (something that can only be simulated at present). |
|
Yes. All proposals at any stage may constrain all proposals at any stage, including proposals that don’t exist yet. Language design requires thinking holistically, which includes carving out space in a proposal to allow for a future proposal to fill it in. This also means that every decision is made knowing it might box out certain design directions in the future. |
... and that's where this proposal really bites IMO. It closes significantly more doors than it opens when it comes to the |
|
Do you know what I find funny? It's easier to get a TC39 member to speak up in defense of this proposal than it is to get a simple, straight-forward answer to a question about TC39 processes. I enjoy the discussions immensely, but seriously, can someone answer the OP in a crystal-clear way? |
|
The question has been answered repeatedly in this thread and elsewhere, for example here. |
|
Let me restate, because that (and others that you may be thinking of) never clearly answered the question in my head. By what procedure does TC39 determine that a proposal is unacceptable for each stage in the process, and at which stage do the opinions of non-TC39 affiliated developers cease to carry sufficient weight to affect the forward progress of a proposal? |
So the community isn't actually a part of the approval process, am I understanding that correctly? |
|
@bakkot From that comment, I get:
It's almost as if talking to a brick wall. A lot of people have expressed that they do not like the current proposal, but nothing has happened. The proposal moves forward anyways. The brick wall listened. Imagine the following situation: a new proposal is made and tc39 members think it's a good idea. 70% of the javascript community doesn't, but seeing as most of them haven't even heard of it yet, only some of them end up on github to express their opinions. Their opinions are promptly dismissed, because after all, they have been read. Then what? What use is feedback if nothing happens? |
|
@bakkot These guys share my opinion of things. That's the reason why I want to know the details of the process. From the outside looking in, it looks like opinions only matter when they're inline with what TC39 has a consensus on. That can't possibly be right, can it? Various of you have already admitted that in early introductions of the proposal, you made no attempt to expose any of the potential issues with the proposal, and thus biased your sample base for public opinion. Is this really the process? If it isn't, then please explain in detail. |
|
The procedure is that we discuss a proposal and decide if we consider it acceptable, in light of the feedback we've received and the details and implications of various decisions made. There is no stage at which the existence of developers who disagree with the design of a proposal is sufficient, on its own, to change that proposal (especially given that there inevitably exist other developers who disagree). There are always people who disagree with the design of any nontrivial proposal. As an example, a very large number of people were very, very angry that TC39 refused to ship
Many members of the committee, myself included, have spent years engaging with people on this specific topic. I can promise you that I have thought about all of the feedback. I continue to believe that this is the best design. People are not always going to agree with you. That happens sometimes. It does not mean you are being ignored. |
|
I suggest a tc39 proposal that actually codifies a way in which the community can reject a proposal given sufficient opposition. |
|
@brianjenkins94 Interesting idea, but if that effectively meant language design strictly by voting, it really would not work. Community feedback definitely needs to be incorporated, and even as an outside observer (i.e. not a TC39 member), it's apparent to me that there were some flaws in the process of gathering and considering feedback for this proposal in particular. But making good design choices requires a highly technical and intimate knowledge of language internals, which is why there's a selection process to be on the committee. Oftentimes people without such expert knowledge can provide very valuable feedback and ideas, and their perspective is very valuable, but at the end of the day that needs to be considered together with a lot of other factors. This discussion reminded me of how in NYC there's a relatively new position of "public advocate" in addition to the traditional elected offices, intended to be a direct representative of community interests. Of course it would be quite challenging to have a single person represent JS developers everywhere, and after all the current committee selection process is already intended to include developers who either directly represent or in any case consider the interests of the wider community. And then there's the question of how such an advocate would be selected, or how you would even notify JS developers everywhere about a nomination and voting process. Given all of these practical difficulties, I'm not suggesting to follow the public advocate model literally. But perhaps we could take inspiration from it...for example, if the wider community of JS developers were to come together a bit more cohesively in a single organization, perhaps there could be 2-3 representatives from that organization who would serve on the TC39 committee. Of course, such an organization would need to be very carefully set up so that it couldn't ever be taken over by leadership that only represented one perspective. Anyway, the bottom line is that while the current TC39 committee is obviously trying to serve the community at large to the best of their ability and according to their best judgment, there seems to be a disconnect where large factions of dissent in the community were not represented as well as they should have been in the discussions about this proposal. I'm not saying the committee was unaware of this dissent, but rather that there weren't many committee members actually acting as champions of it, which helped contribute to this public perception of it being the committee vs. the community. And I'm saying all this as one of the relatively few community members commenting in this github repo who's actually fairly happy overall with how this proposal turned out. While I support the committee and think it's full of great people who are often judged too harshly, I can understand why others feel a lot more bitter about it. |
|
I'm not necessarily saying approval-by-voting, but I wouldn't mind a killswitch. I would much rather the language not grow than it grow in an unfavorable direction. Not constructivethe current TC39 committee is obviously trying to serve the community at large to the best of their ability and according to their best judgment Unfortunately, I don't share your confidence. The way that this has been handled feels an awful lot like some special-interest group railroaded this proposal through to stage 4. |
Is that even true? As far as I understand, it's whatever companies that want to pay to be ECMA members, provide their own delegates. |
|
Last time I checked, @shannon is right. |
|
Ah, that must have been an erroneous assumption on my part. Well, I get the impression that there is some internal organization within the committee, e.g. longtime members mentoring newer members, but I don't know any details. If someone has a link with more details about internal organization of the committee, how companies get on the committee, etc., please share it. |
|
Honestly, from an outside perspective, it looks to me like a handful of companies pay 17k - 70k CHF a year to just do whatever they please with the language. There is no real open process here. Why should we all be beholden to these companies? Why do companies like Airbnb, GoDaddy, and Bloomberg get to make these decisions? Let's not fool ourselves here, this process is broken and far from open. Maybe someone should start a Kickstarter for a community driven ECMA membership with full voting rights on the committee. |
|
@shannon You could pretend to be a not-for-profit organization (which would be accurate in that case, as you aren't actually making any profit) |
|
@shannon I'm not saying this to disagree with you, but I just wanted to mention that Mozilla is also a member of TC39, and they're primarily more of a platform than a consumer of the language, FWIW. |
|
@mbrowne Well I mean they do make Firefox, so excluding them from tc39 would be an awfully bad idea. |
|
I didn't mean that in a negative way at all. Rather, I was bringing it up because I don't see why they would have a particular bias about the design of class fields from the developer's perspective. It was just meant to be a passing comment though; let's not dive too deep into this particular example. |
|
@mbrowne well I will say that I saw a real heavy influence from specific member company with regards to how this proposal effects proxies and the membrane pattern. Or more specifically how alternatives would effect their use case. Which was not necessarily invalid, I just use this as an example to show that a single ECMA member's use case can outweigh the community's opinion on the right design choices. |
|
@bakkot Thank you for providing such a clear response. That's what I was looking for. From what you've said, I can surmise that TC39 is not too unlike the US Electoral College in that there is absolutely nothing stopping you from completely disregarding and/or undervaluing the will of the community. Am I saying TC39 should devolve into a design-by-vote system? NO! I am, however, saying that the community needs to have the last word on whether or not a proposal approved and offered by ES becomes a formal part of the language (reaches stage 4).
This is undoubtedly true. However, there are numerous trade-offs in this proposal that, even if we accept everything in the FAQ, simply didn't need to be made. It's possible to construct several alternative proposals that keep consistent with the necessary semantics of this proposal that do not trade away so much of what developers are going to expect. It'd be one thing if only a small percentage of developers were to disagree with this proposal. However, because no substantial effort has been made to attract the attention of the majority of the community and gauge the response after a balanced discussion of the merits and faults of this proposal, TC39 doesn't know if it's just those of us who are aware and dissenting that will be affected, or if >50% of the community will be. That's flying blind. When a large % of the aware-and-vocal community are raising flags like this, that should be a sign that some rigorous validating needs to be done. That's all I'm really saying here. I have no doubts that unless I'm forced to by my job, or an uncrippled version of decorators is released, I will not be able to make use of this proposal in any project I work on. It's simply that bad. For others who use the language differently than I, this proposal may be a good thing. However, there was nothing technical preventing this proposal to be good for both them and developers like me. Anyway, as the question has finally been answered, I'm closing this topic. |
|
I think another problem with the current process is that TC39 members engaging in direct discussions with the community is entirely voluntary. Given this fact, we're actually fortunate to have some committee members who are as engaged as they are on GitHub. There are many other members who apparently are not particularly interested in hearing directly from the community, or in some cases I'm sure they're just busy, and the idea that they "should" explain their reasoning openly here isn't sufficient motivation. I'm thankful that @littledan said he's trying to encourage more committee members to be involved here, but it seems like this should be better built into the process and rules themselves. And I don't mean just forcing TC39 members to read endless GitHub threads and write obligatory responses; I would like to see something much more meaningful and genuine than that. As a part of this, we might need to explore alternative formats or better ways to consolidate community feedback. |
Is there a simple way to review Stage 2 feedback for this proposal, given that it is a merger of multiple proposals? It would be useful for those who were not involved at that stage to understand some of the decisions reached. |
|
The community will always have a say. The way forward is to do what Douglas Crockford did back in the 2000s: decide on the good parts of javascript and avoid using the bad parts. If you disagree with the proposal, you can:
The worst thing going forward is that members of the community who disagreed with the private class member proposal use them in an offhand way, and then have the tc39 committee point to this perceived usage as justification for other unpopular add-on changes to the language. We can stop that right here and right now by pledging not to use them and obstructing their progress in all the downstream projects of tc39. ✊😅 |
I am still interested in this if anyone knows more. |
The purpose of this thread is to discover if the ES community has any recourse for rejecting a proposal being pushed by TC39, whether it be this proposal or any other. There is already some precedent for proposals being removed:
Observer. However, the procedure and process for evoking such an event is likely not understood at all by any but a select few outside of TC39 itself.This thread is not about me and my desire, but rather about how TC39 reacts to the criticism that they have made a non-errant bad decision by many well informed members of the ES community, as well as by other members of the ES community who are encountering an inability to continue using common programming patterns while attempting to use features of the new proposal.
Recap from #150
@trusktr commented
@ljharb commented:
I commented:
@bakkot commented:
I commented:
@bakkot commented:
The text was updated successfully, but these errors were encountered: