distinguish standards-track drafts vs proposals #684
Conversation
distinguish standards-track drafts vs proposals right up front to help reduce confusion that WICG (or any CG) is standards-track (or in any way produces "standards")
|
So, I'm confused. Typically, Google will request positions here as a way of seeing if there is interest in moving something from incubation to standards track. Is that inappropriate? Because frankly, if something is already standards-track - e.g., it's already made it into a Working Group, not been Formally Objected to, etc, I expect there's a presumption asking about it here is not really worth the time. I agree, of course, that an incubation in WICG is not "standards-track", nor should WICG (or ANY other CG) be described as "producing standards". But the part we need to better define is how we build moment for an incubation to move TO "standards track" - and I thought this repo was an important piece of that. Is that not an appropriate view? |
|
@cwilso as I hope is obvious by the long list in https://mozilla.github.io/standards-positions/ and this README since this repo was established, there's a long history of requests for standards-positions on both specs in WGs and proposals being incubated. "interest in moving something from incubation to standards track" is a valid use-case but not the only use-case for standards-positions. I'm confused as to what here or elsewhere implied any kind of mutual exclusivity of use-cases. |
|
I'd propose saying something like: "This repo is where Mozilla decides and documents what it thinks about emerging technical specifications for the Web. Typically these are standards-track drafts in the IETF, W3C, WHATWG, or Ecma TC39. We will also provide positions on documents located outside a standards process e.g. those in W3C Community Groups such as WICG, but as a general rule believe that any such work must be moved to a formal standards track before it's appropriate for adoption as part of the web platform." Whilst the difference between CGs and the actual standards track is clear to people who are deeply involved with standards work, I don't think that difference is clear to everyone, and in particular I don't think we want to give the impression that a positive standards position on something in e.g. WICG is an endorsement for shipping that technology without first moving it to an appropriate venue. |
grammar edits, simpler sentences, and incorporate suggestions from @jgraham
|
@jgraham I've incorporated the improvements in the first paragraph which is all I wanted to do with this PR. Something like this:
might be more appropriate for documenting later in the README, e.g. after the descriptions of the positions, and we can discuss in a separate PR since it touches on more issues beyond the scope of the clarifications intended for this PR. |
There was a problem hiding this comment.
Thanks for spelling that out! One other layperson comment would be explaining the relationship between this repo in the process and https://github.com/w3ctag/design-reviews
That sounds orthogonal to this PR in particular. Could you open a new issue for this request? |
Yes, I meant that part as a reply to @cwilso's concerns, not as a suggestion for inclusion in the README. Apologies for not making that clear. |
There was a problem hiding this comment.
This is a useful distinction to be making, though I don't think we need to put it right up front like this. The README should give people a quick sense of what we are seeking to achieve, but this distinction is definitely inside baseball.
If you look at CONTRIBUTING.md, we sort of address this point already, though I think this distinction is useful, I would phrase it in terms of:
Mozilla will likely decline to provide a position on a specification that has unclear IPR status. Inclusion under the process of one of the above standards bodies helps avoid this issue.
Mozilla might also defer or decline requests for positions on proposals to those bodies until they advance further in the standards process. We would like to engage with proposals early, but do not always have the capacity to do so. Note: our exposure guidelines describe what we consider to be acceptable states for implementation or deployment; we welcome requests for less mature specifications, but might not always be able to provide a response.
Rewording welcome, of course.
| We may also provide positions on documents located outside a standards process, | ||
| e.g. those in W3C Community Groups such as [WICG](https://wicg.github.io/) | ||
| or other community incubation efforts with well-understood | ||
| <abbr title="intellectual property rights">IPR</abbr> terms, | ||
| but as a general rule believe that any such work must be moved to a formal standards track | ||
| before it’s appropriate for adoption as part of the web platform. |
There was a problem hiding this comment.
This text might be better moved to the CONTRIBUTING.md file where we have a lot more detail on how to ask for a position and what we require of people who are asking. This is a lot of detail to put up front.
| [IETF](https://ietf.org/), [W3C](https://w3.org/), | ||
| [WHATWG](https://whatwg.org/), and [Ecma TC39](https://github.com/tc39). | ||
| We may also provide positions on documents located outside a standards process, | ||
| e.g. those in W3C Community Groups such as [WICG](https://wicg.github.io/) |
There was a problem hiding this comment.
| e.g. those in W3C Community Groups such as [WICG](https://wicg.github.io/) | |
| e.g., those in W3C Community Groups such as [WICG](https://wicg.github.io/) |
distinguish standards-track drafts vs proposals right up front to help reduce confusion that WICG (or any CG) is standards-track (or in any way produces "standards")