Update proposals-CG-WG.md #12
Conversation
| * [ ] An [Editor's Draft](https://www.w3.org/policies/process/#editors-draft) can be used to get PRs merged between [Working Draft](https://www.w3.org/policies/process/#RecsWD) revisions. | ||
| * [ ] Working Group consensus to adopt the proposal as the basis for their work. | ||
| * [ ] A clear list of blocking issues to be addressed before advancing to Stage 3. | ||
| * [ ] A completed Working Draft for further iteration. |
There was a problem hiding this comment.
What does this mean? What does it mean that we ask the Working Group for a Working Draft?
That is, do we expect every different proposal to have separate working drafts?
There was a problem hiding this comment.
As a spec editor, I would not enjoy having a separate 'working draft' for every feature. That said, maybe this can say 'pull request' at least for features that are intended to be part of an existing spec and not their own spec (which are probably the vast majority)?
There was a problem hiding this comment.
If it's an update, then yes, a PR. If it's a whole new thing, then a doc draft.
| * [ ] A specific preferred proposal, e.g., code samples, examples, or a spec PRs (if the formalism is needed to understand the proposal) | ||
| * [ ] Browser and developer implementation experience (e.g., a prototype, dev trials, origin trials, etc) | ||
| * [ ] Confidence of developer demand and fitness for purpose (e.g. a developer that needs this proposal) | ||
| * [ ] An [explainer](https://tag.w3.org/explainers/). |
There was a problem hiding this comment.
Can I suggest that we keep these editorial fixes outside of this PR so that we can focus on the normative changes? For example, I almost dismissed the change below because I assumed that it was just making editorial changes rather than normative.
The editorial changes are perfectly valid, I just think that they may be best done in isolation rather than together with this spec PR.
There was a problem hiding this comment.
can you revert the non-editorial changes so that it is easier to review?
| * [ ] A home for incubating the proposal. Small features will incubate in issues. If and when the champions are ready to more thoroughly document their proposal, the WG chairs will create a repo for the champions to develop the feature (e.g., [example](https://github.com/fedidcg/LightweightFedCM)). | ||
|
|
||
| # Stage 2: Formalization | ||
|
|
||
| The purpose of Stage 2 Proposals is to formally specify the best (and seemingly workable) alternative that was identified in the prior step: handle corner cases, integrate with other parts, reconcile with other proposals, and resolve the concerns identified at the entrance. The Proposal enters Stage 2 with a list of blocking issues to advance to the next stage and exits with all of the issues resolved. | ||
| The goal of Stage 2 is to refine the preferred solution into a detailed, cohesive proposal that addresses known issues and integrates feedback from stakeholders. The Proposal enters Stage 2 with a list of blocking issues to advance to the next stage and exits with all of the issues resolved. This stage focuses on preparing the proposal for Working Group review and creating a complete, formal draft. |
There was a problem hiding this comment.
Complete formal draft of what? I guess the specification of the feature?
There was a problem hiding this comment.
Yes, specification of the feature.
There was a problem hiding this comment.
W3C CGs use Draft Report and Final Report terminology. Could draft report make it more clear?
https://www.w3.org/community/about/process/#deliverables
| * [ ] An [Editor's Draft](https://www.w3.org/policies/process/#editors-draft) can be used to get PRs merged between [Working Draft](https://www.w3.org/policies/process/#RecsWD) revisions. | ||
| * [ ] Working Group consensus to adopt the proposal as the basis for their work. | ||
| * [ ] A clear list of blocking issues to be addressed before advancing to Stage 3. | ||
| * [ ] A completed Working Draft for further iteration. |
There was a problem hiding this comment.
As a spec editor, I would not enjoy having a separate 'working draft' for every feature. That said, maybe this can say 'pull request' at least for features that are intended to be part of an existing spec and not their own spec (which are probably the vast majority)?
proposals-CG-WG.md
Outdated
| * What's asked of the **Working Group**? | ||
| * [ ] Working Group consensus that the [Working Draft](https://www.w3.org/policies/process/#RecsWD) sufficiently resolves all of the issues raised at [Stage 2](#stage-2) | ||
| * [ ] Working Group consensus to publish the [Working Draft](https://www.w3.org/policies/process/#RecsWD) as the Working Group's [Candidate Recommendation](https://www.w3.org/policies/process/#RecsCR) | ||
| * [ ] Working Group consensus that the [Working Draft](https://www.w3.org/policies/process/#RecsWD) sufficiently resolves all of the issues raised at [Stage 2](#stage-2). |
There was a problem hiding this comment.
Since we are modifying this, maybe we should address the issue about not all features within a spec reaching Stage 3 at the same time. Perhaps the CR mentioned below can be a frozen branch from the WD, possibly with features in lesser stages removed?
proposals-CG-WG.md
Outdated
| * Decorators Repo: [https://github.com/tc39/proposal-decorators](https://github.com/tc39/proposal-decorators) | ||
| * Temporal Repo: [https://github.com/tc39/proposal-temporal](https://github.com/tc39/proposal-temporal) |
There was a problem hiding this comment.
Why the extra space for this third-tier indent, here and below? Note that prior levels (and the "original" being changed here) are using 2 spaces per tier, a la --
* top
* second
* third
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
preparing to split out purely editorial changes Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
preparing to split out editorial changes Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
preparing to split out editorial changes Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
preparing to split out editorial changes Co-authored-by: Sam Goto <samuelgoto@gmail.com>
preparing to split out editorial changes Co-authored-by: Sam Goto <samuelgoto@gmail.com>
preparing to split out editorial changes Co-authored-by: Sam Goto <samuelgoto@gmail.com>
preparing to split out editorial changes Co-authored-by: Wendy Seltzer <wendy+gh@seltzer.org>
This reverts commit e2019cc.
This reverts commit 4c33265.
This reverts commit 36b00eb.
This reverts commit 64dc551.
This reverts commit dc2c137.
| * [ ] An [Editor's Draft](https://www.w3.org/policies/process/#editors-draft) can be used to get PRs merged between [Working Draft](https://www.w3.org/policies/process/#RecsWD) revisions. | ||
| * [ ] Working Group consensus to adopt the proposal as the basis for their work. | ||
| * [ ] A clear list of blocking issues to be addressed before advancing to Stage 3. | ||
| * [ ] A completed Working Draft for further iteration. |
There was a problem hiding this comment.
Link to Working Draft seemed useful, why was it removed?
| * [ ] An [Editor's Draft](https://www.w3.org/policies/process/#editors-draft) can be used to get PRs merged between [Working Draft](https://www.w3.org/policies/process/#RecsWD) revisions. | ||
| * [ ] Working Group consensus to adopt the proposal as the basis for their work. | ||
| * [ ] A clear list of blocking issues to be addressed before advancing to Stage 3. | ||
| * [ ] A completed Working Draft for further iteration. |
There was a problem hiding this comment.
This seems at odds with the above Optionally, a draft specification text (or detailed examples/code samples if needed for clarity).. A Working Draft is a draft specification with minimal adoption from the WG, no? So how is the draft spec optional if the WD is required?
There was a problem hiding this comment.
You're right. Reverting that change.
| * [ ] Further implementation experience | ||
| * [ ] Proposal fully merged into the [Working Draft](https://www.w3.org/policies/process/#RecsWD). | ||
| * [ ] Web Platform Tests are available. | ||
| * [ ] At least two independent implementers and no unresolved objections (where resolution may include an agreement not to address the issue). |
There was a problem hiding this comment.
This requirement seems a bit off compared with the previous text since multiple implementations are expected to be produced during this stage. So are multiple implementors needed to reach stage 3 or could they possibly occur during stage 3? Note that in WHATWG it is two implementers supporting which is different from having actually implemented. https://whatwg.org/stages#stage3
There was a problem hiding this comment.
Agreed. Stage 3 is ready for implementation; so rephrasing to supporting makes sense.
| @@ -13,7 +13,7 @@ This is a proposal to break proposals into 5 stages of maturity, with clear guid | |||
| * [Stage 3](#stage3): **Implementation** of the preferred Proposal | |||
| * [Stage 4](#stage4): **Publication** of a Proposed Recommendation | |||
|
|
|||
| These stages support the W3C process. If there is ever any question between W3C process requirements and how the groups will progress their work, the W3C process has precedent. | |||
| These stages support the W3C process and align with the [TC39 process](https://tc39.es/process-document/) and the [WHATWG process](https://whatwg.org/stages). If there is ever any question between W3C process requirements and how the groups will progress their work, the W3C process has precedent. | |||
There was a problem hiding this comment.
Can you revert this change too as it is covered in this other PR? https://github.com/w3c-fedid/Administration/pull/13/files#diff-413347616d7d3063a428e05c5c47d90aa1301ba3dade010736161ffb20774cedR16
| * [ ] A specific preferred proposal, e.g., code samples, examples, or a spec PRs (if the formalism is needed to understand the proposal) | ||
| * [ ] Browser and developer implementation experience (e.g., a prototype, dev trials, origin trials, etc) | ||
| * [ ] Confidence of developer demand and fitness for purpose (e.g. a developer that needs this proposal) | ||
| * [ ] An [explainer](https://tag.w3.org/explainers/). |
There was a problem hiding this comment.
can you revert the non-editorial changes so that it is easier to review?
See #11