-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose specification status #484
Comments
There are specs whose status is incorrectly captured as "Editor's Draft" in A related question is whether the But perhaps the question "is it standards track?" first needs to be expanded a bit. I see BCD defines |
Perhaps we do the work in |
This come up in today's WebDX call (alongside the related issue on browser-specs). I wanted to know what are the intended applications for this? The discussion on the call suggested that answering "is this eligible for Interop?" is one such application. I'm wondering what other concrete uses this might have, which might influence whether and how we expect consumers of this data to show this information to web developers. |
Here is the minutes from the WebDX call where this was discussed: https://docs.google.com/document/d/1ree75ImLZjf60lTZ3BhCaLHygxgywr7SBXp-q0xPs8A/edit#heading=h.1awrxbghdhfj |
It would be useful to expose the specification status of features, to distinguish features with a new and unstable spec from ones with a specification that's gone through a lot of review and has consensus. Roughly, to answer the question "is it standards track?"
There are at least two places we can get this information from:
release.status
andnightly.status
fields inbrowser-specs
standard_track
boolean in BCDI would expect that we couldn't infer everything correctly from these sources, and that we'd still need some manual overrides.
The text was updated successfully, but these errors were encountered: