-
Notifications
You must be signed in to change notification settings - Fork 129
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
Define scope for w3c candidate recommendation #783
Comments
Typically a specification can go to CR when the "CR blocking" issues are resolved. Can we go over the open issues to determine which ones are CR blocking? I created a "CR blocking" label and added the label to a few issues encountered in implementation or issues that could surface soon (e.g. HEVC-related). Overall, quite a few of the open Issues represent "extensions", "questions" (many of which have been answered), implementation bugs or concerns which have been "overtaken by events". So some time spent on triage could probably reduce the open issues quite a bit. |
Good call Eugene, happy to do some triage myself offline to weed out irrelevant issues and the like as Bernard says, and then we can do a focused call on scoping for CR, possibly with a W3C person (that has been using when doing the CR for the Web Audio API). |
This is something I raised in the Media WG meeting yesterday ;-) When we have a call I suggest making this a WG meeting, or at least with chairs and team contact. |
The spec hasn't been evolving so rapidly in the past year and user agents are catching up on the implementation. This is probably a sign that we can move forward with candidate recommendation.
In order to do this, spec editors need to agree on the spec version for a candidate recommendation snapshot.
The text was updated successfully, but these errors were encountered: