Will the community's dissent ever be considered valuable?

[rdking]

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

Has anyone here posted objections to class fields in the issue trackers of browsers that are implementing class fields? Maybe that could help.

I started with two:

• https://bugs.chromium.org/p/chromium/issues/detail?id=962192
• https://bugs.chromium.org/p/chromium/issues/detail?id=974686

@ljharb commented:

The response on both of those was "we are not interested in deviating from what TC39 has decided". Considering that representatives of all the browsers were part of this proposal's consensus, it doesn't seem a viable course of action.

I commented:

While the may not be "interested in deviating", that does not mean that if enough issues are raised, they wouldn't be willing to consider it necessary to remove the implementation.

@bakkot commented:

All of the major vendors participate in TC39 already. Please do not spam their issue trackers and waste the time of their triage people.

I commented:

@bakkot I understand the nuisance of such developer useless spam all too well. I don't want to see that happen either. So that raises a very direct question: How does the community at large go about getting TC39 members to recognize and accept that this proposal in its current form is introducing unacceptable issues? What will it take? Or is it TC39's stance that there is no recourse for the community should it reject use of the proposal?

@bakkot commented:

@rdking The process for you to get TC39 to agree with your position is for you to convince TC39 of your position on this issue tracker. If there are issues which we have not already discussed to death, feel free to bring them up. (As I've said several times, repeating issues we've already discussed at great length is unlikely to convince anyone of anything.)

If you can't convince TC39 of your position here, spamming browser vendors elsewhere is not going to help anything.

[mbrowne]

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.

[MichaelTheriot]

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.

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.

[brainkim]

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:

• Personally never write code with private class members.
• Discourage coworkers and collaborators from using private class members in code review.
• Write blog posts and essays discouraging their usage. There are many compelling arguments against private class members which aren’t “the syntax is ugly”; they’re just tucked away in github issues with 100+ comments.
• Write ESLint rules which disallow private class members.
• Object to the implementation of private class members in browser/compiler issue trackers.

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.

✊😅

[MichaelTheriot]

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.

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.

I am still interested in this if anyone knows more.