This document aims to provide readers with a shorter overview of the W3C Process Document written in plain English. The original W3C Process Document is a complete document, written to be legally accurate and give indepth detail on each item and process. This document aims to give an overview of the main document, so new and existing W3C participants can gain an understanding of all W3C processes and know where to go for more information.

Readers should note that this document is not a legal document, it does not replace the W3C Process Document, and it does not cover aspects of the W3C Patent Policy.

• W3C Process for Busy People
  • The W3C Process Document
  • Language
  • Terms
• Leadership and Leadership Groups
  • Advisory Board (AB)
  • Technical Architecture Group (TAG)
  • Advisory Committee (AC)
  • The W3C Team
• Understanding W3C Members
  • Members
  • Membership Consortia
• W3C Groups
  • W3C Interest and Working Groups
  • Setting Up Interest and Working Groups
  • Charter and Call for Participation
  • Participants
  • Meetings
  • Consensus and Formal Objections
  • Voting
  • Closing a Group
  • W3C Councils
• W3C Recommendations and Notes
  • Requirements for W3C Recommenations
  • Editors
  • W3C Recommenation (Technical Report) Flow: The "Recommendation Track"
  • Maturity Levels Explained
  • Transition Requests and Moving Between Recommendation Track Stages
  • Reviewing Documents and Wide Review
  • Ending a Document
  • Modifying a W3C Recommendation
• Member Submissions
• Communication
  • Confidentiality Levels
• Workshops and Symposia
• Liaisons

The W3C standards process aims to maximise consensus and allow for standards to be built which are well-written, consistent and royalty-free. The full process document can be found here.

The W3C Process Document is updated similar to any W3C document. Every year, the Process Community Group amends the document based on comments expressed by the community, then sends the document for AC Review. On a successful AC Review, the new process will be announced to the AC. More information can be found on the W3C Process Document.

The primary language of W3C is English for specification text (US english). W3C encourage translations of all their documents. More information can be found here.

Use this list to quick link to a section of this document. Or, scroll past it to view the full Process Document for Busy People.

• The AB: See The Advisory Board
• The AC: See The Advisory Committee
• AC Appeal: See AC Appeals
• AC Review: See AC Reviews
• Adaquate Implementation Experience: See Implementation Experience
• Adopted Working Draft:
• The Advisory Board: See The Advisory Board
• The Advisory Committee: See The Advisory Committee
• Amended Recommendation: See Revised Recommendation (Edited and Amended Recommendations)
• Call For Participation: See Charter and Call for Participation
• Candidate Amended Recommendation: See Revised Recommendation (Edited and Amended Recommendations)
• Candidate Recommendation: See Candidate Recommendation
• Charter: See Charter and Call for Participation
• Confidentiality Levels: See Confidentiality Levels
• Consensus: See Consensus and Formal Objections
• Correction Classes: See Correction Classes
• Dissemination Policies: See Communication
• Dissent: See Consensus and Formal Objections
• Edited Recommendation: See Revised Recommendation (Edited and Amended Recommendations)
• Editors: See Editors
• Editors Drafts: See Editors
• First Public Working Draft: See (Working Draft)[#working-draft]
• Formal Objections: See Consensus and Formal Objections
• Group Decision Appeal: See Group Decision Appeals and Formal Objections
• Horizontal Groups: See Reviewing Documents and Wide Review
• Implementation Experience: See Implementation Experience
• Interest Group: See W3C Interest and Working Groups
• Interest Group Notes: See W3C Interest and Working Groups
• Invited Experts: See Participants
• Liaisons: See Liaisons
• Maturity Level: See Maturity Levels Explained
• Member Only: See Confidentiality Levels
• Member Representative: See Participants
• Member Submissions: See Member Submissions
• Members: See Members
• Membership Consortia: See Membership Consortia
• Notes: See W3C Interest and Working Groups
• Obsolete Recommendation: See Rescinded, Obsolete or Superseded Recommendations
• Participant: See Participants
• The Process Document: See The Process Document
• Proposed Recommendation: See Proposed Recommendation
• Public Participant: See Participants
• Rec: See W3C Recommendation
• Recommendation: See W3C Recommendation
• Recommendation Track: See W3C Recommenation (Technical Report) Flow: The "Recommendation Track"
• Reference Draft: latest Working Draft published within 90 days of the First Public Working Draft or if no Public Working Draft __:
• Rescinded Recommendation: See Rescinded, Obsolete or Superseded Recommendations
• Revised Candidate Recommendation: See Revised Candidate Recommendation
• Revised Recommendation: See Revised Recommendation (Edited and Amended Recommendations)
• Standard: See W3C Recommendation
• Substantive Changes: See the W3C Process Document to see details on Substantive Changes.
• Superceded Recommendation: See Rescinded, Obsolete or Superseded Recommendations
• Symposia: See Workshops and Symposia
• The TAG: See The TAG
• Task Forces: See W3C Interest and Working Groups
• The Team: See The W3C Team
• Team Contact: See The W3C Team
• Team Only: See Confidentiality Levels
• Team Representatives: See Participants
• Team Submissions: published information to the W3C Website put forward by the team see The W3C Process Document for more information.
• The Technical Architecture Group: See The TAG
• Technical Report: See W3C Recommendation
• TR: See W3C Recommendation
• Transition Request: See Transition Requests and Moving Between Recommendation Track Stages
• W3C Council: See W3C Councils
• W3C Fellows: Member employees working as part of the Team. See the W3C Website for more information
• W3C Members: See Members
• W3C Member Submissions: See Member Submissions
• W3C Recommendation: See W3C Recommendation
• W3C Symposia: See Workshops and Symposia
• The W3C Team: See The W3C Team
• W3C Workshop: See Workshops and Symposia
• Wide Review: See Reviewing Documents and Wide Review
• Working Draft: See (Working Draft)[#working-draft]
• Working Group: See W3C Interest and Working Groups
• Working Group Charter: See Charter and Call for Participation
• Working Group Notes: See W3C Interest and Working Groups
• Working Group Participants: See Participants
• Workshop: See Workshops and Symposia
• Voting: See Voting.

The W3C leadership and leadership groups are responsible for the process, technical direction, group development and major decisions taken within the W3C.

The Advisory Board (AB) provides ongoing guidance to the Team on issues of strategy, management, legal matters, process, and conflict resolution. The AB also manages the evolution of the W3C Process Document.

The AB is nine individuals elected by the AC. The Team appoints a chair who is not necessarily a member of the AB (currently the W3C CEO). AB members participate as individuals, not on behalf of their employer. The AB provides updates about their activities on the AB website and at AC Meetings.

For more information on AB members, terms, election process and responsibilities, please see the AB Website and the W3C Process Document.

The work of the Technical Architecture Group (TAG) is focused on Web Architecture and technical outputs of W3C. The TAG discuss and resolve issues related to Web Architecture, and coordinate cross-technology architecture developments inside and outside W3C.

The TAG consists of three Team-appointed individuals, six individuals elected by the AC, and Tim Berners-Lee, who is a TAG life-member. TAG members participate as individuals, not on behalf of their employer. The TAG provides updates on its activities at AC Meetings, and on the (member-only) AC Mailing List for AC representatives.

For more information on TAG members, terms, election process and responsibilities, please see the TAG Website and the W3C Process Document.

Each W3C member organisation can nominate one person to the W3C Advisory Committee (AC). This Advisory Committee member will be added to the AC Mailing Lists w3c-ac-members for general annoucements - AC members cannot post to it - and w3c-ac-forum for AC discussions and are invited to AC meetings. The AC responsibilities include:

• Reviewing group charter proposals, proposed recommendations and proposed process documents
• Electing Advisory Board members
• Electing Technical Architecture Group members
• Reviewing W3C strategic and event plans
• (Advisory Committee representatives may also initiate an Advisory Committee Appeal).

The AC holds two face-to-face meetings a year: during TPAC (generally in September, October or November) and a dedicated AC Meeting (usually held between March and June). At AC Meetings the AC will receive updates on the W3C Membership and finances, budget allocation, updates on Interest and Working Groups, and liaisons with other organisations. Meetings are added to the AC Meeting schedule no later than two AC meetings before.

Advisory Committee members may need to disclose certain information regarding ptential conflicts of interest or singificant relationships between W3C member organisations, please consult the W3C Process Document more information.

For more information on AC membership and responsibilities, please see the W3C Process Document.

The AC will review new or modified Working and Interest Groups charters, Proposed Recommendations, proposals to Obsolete, Rescind, Supersede, or Restore Recommendations, and propose changes to the W3C process. Typically, these review periods are at least 28 days.

The Team will send a "Call for Review" to the AC on the AC Mailing List. Each AC member may send in one review on behalf of their W3C Member organisation. AC Members can modify their reviews until the review period has ended.

After the review has ended, the Team will announce the results of the review detailing support and any formal objections. The proposal could be: approved, approved with changes, returned for further work or rejected. Please consult the W3C Process Document for a break down of each of these.

The AC can appeal W3C decisions. This is rare. Appeals are usually related to Working or Interest Group creation or modification, or a document progressing through the Recommendation Track. For a fuller list of decisions which can be appealed please see the W3C Process Document.

Appeals must start within three weeks of the a decision. AC Members send an appeal to the Team, the Team then announce this appeal to the AC allowing the AC to support the appeal if they wish.

If a substantial amount of support is recieved within a certain timeframe then a vote may be organised. The vote will assess whether the AC supports or rejects the W3C decision. Please consult the W3C Process Document for details on the requirements and running of this ballot.

The Team consists of the CEO, W3C paid staff, unpaid interns, and W3C Fellows (Member employees working as part of the Team).

The team provides technical leadership, supports Interest and Working Group acitivies, and manages communications to members and the public. The team may make Team Submissions.

Oversight over the Team is provided by the W3C Board of Directors.

For more information on the W3C team see the W3C Process Document.

W3C Members make up the bulk of participants in W3C Interest and Working Groups. Each member also has one seat on the Advisory Committee.

As well as particpating in Interest and Working Groups, members have access to Member-Only information, they can take advantage of the Member Submission process, and are invited to all W3C Workshops and Symposia.

Please see How to Join W3C for guidelines on how to become a member of W3C.

For more information on members, please see the W3C Process Document.

Members which are related by business contracts such as subsidiaries, partnerships and contracting obligations should consult the W3C Process Document for instructions on declaring these relationships.

A "Member Consortium" means a consortium, user society, or association of two or more individuals, companies, organizations or governments, or any combination of these which participate (or wish to participate) in W3C. Membership Consortia paid staff have the same rights and privileges of the W3C Membership.

Those who require more information on Membership Consortia should refer to the W3C Process Document.

There are two types of W3C group:

• Working Groups: work on deliverables, usually Technical Reports (standards).
• Interest Groups: evaluate potential Web technologies and policies. Do not work on Technical Reports.

Groups have: a publicly available Charter, a Chair (or co-Chairs), a Team Contact, and a mailing list.

A group sometimes will have Task Forces which carry our assignments which are already detailed in the group Charter.

For more information on groups see the W3C Process Document.

The Process for setting up an Interest or Working Group is explained below:

• Generating Interest: a topic gains some interest within W3C. This could be via a member submission, a W3C run workshop, W3C team research, a Community Group or through the Web Incubator Community Group.
• AC Announcement: the Team announces the development of an Interest or Working Group charter on the AC Mailing List.
• Charter Development: the Interest / Working Group proponents work on the new group charter with a W3C team member.
• Member Review: W3C members review the charter, and give feedback.
• W3C Approval: the Team announces a W3C Decision approving the creation of the Interest / Working Group on the AC Mailing List.
• Call For Participation: the Team calls for participation in the newly formed group on the AC Mailing List.

Each Working Group and Interest Group will be supported by at least one W3C team member. Group participants are usually Member Represenatives although Invited Experts may also be able to join groups.

For more information, please see the W3C Process Document.

All Working and Interest Groups have a Charter. Charters are developed by W3C Members and W3C team members. Charters can be made at any time.

When a new Charter is made the proponents (people writing the charter) make the Advisory Committee (AC) aware of the new charter through the AC mailing list list. The AC reviews all new charters for a minimum of four weeks.

After the AC has approved the Charter, the Team calls for participation in the group, inviting all AC members to join or nominate colleagues to join the group.

For details on the Call for Participation and AC Appeals against Working or Interest Groups being created please see the W3C Process Document.

Group charters include the following information:

• The group mission
• Scope of work
• Criteria for success
• Group expected duration
• List of group deliverables and timelines. If these are Recommendation Track documents (specifications) these items should be included (check Charter Deliverable Terms for terms to use for deliverables within Charters):
  • Title
  • Stable URL
  • Publication date.
• Details on how deliverables are approved
• Dependancies on groups within W3C or other bodies
• Level of confidentiality of the group's deliverables
• Frequency and type of meetings
• Communication methods
• Expected time commitments from participants
• Expected time commitments from the team (W3C staff)
• Intellectual property information.

Other possible items to include in the Charter is participation requirements (for Interest Groups), voting procedures, and constraints on participants and deliverables not covered in the W3C Process Document.

Further details can be found in the W3C Process Document.

The W3C Process Document discusses terms such as "Reference Draft", "Exclusion Draft" and "Adopted Draft" as ways to describe deliverables in a Charter. Here is a brief overview of these. Please see the W3C Process Document for a deeper understanding.

• Reference Draft: In most cases this is the latest Working Draft or First Public Working Draft if this is the latest. Patent exclusions will be made against this draft, for specific rules please see the W3C Process Document and W3C Patent Policy.
• Adopted Draft: This draft is used as the basis for the deliverable. Some standards bodies refer to this as "Working Group Adopted Draft". This means this draft will be a basis for the final deliverable, but the final document (which may be a W3C Recommendation or Note) could be very different.
• Exclusion Draft: this is a recent Working Draft or Candidate Recommendation that triggered an Exclusion Opportunity. For specific information please see the W3C Process Document and W3C Patent Policy.

Working and Interest Groups can be extended past their agreed Charter completion dates. The Team can do this by simply announcing to the AC Mailing List that the group has been extended and the new time period.

Details on group extensions can be found in the W3C Process Document.

Participants in Interest and Working Groups should be technically capable, fair and confident to speak and interact with others in the group. There are four types of group participant; all can participate in an Interest Group, all but public participants can participate in a Working Group.

• Member Representatives: An individual representative from a W3C member oragnisation. AC members nominate people within their organisation to participate within groups (in some cases an AC member may be able to nominate someone from outside their organisation).
  • Members in Working Groups: Before joining the group, the AC member sends a statement that confirms the new member agrees with the participation terms detailed in the charter.
  • Members in Interest Groups: Before joining the group, the AC member checks the participation intructions in the group charter (which can involve a statement as for working groups or could simply involve adding the new member to the group mailing list).
• Invited Experts: an individual with valuable expertise to a group and is not an employee of a W3C Member. Detailed rules apply for becoming an Invited Expert.
• Team Representatives: staff members of W3C. Team members can be a Team Contact or a regular participant of a group.
• Public Participants: members of the public. Cannot be Working Group participants.

Generally all group members are members of the group until the group closes or they resign from the group.

For more information on members including dismisal processes see the W3C Process Document on Participation Criteria and Group Participation.

A Conflict of Interest Policy exists which instructs participants on how to disclose any conflict of interest a participant may have with the W3C and / or group work. See the W3C Process Document for more information.

Group participants can sometimes send people in their place when unable to attend themselves. This representative can vote on behalf of the original member. Group members should inform the chairs when they are sending a representative. Rules for this are detailed in the W3C Process Document.

Working Groups work best when composed of a small number of experts. Interest Groups can often be larger. To find out more on group size and possible splitting of larger groups please see the W3C Process Document.

Meetings can either be face-to-face or "distributed" (via teleconference, IRC and / or video conferencing). Meeting announcements are sent on Interest or Working Group mailing lists.

Typically meetings are only open to group participants. Sometimes a meeting guest will be invited, this guest will not have voting rights.

Face-to-face meetings should be announced eight weeks before the meeting, distributed meetings one week before.

For more information on meetings please see the W3C Process Document.

Consensus is a core value of W3C. The W3C agreed definition for Consensus and Dissent is given below; for more information please see the W3C Process Document.

1. Consensus: A substantial number of individuals in the set support the decision and nobody in the set registers a Formal Objection. Individuals in the set may abstain. Abstention is either an explicit expression of no opinion or silence by an individual in the set. Unanimity is the particular case of consensus where all individuals in the set support the decision (i.e., no individual in the set abstains).
2. Dissent: At least one individual in the set registers a Formal Objection.

A set of group members may appeal a group decision. The group should first register their opinion with the chair and team contact, and then raise a Group Decision Appeal which requests a W3C Council to review the decision. For more information please see the W3C Process Document.

Individuals may raise a Formal Objection against Interest or Working Group decisions. A W3C Council will review any Formal Objections and the related group decision. Formal Objections should contain technical arguments and proposed changes. Formal Objections will be public.

For more information on Formal Objections please see the W3C Process Document.

Sometimes, no matter how hard a group tries, consensus cannot be reached for a decision. In these cases, voting is sometimes used. Chairs must follow clear steps and record a set of information when voting, for details on this please see the W3C Process Document. Here is a simple overview of the process:

• Votes generally only happen when consensus cannot be reached
• Chairs must detail the issue and voting process
• Only group participants may vote
• Each organisation only receives one vote (even if they have more members in the group)
• Invite experts can vote
• Outcome of the vote should be recorded in the minutes.

Voting may also be used for minority issues; these votes have less stringest rules. For details on this please see the W3C Process Document.

Groups may close because they have achieved their deliverables, reached their duration and do not wish to extend, or because they cannot achieve their charter goals for some reason (e.g. insufficent resources).

The Team sends a mail to the AC to confirm a group has closed.

A W3C Council is the body convened to resolve Formal Objections by combining the capabilities and perspectives of the AB, the TAG, and the Team, and is tasked with doing so in the best interests of the Web and W3C.

A W3C Recommendation is a recognised W3C standard (also referred to as a "Technical Report"). W3C Recommendations have been agreed and approved by a W3C Working Group, the AC and the Team.

All W3C Recommendations can be found in the index of W3C technical reports.

W3C Groups can also publish W3C Notes which are not Recommendation Track documents. Examples of W3C Notes include: lists of use cases, guidance, status of abandonded work, etc.

W3C Notes also follow the The Recommendation Track. They are usually declared as notes in Publication of zero or more revised Public Working Drafts: stage.

For more information please see the W3C Process Document.

W3C Recommenations (Technical Reports) are public documents at every stage of the Recommendation Track. The document will display a set information including:

• The document's maturity level (see Recommendation Track)
• The Working Group who developed the document
• Instructions on how and where to file bugs
• "Next Steps" for the document
• Explanation on how this document relates to existing web standards
• Explanation of changes from the previous document version (a "Change Log").

Every W3C Recommenation (Technical Report) will have one or more Editors. These Editors are responsible for writing a document in a way which reflects the decisions of the Working Group. All Editors must be members of the Working Group responsible for the document they are editing.

A typical flow of a document from draft to Technical Report is below:

• (Optional) Creation of Editor's Drafts: anyone can start an Editor's Draft. Working Group members will often develop these as individuals or within a small group and then submit them to a group to be considered for a First Public Working Draft.
  • Maturity Level: Editors Draft
  • To progress to next step: submit the Editor's Draft to the Working Group via the Working Group mailing list (email).
• Publication of the First Public Working Draft: a draft document, which can be reviewed by the members of the group and the public.
  • Maturity Level: Working Draft
  • To progress to next step: Working Group consensus on the document, Team verifies.
• Publication of zero or more revised Public Working Drafts: the community makes suggested changes to the drafts, these are considered and possibly added to make a revised Public Working Draft.
  • Maturity Level: Working Draft
  • To progress to next step: Working Group consensus on the document, Team verifies.
• Publication of a Candidate Recommendation: when the Working Group agrees the document is ready for final review the document is progressed to Candidate Recommendation. The document should satisfy all it's technical requirements, and it should have some working implementations. A Working Group should be confident that this document is final. The AC reviews the draft, implementations are encouraged and an opportunity to provide a patent exclusion is made.
  • Maturity Level: Candidate Recommendation
  • To progress to next step: Working Group approves, AC Review, Team verifies.
• Publication of a Proposed Recommendation: The Team has verified the document is of sufficient quality to be a standard, the AC now reviews the document as final. Any changes at this stage requires a new Working Draft or Candidate Recommendation.
  • Maturity Level: Proposed Recommendation
  • To progress to next step: Working Group consensus on the document, AC Review, Team verifies.
• Publication as a W3C Recommendation: the document is now a standard for the Web.
  • Maturity Level: W3C Recommendation
• Possibly, Publication as an Edited Recommendation: a W3C Recommendation receives edits, and must progress these edits through the process.

Members of the group should review documents throughout the process; although reviewing and suggesting changes as-early-as-possible is advised.

As documents progress through the "Recommendation Track" they progress through "document maturity levels", see more information on maturity levels below.

Editors Drafts are documents which individuals or groups work on as proposals to become Working Groups Drafts. Editors Drafts are an important part of many groups work; but they have no standing until they are upgraded to Working Drafts.

Submit the Editors Draft to a Working Group to become a "Working Draft", or "Working Group Note".

When a Working Group has agreed to begin work on a new standard or W3C Note they create a Working Draft. A Working Draft can be a new document or a Working Group can adopt an Editors Draft; both of these transition to become a "First Public Working Draft". This stage triggers a "Call for Exclusions" detailed in the W3C Patent Policy.

A Working Group then continues to work on this document, coming to consensus on decisions and editing the document to continue to create "Revised Working Drafts". If significant changes to the document have been made the group should be re-uploaded the document to the W3C Technical Reports Page. A Revised Working Draft will need to uploaded also if 6 months pass with no change; this Revised Draft indicates why there has been no change within this time.

The group will have to prepare some information on the Working Draft for a transition to the next Recommendation Track stage (see Recommendation Track and Transition Requests for more information on stages and transtions); these include:

• Recordings of the Group decision to advance the document
• Record of the changes from the last version
• Record of which requirements have changed since the last version (if any)
• Report of any change in depencies with other groups.

For all Working Drafts a Working Group will document outstanding issues and issues where the group has not reached consensus (many groups currently do this on Github). For more information please see the W3C Process Document.

Working Drafts can transition to become "Revised Working Drafts", "Candidate Recommendation" or "Working Group Note".

Candidate Recommendations are documents which are in their final review. At this stage the group will prepare a set of information to progress the document to the next stage (see Recommendation Track and Transition Requests for more information on stages and transtions). The information to be collected is:

• Explanation of how the document meets the Working Group requirements (outlined in the Charter) or why the requirements have changed
• Dependencies on other specifications
• Document how adaquate implementation experience was demonstrated
• Detail how the document received wide review
• Identify any at-risk feature.

The Working Group also advertises a deadline for comments, which is at least 28 days after publication.

This stage triggers a "Call for Exclusions" detailed in the W3C Patent Policy.

For more information please see the W3C Process Document.

If during the review period substantive changes are made to the document then the document can become a "Revised Candiate Recommendation"; this may trigger a "Call for Exclusions" detailed in the W3C Patent Policy. Please see the W3C Process Document for more information.

Candidate Recommendations can return to being a "Working Draft", can become a "Revised Candidate Recommendation", or can transition to become a "Proposed Recommendation" or "Working Group Note".

Proposed Recommendation is the final stage of the document before becoming a W3C Recommendation. The main purpose of this stage is to receive AC Review.

Working Groups should ensure the Proposed Recommendation meets the Transition Request requirements and will collect required information including details of implementation experience and explanations of issues and how these were formally addressed. A full list of information to gather can be found in the W3C Process Document.

The Working Group will then notify their Team Contact to request that the Team notifies the AC of the review period. The AC Review Period is at least 28 days and is 10 days after an Exclusion Opportunity (detailed in the W3C Patent Policy.

For more information please see the W3C Process Document.

Substantive edits cannot happen on Proposed Recommendations, so to make any changes the document will move back to being a "Working Draft" or a "Candidate Recommendation". Otherwise it can become a "W3C Recommendation" or "Working Group Note".

The W3C Recommendation is an approved standard of the W3C and the end of the W3C Recommendation Track! There are many informal terms used for a W3C Recommedation including "Rec", "Recommendation", "TR", "Technical Report", "Spec", "Standard"; they all mean the same thing.

To get to W3C Recommendation a "W3C Decision" is required; this is where a document has met all the Transition Request requirements, the Team has approved the document and the document has passed AC Review during the "Proposed Recommendation" stage.

The Team will announce the publication of the W3C Recommendation. If any AC member disagrees with the decision, they could raise an "Advisory Committee Appeal".

W3C Recommendations can become:

• An "Edited Recommendation" if a Working Group chooses to revise the document
• An "Amended Recommendation" if the document needs to be edited in a way which doesn't add new features and when a Working Group no longer exists to work on the document, or
• An "Obsolete Recommendation" if it is either no longer often used on the web or doesn't represent best practices. These may be restored to a Recommendation.
• A "Superseded Recommendation" if it's been replaced with a newer specification. These may be restored to a Recommendation.
• A "Rescinded Recommendation" is a document which W3C no longer endorses, and will never restore to a Recommendation.
• A "Working Group Note, Interest Group Note".

Going from one stage to the next involves making a "Transition Request". Team contacts will make Transition Requests once a number of goals have been met. These include:

• Obtaining and record group consensus
• Obtain Team approval
• Publicly documented changes to the previous version of the document
• Formally address issues by responding to a reviewer explaining decisions which have been made before or since the review (see the W3C Process Document for more information)
• Explain the Formal Objections raised and how these were managed.

It's recommended to include some other information such as details on implementations, changes to requirements or dependencies with other groups. A full list of goals an exclusions is included in the W3C Process Document.

Adaquate implementation experience is required to progress documents to W3C Recommendation. There is no checklist for "adaquate implementation experience", but group participants should strive to gather implementations that are publicly deployed, matching the proposed draft, and implemented by those other than the draft authors. For full guidelines see the W3C Process Document.

Both the W3C Decision and AC decisions could send the document back to a previous stage on The Recommendations Track. It is possible and common for the Team and AC to suggest changes which sends the document back to the Public Working Draft stage.

The W3C and / or the Team can stop the advancement of a draft at any stage; the AC will be made aware if this happens. For more information on these and detail breakdowns of the recommendation flow please see the W3C Process Document.

Documents can be reviewed as soon as they are published. Sending reviews in early is always advised. W3C participants often state that a document should receive "Wide Review"; but this term is not defined by the W3C Process Document.

Generally, all stakeholders of the Web Community should have the ability to review the document. An annoucnement will be made on public-review-announce@w3.org and the responsible Working Group should also make requests to Horizontal Groups (e.g. TAG and the Privacy Interest Group) to gain their reviews. The group should do everything it can to ensure all group participants, implementers, affected industry players, the Horizontal Groups and the general public have had adaquate time and instruction to review the document.

When the Team reviews the document during a Transition Request they will check that the correct level of reviews have been achieved.

The W3C Process Document defines some classes of document changes which gives reviewers some aid in deciding whether the document status has to change (for example, a document at the Proposed Recommendation stage may need to go back to Working Draft).

Working on a document can end at any time.

Errors may be found in a document after it has progressed to W3C Recommendation. In these instances a Working Group will keep a record of the error. The group will also provide details of the error with associated tests linked to the document in some way. The most common way is another published document which links to the W3C Recommendation. The Working Group will then revise the recommendation to correct the error.

If a Working Group has already closed, then the W3C can request the change.

Editorial changes can be progressed without going back to another stage in the Recommendation Track. Substantive changes can require the document to go back to Candidate Recommendation or, when a Working Group no longer exists, a "Candidate Amended Recommendation".

If the Working Group edited the document the recommendation becomes an "Edited Recommendation". If the W3C requested and completed the changes the document becomes an "Amended Recommendation".

All Transition Request requirements apply to revised recommendations as they do for any other stage of the Recommendation Track.

The W3C could decide that a W3C Recommendation is no longer recommended. There are three ways of categorising these Recommendations which have become non-recommended:

• An "Obsolete Recommendation" if it is either no longer often used on the Web or doesn't represent best practices. These continue to exist as W3C Recommendations but are not recommended for future implementations. They may be restored to a Recommendation.
• A "Superseded Recommendation" if it's been replaced with a newer specification. These continue to exist as W3C Recommendations but are not recommended for future implementations. They may be restored to a Recommendation.
• A "Rescinded Recommendation" is a document which W3C no longer endorses, and will never restore to a Recommendation.

There will be an AC Review for any request for a W3C Recommendation to become obsolete, superceded or rescinded. The Team will notify the AC, Working Group Chairs and the public of the request, detailing where to find the Recommendation and the rationale for the request. All stakeholders (including the AC and the public) will have at least 28 days after the Team's announcement to send in their reviews. Please see the W3C Process Document for details on what happens if someone disagrees with moving the document to be obsolete, superceded or rescinded.

The document will then be replublished as an Obsolete or Rescinded Recommendation. Future W3C Recommendations will not normatively reference Rescinded Recommendations.

If only a part of a W3C Recommendation needs to be obsoleted, superceded or rescinded then the document must go through the Revised Recommendation process.

Members can make document submissions to the W3C. These documents usually detail a technology or other ideas applicable to the Web. These documents have been developed outside the W3C, so they have not gone through the W3C Recommendation Track and are not W3C Recommendations. They can become a basis of future work, but there is no guarentee of this.

Member Submissions are a good way to build support for new work proposals for an upcoming Working Group; if a Working Group already exists it is preferable that technology is contributed through the Working Group as normal and follows the Recommendation Track rather than as a Member Submission.

Only one member makes a Member Submission, even if more than one member worked on the original documents. Strict processes are involved in making a Member Submission, please see the W3C Process Document on Information Required in a Submission Request and Submitter Rights.

Member Submissions are to follow the Publication Rules and are sent to the W3C Team. The Team will announce the Member Submission request to the AC then approve or reject the submissions. A rejected Member Submission can be appealed to the TAG or Advisory Board. Information on the appeal process can be found in the W3C Process Document.

The Team can then publish the Member Submission along with any supportive documents and comments; this will then be available to all W3C members and the public.

Further information can be found in the W3C Process Document.

The W3C Team will publish information on W3C Technical Reports, the Mission Statement, Legal Documents (such a Membership Agreements), The Process Document and results of W3C Activites and Workshops. Other W3C related news is distributed regularly. The team also maintains the calendar.

For more information on communication and confidentiality levels please see the W3C Process Document. The W3C Process Document refers to "Communication" as "Dissemination Policies".

There are three confidenetiality levels at W3C:

• Public: information is open to the general public
• Member-only: information is accessible to W3C Members, Invited Experts, AB, TAG and the W3C Team only
• Team-only: information is accessible to the W3C staff only.

Generally all information related to specification development should be publicly available.

For more information on confidentiality levels, the rules on sharing confidential data and changing confidentiality level please see the W3C Process Document.

Workshops are organised by W3C for a number of reasons, including: promoting involvement for new W3C activities, gathering experts to exchange ideas on technology or policy, discovering the applicability of a new technology to the Web (or vice versa) or to address concerns of W3C members.

A Symposium aims to educate participants on a particular subject.

Workshops and Symposium can be limited to W3C Members or open to the public. Often these events result in new groups or work items within W3C, but this is not guarenteed.

Workshops and Symposium has some participation and organisation rules, please see the W3C Process Document for details of these.

W3C sometimes coordinates acitivies with another organisation or informs other organisations of W3C work relevant to their work or operations. Liaisons are managed by the W3C Team.

The Team can negotiate a Technical Agreement (sometimes called a Memorandum of Understanding) with another organisation. This may be for many reasons including the W3C working with another organisation on a joint piece of work. The AC will be informed of an Technical Agreement before signing. For further details on Technical Agreement process please see the W3C Process Document.