tc39 / process-document Goto Github PK

Process documents seems to be invalid in regard of champion required. See tc39/proposals#71 for details.

We discussed #15 in TC39, and several committee members (including @wycats @ljharb @zbraniecki and others) had this great suggestion: When moving from one stage to the next, or any time later, the committee and champions may articulate further things that need to be done to move to the following stage. We might want to write this down in the process document, or in a separate guide for how to champion proposals/be a committee member. We've been doing this sometimes, often in earlier stages; it may be useful for advancing from Stage 3 to 4 as well, articulating web compatibility, implementer experience and buy-in requirements specific to the proposal.

Once a proposal reaches stage 3, it makes sense to file implementation tracking bugs for ChakraCore, JavaScriptCore, SpiderMonkey, and V8, and to link to them from the proposal repository’s README.

Can we make this a post-Stage-3-acceptance requirement? For many stage 3 proposals, it’s currently unclear if bugs have been filed against every major engine or not just by looking at the repository.

In stage 1, the following is an entrance criterion: ‘Identified “champion” who will advance the addition’.

Suggestion: state explicitly whether the champion must be a member of TC39.

Quote from Process Document

There are four “maturity” stages. The TC39 committee must approve acceptance for each stage.

After these sentences goes table named Maturity Stages which has 5 rows from Stage 0 to Stage 4.

It's not clear if first sentence above should be

There are five “maturity” stages.

or there should be a note that there are four maturity stages and Strawman stage

Continue the discussion in https://github.com/tc39/proposals/issues/236

From @mathiasbynens

...having a repository should be a requirement, even for stage 1. I'd go even further and claim that every feature proposal that is presented to TC39 needs a repository of which the README addresses the requirements outlined in the process doc.

From @ljharb

If someone thinks a repo should be a requirement, an issue or PR to the process document is appropriate, but not here :-)

So I create this issue. 😀

Are there any dates of feature freeze? It'll be helpful to add this info to Process Document.

All I found is that

TC39 may submit for approval to the Ecma General Assembly a new Edition of the ECMAScript language in March and September of every year. Additions which have been accepted by the committee as “finished” (stage 4) may be included in a new Edition.

But it's not clear what's happening on March and on September.

Seems really relevant.

Now that we have an editor group instead of a single editor, I am unsure whether every member of that group must approve spec text (in the case of stage 3 entrance) or pull requests (in the case of stage 4 entrance). Are we to assume that any member of the editor group always speaks for the group?

Also, in the case of editor changes, does the approval of someone who was the editor at the time of the approval count as editor approval? What about approval of someone who was not the editor at the time of approval but is now the editor or a member of the editor group? I ask this not simply to explore the theoretical dilemmas but because I have already run into this with one of my proposals. And given we now have an editor group, I expect editor role changes to be more common than they were in the past.

Mentions of current and former editors for their input: @allenwb @bterlson @ljharb @bmeck

In the recent process update, I wrote down that we do not have a formal concept of rejection. However some things should have a strong message from the committee that "we currently think this is a really bad idea" -- that may be stronger than a block.

When proposals don’t have repos, it’s not generally possible for people outside of TC39 to provide feedback or discuss in a way that will be visible and recorded for others. Right now there are four such proposals that are at stage 1. I’m surprised a public repo isn’t a requirement.

(Was hoping to provide feedback on / a suggestion for Map.prototype.updateOrInsert.)