Update proposals-CG-WG.md #12
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
TallTed
suggested changes
Nov 26, 2024
| * [ ] 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.
Suggested change
| 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. | |
| 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 issues that block advancement 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. |
|
|
||
| The purpose of Stage 3 Proposals is to increase implementation and deployment confidence in order to produce a [Candidate Recommendation](https://www.w3.org/policies/process/#RecsCR). | ||
| The purpose of Stage 3 Proposals is to increase implementation and deployment confidence in order to produce a [Candidate Recommendation](https://www.w3.org/policies/process/#RecsCR). The spec should be considered finished, pending editorial nit review. However, since multiple implementations are expected in this stage, it is possible there will be further changes to normative content. |
There was a problem hiding this comment.
Suggested change
| The purpose of Stage 3 Proposals is to increase implementation and deployment confidence in order to produce a [Candidate Recommendation](https://www.w3.org/policies/process/#RecsCR). The spec should be considered finished, pending editorial nit review. However, since multiple implementations are expected in this stage, it is possible there will be further changes to normative content. | |
| The purpose of Stage 3 Proposals is to increase implementation and deployment confidence in order to produce a [Candidate Recommendation](https://www.w3.org/policies/process/#RecsCR). The spec should be considered finished, pending editorial nit review. However, since multiple implementations are expected to be produced during this stage, it is possible there will be further changes to normative content based on feedback from those implementors. |
|
|
||
| # Stage 4: Publication | ||
|
|
||
| The purpose of Stage 4 Proposals is to produce a [W3C Recommendation](https://www.w3.org/policies/process/#RecsW3C). | ||
| The purpose of Stage 4 Proposals is to produce a [W3C Recommendation](https://www.w3.org/policies/process/#RecsW3C). At this stage, the spec is merged and has finished editor review. This editor review could be lengthy, especially if the feature is large and/or the contributor is new to W3C process, but it will usually be short. |
There was a problem hiding this comment.
Suggested change
| The purpose of Stage 4 Proposals is to produce a [W3C Recommendation](https://www.w3.org/policies/process/#RecsW3C). At this stage, the spec is merged and has finished editor review. This editor review could be lengthy, especially if the feature is large and/or the contributor is new to W3C process, but it will usually be short. | |
| The purpose of Stage 4 Proposals is to produce a [W3C Recommendation](https://www.w3.org/policies/process/#RecsW3C). At this stage, the spec is merged and has finished editorial review. This editorial review could be lengthy, especially if the feature is large and/or the contributor is new to W3C process, but it will usually be short. |
bvandersloot-mozilla
approved these changes
Nov 27, 2024
samuelgoto
reviewed
Dec 5, 2024
| * [ ] Confidence of developer demand and fitness for purpose (e.g. a developer that needs this proposal) | ||
| * [ ] An [explainer](https://tag.w3.org/explainers/). | ||
| * [ ] Documentation of alternatives and trade-offs considered. | ||
| * [ ] Draft specification text (or detailed examples/code samples if needed for clarity). |
There was a problem hiding this comment.
This seems like a higher bar than is necessary. I'd suggest allowing proposals to enter Stage 2 without a draft specification text (explainers are necessary).
Suggested change
| * [ ] Draft specification text (or detailed examples/code samples if needed for clarity). | |
| * [ ] Optionally, a draft specification text (or detailed examples/code samples if needed for clarity). |
| * [ ] Documentation of alternatives and trade-offs considered. | ||
| * [ ] Draft specification text (or detailed examples/code samples if needed for clarity). | ||
| * [ ] Early implementation experience, including prototypes or trials. | ||
| * [ ] Evidence of stakeholder demand and use-case alignment. |
There was a problem hiding this comment.
Stakeholders seems unnecessarily underspecified as far as "demand" is concerned. Where else would "demand" come from other than web developers?
Suggested change
| * [ ] Evidence of stakeholder demand and use-case alignment. | |
| * [ ] Evidence of stakeholder (e.g. web developers) demand and use-case alignment. |
There was a problem hiding this comment.
Minor tweaks to @samuelgoto's suggestion
Suggested change
| * [ ] Evidence of stakeholder demand and use-case alignment. | |
| * [ ] Evidence of stakeholder (e.g., web developer) demand and use-case alignment. |
| * [ ] 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)?
| * [ ] 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. | ||
| * [ ] Approval to transition the draft into a formal as the basis for their work as a [Working Draft](https://www.w3.org/policies/process/#RecsWD). |
There was a problem hiding this comment.
I don't follow this: do we expect that, when a proposal enters Stage 2, that it will have the proposal merged into the Working Draft?
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?
Or is it that what one gets is approval to spend time in the WG to review spec PRs?
Suggested change
| * [ ] Approval to transition the draft into a formal as the basis for their work as a [Working Draft](https://www.w3.org/policies/process/#RecsWD). | |
| * [ ] Approval to dedicate the WG's time to Review spec PRs to merge the proposal into the [Working Draft](https://www.w3.org/policies/process/#RecsWD). |
| * [ ] 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.
npm1
reviewed
Dec 5, 2024
| * [ ] 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?
| * [ ] 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)?
| * 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?
TallTed
reviewed
Dec 6, 2024
Comment on lines
+88
to
+89
| * 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
wseltzer
reviewed
Dec 13, 2024
| @@ -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.
Suggested change
| 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. | |
| 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 precedence. |
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See #11