-
Notifications
You must be signed in to change notification settings - Fork 12
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
Standards venue #31
Comments
I'm unsure what you're asking; as noted, it will be integrated into HTML. Everyone is aware of the benefits of standards bodies. I prefer only to move things to such places once there is multi-implementer interest, to avoid standards bodies just becoming a place for a single vendor (in this case Chrome) to flood with proposals. |
It looks like you've requested a W3C TAG design review. Why have you decided to put this proposal up for review there (in a group which has limited bandwidth), and delayed consideration within a standards context on a more specific scope (e.g., HTML) which is likely to have significant time to evaluate it? It seems like the flooding consideration would go the opposite way. Standards venues give a neutral place to accept broad input, beyond a single vendor/champion group. I hope we get the chance for this feedback cycle within WHATWG if this proposal does move to HTML. WHATWG's strongest requirement in its working mode for additions is support from two implementations; I'm not sure what will happen within WHATWG if this proposal is promoted to WHATWG only once that requirement is met. |
Hey Dan, The TAG has a long history of reviewing single-vendor efforts, and personal projects that have not yet graduated to standardization. If you are concerned about that, I'd suggest you interact with them more directly. As I said, we are very aware of the benefits of standards venues. I would appreciate a bit less lecturing in that regard. We have a long history of promoting single-vendor projects to SDOs once they gain multi-implementer interest; this is fairly standard operating procedure. I'll repeat that this is an important mechanism to prevent the domination of SDOs by individuals or companies which have outsized clout by themselves. By keeping things as personal GitHub projects while they are still, well, personal projects, we have an important check and balance in the system that lets SDOs maintain more neutrality. In particular this avoids them becoming a place where insiders (like you or me) are able to give outsized legitimacy to their still-nascent ideas. Stated in TC39 terms, which you may be more familiar with, this proposal is still at "stage 0". Although members of the community are aware of it, and those (like the TAG) who are interested in being actively involved in the early design process have been proactively notified by the authors, this repository still represents a very early-stage idea that has no general agreement by the community on being "in scope" and worth promoting to the official "staging process" and the subsequent transfer of the repository into an official venue. I hope this helps. If you're interested in contributing constructively to layered APIs, I'd love to see you use your contacts to gather that multi-implementer interest. I'm happy to keep discussing this if it would be helpful to you or other members of the community. But I hope you can take the time to consider the tradeoffs of what you're encouraging, i.e. of allowing individuals to immediately push their personal projects to "stage 2" instead of first doing the "stage 0" work you see here. |
I'm not suggesting that things move straight to Stage 2 (meaning that we've agreed we want to standardize something) but rather Stage 1 (that it's under discussion). I think having inclusive discussion before definitively deciding that we're going with a proposal is very important. Until moving to Stage 1, where's the appropriate place to discuss suggestions like this? |
This repository is a good place, as evidenced by the existence of that thread? |
What standards venue is the Layered APIs infrastructure being developed in? I see it noted in this repository that the plan is to eventually integrate it into the HTML specification, but I don't see an indication here of how the current discussion and development relates to a standards body.
Working in a standards venue sooner rather than later has some real benefits:
The text was updated successfully, but these errors were encountered: