Insufficient time allotted for acceptance testing `[[Define]]` semantics

[rdking]

In #176, I raised a simple question:

After the direction settled on Define, was sufficient time given to babel trials to ensure a reasonable level of acceptance from the public?

to which @nicolo-ribaudo replied:

I don't know what is considered "sufficient time", but:

[[Define]] has been opt-in since 6.19.0 (2016-11-16) [[Define]] was enabled by default in 7.0.0-alpha.20 (2017-08-30) The first stable version with [[Define]] enabled by default is 7.0.0 (2018-08-28)

Thanks for the dates. Now when did this proposal go to stage 3? From https://github.com/tc39/proposals, that looks to be 2019-01.

Notes:

• Having [[Define]] be an opt-in option is non-compelling since most won't unless they really need the feature for something. [[Define]] breaks things so I don't believe there would be much need.
• Having it by default in an alpha release is also non-compelling since it's hard enough to get a company to allow you to use the latest version of a package, let alone any pre-release version. So that excludes use by most developers.

Given that, the release data of v7.0.0 (2018-08-28) should be considered the most viable start date of the exposure. That being the case, only during this 4 month window did anyone have a real chance of having to experience [[Define]] as the default state. It can be reasonably surmised that even this wasn't the case as most places do not immediately update their supporting tools immediately after a release.

How much of that 4 months can actually be attributed to acceptance testing is an unknown. So even if we give this situation benefit of the doubt in the face that there actually may have been some who opted-in during the past 2 years, and some who used the alpha, let's be generous say we've got a full 4 months of of actual developer experience with the [[Define]] semantic before this proposal was pushed beyond non-TC39 developer consideration (I say it this way because according to @littledan, once a proposal hits stage 3, developer opinions no longer carry the weight required to change the direction of the proposal unless a major flaw is found as a result).

---

Ok. Here's the question: Is 4 months really enough time to gage developer acceptance for such a disruptive change, especially when no formal data collection is happening to measure developer acceptance?

[MichaelTheriot]

I raised similar concerns in another issue thread.

Review the commits to the repositories that eventually merged into this one:

Date	Proposal	Commit
2015-01-01	Private Fields	Created
2015-09-14	Public Fields	Created
2016-03-31	Private Fields	Stage 1
2016-07-19	Public Fields	Stage 1
2016-08-04	Public Fields	Stage 2
2017-05-14	Class Fields	Created at Stage 2
2017-06-08	Public Fields	Merged with Private Fields
2017-06-29	Private Fields	Merged with Class Fields
2017-07-27	Class Fields	Stage 3

It is difficult to follow the history of this proposal, at least on GitHub.

E.g. one loosely follows the Private Fields proposal, notable for introducing the # sigil:

Date	Repository	Commit
2016-03-31	Private Fields	Reached Stage 1
2017-06-29	Private Fields	Merged into a preexisting proposal at Stage 2
2017-07-27	Class Fields	New proposal reached Stage 3

One would observe the proposal at Stage 1, and less than a month later at Stage 3.

Just my opinion, it should be easier to follow these proposals with accurate updates. I speculate there are a lot of internal workings obscured from the people these proposals ultimately affect.

[bakkot]

The history of these proposals is more complicated than any other since the adoption of the current process, as far as I'm aware, and the merger in particular was not as well documented as it ought to have been.

That said, generally speaking I'd recommend following the proposals repository if one is interested in tracking the progress of proposals. For example, you'd see private fields advancing to stage 2 in December 2016, being merged into class fields in May 2017, and the combined proposal advancing to stage 3 in July 2017 (in all cases within a day or two of when TC39 had consensus on those decisions, I believe).

[shannon]

@bakkot does TC39 think this is an appropriate amount of time to engage with the community before advancing to stage 3? A generous estimate of 7 months which would have required the community to also follow this, as you stated, undocumented process. And the more realistic estimate of 2 months where most would have been watching the public fields proposal independently (as I was).

According to the process, at what point is the community feedback sought out, considered and acted upon? Or is it just up to the descretion of the proposal champion?

[rdking]

@shannon have a read through the last few posts of #253. @bakkot answered that question there.

[shannon]

Well I'm just going to say that I don't think this was an appropriate an amount of time. It's incredibly frustrating since TC39 members have stated that these conversations would have been better during earlier stages of the proposal.

This proposal was rushed, yes I know you have been talking amongst yourselves for years, but it was rushed. At this point browsers are shipping, one TC39 member has publicly stated that they will block this proposal to stage 4 in its current form, and there has been irreparable harm done to the language and developers.

It's terribly disheartening that this is the state of the process for the language I love so much.