Clarify states of incubations - naming issue

[cwilso]

We need to be more intentional about declaring the state of incubations - whether they are active, abandoned, etc. I'd like to use this issue to assess consensus on some names for the "states" we think incubations can be in before filing a PR.

I would suggest the following states for an incubation, once it has been accepted as a proposal and moved into the WICG org:

• Active: actively being iterated
• Mature (or Stable): Incubation has stabilized, looking for review. In general, an incubation probably shouldn't stay in this state particularly long, as it will either move to a WG (ideal!), ship in an engine, or become dormant.
• Shipped: This incubation is stable and has shipped in one implementation. This state may persist for some time, if there is a lack of cross-implementer interest to move it to a WG.
• Implemented interoperably: This incubation has shipped in more than one implementation. This is a strong, strong indicator that this should have been moved to a WG to become a real REC-track standards feature. (Note this is mostly to use as we review old incubations.)
• Dormant (or Hibernating): this incubation was pursued for some time, but momentum has been lost and there is no active development on in. Someone may pick this up in the future and run with it.
• Abandoned (or Archived): this incubation was explored (and we want to maintain a record of it), but it was decided that it was (for one reason or another) a Bad Idea, and should not be picked up as is.

I'd be interested in input specifically from @hober @martinthomson @astearns @tantek @LJWatson @yoavweiss @travisleithead.

[astearns]

For the single implementation case, there can be a lack of cross-implementer interest OR interest with differing schedules/prioritization. Perhaps Shipped could be a modifier to other states?

Mature/Shipped (for those cases where Implemented Interoperably is eventually expected)
Dormant/Shipped (for those cases where more incubation will be needed to progress)

[travisleithead]

Shipping criteria will vary among implementers, and while it's possible that an Active/Immature incubation was shipped out of desperation or early customer-adoption pressure, it's more likely that the incubation was considered stable by that implementer at the time of shipping. To me, that makes "Shipping" and "Mature/Stable" very similar states... but there is weight behind having the incubation shipped (especially in it's ability to change), so tracking that state separately does make sense. I like @asterns idea of Shipped as an orthogonal modifier state. Even Abandoned/Shipped is quite interesting versus Abandoned/NeverShipped.

Not sure we need to track "Implemented interoperably" as this is something better left for MDN WebDocs/caniuse IMO.

I like the terms that mirror volcano stages: 🌋{Active, Mature, Dormant, Extinct}

[martinthomson]

So I think that the volcano stages are pretty good as a general framework. However, trying to tie in the orthogonal state of whether someone shipped something creates problems. So I agree with @astearns and @travisleithead that decoupling that from volcano stages is wise.That something has shipped (and to how many clients and servers) is useful information. It tells us that people are unwilling to wait for something to reach the sort of maturity that this process might aspire to.

I want to note here that we're generally opposed to shipping from any incubation state. Shipping constrains what options we have in terms of changing things, which is why we generally don't like the idea that WICG specs ship under any circumstances: it creates facts on the ground that constrain efforts to standardize.

As incubations, by their very nature, do not always have a whole lot of broad engagement, we would prefer if shipping never happened, short of achieving broad agreement that shipping was OK. Usually we make allowances for things like prefixed attributes or experimental protocol versions with temporary identifiers. Origin Trials work too, as they include similar provisions that allow for changes to the specification. In comparison, shipping creates a commitment to something without agreement.

[cwilso]

I think we are reaching consensus on two pieces of information:

State of incubation:

• Active: actively being iterated
• Mature (or Stable): Incubation has stabilized, looking for review. In general, an incubation probably shouldn't stay in this state particularly long, as it will either move to a WG (ideal!), or become dormant.
• Dormant: this incubation was pursued for some time, but momentum has been lost and there is no active development on in. Someone may pick this up in the future and run with it.
• Abandoned: this incubation was explored (and we want to maintain a record of it), but it was decided that it was (for one reason or another) a Bad Idea, and should not be picked up as is.

Additionally, we should capture and expose the number of implementations of an incubation.

[astearns]

To further decouple the incubation states from implementation/shipping states, I would change the definition of Mature to:

Incubation has stabilized, looking for review. In general, an incubation shouldn't stay in this state particularly long, as it will either move to a WG (ideal!), or become dormant.

[cwilso]

Whoops, missed that. Edited above.

[travisleithead]

Wondering if some of these signals can be folded into the ClearSpec effort? (Especially if related things are already being worked on for integration into ReSpec/Bikeshed?

[travisleithead]

[Co-chairs meeting]
Next steps:

• Annotate spreadsheet of incubations and assigne one of the above noted status values, as well as known implementation count to each row.
• Look into reflecting this status on our home page.