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)

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}

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.

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.

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.

Whoops, missed that. Edited above.

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?

[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.

@martinthomson wrote:

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.

Agree 100000000%. I think that's also the view on the WebKit side.

Thoughts on the labels...

I think we need to deal with single implementer/browser specs as a matter of priority. Those are the biggest source of confusion/frustration and should be clearly marked as such. Things that ship are not necessarily Mature (or "active" for that matter!). Over the last few days, I've found examples where things have shipped, but there appears to be little in way of "incubation" and ongoing discussion in a repo.

Also, we are going to have tension about who gets to decide if an incubation meets the definition of "Abandoned". I don't yet know how we resolve that. We should try to figure that out using something like NetInfo (assuming we all agree that's been "Abandoned", right?). Or, to not stir up tensions and emotions, it might be better for folks that have shipped something they now consider "Abandoned" to put forward a proposal.

Also, unless something has shipped, I don't see the point of marking something as "Abandoned": that's because we can simply archive Abandoned things that haven't shipped.

"Dormant" incubations should be a call for action from the chairs. No incubation should be dormant for long - maybe 1 year?. It should be trying to get feedback and traction and on notice that it risks being archived.

"Mature" incubations should be in the process of trying to transition to a working group, which simply makes them "Active". The transition can sometimes fail for reasons (e.g., it might require a long wait for a group recharter). However, if they are Mature and look like they are "going to happen", then I think it's ok not to label them as anything (or just continue labelling them as Active).

Proposal for dealing with single implementer specs that we somehow agree are "Abandoned": I'm thinking we should use banner at the top of documents that can't be dismissed, that clearly states that "This incubation is abandoned and only shipping in one browser. This is not a web standard." And we make it clear that the document is only online because it needs a place to live (and where people can file bugs, etc.).

So, I propose:

• Active (default state) - there is demonstrable and ongoing developer and/or multi-implementer interest and discussions, issues being actively filed, etc. (e.g., Web Component repo). I should note that there are repos that are Active, which have succeeded that are on the way to successfully being archived (e.g., "inert" has been a great success, and once it ships in Firefox the polyfill will be "Abandoned" and archived)
• Dormant - little sign of the incubation being Active for about 1-2 years. Chairs and community should be trying to make it Active again and the work shows a warning banner at the top of the spec if things are not looking good and the incubation shipped in some browser ("This incubation is at risk of being Abandoned.").
• Abandoned (shipping) - we agree it was a mistake, but those shipping can't get rid of it because developers are using it or the shipping implementation is looking for a deprecation path that could take many many years.
• Archived - goals were met or it morphed into something else, or the people decided to stop working on it for now.

Also, we are going to have tension about who gets to decide if an incubation meets the definition of "Abandoned". I don't yet know how we resolve that. We should try to figure that out using something like NetInfo (assuming we all agree that's been "Abandoned", right?).

We do not.

I would consider NetInfo and other API shipped in a single engine as ones in maintanance mode. They can go back to being worked on as Active ones (e.g. such as this recent attempt for reviving NetInfo), or eventually being archived IFF they are no longer being maintained and are deprecated and removed from shipping implementations.

@yoavweiss, no problem. Can you suggest some other one?

(e.g. such as this recent attempt for reviving NetInfo)

Just noting that "recent" is 2 years ago. We need to reach consensus on some kind of reasonable time cutoff if things haven't gotten traction in X number of years... two years would fall outside at least my definition of "Active".

or eventually being archived IFF they are no longer being maintained and are deprecated and removed from shipping implementations.

Just to be clear, I'm not suggesting we archive it. I'm suggesting we mark it as "Abandoned (shipping)" - and we a banner in the spec.

Something like this for the banner:

Maybe a little more expanded:

Abandoned: This incubation is no longer active and only ships in a single browser. It is not a web standard and may not be suitable for broader use on the Web. Use at your own risk. [More info].

Let's pause this discussion for a week to let @cwilso get back from his vacation, as he explicitly requested.

And just so I'm perfectly clear: I do not consider shipped specifications in maintenance mode to be abandoned, and hence I do not think an "abandoned" label is appropriate.

I appreciate that Chris is away, but that shouldn't prevent us from spitballing ideas. I'm also away next week, so would prefer to keep going with straw-persons while it's all still fresh to me.

I also sympathetic that "Abandoned" might not be the right label.

So, let's see if we can come up with a better label for: "An incubation that shipped in a browser but, despite attempts, has not, and likely will not, graduate - and thus will not be adopted by a W3C Working Group or the WHATWG for standardization, which is the raison d'être for an incubation. However, the incubation is being used on the web by web developers so the spec needs to be maintained indefinitely."

I asked ChatGPT for some suggestions. A not-so-terrible suggestion was:

Community-Supported Legacy Technology: This label indicates that the incubation has not been adopted as a web standard by the W3C or the WHATWG, but is still being used on the web by web developers, and requires ongoing community support and maintenance. The label acknowledges that the technology is in use, despite not having been formally adopted as a web standard, and that it may need to be supported and maintained indefinitely by the web community.

This label highlights the importance of community support and maintenance for the continued use of the technology, and distinguishes it from other types of incubations that may be more actively developed or have a greater chance of being adopted as a web standard.

(I am not back from vacation; however, this bears mentioning now.)

It is absolutely not a consensus that incubations are "abandoned" because neither Apple nor Mozilla ships them. It is unfortunate that such a "browser veto" on what might be explored on the cutting edge of the web is being sought.

It is entirely appropriate that anything in the WICG (as well as ANY Community Group) be clearly identified as "NOT A WEB STANDARD". They are not. However, an incubation can clearly be a success - garnering participation from multiple vendors from across the industry, clearly solving a problem that web developers want solved - without having multiple engines implement that solution.

Certainly when one engine - no matter WHICH engine - ships such an incubation - knowing that it is not a "web standard", and taking responsibility to maintain it as such in their engine - you can hard claim that it has been "abandoned".

(vacation mode back on until Monday)

This was just brought to Edge's attention.

We have always worked in WICG and other standards as an independent actor, flagging features on or off independently, and often developing features downstream of other Chromium ports and offering them here later. As an independent vendor, we take the position that this proposal is aggressive, verging on the destructive.

The fact of Apple or Mozilla not engaging in a specific design conversation, while regrettable, is not anything like a lack of diversity of views or "abandoment". Likewise, the lack of implementations by some engines isn't a reliable sign to developers of anything more than an ongoing conversation. Escalating in this way is extremely counterproductive.

My impression from the discussion earlier in the thread is that an appropriate label for Netinfo would be “Dormant” with the banner @cwilso suggests. Whether that ends up being the case for Netinfo, I think a reasonable first step would be for WICG to identify which of its documents should at least be marked Dormant and given a “Not a web standard” banner.

I was going to send this to the public-wicg thread, but it seems to fit here.

Suggestion: for active incubations, how about adding the number of (shipping?) implementations? IMHO there's a big difference between incubations with 0 implementations, with 1 (active developer feedback happening, e.g. via usage metrics), and with >1 (should probably look at graduating to a WG).

This sounds similar to previous discussion here differentiating e.g. Dormant from Active, but further differentiating the state. Even if something has been in the 1-implementation state for a while, with the spec relatively untouched, usage metrics from the implementation can inform if developers are aggressively adopting it when possible, which might be a signal to other potential implementers.

As an independent vendor, we take the position that this proposal is aggressive, verging on the destructive.

@slightlyoff, you are welcome to propose alternatives. We are just throwing around ideas and invite you to be part of the process instead of getting weirdly defensive about us having a discussion about useful labels.

As for independence, yes: it's on a case a case basis, like it's been fantastic to see the Edge team's implementation on Web Share on MacOS and Windows 🙏 (things that Chrome doesn't yet support 🤞). For the purpose of conformance and standardization, that's exactly what we all strive for and want to see.

However, when code ends up getting upstreamed to a single engine, then that argument doesn't hold for obvious reasons.

So, Alex, what do you suggest for labels and how we might put clear signposts in specs?

Most of the conversation here is about stuff we don't agree on (yet), and I get it - that's hard and kind of loaded - but I'd also like to see us come up with good advice on how to deal best with stuff where we are successful. I believe we had a breakout session about this in 2019 at TPAC, but nothing really came from that.

For example: :focus-visible wasn't very long in incubation at all before it was 'taken up' by the CSS working group pretty quickly - but many of the actual details continued to be fleshed out first through the polyfill and experience/feedback. It's now shipping in 3/3 engines. So... What do we do with the repo? The polyfill is still potentially useful for some people for some time, as there are people who just can't update or browsers that lag downstream... But at what point are we done maintaining that too...

inert will be in that situation soon too, I hope as it finishes up interop work in FF this year...

What is the label those get? What happens to the repo/polyfill -- and when, I guess, should that happen (or already have happened)?

I think focus-visible should be considered to have graduated, at this point, and we should work to archive repos in places where the WG doesn't want them transferred. Is there anything other than polyfill that is important to maintain in the WICG focus-visible repo at this point? (The polyfill instructions would still be visible even if it were archived.)

Same for inert, if I read the tea leaves correctly.

@bkardell, we came up with a good plan over in Inert WICG/inert#195 (comment)

We should follow that for polyfills - and maybe even moving polyfills to their own orgs if things need to be maintained for a long time. Eventually, all polyfills get deprecated (because people move onto other things/companies) and there is support in distribution methods like npm.

Seems like a fine plan, although unless the polyfills need to be actively maintained, you could go ahead and archive their repo anyway - they'd still be visible even while archived.

To take @marcoscaceres’ remarks from above further, as a Web developer myself who sees themselves in the need for polyfills occasionally, I always struggle to find the authoritative one. What if there were a repo run by this group where all incubations, if applicable, hosted their polyfills in a subfolder? Ideally accompanied by an npm organization, so you can be sure that when you npm install @wicg/inert-polyfill, you get the authoritative one. I see polyfill engineering work separate from the spec authoring work (even if it can be done by the same person of course).

Back to the initial question, as the author of the NetInfo reboot effort, I just wanted to highlight that not all activity is world-visible or repo-visible. The reboot proposal is “stable” (as in: addresses the concerns with the existing API [in Chrome’s humble opinion]), and a partial “behind a flag” implementation exists. We also run an internal chat group where we discuss, among other things, relevant metrics we can see from Chrome telemetry.

This as a random data point to say we probably need some sort of $state-single-engine labels.

These can well be temporary, for example, CompressionStream was Chromium-only (shipped in Chrome 80, released February 2020), but now Safari 16.4 (in iOS betas and TP) ships it (🤞).

@marcoscaceres I’ve been told by @cwilso that you are working on gathering the information you will need to assign the dormant status to various incubations. How is that going?