Consistent usage of ‘proposal’ instead of ‘spec’ #151
Conversation
See the thread at https://twitter.com/alanstearns/status/1507506854171078658 WICG should try to be consistent about the CG documents being proposals.
|
See also #98 |
|
Thanks! :) Regarding this PR (and the twitter thread you linked to), it seems worth noting that "proposal" and "specification" are not synonyms. Some proposals may only have explainers (or not even that). Others may have specifications, which could be a rough outline of their design or a fully interoperable specification explaining their processing models in detail. |
|
I think you must have misunderstood #98. It is actually quite important that CG incubations be considered "Specifications" - because the CLA (https://www.w3.org/community/about/process/cla/) applies to Specifications, and the intent (as captured in #98) is definitely that the CLA cover proposals as contributions. Additionally, "specification" is (as Maciej said: https://twitter.com/othermaciej/status/1507508045240102913) a quite general term in engineering, and it applies here regardless of interoperability or REC-track status. I do think WICG documents need to be clear they are incubations, and not REC-track "standards" - as ALL CG documents should be (nothing in a CG, even one with more formal rules such as the Privacy CG, have any more weight as a "standard"). I'm open to other ideas to improve the misunderstandings, but trying to rename specification to something else isn't the right approach, IMO. |
| @@ -1,7 +1,7 @@ | |||
| # WICG administration repository | |||
| This repo is for administration of the community group. | |||
|
|
|||
| * [Home page - wicg.io](https://wicg.io) - includes links to active specs. | |||
| * [Home page - wicg.io](https://wicg.io) - includes links to active proposals. | |||
There was a problem hiding this comment.
The link is actually to the proposal's repo homepage. In most cases, that's a spec, although some may point at an explainer if that's all they got.
| @@ -24,7 +24,7 @@ The following is given as guidance. It's is not a requirement for starting work | |||
| 1. **Join the group**: Before bringing the above to the group's attention, <a href="https://www.w3.org/community/wicg/">join the community group</a>, which means you agree with the terms of the <a href="https://www.w3.org/community/about/agreements/cla/">W3C's Community Contributor License Agreement</a> (CLA). It's critical if you first <a href="https://www.w3.org/community/wicg/">join the group</a> or else key members won't be able to review or discuss your proposal. | |||
| 1. **State the problem, make a rough proposal**: Write an informal description of a limitation with the Web platform and post it to <a href="https://discourse.wicg.io/">Discourse</a>. This should be something you believe is missing in the platform and would make the lives of developers significantly easier if it were added. It can also be something you've noticed is a recurring development pattern which would benefit from standardization. If you have a rough proposal for a solution, spinning up a public GitHub repo from your own account is probably the best way to disseminate it. It's fine if your proposal is totally rough and informal - include code examples, diagrams, or whatever you think helps explain the problem best. Be sure to examine use cases. This can be informally in the Discourse post, or a short document in the repo. Such a document can help prove to the community that there is indeed a need for a solution that needs standardization (see the <a href="https://usecases.responsiveimages.org/">Use Cases and Requirements for Standardizing Responsive Images</a>, for example). | |||
| 1. **Evaluation**: As a community, we will use Discourse to evaluate interest and ask for potential editors for the proposal. As soon as sufficient interest is shown in the discourse (notably from potential implementers), the WICG chairs will enable a team of editors to manage the proposal (based on the discourse), and those team members can move ownership of the GitHub repo (if any) to WICG. We will expect all previous contributions to the proposal to have been made by WICG members, or will need explicit CLAs from other contributors - ask the chairs for assistance if needed. | |||
| 1. **Editing and Refinement**: The community should incubate and refine the proposal, through discussion on GitHub issues on the repo (and Discourse, if appropriate) until they feel the proposal has sufficient support and resolution to move to an appropriate Working Group; at that point, the editing team should contact the chairs, and the chairs will help do an "<a href="https://w3c.github.io/charter-html/request-to-transition.html">intent to migrate</a>": where we move the spec to a W3C Working group to seek royalty free licensing commitments from W3C members (you know, the "free" in "free and open"). As part of that transition, the WICG should seek an [FSA](https://www.w3.org/community/about/process/final/) commitment from any contributors to the incubation that choose not to join the WG to which it has been transitioned; this will provide the broadest possible IP coverage. | |||
| 1. **Editing and Refinement**: The community should incubate and refine the proposal, through discussion on GitHub issues on the repo (and Discourse, if appropriate) until they feel the proposal has sufficient support and resolution to move to an appropriate Working Group; at that point, the editing team should contact the chairs, and the chairs will help do an "<a href="https://w3c.github.io/charter-html/request-to-transition.html">intent to migrate</a>": where we move the proposal to a W3C Working group to seek royalty free licensing commitments from W3C members (you know, the "free" in "free and open"). As part of that transition, the WICG should seek an [FSA](https://www.w3.org/community/about/process/final/) commitment from any contributors to the incubation that choose not to join the WG to which it has been transitioned; this will provide the broadest possible IP coverage. | |||
There was a problem hiding this comment.
When migrating to a WG, the proposal typically has a spec.
|
Looks like taking Tab’s misapprehension as a basis for making this change doesn’t actually work :) Closing this in favor of making progress on #138 |
See the thread at https://twitter.com/alanstearns/status/1507506854171078658
WICG should try to be consistent about the CG documents being proposals.