Add controversial mark

[rumkin]

Add special mark (like 🚀) for controversial proposals, which need extra attention before been implemented, require more constructive discussion or should be delayed.

[ljharb]

That's generally something that you'd look at each proposal's repo to determine; it's pretty hard to make a general standard of "controversial", since by some metric, anything could be :-)

[rumkin]

I think good start point is proposals with probable breaking change like smoosh/flatten or globalThis.

[ljharb]

That sounds like you want to identify which proposals have web compatibility risks - which is basically anything that’s not syntax.

[littledan]

You can watch how a proposal moves through the stage process to see how settled it is. Many of us in TC39 are working to understand the broader community and ensure that this feedback is taken into account in the decisions about when and whether to advance (or retract) a stage.

[arcanis]

Maybe rather than a boolean it could be a metric such as the number of meetings during which the feature has been discussed? I guess "controversial" proposals have much more back-and-forth?

[rumkin]

@ljharb I'm talking about indication to community that some task need more attention. And if there is too much issues that has backward compatibility issues, then we need to find solution how to move forward without making choice between breaking changes and strange naming decisions again and again.

But this issue is not about backward compatibility only. It's about some notable discussions like this one. It was closed and new users or committee members should to make investigation to find it. It means that author of proposal could to manipulate opinions.

@littledan TC39 has great power and responsibility of the Web's future and I think it just could be a good form of noticing about it to all members of the process at both sides.

@arcanis It's very good addition. It's could be supplemented with a next discussion date and a link to short log with proposal history. For example like this:

2018-12-23 Moved to stage 1.
2018-12-20 Improvements required.

[ljharb]

The champion of a proposal would be the arbiter of such a mark on their own proposal here, too, so if they didn’t want it to show up, they’d be able to remove it. Are you implying that champions are acting in bad faith? I don’t think adding more noise to this table would address that problem (one I don’t agree exists).

[littledan]

If this is trying to solve a communication problem, I think it's already clear to the committee and community that private fields and methods based on # syntax and strong encapsulation guarantees is controversial. Nevertheless, the committee can still discuss it and come to conclusions.

[rumkin]

@ljharb

The champion of a proposal would be the arbiter of such a mark on their own proposal here, too, so if they didn’t want it to show up, they’d be able to remove it. .

Well, it's true while proposal is only a suggestion and has no stage level. Everything changes when it receive official status. JS is public property so there should be strict rules when and how to accept changes, when not, how to support discussion. Whole process should be transparent and open. Currently committee members are privileged.

Are you implying that champions are acting in bad faith?

No. I'm not about to blame someone. There is a human factor. Currently it looks like a train without stop-cock. I think there should be some clear process of how community can influence on the process. Situation with smoosh shown that there is some issues with that.

I don’t think adding more noise to this table would address that problem (one I don’t agree exists).

This table isn't in it's perfect form. It's already a little bit noisy (Rocket issue #161) and could be optimized to be more informative. Static unchangeable information like author and champion names could be removed from it completely and moved to section with short proposal description.

@littledan

Discussion of the private properties proposal is beyond the scope of this issue. It's just an example of such situation.

[ljharb]

There are strict rules on all of those things - and committee members are privileged by necessity; but this isn’t the place to discuss our process, either.

It seems like what you’re really interested in is a change in our process, and not just altering the information displayed in this table.

I think it’s useful to have the static information here, and the specific information (including descriptions) on each proposal’s repo, where it can be most easily kept up to date.

[rumkin]

There are strict rules on all of those things - and committee members are privileged by necessity...

Privileges without limitations leads to misbalance and incorrect decisions. There is already exists such situations and I mentioned them before.

but this isn’t the place to discuss our process, either

Where is other public place to discuss it?

It seems like what you’re really interested in is a change in our process, and not just altering the information displayed in this table.

I think that change of information could help to solve current problems without changing the process.

I think it’s useful to have the static information here, and the specific information (including descriptions) on each proposal’s repo, where it can be most easily kept up to date.

Well as final solution I propose to add a link to public discussion to each proposal. And thumbs up/down could be an indicator of community relation.

[littledan]

You can find public discussion about each proposal in its issue tracker. Maybe we should document that fact more clearly somewhere.

[ljharb]

Each proposal in the table already links to the repo, which is where all public discussion about it can be had.

[rumkin]

@littledan @ljharb

I see that this issue in current form is too general to have a solution or to find support from members. But I'm sure there are many possibilities to enhance current information model to make process more efficient. So I will create new issue with more strict and clear proposals. Thanks for your time.