Rec revision pubrules
Publishing rules for Recommendation revisions
Summary in plain English
This is, hopefully, a good summary of the various publication steps we have to follow for our Recommendation revisions.
General background: every time a new publication is made, it is a Recommendation, not a Working Draft. In other words, the document supersedes any earlier version of the Rec (in other words, the official URL will point to the revised version). This may explain why the publication requirements are somewhat convoluted.
In all cases, the publication itself has to go through the staff contact installing the document on /TR, and the webmaster doing his/her own magic. In other words, we have no echidna at our disposal at this stage.
The WG has the right to publish such updates on its own decision, see formal transition steps. Editorially, the document is published in its final version.
Class 3 changes
The WG has the right to publish such updates on its own decision, but a set of formal steps should be followed.
-
Candidate Corrections: These play, roughly, the role of subsequent Candidate Recommendations Drafts, insofar as the WG can decide to publish without any further ado. See the formal transition steps. Editorially, the document is published with the changes clearly marked via
<del>and<ins>elements (or equivalents). Note that this step is optional, i.e., the group may decide to go for a Proposed Correction (see next point) right away. -
Proposed Corrections (a.k.a. "Last Call for Review of Proposed Amendments"): These play, roughly, the role of Proposed Recommendations, insofar as the AC is requested to review and vote on the proposed changes. See the formal transition steps. Editorially, the document is published with the changes clearly marked via
<del>and<ins>elements (or equivalents), and the publication is accompanied by a call for an AC vote using the "usual" voting form.Note that the review period must be at least 60 days. Note also that implementation testing results should be provided for the changed features, if applicable, just as for Candidate Recommendations.
-
Incorporating Changes into a Recommendation: As its name suggests, all the changes are incorporated, i.e., the
<del>and<ins>elements in the document are “resolved” before publication. This is possible after a successful AC vote (with the inclusion of the extra changes requested by the AC). See the formal transition steps.
Class 4 changes
These are published following the same approach as class 3 changes (the terms are slightly different). Note that we are not allowed to do that for the EPUB 3.3 Recommendations, but we are allowed for the Audiobooks and Publication Manifest Recommendations.
A More formal version
This document distinguishes the following classes of changes to a document. The first two classes of change are considered editorial changes, the next two substantive changes.
1.1 Class 1
No changes to text content: these changes include fixing broken links, style sheets, or invalid markup.
1.1.1 Procedure
1.2 Class 2
Changes that do not functionally affect interpretation of the document: changes that do not affect conformance, i.e., changes that reasonable implementers would not interpret as changing architectural or interoperability requirements or their implementation. Changes which resolve ambiguities in the specification are considered to change (by clarification) the implementation requirements do not fall into this class.
Examples of changes in this class include correcting non-normative examples which clearly conflict with normative requirements, clarifying informative use cases or other non-normative text, fixing typos or grammatical errors where the change does not change requirements.
If there is any doubt or disagreement as to whether a change functionally affects interpretation, that change does not fall into this class.
Editorial changes to a Recommendation require no technical review of the intended changes. A Working Group, provided there are no votes against the decision to publish, may request publication of a Recommendation to make this class of change without passing through earlier maturity stages.
1.2.1 Procedure
1.3 Class 3
Other changes that do not add new features: changes may affect conformance to the specification. A change that affects conformance is one that:
- makes conforming data, processors, or other conforming agents become non-conforming according to the new version, or
- makes non-conforming data, processors, or other agents become conforming, or
- clears up an ambiguity or under-specified part of the specification in such a way that data, a processor, or an agent whose conformance was once unclear becomes clearly either conforming or non-conforming.
1.3.1 Procedure
- Publish a candidate correction via a publication request to webreq@w3.org. The document annotates the candidate corrections to the document.
- Organize a Last Call for Review of Proposed Amendments in conjunction with the communication team (which then sends an announcement to the members that also starts a new round for call for exclusions and an AC review). In parallel, publish the document with the proposed amendments through a publication request to webreq@w3.org.
- In case of a successful review:
- Issue an update publication request as a formal transition request.
- If the team approves, issue a publication request to webreq@w3.org. In parallel, prepare an announcement with the communication team to issue a transition announcement.
Alternatively, a Working Group may incorporate the changes and publish as a Working Draft—or, if the relevant criteria are fulfilled, publish as a Candidate Recommendation—and advance the specification from that state.
1.4 Class 4
New features: changes that add new functionality, such as new elements, new APIs, new rules, etc.
1.4.1 Procedure
- Publish a candidate addition via a publication request to webreq@w3.org. The document annotates the candidate corrections to the document.
- Organize a Last Call for Review of Proposed Amendments in conjunction with the communication team (which then sends an announcement to the members that also starts a new round for call for exclusions and an AC review). In parallel, publish the document with the proposed amendments through a publication request to webreq@w3.org.
- In case of a successful review:
- Issue an update publication request as a formal transition request.
- If the team approves, issue a publication request to webreq@w3.org. In parallel, prepare an announcement with the communication team to issue a transition announcement.
Alternatively, a Working Group may incorporate the changes and publish as a Working Draft—or, if the relevant criteria are fulfilled, publish as a Candidate Recommendation—and advance the specification from that state.