Adopt new definition and guideline for experimental status

[ddbeck]

This PR:

• Proposes a new, hopefully clearer definition of experimental in the schema docs, for consumers. This is less an attempt to change the definition, so much as to describe what it actually is. It has an additional benefit of sidestepping standards questions.
• Proposes a guideline for setting and changing the experimental status, for contributors. This is an attempt to get consensus on how we set the status as PR authors and reviewers.
• Reformats the other status definitions in the schema docs for symmetry with the new definition.

That said, this is probably not complete. See my line comment on sunsetting experimental features. There's a wrinkle that I don't like and I'm not sure how to resolve it.

Fixes #6905.

[jpmedley]

What if the feature is in a W3C recommendation and it just happens that Safari reached the finish line first?

[ddbeck]

If Safari crosses the finish line first, then it's still experimental until at least one engine catches up.

Part of the goal here is to clearly distinguish between experimental and standard track. Under this revised approach, experimental can be set independently of the standard track value (that is to say, the two values don't depend on each other—you don't even have to know what the standards status is to set the experimental status). This makes it more clear what experimental actually adds to our data set (a marker of consensus, or failing that, stasis) and lets us deal with features that are unchanging, but not standardized.

[jpmedley]

I get all that. It just seems misapplied here. If a feature is a full W3C recommendation, it's not a matter of if the second browser will implement. It's a matter of when. Knowing that fact is useful to developers. This information can help developers make other vendors aware that they should prioritize something. Here's how this would play out for Chrome.

1. Safari implements a full recommendation.
2. Developers see that Chrome hasn't implemented it yet, but they want it.
3. They do one of three things: star an existing ticket on crbug.com, open a ticket on crbug.com, or they star the feature's entry on chromestatus.com.
4. Chrome management sees a surge in developer interest and decides to prioritize it over The Obscure API. (Developer interest isn't the only thing we consider, but we do prioritize developer interest if we see a lot of it.)

[ddbeck]

It just seems misapplied here.

First, a question: do you mean that the guideline and definition as written shouldn't result in this outcome? Or that you'd like to see different text that leads to a different outcome?

Second, what I want from this PR is to encourage the scenario you describe. Ideally, the experimental flag should be a signal to web developers to tell browser vendors and spec authors what they think of an emerging feature, including saying "I want this feature." I want to upstream the new experimental definition to MDN itself too, so this signal is stronger.

[jpmedley]

You overall heuristic seems misapplied to the case of a completely speced feature with one implementation, where 'speced feature' means one in a full recommendation.

what I want from this PR is to encourage the scenario you describe

The scenarios for a speced and unspeced feature are different.

• For features in candidate recommendations, or wicg specs, or whatever, the signal vendors need is should the experimentation continue?
• For features that are full recommendations, the signal vendors need is should we prioritize implementing feature X over feature Y? We have to do both because we agreed they should be part of the platform. Which do we want to do first?

Web developers would treat these differently as well.

• For truly experimental features, I may not want to use the feature yet, or my employer may not let me use the feature in production. My shop doesn't let me use an open source polyfill. (Yes, that's a thing. I worked in one. There were liability concerns.) My shop's approved framework says they'll support it with a polyfill, but it's not coming for six months. Perhaps I'm overly cautious because I previously embraced an experimental feature and it got dropped. (Remember WebVR?)
• For full recommendations, the most important concern with using is when will the other vendors catch up and will my framework support it in the meantime.

[foolip]

@jpmedley I'm not really following here. How good a spec here is actually very hard to judge, and browser implementers will not trust the status the spec claims for itself, whether that's "Unofficial Draft", "Living Standard", or "Recommendation".

I don't think we should use the spec's own claim about how stable it is as input to the "experimental" setting here, but base it entirely on implementation status, like @ddbeck is suggesting in this guideline.

[Elchi3]

I don't follow Joe either. I think this guideline is a lot clearer and I agree with @foolip and @ddbeck that it is good that we don't need to make any assumptions about the status of specs. @jpmedley feel free to start a discussion in an issue if you feel strongly about it.

Let's merge this. There is a lot of useful guideline work in here.