CR preparation for Fetch Metadata

[simoneonofri]

This is an issue for managing the Transition Request process.
We can create various sub-issues to keep everything organized.

Ref. #681

[cc'ing @mikewest ]

Prerequisite Steps for All Transition Requests

• Record Group Decision to Advance

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

• Obtain Team Verification

  • 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.

• Document Changes Since Last Publication

  • Publicly document all new features (class 4 changes).
  • 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

  • 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, taking the list from the charter).

• Demonstrate horizontal review

  • Prepare and ask for Design Review (e.g., for each new feature)
  • Prepare and ask for Security Review
  • Prepare and ask for Privacy Review
  • Prepare and ask for Internationalization Review
  • Prepare and ask for Accessibility Review
  • Resolve all need-resolutions issues from the reviews

• 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.