Prepare for CR

[simoneonofri]

Prerequisite Steps for All Transition Requests

• [x] Record Group Decision to Advance

  • [x] The Working Group must document a formal decision to request advancement.

• [x] Obtain Team Verification

  • [x] Seek Team verification that all Process requirements are met.
  • [ ] Ensure no unresolved Formal Objections remain.
  • [ ] Confirm that the document reflects all relevant W3C Council decisions.
  • [ ] If verification is withheld, understand and address the Team’s rationale.

• [x] Document Changes Since Last Publication

  • [x] Publicly document all new features (class 4 changes).
  • [x] Publicly document substantive changes (class 3 changes), ideally with details.
  • [ ] (Optional) Publicly document editorial changes with details if helpful.

• [ ] Address All Issues and Formal Objections

  • [x] Formally address all issues raised since the previous maturity stage.
  • [ ] Provide public documentation of any Formal Objections and how they were handled.

• [ ] Report Requirement and Dependency Changes

  • [ ] Report which, if any, requirements for the document have changed since the previous step.
  • [ ] Report any changes in dependencies with other groups.

• [ ] Document Known Implementations

  • [ ] Provide information about implementations known to the Working Group.

Note: For a First Public Working Draft, many of these requirements do not apply, and verification is normally straightforward.
Note: Transition Requests to First Public Working Draft or Candidate Recommendation will not normally be approved while a Working Group's charter is undergoing or awaiting a decision on an Advisory Committee Review.

---

Proposed Steps to Transition the Permissions Specification to Candidate Recommendation

• [ ] Demonstrate compliance with Working Group requirements

  • [ ] Verify that the specification has met all original WG requirements.
  • [ ] If any requirements have changed or been deferred, document and justify those changes.

• [ ] Document changes in dependencies

  • [ ] List all dependencies on other specifications and note any changes made during development.
  • [ ] Confirm that all dependencies are stable or provide a mitigation plan if not.

• [ ] Outline implementation experience criteria

  • [ ] Define what constitutes "adequate implementation experience" for the specification.
  • [ ] Identify criteria, test suites, or plans to demonstrate sufficient interoperability and maturity.

• [ ] Set comment period and review schedule

  • [ ] Specify the formal comment period (at least 28 days).
  • [ ] Provide a detailed schedule for review, including expected review groups and forums.

• [ ] Demonstrate wide review

  • [ ] Document evidence of wide review (e.g., links to reviews, issues filed, feedback from relevant communities and WGs).

• [ ] Identify features at risk (optional)

  • [ ] Mark any features that may be removed before Proposed Recommendation without a new CR publication.

• [ ] Coordinate publication as a Candidate Recommendation Snapshot

  • [ ] Prepare the CR snapshot once the Transition Request requirements are met.
  • [ ] After publication, ensure the W3C Team announces it to relevant W3C groups and the public.

• [ ] Plan for subsequent steps after CR Snapshot

  • [ ] Consider next steps (e.g., returning to WD, revising CR, moving to PR, or discontinuation).
  • [ ] Be prepared to handle any Advisory Committee appeals.

Once all items are completed, proceed with the Transition Request and publish as a Candidate Recommendation.