W3C Process Document

Proposed Process,

This version:
https://www.w3.org/Consortium/Process/Drafts/snapshots/2020-06-25/
Latest published version:
https://www.w3.org/Consortium/Process/
Editor's Draft:
https://www.w3.org/Consortium/Process/Drafts/
Previous Versions:
Issue Tracking:
GitHub
Editors:
Elika J. Etemad / fantasai (Invited Expert)
Florian Rivoal (Invited Expert)
Former Editors:
Natasha Rooney (Invited Expert)
Charles McCathie Nevile (Yandex)
Ian Jacobs (W3C)

Abstract

The mission of the World Wide Web Consortium (W3C) is to lead the World Wide Web to its full potential by developing common protocols that promote its evolution and ensure its interoperability. The W3C Process Document describes the organizational structure of the W3C and processes, responsibilities and functions that enable W3C to accomplish its mission. This document does not describe the internal workings of the Team.

For more information about the W3C mission and the history of W3C, please refer to About W3C.

Status of this Document

W3C, including all existing chartered groups, follows the most recent operative Process Document announced to the Membership. This document is developed by the Advisory Board’s Process Task Force working within the Revising W3C Process Community Group (which anyone can join).

This document is based on the 1 March 2019 Process, which is the currently operative W3C Process.

This draft is offered for W3C Advisory Committee Review of the proposal to adopt this as the new operative Process document per Section 11 Process Changes.

A history of substantial changes from previous versions of the Process Document is provided. Comment is invited on the draft. Please file comments as issues in the w3c/w3process GitHub Repository. If you are unable to do this you may send them in email to public-w3process@w3.org (publicly archived) or to process-issues@w3.org (Member-only archive).

Relation of Process Document to Patent Policy

W3C Members' attention is called to the fact that provisions of the Process Document are binding on Members per the Membership Agreement [MEMBER-AGREEMENT]. The W3C Patent Policy [PATENT-POLICY] is incorporated by normative reference as a part of the Process Document, and is thus equally binding.

The Patent Policy places additional obligations on Members, Team, and other participants in W3C. The Process Document does not restate those requirements but includes references to them. The Process Document and Patent Policy have been designed to allow them to evolve independently.

In the Process Document, the term “participant” refers to an individual, not an organization.

Conformance and specialized terms

The terms must, must not, should, should not, required, and may are used in accordance with RFC 2119. The term not required is equivalent to the term may as defined in RFC2119 [RFC2119].

Some terms have been capitalized in this document (and in other W3C materials) to indicate that they are entities with special relevance to the W3C Process. These terms are defined within this document, and readers are reminded that the ordinary English definitions are insufficient for the purpose of understanding this document.

1. Introduction

Most W3C work revolves around the standardization of Web technologies. To accomplish this work, W3C follows processes that promote the development of high-quality standards based on the consensus of the Membership, Team, and public. W3C processes promote fairness, responsiveness, and progress: all facets of the W3C mission. This document describes the processes W3C follows in pursuit of its mission.

Here is a general overview of how W3C standardizes a Web technology. In many cases, the goal of this work is a W3C Recommendationa Web standard.

  1. People generate interest in a particular topic. For instance, Members express interest in the form of Member Submissions, and the Team monitors work inside and outside of W3C for signs of interest. Also, W3C is likely to organize a Workshop to bring people together to discuss topics that interest the W3C community.
  2. When there is enough interest in a topic (e.g., after a successful Workshop and/or discussion on an Advisory Committee mailing list), the Director announces the development of a proposal for one or more new Interest Group or Working Group charters, depending on the breadth of the topic of interest. W3C Members review the proposed charters. When there is support within W3C for investing resources in the topic of interest, the Director approves the group(s) and they begin their work.
  3. There are three types of Working Group participants: Member representatives, Invited Experts, and Team representatives. Team representatives both contribute to the technical work and help ensure the group’s proper integration with the rest of W3C. The Working Group charter sets expectations about each group’s deliverables (e.g., technical reports, test suites, and tutorials).
  4. Working Groups generally create specifications and guidelines that undergo cycles of revision and review as they advance to W3C Recommendation status. The W3C process for producing these technical reports includes significant review by the Members and public, and requirements that the Working Group be able to show implementation and interoperability experience. At the end of the process, the Advisory Committee reviews the mature technical report, and if there is support, W3C publishes it as a Recommendation.

The Process Document promotes the goals of quality and fairness in technical decisions by encouraging consensus, requiring reviews (by both Members and public) as part of the technical report development process, and through an Advisory Committee Appeal process.

The other sections of the Process Document:

  1. set forth policies for participation in W3C groups,
  2. establish two permanent groups within W3C: the Technical Architecture Group (TAG), to help resolve Consortium-wide technical issues; and the Advisory Board (AB), to help resolve Consortium-wide non-technical issues, and to manage the evolution of the W3C process, and
  3. describe other interactions between the Members (as represented by the W3C Advisory Committee), the Team, and the general public.

The W3C also operates Community and Business Groups, which are separately described in their own process document [BG-CG].

2. Members, Advisory Committee, Team, Advisory Board, Technical Architecture Group

W3C’s mission is to lead the Web to its full potential. W3C Member organizations provide resources to this end, and the W3C Team provides the technical leadership and organization to coordinate the effort.

2.1. Members

W3C Members are primarily represented in W3C processes as follows:

  1. The Advisory Committee is composed of one representative from each Member organization (refer to the Member-only list of current Advisory Committee representatives. [CURRENT-AC]) The Advisory Committee:

    Advisory Committee representatives may initiate an Advisory Committee Appeal in some cases described in this document.

  2. Representatives of Member organizations participate in Working Groups and Interest Groups and author and review technical reports.

W3C membership is open to all entities, as described in “How to Join W3C[JOIN]; (refer to the public list of current W3C Members [MEMBER-LIST]). Organizations subscribe according to the Membership Agreement [MEMBER-AGREEMENT]. The Team must ensure that Member participation agreements remain Team-only and that no Member receives preferential treatment within W3C.

While W3C does not have a class of membership tailored to individuals, individuals may join W3C. Restrictions pertaining to related Members apply when the individual also represents another W3C Member.

2.1.1. Rights of Members

Each Member organization enjoys the following rights and benefits:

Furthermore, subject to further restrictions included in the Member Agreement, representatives of Member organizations participate in W3C as follows:

The rights and benefits of W3C membership are contingent upon conformance to the processes described in this document. The vast majority of W3C Members faithfully follow the spirit as well as the letter of these processes. When serious and/or repeated violations do occur, and repeated attempts to address these violations have not resolved the situation, the Director may take disciplinary action. Arbitration in the case of further disagreement is governed by paragraph 19 of the Membership Agreement [MEMBER-AGREEMENT]. Refer to the Guidelines for Disciplinary Action [DISCIPLINARY-GL].

2.1.2. Member Consortia and Related Members

2.1.2.1. Membership Consortia

A “Member Consortium” means a consortium, user society, or association of two or more individuals, companies, organizations or governments, or any combination of these entities which has the purpose of participating in a common activity or pooling resources to achieve a common goal other than participation in, or achieving certain goals in, W3C. A joint-stock corporation or similar entity is not a Member Consortium merely because it has shareholders or stockholders. If it is not clear whether a prospective Member qualifies as a Member Consortium, the Director may reasonably make the determination. For a Member Consortium, the rights and privileges of W3C Membership described in the W3C Process Document extend to the Member Consortium's paid staff and Advisory Committee representative.

Member Consortia may also designate up to four (or more at the Team’s discretion) individuals who, though not employed by the organization, may exercise the rights of Member representatives.

For Member Consortia that have individual people as members, these individuals must disclose their employment affiliation when participating in W3C work. Provisions for related Members apply. Furthermore, these individuals must represent the broad interests of the W3C Member organization and not the particular interests of their employers.

For Member Consortia that have organizations as Members, all such designated representatives must be an official representative of the Member organization (e.g. a Committee or Task Force Chairperson) and must disclose their employment affiliation when participating in W3C work. Provisions for related Members apply. Furthermore, these individuals must represent the broad interests of the W3C Member organization and not the particular interests of their employers.

For all representatives of a Member Consortium, IPR commitments are made on behalf of the Member Consortium, unless a further IPR commitment is made by the individuals' employers.

2.1.2.2. Related Members

In the interest of ensuring the integrity of the consensus process, Member involvement in some of the processes in this document is affected by related Member status. As used herein, two Members are related if:

  1. Either Member is a subsidiary of the other, or
  2. Both Members are subsidiaries of a common entity, or
  3. The Members have an employment contract or consulting contract that affects W3C participation.

A subsidiary is an organization of which effective control and/or majority ownership rests with another, single organization.

Related Members must disclose these relationships according to the mechanisms described in the New Member Orientation [INTRO].

2.1.3. Advisory Committee (AC)

When an organization joins W3C (see “How to Join W3C[JOIN]), it must name its Advisory Committee representative as part of the Membership Agreement. The New Member Orientation [INTRO] explains how to subscribe or unsubscribe to Advisory Committee mailing lists, provides information about Advisory Committee Meetings, explains how to name a new Advisory Committee representative, and more. Advisory Committee representatives must follow the conflict of interest policy by disclosing information according to the mechanisms described in the New Member Orientation. See also the additional roles of Advisory Committee representatives described in the W3C Patent Policy [PATENT-POLICY].

Additional information for Members is available at the Member Web site [MEMBER-HP].

2.1.3.1. Advisory Committee Mailing Lists

The Team must provide two mailing lists for use by the Advisory Committee:

  1. One for official announcements (e.g., those required by this document) from the Team to the Advisory Committee. This list is read-only for Advisory Committee representatives.
  2. One for discussion among Advisory Committee representatives. Though this list is primarily for Advisory Committee representatives, the Team must monitor discussion and should participate in discussion when appropriate. Ongoing detailed discussions should be moved to other appropriate lists (new or existing, such as a mailing list created for a Workshop).

An Advisory Committee representative may request that additional individuals from their organization be subscribed to these lists. Failure to contain distribution internally may result in suspension of additional email addresses, at the discretion of the Team.

2.1.3.2. Advisory Committee Meetings

The Team organizes a face-to-face meeting for the Advisory Committee twice a year. The Team appoints the Chair of these meetings (generally the CEO). At each Advisory Committee meeting, the Team should provide an update to the Advisory Committee about:

Resources
  • The number of W3C Members at each level.
  • An overview of the financial status of W3C.
Allocations
  • The allocation of the annual budget, including size of the Team and their approximate deployment.
  • A list of all activities (including but not limited to Working and Interest Groups) and brief status statement about each, in particular those started or terminated since the previous Advisory Committee meeting.
  • The allocation of resources to pursuing liaisons with other organizations.

Each Member organization should send one representative to each Advisory Committee Meeting. In exceptional circumstances (e.g., during a period of transition between representatives from an organization), the meeting Chair may allow a Member organization to send two representatives to a meeting.

The Team must announce the date and location of each Advisory Committee meeting no later than at the end of the previous meeting; one year’s notice is preferred. The Team must announce the region of each Advisory Committee meeting at least one year in advance.

More information about Advisory Committee meetings [AC-MEETING] is available at the Member Web site.

2.2. The W3C Team

The Team consists of the Director, CEO, W3C paid staff, unpaid interns, and W3C Fellows. W3C Fellows are Member employees working as part of the Team; see the W3C Fellows Program [FELLOWS]. The Team provides technical leadership about Web technologies, organizes and manages W3C activities to reach goals within practical constraints (such as resources available), and communicates with the Members and the public about the Web and W3C technologies.

The Director and CEO may delegate responsibility (generally to other individuals in the Team) for any of their roles described in this document, except participation in the TAG.

The Director is the lead technical architect at W3C, whose responsibilities are identified throughout this document in relevant places. Some key ones include: assessing consensus within W3C for architectural choices, publication of technical reports, and chartering new Groups; appointing group Chairs, adjudicating as "tie-breaker" for Group decision appeals, and deciding on the outcome of formal objections; the Director is generally Chair of the TAG.

Team administrative information such as Team salaries, detailed budgeting, and other business decisions are Team-only, subject to oversight by the Host institutions.

Note: W3C is not currently incorporated. For legal contracts, W3C is represented by four “Host” institutions: Beihang University, the European Research Consortium for Informatics and Mathematics (ERCIM), Keio University, and the Massachusetts Institute of Technology (MIT). Within W3C, the Host institutions are governed by hosting agreements; the Hosts themselves are not W3C Members.

2.3. Advisory Board (AB)

Created in March 1998, the Advisory Board provides ongoing guidance to the Team on issues of strategy, management, legal matters, process, and conflict resolution. The Advisory Board also serves the Members by tracking issues raised between Advisory Committee meetings, soliciting Member comments on such issues, and proposing actions to resolve these issues. The Advisory Board manages the evolution of the Process Document. The Advisory Board hears a Submission Appeal when a Member Submission is rejected for reasons unrelated to Web architecture; see also the TAG.

The Advisory Board is not a board of directors and has no decision-making authority within W3C; its role is strictly advisory.

The Team must make available a mailing list, confidential to the Advisory Board and Team, for the Advisory Board to use for its communication.

The Advisory Board should send a summary of each of its meetings to the Advisory Committee and other group Chairs. The Advisory Board should also report on its activities at each Advisory Committee meeting.

Details about the Advisory Board (e.g., the list of Advisory Board participants, mailing list information, and summaries of Advisory Board meetings) are available at the Advisory Board home page [AB-HP].

2.3.1. Advisory Board Participation

The Advisory Board consists of nine to eleven elected participants and a Chair. The Team appoints the Chair of the Advisory Board, who is generally the CEO. The team also appoints a Team Contact for the AB, as described in § 5.1 Requirements for All Working and Interest Groups.

The remaining nine to eleven Advisory Board participants are elected by the W3C Advisory Committee following the AB/TAG nomination and election process.

With the exception of the Chair, the terms of all Advisory Board participants are for two years. Terms are staggered so that each year, either five or six terms expire. If an individual is elected to fill an incomplete term, that individual’s term ends at the normal expiration date of that term. Regular Advisory Board terms begin on 1 July and end on 30 June.

2.4. Technical Architecture Group (TAG)

Created in February 2001, the mission of the TAG is stewardship of the Web architecture. There are three aspects to this mission:

  1. to document and build consensus around principles of Web architecture and to interpret and clarify these principles when necessary;
  2. to resolve issues involving general Web architecture brought to the TAG;
  3. to help coordinate cross-technology architecture developments inside and outside W3C.

The TAG hears a Submission Appeal when a Member Submission is rejected for reasons related to Web architecture; see also the Advisory Board.

The TAG's scope is limited to technical issues about Web architecture. The TAG should not consider administrative, process, or organizational policy issues of W3C, which are generally addressed by the W3C Advisory Committee, Advisory Board, and Team. Please refer to the TAG charter [TAG-CHARTER] for more information about the background and scope of the TAG, and the expected qualifications of TAG participants.

The Team must make available two mailing lists for the TAG:

The TAG may also request the creation of additional topic-specific, public mailing lists. For some TAG discussions (e.g., a Submission Appeal), the TAG may use a list that will be Member-only.

The TAG should send a summary of each of its meetings to the Advisory Committee and other group Chairs. The TAG should also report on its activities at each Advisory Committee meeting.

When the TAG votes to resolve an issue, each TAG participant (whether appointed, elected, or the Chair) has one vote; see also the section on voting in the TAG charter [TAG-CHARTER] and the general section on votes in this Process Document.

Details about the TAG (e.g., the list of TAG participants, mailing list information, and summaries of TAG meetings) are available at the TAG home page [TAG-HP].

2.4.1. Technical Architecture Group Participation

The TAG consists of:

The Team appoints the Chair of the TAG, who must be one of the participants. The team also appoints a Team Contact [TEAM-CONTACT] for the TAG, as described in § 5.1 Requirements for All Working and Interest Groups.

The terms of elected and Director-appointed TAG participants are for two years. Terms are staggered so that each year three elected terms, and either one or two appointed terms expire. If an individual is appointed or elected to fill an incomplete term, that individual’s term ends at the normal expiration date of that term. Regular TAG terms begin on 1 February and end on 31 January.

The Director may announce the appointed participants after the results for the Advisory Committee election of participants have been announced.

2.5. Advisory Board and Technical Architecture Group Participation

Advisory Board and TAG participants have a special role within W3C: they are elected by the Membership and appointed by the Director with the expectation that they will use their best judgment to find the best solutions for the Web, not just for any particular network, technology, vendor, or user. Advisory Board and TAG participants are expected to participate regularly and fully. Advisory Board and TAG participants should attend Advisory Committee meetings.

Individuals elected or appointed to the Advisory Board or TAG act in their personal capacity, to serve the needs of the W3C membership as a whole, and the Web community. Whether they are Member representatives or Invited Experts, their activities in those roles are separate and distinct from their activities on the Advisory Board or TAG.

An individual participates on the Advisory Board or TAG from the moment the individual’s term begins until the seat is vacated (e.g. because the term ends). Although Advisory Board and TAG participants do not advocate for the commercial interests of their employers, their participation does carry the responsibilities associated with Member representation, Invited Expert status, or Team representation (as described in the section on the AB/TAG nomination and election process).

Participation in the TAG or AB is afforded to the specific individuals elected or appointed to those positions, and a participant’s seat must not be delegated to any other person.

2.5.1. Advisory Board and Technical Architecture Group Participation Constraints

Given the few seats available on the Advisory Board and the TAG, and in order to ensure that the diversity of W3C Members is represented:

2.5.2. Advisory Board and Technical Architecture Group Elections

The Advisory Board and a portion of the Technical Architecture Group are elected by the Advisory Committee, using a Single Transferable Vote system. An election begins when the Team sends a Call for Nominations to the Advisory Committee. Any Call for Nominations specifies the minimum and maximum number of available seats, the deadline for nominations, details about the specific vote tabulation system selected by the Team for the election, and operational information such as how to nominate a candidate. The Team may modify the tabulation system after the Call for Nominations but must stabilize it no later than the Call for Votes. The Director should announce appointments no later than the start of a nomination period as part of the Call for Nominations.

In the case of regularly scheduled elections of the TAG, the minimum and maximum number of available seats are the same: the 3 seats of the terms expiring that year, plus the number of other seats that are vacant or will be vacant by the time the newly elected members take their seats.

In the case of regularly scheduled elections of the AB, the minimum and maximum number of available seats differ: The maximum number is the 5 or 6 seats of the terms expiring that year, plus the number of other seats that are vacant or will be vacant by the time the newly elected members take their seats; the minimum number is such that when added to the occupied seats from the prior year, the minimum size of the AB (9) is reached.

Each Member (or group of related Members) may nominate one individual. A nomination must be made with the consent of the nominee. In order for an individual to be nominated as a Member representative, the individual must qualify for Member representation and the Member’s Advisory Committee representative must include in the nomination the (same) information required for a Member representative in a Working Group. In order for an individual to be nominated as an Invited Expert, the individual must provide the (same) information required for an Invited Expert in a Working Group and the nominating Advisory Committee representative must include that information in the nomination. In order for an individual to be nominated as a Team representative, the nominating Advisory Committee representative must first secure approval from Team management. A nominee is not required to be an employee of a Member organization, and may be a W3C Fellow. The nomination form must ask for the nominee’s primary affiliation, and this will be reported on the ballot. For most nominees, the primary affiliation is their employer and will match their affiliation in the W3C database. For contractors and invited experts, this will normally be their contracting company or their invited expert status; in some cases (e.g. where a consultant is consulting for only one organization) this may be the organization for whom the nominee is consulting. A change of affiliation is defined such that this field would carry a different answer if the nominee were to be re-nominated (therefore, terminating employment, or accepting new employment, are changes of affiliation). (Other formal relationships such as other contracts should be disclosed as potential conflicts of interest.) Each nomination should include a few informative paragraphs about the nominee.

If, after the deadline for nominations, the number of nominees is:

When there is a vote, each Member (or group of related Members) may submit one ballot that ranks candidates in the Member’s preferred order. Once the deadline for votes has passed, the Team announces the results to the Advisory Committee. In case of a tie the verifiable random selection procedure described below will be used to fill the available seats.

The shortest term is assigned to the elected candidate ranked lowest by the tabulation of votes, the next shortest term to the next-lowest ranked elected candidate, and so on. In the case of a tie among those eligible for a short term, the verifiable random selection procedure described below will be used to assign the short term.

Refer to How to Organize an Advisory Board or TAG election [ELECTION-HOWTO] for more details.

2.5.2.1. Verifiable Random Selection Procedure

When it is necessary to use a verifiable random selection process (e.g., in an AB or TAG election, to “draw straws” in case of a tie or to fill a short term), W3C uses the random and verifiable procedure defined in RFC 3797 [RFC3797]. The procedure orders an input list of names (listed in alphabetical order by family name unless otherwise specified) into a “result order”.

W3C applies this procedure as follows:

  1. When N people have tied for M (less than N) seats. In this case, only the names of the N individuals who tied are provided as input to the procedure. The M seats are assigned in result order.
  2. After all elected individuals have been identified, when N people are eligible for M (less than N) short terms. In this case, only the names of those N individuals are provided as input to the procedure. The short terms are assigned in result order.

2.5.3. Advisory Board and Technical Architecture Group Vacated Seats

An Advisory Board or TAG participant’s seat is vacated when:

If a participant changes affiliation, but the participation constraints are met, that participant’s seat becomes vacant at the next regularly scheduled election for that group.

Vacated seats are filled according to this schedule:

3. General Policies for W3C Groups

This section describes general policies for W3C groups regarding participation, meeting requirements, and decision-making. These policies apply to participants in the following groups: Advisory Committee, Advisory Board, TAG, Working Groups, and Interest Groups.

3.1. Individual Participation Criteria

There are three qualities an individual is expected to demonstrate in order to participate in W3C:

  1. Technical competence in one’s role;
  2. The ability to act fairly;
  3. Social competence in one’s role.

Advisory Committee representatives who nominate individuals from their organization for participation in W3C activities are responsible for assessing and attesting to the qualities of those nominees.

Participants in any W3C activity must abide by the terms and spirit of the W3C Code of Ethics and Professional Conduct [CEPC] and the participation requirements described in “Disclosure” in the W3C Patent Policy [PATENT-POLICY].

The Director may suspend or remove for cause a participant in any group (including the AB and TAG), where cause includes failure to meet the requirements of this process, the membership agreement, or applicable laws.

3.1.1. Conflict of Interest Policy

Individuals participating materially in W3C work must disclose significant relationships when those relationships might reasonably be perceived as creating a conflict of interest with the individual’s role at W3C. These disclosures must be kept up-to-date as the individual’s affiliations change and W3C membership evolves (since, for example, the individual might have a relationship with an organization that joins or leaves W3C). Each section in this document that describes a W3C group provides more detail about the disclosure mechanisms for that group.

The ability of an individual to fulfill a role within a group without risking a conflict of interest depends on the individual’s affiliations. When these affiliations change, the individual’s assignment to the role must be evaluated. The role may be reassigned according to the appropriate process. For instance, the Director may appoint a new group Chair when the current Chair changes affiliations (e.g., if there is a risk of conflict of interest, or if there is risk that the Chair’s new employer will be over-represented within a W3C activity).

The following are some scenarios where disclosure is appropriate:

Individuals seeking assistance on these matters should contact the Team.

Team members are subject to the W3C Team conflict of interest policy [CONFLICT-POLICY].

3.1.2. Individuals Representing a Member Organization

Generally, individuals representing a Member in an official capacity within W3C are employees of the Member organization. However, an Advisory Committee representative may designate a non-employee to represent the Member. Non-employee Member representatives must disclose relevant affiliations to the Team and to any group in which the individual participates.

In exceptional circumstances (e.g., situations that might jeopardize the progress of a group or create a conflict of interest), the Director may decline to allow an individual designated by an Advisory Committee representative to participate in a group.

A group charter may limit the number of individuals representing a W3C Member (or group of related Members).

3.2. Meetings

W3C groups (including the Advisory Committee, Advisory Board, TAG, and Working Groups) should observe the meeting requirements in this section.

W3C distinguishes two types of meetings:

  1. A face-to-face meeting is one where most of the attendees are expected to participate in the same physical location.
  2. A distributed meeting is one where most of the attendees are expected to participate from remote locations (e.g., by telephone, video conferencing, or IRC).

A Chair may invite an individual with a particular expertise to attend a meeting on an exceptional basis. This person is a meeting guest, not a group participant. Meeting guests do not have voting rights. It is the responsibility of the Chair to ensure that all meeting guests respect the chartered level of confidentiality and other group requirements.

Meeting announcements should be sent to all appropriate group mailing lists, i.e. those most relevant to the anticipated meeting participants.

The following table lists requirements for organizing a meeting:

Face-to-face meetings Distributed meetings
Meeting announcement (before) eight weeks* one week*
Agenda available (before) two weeks 24 hours (or longer if a meeting is scheduled after a weekend or holiday)
Participation confirmed (before) three days 24 hours
Action items available (after) three days 24 hours
Minutes available (after) two weeks 48 hours

* To allow proper planning (e.g., travel arrangements), the Chair is responsible for giving sufficient advance notice about the date and location of a meeting. Shorter notice for a meeting is allowed provided that there are no objections from group participants.

3.3. Consensus

Consensus is a core value of W3C. To promote consensus, the W3C process requires Chairs to ensure that groups consider all legitimate views and objections, and endeavor to resolve them, whether these views and objections are expressed by the active participants of the group or by others (e.g., another W3C group, a group in another organization, or the general public). Decisions may be made during meetings (face-to-face or distributed) as well as through email.

Note: The Director, CEO, and COO have the role of assessing consensus within the Advisory Committee.

The following terms are used in this document to describe the level of support for a decision among a set of eligible individuals:

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:
The particular case of consensus where all individuals in the set support the decision (i.e., no individual in the set abstains).
Dissent:
At least one individual in the set registers a Formal Objection.

By default, the set of individuals eligible to participate in a decision is the set of group participants. The Process Document does not require a quorum for decisions (i.e., the minimal number of eligible participants required to be present before the Chair can call a question). A charter may include a quorum requirement for consensus decisions.

Where unanimity is not possible, a group should strive to make consensus decisions where there is significant support and few abstentions. The Process Document does not require a particular percentage of eligible participants to agree to a motion in order for a decision to be made. To avoid decisions where there is widespread apathy, (i.e., little support and many abstentions), groups should set minimum thresholds of active support before a decision can be recorded. The appropriate percentage may vary depending on the size of the group and the nature of the decision. A charter may include threshold requirements for consensus decisions. For instance, a charter might require a supermajority of eligible participants (i.e., some established percentage above 50%) to support certain types of consensus decisions.

Note: Chairs have substantial flexibility in how they obtain and assess consensus among their groups. Unless otherwise constrained by charter, they may use modes including but not limited to explicit calls for consensus, polls of participants, “lazy consensus” in which lack of objection after sufficient notice is taken as assent; or they may also delegate and empower a document editor to assess consensus on their behalf, whether in general or for specific pre-determined circumstances (e.g. in non-controversial situations, for specific types of issues, etc.).

If questions or disagreements arise, the final determination of consensus remains with the chair.

3.3.1. Managing Dissent

In some cases, even after careful consideration of all points of view, a group might find itself unable to reach consensus. The Chair may record a decision where there is dissent (i.e., there is at least one Formal Objection) so that the group can make progress (for example, to produce a deliverable in a timely manner). Dissenters cannot stop a group’s work simply by saying that they cannot live with a decision. When the Chair believes that the Group has duly considered the legitimate concerns of dissenters as far as is possible and reasonable, the group should move on.

Groups should favor proposals that create the weakest objections. This is preferred over proposals that are supported by a large majority but that cause strong objections from a few people. As part of making a decision where there is dissent, the Chair is expected to be aware of which participants work for the same (or related) Member organizations and weigh their input accordingly.

3.3.2. Recording and Reporting Formal Objections

In the W3C process, an individual may register a Formal Objection to a decision. A Formal Objection to a group decision is one that the reviewer requests that the Director consider as part of evaluating the related decision (e.g., in response to a request to advance a technical report).

Note: In this document, the term “Formal Objection” is used to emphasize this process implication: Formal Objections receive Director consideration. The word “objection” used alone has ordinary English connotations.

An individual who registers a Formal Objection should cite technical arguments and propose changes that would remove the Formal Objection; these proposals may be vague or incomplete. Formal Objections that do not provide substantive arguments or rationale are unlikely to receive serious consideration by the Director.

A record of each Formal Objection must be publicly available. A Call for Review (of a document) to the Advisory Committee must identify any Formal Objections.

3.3.3. Formally Addressing an Issue

In the context of this document, a group has formally addressed an issue when it has sent a public, substantive response to the reviewer who raised the issue. A substantive response is expected to include rationale for decisions (e.g., a technical explanation, a pointer to charter scope, or a pointer to a requirements document). The adequacy of a response is measured against what a W3C reviewer would generally consider to be technically sound. If a group believes that a reviewer’s comments result from a misunderstanding, the group should seek clarification before reaching a decision.

As a courtesy, both Chairs and reviewers should set expectations for the schedule of responses and acknowledgments. The group should reply to a reviewer’s initial comments in a timely manner. The group should set a time limit for acknowledgment by a reviewer of the group’s substantive response; a reviewer cannot block a group’s progress. It is common for a reviewer to require a week or more to acknowledge and comment on a substantive response. The group’s responsibility to respond to reviewers does not end once a reasonable amount of time has elapsed. However, reviewers should realize that their comments will carry less weight if not sent to the group in a timely manner.

Substantive responses should be recorded. The group should maintain an accurate summary of all substantive issues and responses to them (e.g., in the form of an issues list with links to mailing list archives).

3.3.4. Reopening a Decision When Presented With New Information

The Chair may reopen a decision when presented with new information, including:

The Chair should record that a decision has been reopened, and must do so upon request from a group participant.

3.4. Votes

A group should only conduct a vote to resolve a substantive issue after the Chair has determined that all available means of reaching consensus through technical discussion and compromise have failed, and that a vote is necessary to break a deadlock. In this case the Chair must record (e.g., in the minutes of the meeting or in an archived email message):

In order to vote to resolve a substantive issue, an individual must be a group participant. Each organization represented in the group must have at most one vote, even when the organization is represented by several participants in the group (including Invited Experts). For the purposes of voting:

Unless the charter states otherwise, Invited Experts may vote.

If a participant is unable to attend a vote, that individual may authorize anyone at the meeting to act as a proxy. The absent participant must inform the Chair in writing who is acting as proxy, with written instructions on the use of the proxy. For a Working Group or Interest Group, see the related requirements regarding an individual who attends a meeting as a substitute for a participant.

A group may vote for other purposes than to resolve a substantive issue. For instance, the Chair often conducts a “straw poll” vote as a means of determining whether there is consensus about a potential decision.

A group may also vote to make a process decision. For example, it is appropriate to decide by simple majority whether to hold a meeting in San Francisco or San Jose (there’s not much difference geographically). When simple majority votes are used to decide minor issues, voters are not required to state the reasons for votes, and the group is not required to record individual votes.

A group charter may include formal voting procedures (e.g., quorum or threshold requirements) for making decisions about substantive issues.

Procedures for Advisory Committee votes are described separately.

3.5. Appeal of Chair Decisions and Group Decisions

Groups resolve issues through dialog. Individuals who disagree strongly with a decision should register with the Chair any Formal Objections (e.g., to a decision made as the result of a vote).

As detailed in other parts of this document, the Chair of a Working Group or Interest Group has the prerogative to make certain decisions based on their own judgment. Such decisions are called Chair Decisions. In contrast, decisions taken by the Chair of a Working Group or Interest Group on the basis of having assessed the consensus of the group or following a vote (see § 3.4 Votes) are called Group Decisions.

When group participants believe that their concerns are not being duly considered by the group or the Chair, they may ask the Director (for representatives of a Member organization, via their Advisory Committee representative) to confirm or deny the decision. This is a Group Decision Appeal or a Chair Decision Appeal. The participants should also make their requests known to the Team Contact. The Team Contact must inform the Director when a group participant has raised concerns about due process.

Any requests to the Director to confirm a decision must include a summary of the issue (whether technical or procedural), decision, and rationale for the objection. All counter-arguments, rationales, and decisions must be recorded.

Procedures for Advisory Committee appeals are described separately.

3.6. Resignation from a Group

A W3C Member or Invited Expert may resign from a group. On written notification from an Advisory Committee representative or Invited Expert to the team, the Member and their representatives or the Invited Expert will be deemed to have resigned from the relevant group. The team must record the notification. See “Exclusion and Resignation from the Working Group” in the W3C Patent Policy [PATENT-POLICY] for information about obligations remaining after resignation from certain groups.

4. Dissemination Policies

The Team is responsible for managing communication within W3C and with the general public (e.g., news services, press releases, managing the Web site and access privileges, and managing calendars). Members should solicit review by the Team prior to issuing press releases about their work within W3C.

The Team makes every effort to ensure the persistence and availability of the following public information:

To keep the Members abreast of W3C meetings, Workshops, and review deadlines, the Team provides them with a regular (e.g., weekly) news service and maintains a calendar [CALENDAR] of official W3C events. Members are encouraged to send schedule and event information to the Team for inclusion on this calendar.

4.1. Confidentiality Levels

There are three principal levels of access to W3C information (on the W3C Web site, in W3C meetings, etc.): public, Member-only, and Team-only.

While much information made available by W3C is public, “Member-only” information is available to authorized parties only, including representatives of Member organizations, Invited Experts, the Advisory Board, the TAG, and the Team. For example, the charter of some Working Groups may specify a Member-only confidentiality level for group proceedings.

Team-only” information is available to the Team and other authorized parties.

Those authorized to access Member-only and Team-only information:

The Team must provide mechanisms to protect the confidentiality of Member-only information and ensure that authorized parties have proper access to this information. Documents should clearly indicate whether they require Member-only confidentiality. Individuals uncertain of the confidentiality level of a piece of information should contact the Team.

Advisory Committee representatives may authorize Member-only access to Member representatives and other individuals employed by the Member who are considered appropriate recipients. For instance, it is the responsibility of the Advisory Committee representative and other employees and official representatives of the organization to ensure that Member-only news announcements are distributed for internal use only within their organization. Information about Member mailing lists is available in the New Member Orientation [INTRO].

4.1.1. Changing Confidentiality Level

As a benefit of membership, W3C provides some Team-only and Member-only channels for certain types of communication. For example, Advisory Committee representatives can send reviews to a Team-only channel. However, for W3C processes with a significant public component, such as the technical report development process, it is also important for information that affects decision-making to be publicly available. The Team may need to communicate Team-only information to a Working Group or the public. Similarly, a Working Group whose proceedings are Member-only must make public information pertinent to the technical report development process.

This document clearly indicates which information must be available to Members or the public, even though that information was initially communicated on Team-only or Member-only channels. Only the Team and parties authorized by the Team may change the level of confidentiality of this information. When doing so:

  1. The Team must use a version of the information that was expressly provided by the author for the new confidentiality level. In Calls for Review and other similar messages, the Team should remind recipients to provide such alternatives.
  2. The Team must not attribute the version for the new confidentiality level to the author without the author’s consent.
  3. If the author has not conveyed to the Team a version that is suitable for another confidentiality level, the Team may make available a version that reasonably communicates what is required, while respecting the original level of confidentiality, and without attribution to the original author.

5. Working Groups and Interest Groups

This document defines two types of groups:

Working Groups.
Working Groups typically produce deliverables (e.g., Recommendation Track technical reports, software, test suites, and reviews of the deliverables of other groups). There are additional participation requirements described in the W3C Patent Policy [PATENT-POLICY].
Interest Groups.
The primary goal of an Interest Group is to bring together people who wish to evaluate potential Web technologies and policies. An Interest Group is a forum for the exchange of ideas.

Interest Groups do not publish Recommendation Track technical reports; see information about maturity levels for Interest Groups.

5.1. Requirements for All Working and Interest Groups

Each group must have a charter. Requirements for the charter depend on the group type. All group charters must be public (even if other proceedings of the group are Member-only).

Each group must have a Chair (or co-Chairs) to coordinate the group’s tasks. The Director appoints (and re-appoints) Chairs for all groups. The Chair is a Member representative, a Team representative, or an Invited Expert (invited by the Director). The requirements of this document that apply to those types of participants apply to Chairs as well. The role of the Chair [CHAIR] is described in the Art of Consensus [GUIDE].

Each group must have a Team Contact, who acts as the interface between the Chair, group participants, and the rest of the Team. The role of the Team Contact [TEAM-CONTACT] is described in the Art of Consensus [GUIDE]. The Chair and the Team Contact of a group should not be the same individual.

Each group must have an archived mailing list for formal group communication (e.g., for meeting announcements and minutes, documentation of decisions, and Formal Objections to decisions). It is the responsibility of the Chair and Team Contact to ensure that new participants are subscribed to all relevant mailing lists. Refer to the list of group mailing lists [GROUP-MAIL].

A Chair may form task forces (composed of group participants) to carry out assignments for the group. The scope of these assignments must not exceed the scope of the group’s charter. A group should document the process it uses to create task forces (e.g., each task force might have an informal "charter"). Task forces do not publish technical reports; the Working Group may choose to publish their results as part of a technical report.

5.2. Working Groups and Interest Groups

Although Working Groups and Interest Groups have different purposes, they share some characteristics, and so are defined together in the following sections.

5.2.1. Working Group and Interest Group Participation Requirements

There are three types of individual participants in a Working Group: Member representatives, Invited Experts, and Team representatives (including the Team Contact).

There are four types of individual participants in an Interest Group: the same three types as for Working Groups plus, for an Interest Group where the only participation requirement is mailing list subscription, public participants.

Except where noted in this document or in a group charter, all participants share the same rights and responsibilities in a group; see also the individual participation criteria.

A participant may represent more than one organization in a Working Group or Interest Group. Those organizations must all be members of the group.

An individual may become a Working or Interest Group participant at any time during the group’s existence. See also relevant requirements in “Joining an Already Established Working Group” in the W3C Patent Policy [PATENT-POLICY].

On an exceptional basis, a Working or Interest Group participant may designate a substitute to attend a meeting and should inform the Chair. The substitute may act on behalf of the participant, including for votes. For the substitute to vote, the participant must inform the Chair in writing in advance. As a courtesy to the group, if the substitute is not well-versed in the group’s discussions, the regular participant should authorize another participant to act as proxy for votes.

To allow rapid progress, Working Groups are intended to be small (typically fewer than 15 people) and composed of experts in the area defined by the charter. In principle, Interest Groups have no limit on the number of participants. When a Working Group grows too large to be effective, W3C may split it into an Interest Group (a discussion forum) and a much smaller Working Group (a core group of highly dedicated participants).

See also the licensing obligations on Working Group participants in “Licensing Obligations” in the W3C Patent Policy [PATENT-POLICY], and the patent claim exclusion process in “Exclusion From W3C RF Licensing Requirements” in the Patent Policy.

5.2.1.1. Member Representative in a Working Group

An individual is a Member representative in a Working Group if all of the following conditions are satisfied:

To designate an individual as a Member representative in a Working Group, an Advisory Committee representative must provide the Chair and Team Contact with all of the following information, in addition to any other information required by the Call for Participation and charter (including the participation requirements of the W3C Patent Policy [PATENT-POLICY]):

  1. The name of the W3C Member the individual represents and whether the individual is an employee of that Member organization;
  2. A statement that the individual accepts the participation terms set forth in the charter (with an indication of charter date or version);
  3. A statement that the Member will provide the necessary financial support for participation (e.g., for travel, telephone calls, and conferences).

A Member participates in a Working Group from the moment the first Member representative joins the group until either of the following occurs:

5.2.1.2. Member Representative in an Interest Group

When the participation requirements exceed Interest Group mailing list subscription, an individual is a Member representative in an Interest Group if all of the following conditions are satisfied:

To designate an individual as a Member representative in an Interest Group, the Advisory Committee representative must follow the instructions in the Call for Participation and charter.

Member participation in an Interest Group ceases under the same conditions as for a Working Group.

5.2.1.3. Invited Expert in a Working Group

The Chair may invite an individual with a particular expertise to participate in a Working Group. This individual may represent an organization in the group (e.g., if acting as a liaison with another organization).

An individual is an Invited Expert in a Working Group if all of the following conditions are satisfied:

To designate an individual as an Invited Expert in a Working Group, the Chair must inform the Team Contact and provide rationale for the choice. When the Chair and the Team Contact disagree about a designation, the Director determines whether the individual will be invited to participate in the Working Group.

To participate in a Working Group as an Invited Expert, an individual must:

The Chair should not designate as an Invited Expert in a Working Group an individual who is an employee of a W3C Member. The Chair must not use Invited Expert status to circumvent participation limits imposed by the charter.

An Invited Expert participates in a Working Group from the moment the individual joins the group until any of the following occurs:

5.2.1.4. Invited Expert in an Interest Group

When the participation requirements exceed Interest Group mailing list subscription, the participation requirements for an Invited Expert in an Interest Group are the same as those for an Invited Expert in a Working Group.

5.2.1.5. Team Representative in a Working Group

An individual is a Team representative in a Working Group when so designated by W3C management.

A Team representative participates in a Working Group from the moment the individual joins the group until any of the following occurs:

The Team participates in a Working Group from the moment the Director announces the creation of the group until the group closes.

5.2.1.6. Team Representative in an Interest Group

When the participation requirements exceed Interest Group mailing list subscription, an individual is a Team representative in an Interest Group when so designated by W3C management.

5.2.2. Working Group and Interest Group Charter Development

W3C creates a charter based on interest from the Members and Team. The Team must notify the Advisory Committee when a charter for a new Working Group or Interest Group is in development. This is intended to raise awareness, even if no formal proposal is yet available. Advisory Committee representatives may provide feedback on the Advisory Committee discussion list.

W3C may begin work on a Working Group or Interest Group charter at any time.

5.2.3. Advisory Committee Review of a Working Group or Interest Group Charter

The Director must solicit Advisory Committee review of every new or substantively modified Working Group or Interest Group charter, except for either:

The review period must be at least 28 days. The following are examples of substantive changes that would not require an Advisory Committee Review: the addition of an in-scope deliverable, a change of Team Contact, or a change of Chair. Such changes must nonetheless be announced to the Advisory Committee and to participants in the Working or in the Interest Group, and a rationale must be provided.

The Director’s Call for Review of a substantively modified charter must highlight important changes (e.g., regarding deliverables or resource allocation) and include rationale for the changes.

As part of the Advisory Committee review of any new or substantively modified Working Group charter, any Advisory Committee representative may request an extended review period.

Such a request must be submitted with a Member’s comments in response to the Call for Review. Upon receipt of any such request, the Director must ensure that the Call for Participation for the Working Group occurs at least 60 days after the Call for Review of the charter.

5.2.4. Call for Participation in a Working Group or Interest Group

After Advisory Committee review of a Working Group or Interest Group charter, the Director may issue a Call for Participation to the Advisory Committee. Charters may be amended based on review comments before the Director issues a Call for Participation.

For a new group, this announcement officially creates the group. The announcement must include a reference to the charter, the name(s) of the group’s Chair(s), and the name(s) of the Team Contact(s).

After a Call for Participation, any Member representatives and Invited Experts must be designated (or re-designated).

Advisory Committee representatives may initiate an Advisory Committee Appeal against a Director’s decision to create or substantially modify a Working Group or Interest Group charter.

5.2.5. Working Group and Interest Group Charter Extension

To extend a Working Group or Interest Group charter with no other substantive modifications, the Director announces the extension to the Advisory Committee. The announcement must indicate the new duration. The announcement must also include rationale for the extension, a reference to the charter, the name(s) of the group’s Chair(s), the name of the Team Contact, and instructions for joining the group.

After a charter extension, Advisory Committee representatives and the Chair are not required to re-designate Member representatives and Invited Experts.

Advisory Committee representatives may initiate an Advisory Committee Appeal against a Director’s decision regarding the extension of a Working Group or Interest Group charter.

5.2.6. Working Group and Interest Group Charters

A Working Group or Interest Group charter must include all of the following information.

See also the charter requirements in “Licensing Goals for W3C Specifications” in the W3C Patent Policy [PATENT-POLICY].

For every Recommendation Track deliverable that continues work on technical report published under any other Charter (including a predecessor group of the same name), for which there is at least an existing First Public Working Draft the description of that deliverable in the proposed charter of the adopting Working Group must provide the following information:

All of the above data must be identified in the adopting Working Group’s charter using the labels indicated.

The Adopted Draft and the Exclusion Draft must each be adopted in their entirety and without any modification. The proposed charter must state the dates on which the Exclusion Opportunity that arose on publishing the Exclusion Draft began and ended. As per “Joining an Already Established Working Group” in the W3C Patent Policy [PATENT-POLICY], this potentially means that exclusions can only be made immediately on joining a Working Group.

An Interest Group charter may include provisions regarding participation, including specifying that the only requirement for participation (by anyone) in the Interest Group is subscription to the Interest Group mailing list. This type of Interest Group may have public participants.

A charter may include provisions other than those required by this document. The charter should highlight whether additional provisions impose constraints beyond those of the W3C Process Document (e.g., limits on the number of individuals in a Working Group who represent the same Member organization or group of related Members).

5.2.7. Working Group and Interest Group Closure

A Working Group or Interest Group charter specifies a duration for the group. The Director may decide to close a group prior to the date specified in the charter in any of the following circumstances:

The Director closes a Working Group or Interest Group by announcement to the Advisory Committee. Advisory Committee representatives may initiate an Advisory Committee Appeal.

Closing a Working Group has implications with respect to the W3C Patent Policy [PATENT-POLICY].

6. W3C Technical Report Development Process

The W3C technical report development process is the set of steps and requirements followed by W3C Working Groups to standardize Web technology. The W3C technical report development process is designed to:

See also “licensing goals for W3C Specifications” in the W3C Patent Policy [PATENT-POLICY].

6.1. W3C Technical Reports

Publishing as used in this document refers to producing a version which is listed as a W3C Technical Report on its Technical Reports page https://www.w3.org/TR [TR].

This chapter describes the formal requirements for publishing and maintaining a W3C Recommendation or Note.

Recommendations
Working Groups develop technical reports on the W3C Recommendation Track in order to produce normative specifications or guidelines as standards for the Web. The Recommendation Track process incorporates requirements for wide review, adequate implementation experience, and consensus-building, and is subject to the W3C Patent Policy [PATENT-POLICY] which grants Royalty-Free IPR licenses to implementations. See § 6.2 The W3C Recommendation Track for details.
Notes
Groups can also publish documents as W3C Notes, typically either to document information other than technical specifications, such as use cases motivating a specification and best practices for its use, or to clarify the status of work that is abandoned. See § 6.3 Working Group and Interest Group Notes for details.

Individual Working Groups and Interest Groups should adopt additional processes for developing publications, so long as they do not conflict with the requirements in this chapter.

6.1.1. General requirements for Technical Reports

Every document published as part of the technical report development process must be a public document. The index of W3C technical reports [TR] is available at the W3C Web site. W3C strives to make archival documents indefinitely available at their original address in their original form.

Every document published as part of the technical report development process must clearly indicate its maturity level, and must include information about the status of the document. This status information:

Every Technical Report published as part of the Technical Report development process is edited by one or more editors appointed by a Group Chair. It is the responsibility of these editors to ensure that the decisions of the Group are correctly reflected in subsequent drafts of the technical report. An editor must be a participant, per § 5.2.1 Working Group and Interest Group Participation Requirements in the Group responsible for the document(s) they are editing.

The Team is not required to publish a Technical Report that does not conform to the Team’s Publication Rules [PUBRULES] (e.g., for naming, status information, style, and copyright requirements). These rules are subject to change by the Team from time to time. The Team must inform group Chairs and the Advisory Committee of any changes to these rules.

The primary language for W3C Technical Reports is English. W3C encourages the translation of its Technical Reports. Information about translations of W3C technical reports [TRANSLATION] is available at the W3C Web site.

6.1.2. Reviews and Review Responsibilities

A document is available for review from the moment it is first published. Working Groups should formally address any substantive review comment about a technical report in a timely manner.

Reviewers should send substantive technical reviews as early as possible. Working Groups are often reluctant to make substantive changes to a mature document, particularly if this would cause significant compatibility problems due to existing implementation. Working Groups should record substantive or interesting proposals raised by reviews but not incorporated into a current specification.

6.1.2.1. Wide Review

The requirements for wide review are not precisely defined by the W3C Process. The objective is to ensure that the entire set of stakeholders of the Web community, including the general public, have had adequate notice of the progress of the Working Group (for example through notices posted to public-review-announce@w3.org) and were able to actually perform reviews of and provide comments on the specification. A second objective is to encourage groups to request reviews early enough that comments and suggested changes can still be reasonably incorporated in response to the review. Before approving transitions, the Director will consider who has been explicitly offered a reasonable opportunity to review the document, who has provided comments, the record of requests to and responses from reviewers, especially W3C Horizontal Groups [CHARTER] and groups identified as dependencies in the charter or identified as liaisons [LIAISON], and seek evidence of clear communication to the general public about appropriate times and which content to review and whether such reviews actually occurred.

For example, inviting review of new or significantly revised sections published in Working Drafts, and tracking those comments and the Working Group's responses, is generally a good practice which would often be considered positive evidence of wide review. Working Groups should announce to other W3C Working Groups as well as the general public, especially those affected by this specification, a proposal to enter Candidate Recommendation (for example in approximately 28 days). By contrast a generic statement in a document requesting review at any time is likely not to be considered as sufficient evidence that the group has solicited wide review.

A Working Group could present evidence that wide review has been received, irrespective of solicitation. But it is important to note that receiving many detailed reviews is not necessarily the same as wide review, since they might only represent comment from a small segment of the relevant stakeholder community.

6.1.3. Classes of Changes

This document distinguishes the following 4 classes of changes to a specification. The first two classes of change are considered editorial changes, the latter two substantive changes.

  1. No changes to text content

These changes include fixing broken links, style sheets or invalid markup.
  1. Corrections that do not affect conformance

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 and do not fall into this class.
Examples of changes in this class include correcting non-normative code examples where the code clearly conflicts with normative requirements, clarifying informative use cases or other non-normative text, fixing typos or grammatical errors where the change does not change implementation requirements. If there is any doubt or disagreement as to whether requirements are changed, such changes do not fall into this class.
  1. Corrections that do not add new features

These 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. New features

Changes that add a new functionality, element, etc.

6.1.4. Errata Management

Tracking errors is an important part of a Working Group's ongoing care of a technical report; for this reason, the scope of a Working Group charter generally allows time for work after publication of a Recommendation. In this Process Document, the term “erratum” (plural “errata”) refers to any error that can be resolved by one or more changes in classes 1-3 of section § 6.1.3 Classes of Changes.

Working Groups must keep a public record of errors that are reported by readers and implementers for Recommendations. Such error reports should be compiled no less frequently than quarterly.

Working Groups decide how to document errata. Such documentation must identify the affected technical report text and describe the error; it may also describe some possible solution(s). Readers of the technical report should be able easily to find and see the errata that apply to that specific technical report with their associated tests. Errata may be documented in a separate errata page or tracking system. They may, in addition or alternatively, be annotated inline alongside the affected technical report text or at the start or end of the most relevant section(s).

6.1.5. Candidate Changes

An erratum may be accompanied by an informative, candidate correction approved by the consensus of the Working Group. When annotated inline, errata—including their candidate correctionsmust be marked as such, are treated as class 2 changes, and are published accordingly.

Note: Annotating changes in this way allows more mature documents such as Recommendations and Candidate Recommendations to be updated quickly with the Working Group’s most current thinking, even when the candidate changes have not yet received sufficient review or implementation experience to be normatively incorporated into the specification proper.

A candidate addition is similar to a candidate correction, except that it proposes a new feature rather than an error correction.

Candidate corrections and candidate additions are collectively known as candidate changes.

In addition to their actual maturity level, published REC Track documents with candidate changes are also considered, for the purpose of the W3C Patent Policy [PATENT-POLICY], to be Working Drafts with those candidate changes treated as normative.

6.1.6. License Grants from Non-Participants

When a party who is not already obligated under the Patent Policy offers a change in class 3 or 4 (as described in § 6.1.3 Classes of Changes) to a technical report under this process the Team must request a recorded royalty-free patent commitment; for a change in class 4, the Team must secure such commitment. Such commitment should cover, at a minimum, all the party’s Essential Claims both in the contribution, and that become Essential Claims as a result of incorporating the contribution into the draft that existed at the time of the contribution, on the terms specified in the “W3C Royalty-Free (RF) Licensing Requirements” section of the W3C Patent Policy [PATENT-POLICY].

6.2. The W3C Recommendation Track

When advancing a technical report to Recommendation, typically a series of Working Drafts are published, each of which refines a document under development to complete the scope of work envisioned by a Working Group's charter. For a technical specification, once review suggests the Working Group has met their requirements satisfactorily for a new standard, there is a Candidate Recommendation phase. This allows the entire W3C membership to provide feedback on the specification, while the Working Group formally collects implementation experience to demonstrate that the specification works in practice. The next phase is a Proposed Recommendation, to finalize the review of W3C Members. If the Director determines that W3C Member review supports a specification becoming a standard, W3C publishes it as a Recommendation.

In summary, the W3C Recommendation Track consists of:

  1. Publication of the First Public Working Draft.
  2. Publication of zero or more revised Working Drafts.
  3. Publication of one or more Candidate Recommendations.
  4. Publication of a Proposed Recommendation.
  5. Publication as a W3C Recommendation.
  6. Possibly, publication as an Amended Recommendation.
Basic W3C Recommendation Track First Public Working Draft (FPWD) - Exclusion opportunity WG decision Director's approval Working Draft (WD) Publish a new Working Draft WG Decision: review needed, or No change for 6 months Advance to Candidate Recommendation Director's approval Candidate Recommendation (CR) - Patent Policy exclusion opportunity Candidate Recommendation Draft (CRD) Publish revised Candidate Recommendation Draft WG Decision Publish revised Candidate Recommendation Draft WG Decision Publish revised Candidate Recommendation WG Decision + Director’s approval Publish revised Candidate Recommendation WG Decision Director’s approval Advance to Proposed Recommendation Director's approval Return to Working Draft WG or Director decision e.g. for further review Proposed Recommendation (PR) - Advisory Committee review Advance to Recommendation Advisory Committee Review Director's Decision Return to Candidate Recommendation AC Review, Director Decision e.g. for editorial changes Return to Working Draft Advisory Committee review and Director's Decision, e.g. for further work and review Recommendation (Rec)

This Process defines certain Recommendation Track publications as Patent Review Drafts. Under the 2004 (updated in 2017) Patent Policy, these correspond to “Last Call Working Draft” in the Patent Policy [PATENT-POLICY-2017]; Under the 2020 Patent Policy, these correspond to “Patent Review Draft” in the Patent Policy [PATENT-POLICY].

W3C may end work on a technical report at any time.

The Director may decline a request to advance in maturity level, requiring a Working Group to conduct further work, and may require the specification to return to a lower maturity level. The Director must inform the Advisory Committee and Working Group Chairs when a Working Group's request for a specification to advance in maturity level is declined and the specification is returned to a Working Group for further work.

6.2.1. Maturity Levels on the Recommendation Track

Working Draft (WD)
A Working Draft is a document that W3C has published on the W3C’s Technical Reports page [TR] for review by the community (including W3C Members), the public, and other technical organizations, and for simple historical reference. Some, but not all, Working Drafts are meant to advance to Recommendation; see the document status section of a Working Draft for the group’s expectations. Working Drafts do not necessarily represent a consensus of the Working Group with respect to their content, and do not imply any endorsement by W3C or its members beyond agreement to work on a general area of technology. Nevertheless the Working Group decided to adopt the Working Draft as the basis for their work at the time of adoption. A Working Draft is suitable for gathering wide review prior to advancing to the next stage of maturity.

For all Working Drafts a Working Group:

  • should document outstanding issues, and parts of the document on which the Working Group does not have consensus, and
  • may request publication of a Working Draft even if its content is considered unstable and does not meet all Working Group requirements.

The first Working Draft of a technical report is called the First Public Working Draft (FPWD), and has patent implications as defined in the W3C Patent Policy [PATENT-POLICY].

Candidate Recommendation (CR)
A Candidate Recommendation is a document that satisfies the technical requirements of the Working Group that produced it and their dependencies, or makes substantive corrections to a Recommendation that is not maintained by a Working Group, and has already received wide review. W3C publishes a Candidate Recommendation to

Note: Advancing to Candidate Recommendation indicates that the document is considered complete and fit for purpose, and that no further refinement to the text is expected without additional implementation experience and testing; additional features in a later revision may however be expected. A Candidate Recommendation is expected to be as well-written, detailed, self-consistent, and technically complete as a Recommendation, and acceptable as such if and when the requirements for further advancement are met.

Candidate Recommendation publications take one of two forms:

Candidate Recommendation Snapshot
A Review Snapshot corresponds to a Patent Review Draft as used in the W3C Patent Policy [PATENT-POLICY]. Publishing a Patent Review Draft triggers a Call for Exclusions, per “Exclusion From W3C RF Licensing Requirements” in the W3C Patent Policy.

Publication as a Candidate Recommendation Snapshot requires approval of either a Transition Request (for the first Candidate Recommendation publication from another maturity level) or an Update Request (for subsequent Candidate Recommendation Snapshots).

Candidate Recommendation Draft
A Candidate Recommendation Draft is published on the W3C’s Technical Reports page [TR] to integrate changes from the previous Candidate Recommendation Snapshot that the Working Group intends to include in a subsequent Candidate Recommendation Snapshot. This allows for wider review of the changes and for ease of reference to the integrated specification.

Any changes published directly into a Candidate Recommendation Draft should be at the same level of quality as a Candidate Recommendation Review Snapshot. However, the process requirements are minimized so that the Working Group can easily keep the specification up to date.

A Candidate Recommendation Draft does not provide an exclusion opportunity instead, it is considered a Working Draft for the purpose of the W3C Patent Policy [PATENT-POLICY].

A Rescinded Candidate Recommendation is a Candidate Recommendation in which significant problems have been discovered such that W3C cannot endorse it or continue work on it, for example due to burdensome patent claims that affect implementers and cannot be resolved (see the W3C Patent Policy [PATENT-POLICY] and in particular “PAG Conclusion”). There is no path to restoration for a Rescinded Candidate Recommendation. See “W3C Royalty-Free (RF) Licensing Requirements” in the W3C Patent Policy [PATENT-POLICY] for implication on patent licensing obligations.

Proposed Recommendation (PR)
A Proposed Recommendation is a document that has been accepted by the W3C as of sufficient quality to become a W3C Recommendation. This phase triggers formal review by the Advisory Committee, who may recommend that the document be published as a W3C Recommendation, returned to the Working Group for further work, or abandoned. Substantive changes must not be made to a Proposed Recommendation except by publishing a new Working Draft or Candidate Recommendation.
W3C Recommendation (REC)
A W3C Recommendation is a specification or set of guidelines or requirements that, after extensive consensus-building, has received the endorsement of the W3C and its Members. W3C recommends the wide deployment of its Recommendations as standards for the Web. The W3C Royalty-Free IPR licenses granted under the W3C Patent Policy [PATENT-POLICY] apply to W3C Recommendations. As technology evolves, a W3C Recommendation may become:
An Amended Recommendation
An Amended Recommendation is a Recommendation that is amended to include substantive changes that do not add new features, and is produced by the W3C at a time when the Recommendation does not fit within the charter of any active Working Group. Since the W3C team rather than a Working Group moves it through the Process, there are implications regarding the scope of Royalty-Free IPR licenses granted under the W3C Patent Policy [PATENT-POLICY].
A Superseded Recommendation
A Superseded Recommendation is a specification that has been replaced by a newer version that the W3C recommends for new adoption. An Obsolete or Superseded specification has the same status as a W3C Recommendation with regards to W3C Royalty-Free IPR Licenses granted under the Patent Policy.

Note: When a Technical Report which had previously been published as a Recommendation is again published as a Recommendation after following the necessary steps to revise it, the latest version replaces the old one, without the need to invoke the steps of § 6.2.12.3 Abandoning a W3C Recommendation: it is the same document, updated. Explicitly declaring a documented superseded, using the process documented in § 6.2.12.3 Abandoning a W3C Recommendation, is intended for cases where a Recommendation is superseded by a separate Technical Report (or a by a document managed outside of W3C).

An Obsolete Recommendation
An Obsolete Recommendation is a specification that the W3C has determined lacks sufficient market relevance to continue recommending it for implementation, but which does not have fundamental problems that would require it to be Rescinded. If an Obsolete specification gains sufficient market relevance, the W3C may decide to restore it to Recommendation status.
Rescinded Recommendation
A Rescinded Recommendation is an entire Recommendation that W3C no longer endorses, and believes is unlikely to ever be restored to Recommendation status. See also “W3C Royalty-Free (RF) Licensing Requirements” in the W3C Patent Policy [PATENT-POLICY].

Only sufficiently technically mature work should be advanced.

Note: Should faster advancement to meet scheduling considerations be desired, this can be achieved by reducing the scope of the technical report to a subset that is adequately mature and deferring less stable features to other technical reports.

When publishing an updated version of an existing Candidate Recommendation or Recommendation, technical reports are expected to meet the same maturity criteria as when they are first published under that status. However, in the interest of replacing stale documents with improved ones in a timely manner, if flaws have been discovered in the technical report after its initial publication as a CR or REC that would have been severe enough to reject that publication had they be known in time, it is also permissible to publish an updated CR or REC following the usual process, even if only some of these flaws have been satisfactorily addressed.

Working Groups and Interest Groups may make available Editor’s drafts. Editor’s drafts (ED) have no official standing whatsoever, and do not necessarily imply consensus of a Working Group or Interest Group, nor are their contents endorsed in any way by W3C.

6.2.2. Implementation Experience

Implementation experience is required to show that a specification is sufficiently clear, complete, and relevant to market needs, to ensure that independent interoperable implementations of each feature of the specification will be realized. While no exhaustive list of requirements is provided here, when assessing that there is adequate implementation experience the Director will consider (though not be limited to):

Planning and accomplishing a demonstration of (interoperable) implementations can be very time consuming. Groups are often able to work more effectively if they plan how they will demonstrate interoperable implementations early in the development process; for example, developing tests in concert with implementation efforts.

6.2.3. Advancement on the Recommendation Track

For all requests to advance a specification to a new maturity level other than Note (called Transition Requests), the Working Group:

For a First Public Working Draft there is no “previous maturity level”, so many requirements do not apply, and approval is normally fairly automatic. For later stages, especially transition to Candidate or Proposed Recommendation, there is usually a formal review meeting to ensure the requirements have been met before Director's approval is given.

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 Director's decision on an Advisory Committee Review.

6.2.4. Updating Mature Publications on the Recommendation Track

Certain requests to re-publish a specification within its current maturity level (called Update Requests) require Director approval. For such update requests, the Working Group:

There is usually a formal review meeting to ensure the requirements have been met before Director's approval is given.

Note: Update request approval is expected to be fairly simple compared to getting approval for a transition request.

The Director must announce the publication of the revised specification to other W3C groups and the Public.

6.2.4.1. Streamlined Publication Approval

Note: These criteria are intentionally stricter than the general requirements for an update request. This is in order to minimize ambiguities and the need for expert judgment, and to make self-evaluation practical.

In order to streamline the publication process in non-controversial cases, approval to an update request is automatically granted without formal review when the following additional criteria are fulfilled:

Additionally, for updates to Recommendations with substantive changes or with new features:

The Working Group must provide written evidence for these claims, and the Team must make these answers publicly and permanently available.

After publication, if an AC Representative or Team member doubts that the evidence presented supports the claims, they may request that a formal review meeting be convened post facto. If that review finds that the requirements were not fulfilled, the Team may revert the changes by updating in place the status section to indicate that it has been reverted, and by republishing the previously approved version of the technical report.

6.2.5. Publishing a First Public Working Draft

To publish the First Public Working Draft of a document, a Working Group must meet the applicable requirements for advancement.

The Director must announce the publication of a First Public Working Draft to other W3C groups and to the public.

6.2.6. Revising a Working Draft

A Working Group should publish a Working Draft to the W3C Technical Reports page when there have been significant changes to the previous published document that would benefit from review beyond the Working Group.

If 6 months elapse without significant changes to a specification, a Working Group should publish a revised Working Draft, whose status section should indicate reasons for the lack of change.

To publish a revision of a Working draft, a Working Group:

Possible next steps for any Working Draft:

6.2.7. Transitioning to Candidate Recommendation

To publish a Candidate Recommendation, in addition to meeting the requirements for advancement a Working Group, or in the case of a candidate Amended Recommendation (a document intended to become an Amended Recommendation), the W3C:

The first Candidate Recommendation publication after approval of a Transition Request is always a Candidate Recommendation Snapshot. The Director must announce the publication of the Candidate Recommendation Snapshot to other W3C groups and to the public.

Possible next steps after a Candidate Recommendation Snapshot:

Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to advance the technical report.

6.2.8. Revising a Candidate Recommendation

6.2.8.1. Publishing a Candidate Recommendation Snapshot

If there are any substantive changes made to a Candidate Recommendation since the previous Candidate Recommendation Snapshot other than to remove features explicitly identified as at risk, the Working Group must meet the requirements of an update request in order to republish.

In addition the Working Group:

The Director must announce the publication of a revised Candidate Recommendation Snapshot to other W3C groups and to the public.

To provide timely updates and patent protection, a Candidate Recommendation Snapshot should be published within 24 months of the Working Group accepting any proposal for a substantive change (and preferably sooner). To make scheduling reviews easier, a Candidate Recommendation Snapshot should not be published more often than approximately once every 6 months.

Note: Substantive changes trigger a new Exclusion Opportunity per “Exclusion From W3C RF Licensing Requirements” in the W3C Patent Policy [PATENT-POLICY].

6.2.8.2. Publishing a Candidate Recommendation Draft

A Working Group should publish an Update Draft to the W3C Technical Reports page when there have been significant changes to the previous published document that would benefit from review beyond the Working Group.

To publish a revision of a Candidate Recommendation Draft, a Working Group:

Note: A Working Group does not need to meet the requirements of a Candidate Recommendation Snapshot update request in order to publish a Candidate Recommendation Draft.

Possible next steps after a Candidate Recommendation Draft:

6.2.9. Transitioning to Proposed Recommendation

In addition to meeting the requirements for advancement,

A Working Group, or for a proposed Amended Recommendation, the W3C:

The Director:

Since a W3C Recommendation must not include any substantive changes from the Proposed Recommendation it is based on, to make any substantive change to a Proposed Recommendation the Working Group must return the specification to Candidate Recommendation or Working Draft.

A Proposed Recommendation may identify itself as intending to allow new features (class 4 changes) after its initial publication as a Recommendation, as described in § 6.2.11.4 Revising a Recommendation: New Features. Such an allowance cannot be added to a technical report previously published as a Recommendation that did not allow such changes.

Possible Next Steps:

Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to advance the technical report.

6.2.10. Transitioning to W3C Recommendation

The decision to advance a document to Recommendation is a W3C Decision.

In addition to meeting the requirements for advancement,

Possible next steps: A W3C Recommendation normally retains its status indefinitely. However it may be:

6.2.11. Revising a W3C Recommendation

This section details the process for making changes to a Recommendation.

6.2.11.1. Revising a Recommendation: Markup Changes

A Working group may request republication of a Recommendation, or if there is no Working Group chartered to maintain a Recommendation W3C may republish the Recommendation, to make corrections that do not result in any changes to the text of the specification. (See class 1 changes.)

6.2.11.2. Revising a Recommendation: Editorial Changes

Editorial changes to a Recommendation require no technical review of the intended changes. A Working Group, provided there are no votes against the resolution to publish, may request publication of a Recommendation or W3C may publish a Recommendation to make this class of change without passing through earlier maturity levels. (See class 2 changes.)

6.2.11.3. Revising a Recommendation: Substantive Changes

A candidate correction can be made normative and be folded into the main text of the Recommendation, once it has satisfied all the same criteria as the rest of the Recommendation, including review by the community to ensure the technical and editorial soundness of the candidate change. To validate this, the Working Group must request a Last Call for Review of Proposed Changes, followed by an update request. See § 6.2.11.5 Incorporating Candidate Changes.

Alternatively, a Working Group may incorporate the changes and publish as a Candidate Recommendation, or if no Working Group is chartered to maintain a Recommendation W3C may publish a candidate Amended Recommendation, and advance the specification from that state. If the publication was requested by the W3C team in the absence of a Working Group, the resulting Recommendation will be called an Amended Recommendation. (See class 3 changes.)

6.2.11.4. Revising a Recommendation: New Features

New features (see class 4 changes) may be incorporated into a Recommendation explicitly identified as allowing new features using candidate additions. A candidate addition can be made normative and be folded into the main text of the Recommendation, once it has satisfied all the same criteria as the rest of the Recommendation, including review by the community to ensure the technical and editorial soundness of the candidate change. To validate this, the Working Group must request a Last Call for Review of Proposed Changes, followed by an update request. See § 6.2.11.5 Incorporating Candidate Changes.

Note: This prohibition against new features unless explicitly allowed enables third parties to depend on Recommendations having a stable feature-set, as they have prior to the 2020 revision of this Process.

To make changes which introduce a new feature to a Recommendation that was not approved for accepting new features, W3C must create a new technical report, following the full process of advancing a technical report to Recommendation beginning with a new First Public Working Draft.

6.2.11.5. Incorporating Candidate Changes

A Last Call for Review of Proposed Changes verifies acceptance by the W3C community of candidate changes by combining an AC Review with a patent exclusion opportunity.

The Last Call for Review of Proposed Changes must be announced to other W3C groups, the public, and the Advisory Committee. The announcement must:

The combination of the existing Recommendation with the proposed changes included in the Last Call for Review of Proposed Changes is considered a Patent Review Draft for the purposes of the Patent Policy [PATENT-POLICY]. Also, the review initiated by the Last Call for Review of Proposed Additions is an Advisory Committee Review.

Note: Last Call for Review of Proposed Additions and Last Call for Review of Proposed Corrections and Additions can only be issued for Recommendations that allow new features.

A Working Group may batch multiple proposed changes into a single Last Call for Review of Proposed Changes. To facilitate review, a Last Call for Review of Proposed Changes on a given specification should not be issued more frequently than approximately once every 6 months.

At the end of the Last Call for Review of Proposed Changes, the W3C Decision may either be to reject the proposed change, or to clear the proposed change for advancement as is, or to return the proposal to the Working Group with a request to formally address comments made on the changes under review. If the Working Group needs to amend a proposed change in response to review feedback it must issue another Last Call for Review of Proposed Change on the revised change before it can be incorporated into the main text.

Once all comments on a proposed change have been formally addressed, and after the Working Group can show adequate implementation experience and the fulfillment of all other requirements of Recommendation text, it may incorporate the proposed change into the normative Recommendation by issuing an update request for publication of the updated Recommendation.

To ensure adequate review of proposed change combinations, only proposed changes included in the most recent Last Call for Review of Proposed Changes can be incorporated into the normative Recommendation text. (Thus if incorporation of a proposed change is postponed, it may need to be included in multiple Last Calls for Review of Proposed Changes.)

6.2.12. Retiring Recommendation Track Documents

Work on a technical report may cease at any time. Work should cease if W3C or a Working Group determines that it cannot productively carry the work any further.

6.2.12.1. Abandoning an Unfinished Technical Report

Any technical report no longer intended to advance or to be maintained, and that is not being rescinded, should be published as a Working Group Note. This can happen if the Working Group decided to abandon work on the report, or the Director required the Working Group to discontinue work on the technical report before completion. If the Director closes a Working Group W3C must publish any unfinished technical report on the Recommendation track as Working Group Notes.

6.2.12.2. Rescinding a Candidate Recommendation

The process for rescinding a Candidate Recommendation is the same as for rescinding a Recommendation.

6.2.12.3. Abandoning a W3C Recommendation

It is possible that W3C decides that implementing a particular Recommendation is no longer recommended. There are three designations for such specifications, chosen depending on the advice W3C wishes to give about further use of the specification.

W3C may obsolete a Recommendation, for example if the W3C Community decides that the Recommendation no longer represents best practices, or is not adopted and is not apparently likely to be adopted. An Obsolete Recommendation may be restored to normal Recommendation, for example because despite marking it Obsolete the specification is later more broadly adopted.

W3C may declare a Recommendation Superseded if a newer version exists which the W3C recommends for new adoption. The process for declaring a Recommendation Superseded is the same as for declaring it Obsolete, below; only the name and explanation change.

W3C may rescind a Recommendation if W3C believes there is no reasonable prospect of it being restored for example due to burdensome patent claims that affect implementers and cannot be resolved; see the W3C Patent Policy [PATENT-POLICY] and in particular “W3C Royalty-Free (RF) Licensing Requirements” and “PAG Conclusion”.

W3C only rescinds, supersedes, or obsoletes entire Recommendations. A Recommendation can be both superseded and obsolete. To rescind, supersede, or obsolete some part of a Recommendation, W3C follows the process for modifying a Recommendation.

Note: For the purposes of the W3C Patent Policy [PATENT-POLICY] an Obsolete or Superseded Recommendation has the status of an active Recommendation, although it is not recommended for future implementation; a Rescinded Recommendation ceases to be in effect and no new licenses are granted under the Patent Policy.

Supersede, Obsolete or Rescind a W3C Recommendation Recommendation (Rec) A major problem and an AC review can lead to a Recommendation being Rescinded. There are no new IPR licences issued under the W3C Patent Policy, and reinstating the Recommendation requires going through the full Rec-track process again. Major problem, AC review Rescinded Recommendation - no new IPR licenses With little uptake, following AC review a specification may become an Obsolete Recommendation Obsolete Recommendation If there is new uptake, with AC review an Obsolete Recommendation may return to normal Recommendation status Replaced by a new version, AC review Superseded Recommendation A Superseded Recommendation can become a normal Recommendation with AC review
6.2.12.4. Process for Rescinding, Obsoleting, Superseding a Recommendation

The process of rescinding, obsoleting, superseding, or restoring a Recommendation can be initiated either by a request from the Director or via a request from any of the following:

The Director must then submit the request to the Advisory Committee for review. For any Advisory Committee review of a proposal to rescind, obsolete, supersede, or restore a Recommendation the Director must:

and should

If there was any dissent in the Advisory Committee review, the Director must publish the substantive content of the dissent to W3C and the public, and must formally address the dissent at least 14 days before publication as an Obsolete or Rescinded Recommendation.

The Advisory Committee may initiate an Advisory Committee Appeal of the Director's decision.

W3C must publish an Obsolete or Rescinded Recommendation with up to date status. The updated version may remove the main body of the document. The Status of this Document section should link to the explanation of Obsoleting and Rescinding W3C Specifications [OBS-RESC] as appropriate.

Once W3C has published a Rescinded Recommendation, future W3C technical reports must not include normative references to that technical report.

Note: W3C strives to ensure that all Technical Reports will continue to be available at their version-specific URL.

6.3. Working Group and Interest Group Notes

A Working Group Note or Interest Group Note (NOTE) is published by a chartered Working Group or Interest Group to provide a stable reference for a useful document that is not intended to be a formal standard, or to document work that was abandoned without producing a Recommendation.

Working Groups and Interest Groups may publish work as W3C Notes. Examples include:

Some W3C Notes are developed through successive Working Drafts, with an expectation that they will become Notes, while others are simply published. There are few formal requirements to publish a document as a W3C Note, and they have no standing as a recommendation of W3C but are simply documents preserved for historical reference.

In order to publish a Note, a Working Group or Interest Group:

Possible next steps:

Note: The W3C Patent Policy [PATENT-POLICY] does not specify any licensing requirements or commitments for Working Group Notes.

6.4. Further reading

Refer to "How to Organize a Recommendation Track Transition" [TRANSITION] in the Art of Consensus [GUIDE] for practical information about preparing for the reviews and announcements of the various steps, and tips on getting to Recommendation faster [REC-TIPS]. Please see also the Requirements for modification of W3C Technical Reports [REPUBLISHING].

7. Advisory Committee Reviews, Appeals, and Votes

This section describes how the Advisory Committee reviews proposals from the Director and how Advisory Committee representatives initiate an Advisory Committee Appeal of a W3C decision or Director's decision. A W3C decision is one where the Director decides, after exercising the role of assessing consensus of the W3C Community after an Advisory Committee review.

7.1. Advisory Committee Reviews

The Advisory Committee reviews:

7.1.1. Start of a Review Period

Each Advisory Committee review period begins with a Call for Review from the Team to the Advisory Committee. The Call for Review describes the proposal, raises attention to deadlines, estimates when the decision will be available, and includes other practical information. Each Member organization may send one review, which must be returned by its Advisory Committee representative.

The Team must provide two channels for Advisory Committee review comments:

  1. an archived Team-only channel;
  2. an archived Member-only channel.

The Call for Review must specify which channel is the default for review comments on that Call.

Reviewers may send information to either or both channels. They may also share their reviews with other Members on the Advisory Committee discussion list.

A Member organization may modify its review during a review period (e.g., in light of comments from other Members).

7.1.2. After the Review Period

After the review period, the Director must announce to the Advisory Committee the level of support for the proposal (consensus or dissent). The Director must also indicate whether there were any Formal Objections, with attention to changing confidentiality level. This W3C decision is generally one of the following:

  1. The proposal is approved, possibly with editorial changes integrated.
  2. The proposal is approved, possibly with substantive changes integrated. In this case the Director’s announcement must include rationale for the decision to advance the document despite the proposal for a substantive change.
  3. The proposal is returned for additional work, with a request to the initiator to formally address certain issues.
  4. The proposal is rejected.

This document does not specify time intervals between the end of an Advisory Committee review period and the W3C decision. This is to ensure that the Members and Team have sufficient time to consider comments gathered during the review. The Advisory Committee should not expect an announcement sooner than two weeks after the end of a review period. If, after three weeks, the Director has not announced the outcome, the Director should provide the Advisory Committee with an update.

7.2. Appeal by Advisory Committee Representatives

Advisory Committee representatives may appeal certain decisions, though appeals are only expected to occur in extraordinary circumstances.

When a W3C decision is made following an Advisory Committee review, Advisory Committee representatives may initiate an Advisory Committee Appeal. These W3C decisions include those related to group creation and modification, and transitions to new maturity levels for Recommendation Track documents and the Process document.

Advisory Committee representatives may also initiate an appeal for certain Director's decisions that do not involve an Advisory Committee review. These cases are identified in the sections which describe the requirements for the Director's decision and include additional (non-reviewed) maturity levels of Recommendation Track documents, group charter extensions and closures, and Memoranda of Understanding.

In all cases, an appeal must be initiated within three weeks of the decision.

An Advisory Committee representative initiates an appeal by sending a request to the Team. The request should say “I appeal this Director’s Decision” and identify the decision. Within one week the Team must announce the appeal process to the Advisory Committee and provide a mechanism for Advisory Committee representatives to respond with a statement of positive support for this appeal. The archive of these statements must be member-only. If, within one week of the Team’s announcement, 5% or more of the Advisory Committee support the appeal request, the Team must organize an appeal vote asking the Advisory Committee “Do you approve of the Director’s Decision?” together with links to the Director's decision and the appeal support.

The ballot must allow for three possible responses: “Approve”, “Reject”, and “Abstain”, together with Comments.

If the number of votes to reject exceeds the number of votes to approve, the decision is overturned. In that case, there are the following possible next steps:

  1. The proposal is rejected.
  2. The proposal is returned for additional work, after which the applicable decision process is re-initiated.

7.3. Advisory Committee Votes

The Advisory Committee votes in elections for seats on the TAG or Advisory Board, and in the event of an Advisory Committee Appeal achieving the required support to trigger an appeal vote. Whenever the Advisory Committee votes, each Member or group of related Members has one vote. In the case of Advisory Board and TAG elections, “one vote” means “one vote per available seat”.

8. Workshops and Symposia

The Team organizes Workshops and Symposia to promote early involvement in the development of W3C activities from Members and the public.

The goal of a Workshop is usually either to convene experts and other interested parties for an exchange of ideas about a technology or policy, or to address the pressing concerns of W3C Members. Organizers of the first type of Workshop may solicit position papers for the Workshop program and may use those papers to choose attendees and/or presenters.

The goal of a Symposium is usually to educate interested parties about a particular subject.

The Call for Participation in a Workshop or Symposium may indicate participation requirements or limits, and expected deliverables (e.g., reports and minutes). Organization of an event does not guarantee further investment by W3C in a particular topic, but may lead to proposals for new activities or groups.

Workshops and Symposia generally last one to three days. If a Workshop is being organized to address the pressing concerns of Members, the Team must issue the Call for Participation no later than six weeks prior to the Workshop’s scheduled start date. For other Workshops and Symposia, the Team must issue a Call for Participation no later than eight weeks prior to the meeting’s scheduled start date. This helps ensure that speakers and authors have adequate time to prepare position papers and talks.

9. Liaisons

W3C uses the term liaison to refer to coordination of activities with a variety of organizations, through a number of mechanisms ranging from very informal (e.g., an individual from another organization participates in a W3C Working Group, or just follows its work) to mutual membership, to even more formal agreements. Liaisons are not meant to substitute for W3C membership.

All liaisons must be coordinated by the Team due to requirements for public communication; patent, copyright, and other IPR policies; confidentiality agreements; and mutual membership agreements.

The W3C Director may negotiate a Memorandum of Understanding with another organization. For the purposes of the W3C Process a Memorandum of Understanding (MoU) is a formal agreement or similar contractual framework between W3C and another party or parties, other than agreements between the Hosts or between Hosts and W3C members for the purposes of membership and agreements related to the ordinary provision of services for the purposes of running W3C, that specifies rights and obligations of each party toward the others. These rights and obligations may include joint deliverables, an agreed share of technical responsibilities with due coordination, and/or considerations for confidentiality and specific IPR. The agreement may be called something other than a “Memorandum of Understanding”, and something called a “Memorandum of Understanding” may not be an MoU for the purposes of the Process.

Before signing the MoU, the Team must inform the Advisory Committee of the intent to sign and make the MoU available for Advisory Committee review; Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to sign the MoU. Unless an appeal rejects the proposal to sign an MoU, the Director may sign the MoU on behalf of W3C. A signed Memorandum of Understanding should be made public.

Information about W3C liaisons with other organizations [LIAISON] and the guidelines W3C follows when creating a liaison is available on the Web.

10. Member Submission Process

The Member Submission process allows Members to propose technology or other ideas for consideration by the Team. After review, the Team may make the material available at the W3C Web site. The formal process affords Members a record of their contribution and gives them a mechanism for disclosing the details of the transaction with the Team (including IPR claims). The Team also makes review comments on the Submitted materials available for W3C Members, the public, and the media.

A Member Submission consists of:

One or more Members (called the Submitter(s)) may participate in a Member Submission. Only W3C Members may be listed as Submitters.

The Submission process consists of the following steps:

  1. One of the Submitters sends a request to the Team to acknowledge the Submission request. The Team and Submitter(s) communicate to ensure that the Member Submission is complete.
  2. After Team review, the Director must either acknowledge or reject the Submission request.
Note: To avoid confusion about the Member Submission process, please note that:

Making a Member Submission available at the W3C website does not imply endorsement by W3C, including the W3C Team or Members. The acknowledgment of a Submission request does not imply that any action will be taken by W3C. It merely records publicly that the Submission request has been made by the Submitter. A Member Submission made available by W3C must not be referred to as “work in progress” of the W3C.

The list of acknowledged Member Submissions [SUBMISSION-LIST] is available at the W3C Web site.

10.1. Submitter Rights and Obligations

When more than one Member jointly participates in a Submission request, only one Member formally sends in the request. That Member must copy each of the Advisory Committee representatives of the other participating Members, and each of those Advisory Committee representatives must confirm (by email to the Team) their participation in the Submission request.

At any time prior to acknowledgment, any Submitter may withdraw support for a Submission request (described in "How to send a Submission request" [SUBMISSION-REQ]). A Submission request is “withdrawn” when no Submitter(s) support it. The Team must not make statements about withdrawn Submission requests.

Prior to acknowledgment, the Submitter(s) must not, under any circumstances, refer to a document as “submitted to the World Wide Web Consortium” or “under consideration by W3C” or any similar phrase either in public or Member communication. The Submitter(s) must not imply in public or Member communication that W3C is working (with the Submitter(s)) on the material in the Member Submission. The Submitter(s) may release the documents in the Member Submission to the public prior to acknowledgment (without reference to the Submission request).

After acknowledgment, the Submitter(s) must not, under any circumstances, imply W3C investment in the Member Submission until, and unless, the material has been adopted as a deliverable of a W3C Working Group.

10.1.1. Scope of Member Submissions

When a technology overlaps in scope with the work of a chartered Working Group, Members should participate in the Working Group and contribute the technology to the group’s process rather than seek publication through the Member Submission process. The Working Group may incorporate the contributed technology into its deliverables. If the Working Group does not incorporate the technology, it should not publish the contributed documents as Working Group Notes since Working Group Notes represent group output, not input to the group.

On the other hand, while W3C is in the early stages of developing a charter, Members should use the Submission process to build consensus around concrete proposals for new work.

Members should not submit materials covering topics well outside the scope of W3C’s mission [MISSION].

10.1.2. Information Required in a Submission Request

The Submitter(s) and any other authors of the submitted material must agree that, if the request is acknowledged, the documents in the Member Submission will be subject to the W3C Document License [DOC-LICENSE] and will include a reference to it. The Submitter(s) may hold the copyright for the documents in a Member Submission.

The request must satisfy the Member Submission licensing commitments in “Licensing Commitments in W3C Submissions” in the W3C Patent Policy [PATENT-POLICY].

The Submitter(s) must include the following information:

The request must also answer the following questions.

For other administrative requirements related to Submission requests, see “How to send a Submission request[MEMBER-SUB].

10.2. Team Rights and Obligations

Although they are not technical reports, the documents in a Member Submission must fulfil the requirements established by the Team, including the Team’s Publication Rules [PUBRULES].

The Team sends a validation notice to the Submitter(s) once the Team has reviewed a Submission request and judged it complete and correct.

Prior to a decision to acknowledge or reject the request, the request is Team-only, and the Team must hold it in the strictest confidentiality. In particular, the Team must not comment to the media about the Submission request.

10.3. Acknowledgment of a Submission Request

The Director acknowledges a Submission request by sending an announcement to the Advisory Committee. Though the announcement may be made at any time, the Submitter(s) can expect an announcement between four to six weeks after the validation notice. The Team must keep the Submitter(s) informed of when an announcement is likely to be made.

Once a Submission request has been acknowledged, the Team must:

If the Submitter(s) wishes to modify a document made available as the result of acknowledgment, the Submitter(s) must start the Submission process from the beginning, even just to correct editorial changes.

10.4. Rejection of a Submission Request, and Submission Appeals

The Director may reject a Submission request for a variety of reasons, including any of the following:

In case of a rejection, the Team must inform the Advisory Committee representative(s) of the Submitter(s). If requested by the Submitter(s), the Team must provide rationale to the Submitter(s) about the rejection. Other than to the Submitter(s), the Team must not make statements about why a Submission request was rejected.

The Advisory Committee representative(s) of the Submitters(s) may initiate a Submission Appeal of the Team’s Decision to the TAG if the reasons are related to Web architecture, or to the Advisory Board if the request is rejected for other reasons. In this case the Team should make available its rationale for the rejection to the appropriate body. The Team will establish a process for such appeals that ensures the appropriate level of confidentiality.

11. Process Evolution

Revision of the W3C Process and related documents (see below) undergoes similar consensus-building processes as for technical reports, with the Advisory Boardacting as the sponsoring Working Group. The documents may be developed by the AB or by another group to whom the AB has delegated development. Review includes soliciting input from the W3C community, and in particular the Team.

The documents covered by this section are:

The Advisory Board initiates review as follows:

  1. The Team sends a Call for Review to the Advisory Committee and other W3C groups.
  2. After comments have been formally addressed and the document possibly modified, the Team seeks endorsement from the Members by initiating an Advisory Committee review. The review period must last at least 28 days.
  3. After the Advisory Committee review, following a W3C decision to adopt the document(s), the Team does so and sends an announcement to the Advisory Committee. Advisory Committee representatives may initiate an Advisory Committee Appeal to the W3C.

Note: As of June 2020, the Patent Policy is developed in the Patents and Standards Interest Group, the Code of Ethics and Professional Conduct in the Positive Work Environment Community Group, and the Process in the W3C Process Community Group.

12. Acknowledgments

This section is non-normative.

The editors are grateful to the following people, who as interested individuals and/or with the affiliation(s) listed, have contributed to this proposal for a revised Process: Brian Kardell, Carine Bournez (W3C), Charles McCathie Nevile (ConsenSys), Chris Wilson (Google), David Singer (Apple), Delfí Ramírez, Dominique Hazaël-Massieux (W3C), Elika J. Etemad aka fantasai, Fuqiao Xue (W3C), Jeff Jaffe (W3C), Kevin Fleming (Bloomberg), Léonie Watson (The Paciello Group), Michael Champion (Microsoft), Nigel Megitt (BBC), Philippe Le Hégaret (W3C), Ralph Swick (W3C), Samuel Weiler (W3C), Sandro Hawke (W3C), Tantek Çelik (Mozilla), Virginia Fournier (Apple), Wendy Seltzer (W3C), Yves Lafon (W3C).

The editors are sorry for forgetting any names, and grateful to those who have listened patiently to conversations about this document without feeling a need to add more.

The following individuals contributed to the development of earlier versions of the Process: Alex Russell (Google), Andreas Tai (Institut fuer Rundfunktechnik), Andrew Betts (Fastly), Ann Bassetti (The Boeing Company), Anne van Kesteren, Art Barstow (Nokia, unaffiliated), Bede McCall (MITRE), Ben Wilson, Brad Hill (Facebook), Brian Kardell (JQuery), Carine Bournez (W3C), Carl Cargill (Netscape, Sun Microsystems, Adobe), Chris Lilley (W3C), Chris Wilson (Google), Claus von Riegen (SAP AG), Coralie Mercier (W3C), Cullen Jennings (Cisco), Dan Appelquist (Telefonica, Samsung), Dan Connolly (W3C), Daniel Dardailler (W3C), Daniel Glazman (Disruptive Innovations), David Baron (Mozilla), David Fallside (IBM), David Singer (Apple), David Singer (IBM), Delfí Ramírez, Dominique Hazaël-Massieux (W3C), Don Brutzman (Web3D), Don Deutsch (Oracle), Eduardo Gutentag (Sun Microsystems), Elika J. Etemad aka fantasai, Florian Rivoal, Fuqiao Xue (W3C), Geoffrey Creighton (Microsoft), Geoffrey Snedden, Giri Mandyam (Qualcomm), Gregg Kellogg, Hadley Beeman, Helene Workman (Apple), Henri Sivonen (Mozilla), Håkon Wium Lie (Opera Software), Ian Hickson (Google), Ian Jacobs (W3C), Ivan Herman (W3C), J Alan Bird (W3C), Jay Kishigami 岸上順一 (NTT), Jean-Charles Verdié (MStar), Jean-François Abramatic (IBM, ILOG, W3C), Jeff Jaffe (W3C), Jim Bell (HP), Jim Miller (W3C), Joe Hall (CDT), John Klensin (MCI), Josh Soref (BlackBerry, unaffiliated), Judy Brewer (W3C), Judy Zhu 朱红儒 (Alibaba), Kari Laihonen (Ericsson), Karl Dubost (Mozilla), Ken Laskey (MITRE), Kevin Fleming (Bloomberg), Klaus Birkenbihl (Fraunhofer Gesellschaft), Larry Masinter (Adobe Systems), Lauren Wood (unaffiliated), Liam Quin (W3C), Léonie Watson (The Paciello Group), Marcos Cáceres (Mozilla), Maria Courtemanche (IBM), Mark Crawford (SAP), Mark Nottingham, Michael Champion (Microsoft), Michael Geldblum (Oracle), Mike West (Google), Mitch Stoltz (EFF), Natasha Rooney (GSMA), Nigel Megitt (BBC), Olle Olsson (SICS), Ora Lassila (Nokia), Paul Cotton (Microsoft), Paul Grosso (Arbortext), Peter Linss, Peter Patel-Schneider, Philippe Le Hégaret (W3C), Qiuling Pan (Huawei), Ralph Swick (W3C), Renato Iannella (IPR Systems), Rigo Wenning (W3C), Rob Sanderson (J Paul Getty Trust), Robin Berjon (W3C), Sally Khudairi (W3C), Sam Ruby (IBM), Sandro Hawke (W3C), Sangwhan Moon (Odd Concepts), Scott Peterson (Google), Steve Holbrook (IBM), Steve Zilles (Adobe Systems) Steven Pemberton (CWI), TV Raman (Google), Tantek Çelik (Mozilla), Terence Eden (Her Majesty’s Government), Thomas Reardon (Microsoft), Tim Berners-Lee (W3C), Tim Krauskopf (Spyglass), Travis Leithead (Microsoft), Virginia Fournier (Apple), Virginie Galindo (Gemalto), Wayne Carr (Intel), Wendy Fong (Hewlett-Packard), Wendy Seltzer (W3C), Yves Lafon (W3C).

13. Changes

This section is non-normative.

Changes since the 1 March 2019 Process

This document is based on the 1 March 2019 Process. A Disposition of Comments, as well as a detailed log of all changes since then are available.

A diff comparing it to the 2019 edition of the Process is available. Note that due to overlapping changes, this diff may be somewhat difficult to review. In order to make review easier, several partial diffs, grouping related changes, are available as well, as detailed below.

Major Update to the Recommendation Track

Significant additions and modifications were made to the Recommendation Track. While the meaning of the various maturities and associated transition criteria are unchanged, important additions have been made to what can be done during CR and REC phases. These aim to facilitate maintenance of specifications, and to provide a Living Standards capability as a native capability of the W3C Recommendation Track.

Some minor simplifications have also been made:

A diff comparing the state before/after these changes is available.

Other Substantive Changes and Clarifications

A diff comparing the state before/after these changes is available.

Notable Editorial Changes

Final adjustements

Based on a cycle of review by the Advisory Committee and the broader community of the changes described above, a few final adjustments were made:

A diff comparing the state before/after these changes is available.

Changes since earlier versions

Changes since earlier version of the Process are detailed in the changes section of the previous version of the Process.

References

Normative References

[CEPC]
W3C Code of Ethics and Professional Conduct. URL: https://www.w3.org/Consortium/cepc/
[COLLABORATORS-AGREEMENT]
Invited expert and collaborators agreement. URL: https://www.w3.org/Consortium/Legal/collaborators-agreement
[CONFLICT-POLICY]
Conflict of Interest Policy for W3C Team Members Engaged in Outside Professional Activities. URL: https://www.w3.org/2000/09/06-conflictpolicy
[DOC-LICENSE]
W3C Document License. URL: https://www.w3.org/Consortium/Legal/copyright-documents
[PATENT-POLICY]
The W3C 2020 Patent Policy. URL: https://www.w3.org/Consortium/Patent-Policy/@@@TBD@@@
[PATENT-POLICY-2017]
The W3C 2004 Patent Policy, Updated 2017. URL: https://www.w3.org/Consortium/Patent-Policy-20170801/
[PUBRULES]
Publication Rules. URL: https://www.w3.org/pubrules/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[RFC3797]
D. Eastlake 3rd. Publicly Verifiable Nominations Committee (NomCom) Random Selection. June 2004. Informational. URL: https://tools.ietf.org/html/rfc3797

Informative References

[AB-HP]
The Advisory Board home page. URL: https://www.w3.org/2002/ab/
[AC-MEETING]
Advisory Committee meetings (Member-only access). URL: https://www.w3.org/Member/Meeting/
[BG-CG]
Community and Business Group Process. URL: https://www.w3.org/community/about/agreements/
[CALENDAR]
Calendar of all scheduled official W3C events. URL: https://www.w3.org/participate/eventscal
[CHAIR]
W3C Working/Interest Group Chair. URL: https://www.w3.org/Guide/chair/role.html
[CHARTER]
How to Create a Working Group or Interest Group. URL: https://www.w3.org/Guide/process/charter.html
[CURRENT-AC]
Current Advisory Committee representatives (Member-only access). URL: https://www.w3.org/Member/ACList
[DISCIPLINARY-GL]
Guidelines for Disciplinary Action. URL: https://www.w3.org/2002/09/discipline
[ELECTION-HOWTO]
How to Organize an Advisory Board or TAG election. URL: https://www.w3.org/2002/10/election-howto
[FELLOWS]
W3C Fellows Program. URL: https://www.w3.org/Consortium/Recruitment/Fellows
[GROUP-MAIL]
Group mailing lists (Member-only access). URL: https://www.w3.org/Member/Groups
[GUIDE]
The Art of Consensus, a guidebook for W3C Working Group Chairs and other collaborators. URL: https://www.w3.org/Guide/
[INTRO]
Process, Patent Policy, Finances, Specs management, Strategic vision (Member-only access). URL: https://www.w3.org/Member/Intro
[JOIN]
How to Join W3C. URL: https://www.w3.org/Consortium/join
[LIAISON]
W3C liaisons with other organizations. URL: https://www.w3.org/2001/11/StdLiaison
[MEMBER-AGREEMENT]
W3C Membership Agreement. URL: https://www.w3.org/Consortium/Agreement/Member-Agreement
[MEMBER-HP]
Member Web site (Member-only access). URL: https://www.w3.org/Member/
[MEMBER-LIST]
The list of current W3C Members. URL: https://www.w3.org/Consortium/Member/List
[MEMBER-SUB]
How to send a Submission request. URL: https://www.w3.org/2000/09/submission
[MISSION]
The W3C Mission statement. URL: https://www.w3.org/Consortium/mission
[OBS-RESC]
Obsoleting and Rescinding W3C Specifications. URL: https://www.w3.org/2016/11/obsoleting-rescinding/
[REC-TIPS]
Tips for Getting to Recommendation Faster. URL: https://www.w3.org/2002/05/rec-tips
[REPUBLISHING]
In-place modification of W3C Technical Reports. URL: https://www.w3.org/2003/01/republishing/
[SUBMISSION-LIST]
The list of acknowledged Member Submissions. URL: https://www.w3.org/Submission/
[SUBMISSION-REQ]
Make or Withdraw a Member Submission Request (Member-only access). URL: https://www.w3.org/2000/09/submission
[TAG-CHARTER]
Technical Architecture Group (TAG) Charter. URL: https://www.w3.org/2004/10/27-tag-charter.html
[TAG-HP]
The TAG home page. URL: https://www.w3.org/2001/tag/
[TEAM-CONTACT]
Role of the Team Contact. URL: https://www.w3.org/Guide/teamcontact/role.html
[TR]
The W3C technical reports index. URL: https://www.w3.org/TR/
[TRANSITION]
Organize a Technical Report Transition. URL: https://www.w3.org/Guide/transitions
[TRANSLATION]
Translations of W3C technical reports. URL: https://www.w3.org/Consortium/Translation/

Index

Terms defined by this specification