On 1 August 2014, W3C began atransition away from this document; see thecurrent W3C Process Document.
The W3C technical report development process is the set of steps andrequirements followed by W3CWorking Groupsto standardize Web technology. The processes followed by a Working Group tomanage specifications and guidelines -- called technical reports in thissection -- include:
The W3C technical report development process is designed to maximizeconsensus about the content of atechnical report, to ensure high technical and editorial quality, to promoteconsistency among specifications, and to earn endorsement by W3C and thebroader community. See also the licensing goals for W3C Recommendations insection2 of theW3C PatentPolicy [PUB33].
The following sections describe:
Maturity levels are described first, followed by the steps of the technicalreport development process and the requirements for each step.
The maturity level of a published technical report indicates its place inthe development process. The maturity levels "Working Draft" and "Working GroupNote" represent the possibleinitialstates of a technical report in the development process. The maturitylevels "Recommendation," "Working Group Note," and "Rescinded Recommendation"represent the possibleendstates.
In addition to Working Drafts that are meant to advance to Recommendation,the other maturity levels of the Recommendation Track are:
Note: To avoid confusion in the developer community and themedia about which documents represent the output of chartered groups and whichdocuments are input to W3C Activities (Member Submissions andTeam Submissions), W3C has stopped usingthe unqualified maturity level "Note."
W3CMAY also publish "Interest Group Notes" and"Coordination Group Notes". Because the label "W3C Working Draft" is sostrongly associated with W3C Working Group deliverables (especially those onthe Recommendation Track), W3C publishes "Interest/Coordination Group Notes"for both ongoing and completed work by those groups.
In preparation for advancement to Candidate Recommendation or subsequentmaturity levels up to and including publication as a Recommendation, theWorking GroupMUST:
The following information is important to the decision to advance atechnical report and thereforeMUST bepublicly available:
Refer to"How to Organize a RecommendationTrack Transition" in theMemberguide for practical guidance on satisfying these requirements.
Experience shows that the following help build consensus around technicalreports:
A document receives review from the moment it is first published. Startingwith the First Public Working Draft until the start of a Last Call review, aWorking GroupSHOULDformally addressany substantivereview comment about a technical report andSHOULDdo so in a timely manner.
Starting with a Last Call review up to the transition to ProposedRecommendation, a Working GroupMUSTformally addressany substantivereview comment about a technical report andSHOULDdo so in a timely manner. When a Working Group requests to advance to CandidateRecommendation or beyond, the Director expects positive documentation thatissues have been formally addressed (e.g., in an issues list that shows theirdisposition).
The DirectorMUST formally address anysubstantive issue raised by Advisory Committee representatives during ProposedRecommendation, Proposed Edited Recommendation, and Proposed RescindedRecommendation review periods. The Working GroupMUST communicate to the Director (usually through the TeamContact) any substantive issues raised during Proposed Recommendation, ProposedEdited Recommendation, and Proposed Rescinded Recommendation review periods byparties other than Advisory Committee representatives.
ReviewersSHOULD NOT send substantive technicalreviews late on the Recommendation track. ReviewersSHOULD NOT expect that a Working Group will readily makesubstantive changes to a mature document. Themore evidence a Working Group can show of wide review, the less weightsubstantive comments will carry when provided late on the Recommendation Track.Worthy ideasSHOULD BE recorded even when notincorporated into a mature document.
The Working GroupMUST be able to show evidenceof having attempted to respond to and satisfy reviewers. ReviewersMAY register aFormalObjection any time they are dissatisfied with how a Working Group hashandled an issue.
A Working GroupSHOULD negotiate reviewschedules with other groups expected to review a document, including relevantliaisons.
There are two formal review periods with fixed durations when advancing toRecommendation: after a Last Call announcement and after a Call for Review of aProposed Recommendation. Out of consideration for the Working Group, reviewersSHOULD send their comments early in a reviewperiod. A Working GroupSHOULD NOT start a newreview before the scheduled end of an ongoing review (e.g., do not start a newLast Call review before the scheduled end of an ongoing Last Call review).
Ordinarily, reviewersSHOULD NOT raisesubstantive technical issues about a technical report after the end of a LastCall review period. However, this does occur, and as stated above, a WorkingGroup's requirement to formally address those issues extends until the start ofa Proposed Recommendation review period. However, to allow the Working Group tomake progress on a technical report, the Working GroupMAY decline to make substantive changes to address issuesraised between the end of a Last Call review period and publication of aRecommendation. A reviewerMAY register aFormal Objection.
Advisory Committee representativesSHOULD NOT(butMAY) raise new substantive technical issuesduring a Proposed Recommendation review period. The DirectorMAY respond to the reviewer after the close of the ProposedRecommendation review period.Note: It may be necessary tochange confidentiality levelwhen conveying issues raised by Advisory Committee representatives to theWorking Group.
During review by the Members, the Working GroupSHOULD alsoformallyaddress informed and relevant issues raised outside the Advisory Committee(e.g., by the public or another W3C Working Group), and report them to theDirector in a timely fashion.
When a Working Group receives a substantive issue after the end of ProposedRecommendation review period, the Working GroupMUST respond to the reviewer butMAY decline toformallyaddress the issue. In this case, the Working GroupMAY consider the issue as part of trackingerrata.
W3C follows these steps when advancing a technical report toRecommendation.
In general, Working Groups embark on this journey with the intent ofpublishing one or more Recommendations. However, W3CMAYend work on a technical report atany time, orMAY require a Working Group toconductfurther work, possibly repeating one ormore steps.
Between publication of the First Public Working Draft and Last Callannouncement, a Working Group publishes revisions that generally includesubstantive changes. Between any two steps after a Last Call announcement, theWorking GroupMAY publish a new draft of thetechnical report at the same maturity level provided there are nosubstantive changes since the earlier step.
The TeamMUST notify theAdvisory Committee and other W3C groups of arevision to a Candidate Recommendation or Proposed Recommendation.
These steps of the technical report development process can takeconsiderable time, so participants are encouraged to read thetips on getting to Recommendationfaster [PUB27].
Refer to"How to Organize a RecommendationTrack Transition" in theMemberguide for practical information about preparing for the reviews andannouncements of the various steps.
Document maturity level:Working Draft.
Announcement: The DirectorMUST announce thefirst Working Draft publication to other W3C groups and to the public.
Purpose: The publication of the First Public Working Draft is a signal tothe community to begin reviewing the document. Seesection 4.1 ofthe W3C Patent Policy [PUB33] forinformation about the policy implications of the First Public WorkingDraft.
Entrance criteria: The ChairMUST record thegroup's decision to request advancement. Since this is the first time that adocument with this short name appears in the Technical Reports index, Directorapproval isREQUIRED for the transition.
Ongoing work: After publication of the First Public Working Draft, theWorking Group generally revises the technical report (see theWorking Group "Heartbeat" Requirement) inaccordance with its charter.
In order to make Working Drafts available to a wide audience early in theirdevelopment, the requirements for publication of a Working Draft are limited toan agreement by a chartered Working Group to publish the technical report andsatisfaction of the Team'sPublication Rules [PUB31]. Consensus is not a prerequisite forapproval to publish; the Working GroupMAY requestpublication of a Working Draft even if it is unstable and does not meet allWorking Group requirements.
Working GroupsSHOULD encourage early and widereview of the technical report, within and outside of W3C, especially fromother Working Groups with dependencies on the technical report. AdvisoryCommittee representativesSHOULD encourage reviewwithin their organizations as early as First Public Working Draft, i.e., beforeaLast Call announcement andwell before aCall for Review of a Proposed Recommendation.
The Working GroupSHOULD be responsive to andfacilitate ongoing review by addressing issues in a timely manner and clearlyindicating changes between drafts (e.g., by providing "diffs" and summaries ofsubstantive changes).
Possible next steps:
Document maturity level:Working Draft.
Announcement: The Working GroupMUST announcethe Last Call to other W3C groups and to the public. A Last Call announcementMUST:
Purpose: A Working Group's Last Call announcement is a signal that:
In general, a Last Call announcement is also a signal that the Working Groupis planning to advance the technical report to later maturity levels.
A Working GroupSHOULD work with other groupsprior to a Last Call announcement to reduce the risk of surprise at LastCall.
Ideally, after a Last Call announcement, a Working Group receives onlyindications of support for the document, with no proposals for substantivechange. In practice, Last Call announcements generate comments that sometimesresult in substantive changes to a document. A Working GroupSHOULD NOT assume that it has finished its work by virtue ofissuing a Last Call announcement.
Entrance criteria: Before announcing a Last Call, the Working GroupMUST do all of the following:
Duration of the review: The announcement begins a review period thatSHOULD last at leastthree weeks butMAY lastlonger if the technical report is complex or has significant externaldependencies.
Ongoing work: During the review period, the Working Group solicits andresponds to comments from the Team, the Members, other W3C groups, and thepublic.
It is important to ensure the proper integration of a technical report inthe international community. Starting at this step in the Recommendationprocess, the technical reportSHOULD include astatement about how the technology relates to existing international standardsand to related work outside of W3C.
Possible next steps:
Document maturity level:Candidate Recommendation.
Announcement: The DirectorMUST announce theCall for Implementations to theAdvisoryCommittee.
Purpose: At this step, W3C believes the technical report is stable andappropriate for implementation. The technical reportMAY still change based on implementation experience.
Entrance criteria: The Director calls for implementation when satisfied thatthe Working Group has fulfilled thegeneralrequirements for advancement.
The Working Group isNOT REQUIRED to show thata technical report has two independent and interoperable implementations aspart of a request to the Director to announce a Call for Implementations.However, the Working GroupSHOULD include a reportof present and expected implementations as part of the request.
In the Call for Implementations, the Working GroupMAY identify specific features of the technical report asbeing "features at risk."General statements such as "We plan to remove any unimplemented feature" arenot acceptable; the Working GroupMUST preciselyidentify any features at risk. Thus, in response to a Call for Implementations,reviewers can indicate whether they would register aFormal Objection to the decision to removethe identified features.
After gathering implementation experience, the Working GroupMAY remove features from the technical report that wereidentified as being "at risk" and request that the DirectorCallfor Review of a Proposed Recommendation. If the Working Group makes othersubstantive changes to the technical report,the DirectorMUST return it to the Working Groupforfurther work.
The request to the Director to advance a technical report to CandidateRecommendationMUST indicate whether the WorkingGroup expects to satisfy any Proposed Recommendation entrance criteria beyondthe default requirements (described below).
Advisory Committee representativesMAYappeal the decision to advance the technicalreport.
Duration of the implementation period: The announcementMUST indicate a minimal duration, before which the WorkingGroupMUST NOT request aCall forReview of a Proposed Recommendation; this minimal duration is designed toallow time for comment. The announcementSHOULDalso include the Working Group's estimate of the time expected to gathersufficient implementation data.
Possible next steps:
Document maturity level:Proposed Recommendation.
Announcement: The DirectorMUST announce theCall for Review to theAdvisoryCommittee.
Purpose: At this step, W3C seeks endorsement of the stable technical report.The outcome of this review is taken as an indication of the organization'ssupport for the technical report.
Entrance criteria: The Director calls for review when satisfied that theWorking Group has:
Advisory Committee representativesMAYappeal the decision to advance the technicalreport.
Duration of the review: The announcement begins a review period thatMUST last at leastfour weeks.
Ongoing work: During the review period, the Working Group requestsendorsement and support from Members (e.g., testimonials as part of a pressrelease).
Possible next steps:
Document maturity level:Recommendation.
Announcement: The DirectorMUST announce thepublication of a W3C Recommendation to theAdvisory Committee.
Purpose: W3C publishes Recommendations when it believes that the ideas inthe technical report are appropriate for widespread deployment and that theypromoteW3C's mission.
Entrance criteria: The Director publishes a W3C Recommendation whensatisfied that there is significant support for the technical report from theAdvisory Committee, the Team, W3C Working Groups, and the public. The decisionto advance a document to Recommendation is aW3C decision.
If there was anydissent during theMember review, Advisory Committee representativesMAYappeal the decisionto publish the Recommendation.
Possible next steps:
The DirectorMAY submit a W3C Recommendation toanother standards body for adoption and formal approval by that body.
A technical report is returned to a Working Group for further work in eitherof the following situations:
The DirectorMUST inform theAdvisory Committee and group Chairs when a technicalreport has been returned to a Working Group for further work.
After republication as a Working Draft, the next forward step available tothe Working Group is aLast Call announcement. TheLast Call announcementMAY occur at the same timeas the publication of the Working Draft.
The DirectorMAY ask the Working Group torepublish a technical report as a Candidate Recommendation. At the same time aspublication, the Director issues aCall forImplementations.
Work on a technical reportMAY cease at anytime. When a Working Group completes its work on a technical report, itpublishes it either as a Recommendation or a Working Group Note. For example, aWorking Group might publish several Working Drafts of a requirements document,and then indicate that it no longer plans to work on the requirements documentby publishing a Working Group Note.
WorkMAY also cease because W3C determines thatit cannot productively carry the work any further. For instance, the Directormightclose a Working Group, theparticipants might lose interest in a technical report, or the ideas might besubsumed by another technical report. If W3C decides to discontinue work on atechnical report before completion, the technical reportSHOULD be published as a Working Group Note.
Possible next steps:
W3C makes every effort to maintain its Recommendations (e.g., by trackingerrata, providing test-bed applications, and helping to create test suites) andto encourage widespread implementation. The following sections discuss themanagement of errors and the process for making normative changes to aRecommendation.
Tracking errors is an important part of a Working Group's ongoing care of aRecommendation; for this reason, the scope of a Working Group charter generallyallows time for work after publication of a Recommendation. In this ProcessDocument, the term "erratum" (plural "errata") refers to any class of mistake,from mere editorial to a serious error that may affect the conformance with theRecommendation by software or content (e.g., content validity).Note: Before a document becomes a Recommendation, the W3CProcess focuses onsubstantive changes (thoserelated to prior reviews). After a document has been published asRecommendation, the W3C Process focuses on those changes to a technical reportthat might affect the conformance of content or deployed software.
Working GroupsMUST track errata on an "erratapage." An errata page is a list of enumerated errors, possibly accompanied bycorrections. Each Recommendation links to an errata page; see the Team'sPublication Rules.
A correction is first "proposed" by the Working Group. A correction becomesnormative -- of equal status as the text in the published Recommendation --through one of the processes described below. An errata pageMAY include both proposed and normative corrections. TheWorking GroupMUST clearly identify whichcorrections are proposed and which are normative.
A Working GroupSHOULD keep their errata pagesup-to-date, as errors are reported by readers and implementers. A Working GroupMUST report errata page changes to interestedparties, notably when corrections are proposed or become normative, accordingto the Team's requirements. For instance, the Team might set up a mailing listper Recommendation where a Working Group reports changes to an errata page.
This document distinguishes the following classes of changes to aRecommendation.
The first two classes of change require no technical review of the proposedchanges, although a Working GroupMAY issue a Callfor Review. The modified Recommendation is published according to the Team'srequirements, includingPublicationRules [PUB31].
For the third class of change, W3C requires:
For the third class of change, the Working GroupMUST either:
While the second approach is designed so that a Working Group can establishnormative corrections quickly, it does not obviate the need to incorporatechanges into an edited version of the Recommendation. In particular, whencorrections are numerous or complex, integrating them into a single document isimportant for interoperability; readers might otherwise interpret thecorrections differently.
For the fourth class of change (new features), W3CMUST follow the full process ofadvancing a technical report to Recommendation.
Document maturity level:Proposed EditedRecommendation.
Announcement: The DirectorMUST announce theCall for Review to other W3C groups, the public, and theAdvisory Committee. The announcementMUST clearly indicate that this is a proposal to edit aRecommendation andMUST:
Purpose: At this step, W3C seeks confirmation of proposed corrections to aRecommendation.
Entrance criteria: The Director calls for review when satisfied that, withrespect to changes to the document, the Working Group has fulfilled the sameentrance criteria as for aCall for Review of a ProposedRecommendation (e.g., the Working Group can show implementation experiencethat supports the changes). In the request to advance to this status, theWorking GroupMUST report any substantive issuesabout the technical report that have not been resolved.
Advisory Committee representativesMAYappeal the decision to advance the technicalreport.
Duration of the review: The announcement begins a formal Advisory Committeereview period thatMUST last at leastfour weeks.
Ongoing work: During the review period, the Working Group solicits andresponds to comments from the Team, the Members, other W3C groups, and thepublic.
Possible next steps:
Document maturity level: A Recommendation, plus a list of proposedcorrections. The Working GroupSHOULD also includea detailed description of how the Working Group plans to change the text of theRecommendation for each proposed correction.
Announcement: The Working GroupMUST announcethe Call for Review to other W3C groups, the public, and theAdvisory Committee. This is not a formalAdvisory Committee review. However, theannouncementMUST clearly indicate that this is aproposal to make normative corrections to the Recommendation andMUST:
Purpose: At this step, W3C seeks confirmation of proposed corrections to aRecommendation.
Entrance criteria: The Working Group calls for review when, with respect tochanges to the document, the group has fulfilled the same entrance criteria asfor aCall for Review of a Proposed Recommendation.
Duration of the review: The announcement begins a review period thatMUST last at leastfour weeks.
Ongoing work: Same as for aProposed EditedRecommendation.
If there are noFormalObjections to the proposed corrections, W3C considers them normative. TheWorking GroupMUST report Formal Objections to theDirector, who assesses whether there is sufficient consensus to declare theproposed corrections to be normative.
Possible next steps:
At times, W3CMAY rescind an entireRecommendation, for instance when W3C learns of significant errors in theRecommendation, when the Recommendation becomes outdated, or if W3C discoversburdensome patent claims that affect implementers; see theW3C Patent Policy [PUB33] and in particularsection 5(bullet 10) andsection7.5.
To deprecatepart of a Recommendation, W3C follows the process formodifying a Recommendation.
Once W3C has published a Rescinded Recommendation, future W3C technicalreportsMUST NOT include normative references tothat technical report.
Document maturity level: Recommendation, plus separate rationale for theproposal to rescind.
Announcement: The DirectorMUST announce theProposal to Rescind a Recommendation to other W3C groups, the public, and theAdvisory Committee. The announcementMUST clearly indicate that this is a Proposal toRescind a Recommendation andMUST:
Purpose: At this step, W3C seeks confirmation of a Proposal to Rescind aRecommendation.
Entrance criteria: The Director proposes that W3C rescind a Recommendationwhen satisfied that there is sufficient reason.
Advisory Committee representativesMAYappeal the Proposal to Rescind theRecommendation.
Duration of the review: The announcement begins a review period thatMUST last at leastfour weeks.
Ongoing work: During the review period, the Working Group solicits andresponds to comments from the Team, the Members, other W3C groups, and thepublic.
Possible next steps:
Document maturity level:RescindedRecommendation.
Announcement: The DirectorMUST announce thePublication of a Rescinded Recommendation to theAdvisory Committee.
Purpose: At this step, W3C indicates that it no longer endorses a previouslypublished Recommendation.
Entrance criteria: The Director publishes a Rescinded Recommendation whensatisfied that there is significant support from the Advisory Committee, theTeam, W3C Working Groups, and the public. The decision to advance a document toRescinded Recommendation is aW3Cdecision.
The TeamMAY publish one or more documents inorder to best communicate what has been rescinded and its relation to previousRecommendations (e.g., the publication can be as simple as a cover sheet thatrefers to a previously published Recommendation).
If there was anydissent in theProposed Rescinded Recommendation reviews, Advisory Committee representativesMAYappealthe decision to rescind the Recommendation.
Possible next step:
Every document published as part of the technical report development processMUST be a public document. Theindex of W3C technical reports [PUB11] is available at the W3C Web site. W3C willmake every effort to make archival documents indefinitely available at theiroriginal address in their original form.
Every document published as part of the technical report development processMUST clearly indicate itsmaturity level.
Every technical report published as part of the technical report developmentprocess is edited by one or more editors appointed by a Working Group Chair. Itis the responsibility of these editors to ensure that the decisions of thegroup are correctly reflected in subsequent drafts of the technical report. Aneditor for the TAG or Advisory Board who is not an elected or appointedparticipant in that groupMUST fulfill the sameparticipation requirements for that group, as a Member representative, Teamrepresentative, or Invited Expert. All other W3C editorsMUST be participants in the group responsible for thedocument(s) they are editing. Note that an editor isNOTREQUIRED to be a Team representative.
The Team isNOT REQUIRED to publish a technicalreport that does not conform to the Team'sPublication Rules (e.g., fornaming, style, andcopyright requirements). Theserules are subject to change. The TeamMUST informgroup Chairs and the Advisory Board of any changes.
The Team reserves the right to reformat technical reports at any time so asto conform to changes in W3C practice (e.g., changes to technical report stylesor thedocument status section).
The primary language for W3C technical reports is English. W3C encouragesthe translation of its technical reports.Information about translations ofW3C technical reports [PUB18] isavailable at the W3C Web site.
Each technical reportMUST include a sectionabout the status of the document. The status sectionSHOULD explain why W3C has published the technical report,expectations about next steps, who developed it, where to send comments aboutit, whether implementation experience is being sought, any significant changesfrom the previous version, why work on the technical report has ceased or beensubsumed, and any other relevant information or rationale.
The Team'sPublication Rulesinclude status section requirements for each maturity level.