[contents]  

W3C

On 1 August 2014, W3C began a transition away from this document; see the current W3C Process Document.

World Wide Web Consortium Process Document

5 February 2004

This version:
http://www.w3.org/2004/02/Process-20040205/
Latest operative version:
http://www.w3.org/Consortium/Process/
Previous operative version:
http://www.w3.org/2003/06/Process-20030618/
Editor:
Ian Jacobs, W3C

Please refer to the errata for this document, which may include some normative corrections.

This document is also available in these non-normative packages: single HTML file, self-contained gzipped tar archive, self-contained zip archive.

There may be translations of this document.

Copyright © 1996-2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.

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 the processes related to the responsibilities and functions they exercise to enable W3C to accomplish its mission. This document does not describe the internal workings of the Team or W3C's public communication mechanisms.

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

Status of this Document

This is the 5 February 2004 version of the W3C Process Document. This document has been produced by the W3C Advisory Board and reviewed by the W3C Members and Team.

This version of the Process Document has been harmonized with the 5 February 2004 version of the W3C Patent Policy [PUB33]. The list of changes to the public Process Document is available on the Web.

Please send comments about this document to [email protected] (Member-only archive). Additional Member-only information about the Process Document (e.g., issues lists, Member-only drafts, and changes to Member-only drafts) is available from the Process Plan page. General information about W3C is available on the Web, including information about becoming a W3C Member.

The terms MUST, MUST NOT, SHOULD, SHOULD NOT, REQUIRED, and MAY when highlighted (through style sheets, and in uppercase in the source) are used in accordance with RFC 2119 [RFC2119]. The term NOT REQUIRED (not defined in RFC 2119) indicates exemption.

Time intervals in this document are highlighted through style sheets.

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 [PUB6]. The Patent Policy W3C Patent Policy [PUB33] 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 so that they may evolve independently.

Table of Contents

Expanded table of contents

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 is mission.

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

  1. People generate interest in a particular topic (e.g., Web services). 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. This was the case, for example, with Web services.
  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 a new Activity or Working Group charter, depending on the breadth of the topic of interest. An Activity Proposal describes the scope, duration, and other characteristics of the intended work, and includes the charters of one or more Working Groups, Interest Groups, and possibly Coordination Groups to carry out the work. W3C Members review each Activity Proposal and the associated Working Group charters. When there is support within W3C for investing resources in the topic of interest, the Director approves the new Activity and groups get down to work. For the Web Services Activity, the initial Activity Proposal called for one Working Group to work on Web Services Architecture and one to work on a language for Web Services Description. The Activity Proposal also incorporated an existing Working Group (from another Activity) working on XML Protocols.
  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 Recommendation Track, and through an appeal process for the Advisory Committee.

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.

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 [MEM1]). The Advisory Committee: Advisory Committee representatives have appeal powers for some processes described in this document.
  2. Representatives of Member organizations participate in Working Groups, Interest Groups, and Coordination Groups and author and review documents on the Recommendation Track.

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

W3C does not have a class of membership tailored to, or priced for individuals. However, an individual MAY join W3C as an Affiliate Member. In this case the same 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, representatives of Member organizations participate in W3C as follows:

In the case (described in paragraph 5g of the Membership Agreement), where a Member organization is itself a consortium, user society, or otherwise has members or sponsors, the organization's paid staff and Advisory Committee representative exercise all the rights and privileges of W3C membership. In addition, the Advisory Committee representative MAY 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. These individuals MUST disclose their employment affiliation when participating in W3C work. Provisions for related Members apply. Furthermore, these individuals are expected to represent the broad interests of the W3C Member organization and not the parochial interests of their employers.

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. Refer to the Guidelines for Disciplinary Action [MEM14].

2.1.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 [MEM4].

2.1.3 Advisory Committee (AC)

When an organization joins W3C (see "How to Join W3C" [PUB5]), it MUST name its Advisory Committee representative as part of the Membership Agreement. The New Member Orientation 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 [PUB33].

Additional information for Members is available at the Member Web site [MEM6].

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 W3C Chair or Chief Operating Officer). At each Advisory Committee meeting, the Team SHOULD provide an update to the Advisory Committee about:

Resources
Allocations

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 [MEM5] is available at the Member Web site.

2.2 The W3C Team

The Team consists of the W3C paid staff, unpaid interns, and W3C Fellows. W3C Fellows are Member employees working as part of the Team; see the W3C Fellows Program [PUB32]. 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 Team is led by the Director, W3C Chair, and Chief Operating Officer. These individuals MAY delegate responsibility (generally to other individuals in the Team) for any of their roles described in this document.

The Director is the lead technical architect at W3C and as such, is responsible for assessing consensus within W3C for architectural choices, publication of technical reports, and new Activities. The Director appoints group Chairs and has the role of "tie-breaker" for questions of Good Standing in a Working Group or appeal of a Working Group decision. The Director is generally Chair of the TAG.

The W3C Chair leads Member relations, and liaisons with other organizations, governments, and the public.

The Chief Operating Officer (COO) leads the operation of W3C as an organization: a collection of people, Host institutions, and processes.

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 three "Host" institutions: 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 joint sponsorship contracts; the Hosts themselves are not W3C Members.

2.2.1 Team Submissions

The Team MAY request that the Director publish information at the W3C Web site. At the Director's discretion, these documents are published as "Team Submissions". These documents are analogous to Member Submissions (e.g., in expected scope). However, there is no additional Team comment.

Team Submissions are not part of the Recommendation Track process.

The list of published Team Submissions [PUB16] is available at the W3C Web site.

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 appeals of Member Submission requests that are 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 for the Advisory Board to use for its communication, confidential to the Advisory Board and Team.

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 [PUB30].

2.3.1 Advisory Board Participation

The Advisory Board consists of nine elected participants and a Chair. The Team appoints the Chair of the Advisory Board, who is generally the W3C Chair.

The remaining nine 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 four or five 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 appeals of Member Submission requests that are 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 [PUB25] 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., an appeal of a rejected Member Submission request), 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 [PUB25] 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 [PUB26].

2.4.1 Technical Architecture Group Participation

The TAG consists of eight elected or appointed participants and a Chair. The Team appoints the Chair of the TAG, who is generally the Director.

Three TAG participants are appointed by the Director. Appointees are NOT REQUIRED to be on the W3C Team. The Director MAY appoint W3C Fellows to the TAG.

The remaining five TAG 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 TAG participants are for two years. Terms are staggered so that each year, either two or 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.

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. Good Standing rules as defined for Working Group participants also apply to Advisory Board and TAG participants. Advisory Board and TAG participants SHOULD attend Advisory Committee meetings.

An individual participates on the Advisory Board or TAG from the moment the individual's term begins until the term ends or the seat is vacated. 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). See also the licensing obligations on TAG participants in section 3 of the W3C Patent Policy [PUB33], and the claim exclusion process of section 4.

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:

If, for whatever reason, these constraints are not satisfied (e.g., because a TAG or AB participant changes jobs), one participant MUST cease TAG or AB participation until the situation has been resolved. If after 30 days the situation has not been resolved, the Chair will declare one participant's seat to be vacant. When more than one individual is involved, the verifiable random selection procedure described below will be used to choose one person for continued participation.

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. An election begins when the Team sends a Call for Nominations to the Advisory Committee. Any Call for Nominations specifies the number of available seats, the deadline for nominations, and the address where nominations are sent.

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. 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 vote for as many candidates as there are available seats; see the section on Advisory Committee votes. Once the deadline for votes has passed, the Team announces the results to the Advisory Committee. The candidates with the most votes are elected to the available seats. In case of a tie where there are more apparent winners than available seats (e.g., three candidates receive 10 votes each for two seats), the verifiable random selection procedure described below will be used to fill the available seats.

Refer to How to Organize an Advisory Board or TAG election [MEM15] 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 2777 [RFC2777]. 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 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 to individuals in result order.
  2. When it is necessary to assign one or more short terms to elected participants. In this case, the names of all elected individuals (after resolution of ties) are provided as input to the procedure. Short terms are assigned to individuals 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 either of the following occurs:

When an Advisory Board or TAG participant changes affiliations, as long as Advisory Board and TAG participation constraints are respected, the individual MAY continue to participate until the next regularly scheduled election for that group. Otherwise, the seat is vacated.

When a seat is vacated, it is filled at the next regularly scheduled election for the group.

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, Interest Groups, and Coordination 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.

See also the participation requirements described in section 6 of the W3C Patent Policy [PUB33].

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 is clearly a function of 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 [PUB23].

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, W3C Chair, 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:

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

By default, the set of individuals eligible to participate in a decision is the set of group participants in Good Standing. 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 that are made despite nearly universal apathy (i.e., with 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.

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 may 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 least strong 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

When individual registers a formal objection to a decision, the individual SHOULD cite technical arguments and propose changes that would remove the objection; these proposals MAY be vague or incomplete. When an objection concerning a document on the Recommendation Track or the Process Document includes such information, the Chair MUST report it to the Director in the next request to advance the document (e.g., in the request to the Director to advance a technical report to Candidate Recommendation). If an objection does not include such information, the Chair is NOT REQUIRED to report it at later review stages.

During an Advisory Committee Review, Advisory Committee representatives MUST be able to refer to formal objections. A version of each formal objection MUST be publicly available.

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 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 in Good Standing. Each organization represented in the group MUST have at most one vote, even when the organization is represented by several participants in the group. For the purposes of voting:

Unless the charter states otherwise, Invited Experts MAY vote. Organizations represented by one or more Invited Experts are subject to the same one vote limitation.

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, the minority are NOT REQUIRED to state the reasons for their dissent, and the group is NOT REQUIRED to record individual votes.

A group charter SHOULD 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 a Chair's Decision

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

When group participants believe that their concerns are not being duly considered by the group, they MAY ask the Director (for representatives of a Member organization, via their Advisory Committee representative) to confirm or deny the decision. 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 group participant MAY resign from a group. The Team will establish administrative procedures for participant resignation. See section 4.2. of the W3C Patent Policy [PUB33] 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 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 [MEM3] 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 information at the W3C Web site: 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.

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 Recommendation Track 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 Recommendation Track 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 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 Activities

This section describes the mechanisms for establishing consensus within the areas of Web development the Consortium chooses to pursue. An Activity organizes the work necessary for the development or evolution of a Web technology.

W3C starts an Activity based on interest from the Members and Team. W3C Members build interest around new work through discussions among Advisory Committee representatives, Chairs, and Team, and through the Submission process. The Team tracks Web developments inside and outside W3C, manages liaisons, and organizes workshops.

Based on input from the Team and Members about the structure and scope of an Activity, the Team sends an Activity Proposal to the Advisory Committee. This is a proposal to dedicate Team and Member resources to a particular area of Web technology or policy, and when there is consensus about the motivation, scope, and structure of the proposed work, W3C starts a new Activity.

Each Activity has its own structure that generally includes Working Groups, Interest Groups, and Coordination Groups. Within the framework of an Activity, these groups produce technical reports, review the work of other groups, and develop sample code or test suites.

The progress of each Activity is documented in an Activity Statement. Activity Statements describe the goals of the Activity, completed and unfinished deliverables, changing perspectives based on experience, and future plans. At least before each Advisory Committee meeting, the Team SHOULD revise the Activity Statement for each Activity that has not been closed.

Refer to the list of W3C Activities [PUB9]. Note: This list MAY include some Activities that began prior to the formalization in 1997 of the Activity creation process.

5.1 Activity Proposal Development

The Team MUST notify the Advisory Committee when a proposal for a new or modified Activity is in development. This is intended to raise awareness, even if no formal proposal is yet available. Advisory Committee representatives MAY express their general support on the Advisory Committee discussion list. The Team MAY incorporate discussion points into an Activity Proposal. Refer to additional tips on getting to Recommendation faster [PUB27].

5.2 Advisory Committee Review of an Activity Proposal

The Director MUST solicit Advisory Committee review of every proposal to create, substantively modify, or extend an Activity.

After a Call for Review from the Director, the Advisory Committee reviews and comments on the proposal. The review period MUST be at least four weeks.

The Director announces to the Advisory Committee whether there is consensus within W3C to create or modify the Activity (possibly with changes suggested during the review). For a new Activity, this announcement officially creates the Activity. This announcement MAY include a Call for Participation in any groups created as part of the Activity.

If there was dissent, Advisory Committee representatives MAY appeal a decision to create, modify, or extend the Activity. Note: There is no appeal of a decision not to create an Activity; in general, drafting a new Activity Proposal will be simpler than following the appeal process.

5.3 Modification of an Activity

Activities are intended to be flexible. W3C expects participants to be able to adapt in the face of new ideas (e.g., Member Submission requests) and increased understanding of goals and context, while remaining true to the intent of the original Activity Proposal. If it becomes necessary to make substantive changes to an Activity (e.g., because significant additional resources are necessary or because the Activity's scope has clearly changed from the original proposal), then the Director MUST solicit Advisory Committee review of a complete Activity Proposal, including rationale for the changes.

5.4 Extension of an Activity

When the Director solicits Advisory Committee review of a proposal to extend the duration of an Activity with no other substantive modifications to the composition of the Activity, the proposal MUST indicate the new duration and include rationale for the extension. The Director is NOT REQUIRED to submit a complete Activity Proposal.

5.5 Activity Closure

An Activity Proposal specifies a duration for the Activity. The Director, subject to appeal by Advisory Committee representatives, MAY close an Activity prior to the date specified in the proposal in any of the following circumstances:

The Director closes an Activity by announcement to the Advisory Committee.

5.6 Activity Proposals

An Activity Proposal defines the initial scope and structure of an Activity. The proposal MUST include or reference the following information:

6 Working Groups, Interest Groups, and Coordination Groups

This document defines three types of groups:

  1. 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 Good Standing requirements for Working Group participation as well as additional participation requirements described in the W3C Patent Policy [PUB33].
  2. 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. There are no Good Standing requirements for Interest Group participation. Interest Groups do not create W3C Recommendations.
  3. Coordination Groups. A Coordination Group manages dependencies and facilitates communication with other groups, within or outside of W3C.

6.1 Requirements for All Working, Interest, and Coordination 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). Existing charters that are not yet public MUST be made public when next revised or extended (with attention to changing confidentiality level).

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 [MEM14] is described in the Member guide [MEM9].

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 is described in the Member 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 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 [MEM2].

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.

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

6.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 MUST represent at most one organization in a Working Group or Interest Group.

An individual MAY become a Working or Interest Group participant at any time during the group's existence. See also relevant requirements in section 4.3 of the W3C Patent Policy [PUB33].

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 section 3 of the W3C Patent Policy [PUB33], and the patent claim exclusion process of section 4.

6.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 [PUB33]):

  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:

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

6.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 be able to participate in a Working Group as an Invited Expert, an individual MUST do all of the following:

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:

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

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

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

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

6.2.1.7 Good Standing in a Working Group

Participation in a Working Group on an ongoing basis implies a serious commitment to the charter, including all of the following:

When the Chair and the Team Contact agree, the Chair MAY declare that a participant is no longer in Good Standing (henceforth called "Bad Standing"). If there is disagreement between the Chair and the Team Contact about standing, the Director determines the participant's standing. The Chair MAY declare a Team participant to be in Bad Standing, but it is clearly preferable for the Chair, Team participant, and W3C management to resolve issues internally.

A participant MAY be declared in Bad Standing in any of the following circumstances:

Although all participants representing an organization SHOULD attend all meetings, attendance by one representative of an organization satisfies the meeting attendance requirement for all representatives of the organization.

The above criteria MAY be relaxed if the Chair and Team Contact agree that doing so will not set back the Working Group. For example, the attendance requirement can be relaxed for reasons of expense (e.g., cost of travel) or scheduling (for example, an exceptional teleconference is scheduled at 3:00 a.m. local time for the participant). It is the responsibility of the Chair and Team Contact to apply criteria for Good Standing consistently.

When a participant risks losing Good Standing, the Chair and Team Contact are expected to discuss the matter with the participant and the participant's Advisory Committee representative (or W3C management for the Team) before declaring the participant in Bad Standing.

The Chair declares a participant in Bad Standing by informing the participant's Advisory Committee representative and the participant of the decision. If the Advisory Committee representative and Chair differ in opinion, the Advisory Committee representative MAY ask the Director to confirm or deny the decision. Invited Experts declared in Bad Standing MAY appeal to the Director.

The Chair and Team Contact restore Good Standing and SHOULD do so when the individual in Bad Standing satisfies the above criteria. The Chair MUST inform the individual's Advisory Committee representative of any change in standing.

Changes in an individual's standing in a Working Group have no effect on the obligations associated with Working Group participation that are described in the W3C Patent Policy [PUB33].

6.2.2 Working Group and Interest Group Charter Development

The Team MUST notify the Advisory Committee when a charter for a new Working Group or Interest Group is in development. The suggestions for building support around an Activity Proposal apply to charters as well.

W3C MAY begin work on a Working Group or Interest Group charter at any time. A Working Group or Interest Group MUST be part of an approved Activity.

6.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. The Director is NOT REQUIRED to solicit Advisory Committee review prior to a charter extension or for minor changes.

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.

6.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. 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 of the Team Contact.

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

Advisory Committee representatives MAY appeal creation or substantive modification of a Working Group or Interest Group charter.

6.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, which MUST NOT exceed the duration of the Activity to which the group belongs. 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 appeal the extension of a Working Group or Interest Group charter.

6.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 of section 2 and section 3 of the W3C Patent Policy [PUB33].

An Interest Group charter MAY specify 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 additional voting procedures, but those procedures MUST NOT conflict with the voting requirements of the Process Document.

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

6.2.7 Working Group "Heartbeat" Requirement

When a Working Group has one or more technical reports in the Recommendation Track process that are not in an end state, at least every three months the group MUST publish a new draft of at least one of them on the W3C technical reports index [PUB11]. Each Working Group SHOULD publish a new draft of each active technical report at least every three months.

In exceptional cases, the Chair MAY ask the Director to be excused from this publication requirement. However, in this case, the Working Group MUST issue a public status report with rationale why a new draft has not been published.

There are several reasons for this Working Group "heartbeat" requirement:

As an example, suppose a Working Group has one technical report as a deliverable, which it publishes as a Proposed Recommendation. Per the heartbeat requirement, the Working Group is required to publish a new draft of the Proposed Recommendation at least every three months, even if it is only to revise the status of the Proposed Recommendation document (e.g., to provide an update on the status of the decision to advance). The heartbeat requirement stops when the document becomes a Recommendation (or a Working Group Note).

6.2.8 Working Group and Interest Group Closure

A Working Group or Interest Group charter specifies a duration for the group. The Director, subject to appeal by Advisory Committee representatives, MAY 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.

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

6.3 Coordination Groups

W3C Activities interact in many ways. There are dependencies between groups within the same Activity or in different Activities. There are also dependencies between W3C Activities and the activities of other organizations. Examples of dependencies include the use by one technology of another being developed elsewhere, scheduling constraints between groups, and the synchronization of publicity for the announcement of deliverables. Coordination Groups are created to manage dependencies so that issues are resolved fairly and the solutions are consistent with W3C's mission and results.

Where a Coordination Group's scope covers two groups with unresolved disputes or tensions, it is the first locus of resolution of these disputes.

6.3.1 Coordination Group Participation Requirements

There are four types participants in a Coordination Group: the Chair, the Chair of each coordinated group (to promote effective communication among the groups), Invited Experts (e.g., liaisons to groups inside or outside W3C), and Team representatives (including the Team Contact). The requirements for Invited Expert participation are the same as for an Invited Expert in a Working Group.

Coordination Group participants MUST follow the conflict of interest policy by disclosing information to the rest of the group.

There are no Good Standing requirements for Coordination Group participation; regular participation in a relevant Coordination Group is one of the roles of a group Chair [MEM14].

6.3.2 Coordination Group Creation and Closure

The Director creates or modifies a Coordination Group by sending the Coordination Group charter to the Advisory Committee. A Coordination Group MAY be created as part of an Activity Proposal (for example to coordinate other groups in the Activity or to draw up charters of future groups), or during the life of an Activity when dependencies arise. A Coordination Group MAY operate as part of several W3C Activities.

A Coordination Group SHOULD close when there is no longer a perceived need for coordination.

6.3.3 Coordination Group Charters

A Coordination Group charter MUST include all of the following information:

A charter MAY include additional voting procedures, but those procedures MUST NOT conflict with the voting requirements of the Process Document.

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.

7 W3C Recommendation Track Process

The Recommendation Track process is the set of steps and requirements followed by W3C Working Groups to standardize Web technology. The processes followed by a Working Group to manage specifications and guidelines -- called technical reports in this section -- include:

The W3C Recommendation Track process is designed to maximize consensus about the content of a technical report, to ensure high technical and editorial quality, and to earn endorsement by W3C and the broader community. See also the licensing goals for W3C Recommendations in section 2 of the W3C Patent Policy [PUB33].

The following sections describe:

Maturity levels are described first, followed by the steps on the Recommendation Track and the requirements for each step.

7.1 Recommendation Track Process Maturity Levels

The maturity level of a published technical report indicates its place in the Recommendation Track process. The maturity levels "Working Draft" and "Working Group Note" represent the possible initial states of a technical report in the Recommendation Track process. The maturity levels "Recommendation", "Working Group Note", and "Rescinded Recommendation" represent the possible end states.

7.1.1 Maturity Levels When Advancing a Technical Report Towards Recommendation

Working Draft (WD)
A Working Draft is a document that W3C has published for review by the community, including W3C Members, the public, and other technical organizations.
Candidate Recommendation (CR)
A Candidate Recommendation is a document that W3C believes has been widely reviewed and satisfies the Working Group's technical requirements. W3C publishes a Candidate Recommendation to gather implementation experience.
Proposed Recommendation (PR)
A Proposed Recommendation is a mature technical report that, after wide review for technical soundness and implementability, W3C has sent to the W3C Advisory Committee for final endorsement.
W3C Recommendation (REC)
A W3C Recommendation is a specification or set of guidelines that, after extensive consensus-building, has received the endorsement of W3C Members and the Director. W3C recommends the wide deployment of its Recommendations. Note: W3C Recommendations are similar to the standards published by other organizations.

7.1.2 Maturity Level When Ending Work on a Technical Report

Working Group Note
A Working Group Note is published by a chartered Working Group to indicate that work has ended on a particular topic. A Working Group MAY publish a Working Group Note with or without its prior publication as a Working Draft. W3C MAY also publish "Interest Group Notes" and "Coordination Group Notes" for similar publications by those types of groups. Interest Groups and Coordination Groups do not create technical reports that advance toward Recommendation.
Note: To avoid confusion in the developer community and the media about which documents represent the output of chartered groups and which documents are input to W3C Activities (Member Submissions and Team Submissions), W3C plans to stop using the unqualified maturity level "Note."

7.1.3 Maturity Level When Editing a Recommendation

Proposed Edited Recommendation
A Proposed Edited Recommendation is a Recommendation published for community review of changes, some of which may affect conformance. When there is consensus about the changes, the document is published as a Recommendation.

7.1.4 Maturity Levels When Rescinding a Recommendation

Rescinded Recommendation
A Rescinded Recommendation is an entire Recommendation that W3C no longer endorses.

7.2 General Requirements for Advancement

For a Call for Implementations up to and including publication as a Recommendation, the Working Group MUST:

  1. Record the group's decision to request advancement.
  2. Indicate whether the document has been modified substantively since the previous step. A substantive change (whether deletion, inclusion, or other modification) is one where someone could reasonably expect that making the change would invalidate an individual's review or implementation experience. Other changes (e.g., clarifications, bug fixes, editorial repairs, and minor error corrections) are minor changes. A Working Group MUST document changes (both substantive and minor) between steps.
  3. Report which, if any, of the Working Group's requirements for this document have changed since the previous step.
  4. Report any changes in dependencies with other groups.
  5. Show evidence of wide review.
  6. Formally address all issues raised about the document since the previous step. In practice, once a Working Group wishes to advance to Candidate Recommendation or beyond, the Director expects positive documentation that issues have been formally addressed (e.g., in an issues list that shows their disposition). For earlier stages on the Recommendation Track, less formal documentation generally suffices (e.g., evidence in an archived mailing list).
  7. Report any formal objections.

The following information is important to the decision to advance a technical report and therefore MUST be publicly available:

7.3 Reviews and Review Responsibilities

Experience shows that the following help build consensus around technical reports:

  1. Frequent publication (see the Working Group "Heartbeat" requirement).
  2. Early review, to find errors quickly and decrease the chances of diverging technologies.
  3. Wide review, including from other groups in and outside of W3C.

A document receives review from the moment it is first published. Starting with the First Public Working Draft until the start of a Proposed Recommendation review, a Working Group MUST formally address any substantive review comment about a technical report and SHOULD do so in a timely manner. The Director MUST formally address any substantive issue raised by Advisory Committee representatives during Proposed Recommendation, Proposed Edited Recommendation, and Proposed Rescinded Recommendation review periods. The Working Group MUST communicate to the Director (usually through the Team Contact) any substantive issues raised during Proposed Recommendation, Proposed Edited Recommendation, and Proposed Rescinded Recommendation review periods by parties other than Advisory Committee representatives.

Reviewers SHOULD NOT send substantive technical reviews late on the Recommendation track. Reviewers SHOULD NOT expect that a Working Group will readily make substantive changes to a mature document. The more evidence a Working Group can show of wide review, the less weight substantive comments will carry when provided late on the Recommendation Track. Worthy ideas SHOULD BE recorded even when not incorporated into a mature document.

The Working Group MUST be able to show evidence of having attempted to respond to and satisfy reviewers. Reviewers MAY register a formal objection any time they are dissatisfied with how a Working Group has handled an issue.

A Working Group SHOULD negotiate review schedules with other groups expected to review a document, including relevant liaisons.

There are two formal review periods with fixed durations when advancing to Recommendation: after a Last Call announcement and after a Call for Review of a Proposed Recommendation. Out of consideration for the Working Group, reviewers SHOULD send their comments early in a review period. A Working Group SHOULD NOT start a new review before the scheduled end of an ongoing review (e.g., do not start a new Last Call review before the scheduled end of an ongoing Last Call review).

Ordinarily, reviewers SHOULD NOT raise substantive technical issues about a technical report after the end of a Last Call review period. However, this does occur, and as stated above, a Working Group's requirement to formally address those issues extends until the end of a Proposed Recommendation review period. However, to allow the Working Group to make progress on a technical report, the Working Group MAY decline to make substantive changes to address issues raised between the end of a Last Call review period and publication of a Recommendation. A reviewer MAY register a formal objection.

Advisory Committee representatives SHOULD NOT (but MAY) raise new substantive technical issues during a Proposed Recommendation review period. The Director MAY respond to the reviewer after the close of the Proposed Recommendation review period. Note: It may be necessary to change confidentiality level when conveying issues raised by Advisory Committee representatives to the Working Group.

During review by the Members, the Working Group SHOULD also formally address informed and relevant issues raised outside the Advisory Committee (e.g., by the public or another W3C Working Group), and report them to the Director in a timely fashion.

When a Working Group receives a substantive issue after the end of Proposed Recommendation review period, the Working Group MUST respond to the reviewer but MAY decline to formally address the issue. In this case, the Working Group MAY consider the issue as part of tracking errata.

7.4 Advancing a Technical Report to Recommendation

W3C follows these steps when advancing a technical report to Recommendation.

  1. Publication of the First Public Working Draft.
  2. Last Call announcement
  3. Call for Implementations. Note: The Director MAY permit the Working Group to skip this step if the entrance criteria for the next step have already been satisfied.
  4. Call for Review of a Proposed Recommendation.
  5. Publication as a Recommendation.

In general, Working Groups embark on this journey with the intent of publishing one or more Recommendations. However, W3C MAY end work on a technical report at any time, or MAY require a Working Group to conduct further work, possibly repeating one or more steps.

Between publication of the First Public Working Draft and Last Call announcement, a Working Group publishes revisions that generally include substantive changes. Between any two steps after a Last Call announcement, the Working Group MAY publish a new draft of the technical report at the same maturity level provided there are no substantive changes since the earlier step.

The Team MUST notify the Advisory Committee and other W3C groups of a revision to a Candidate Recommendation or Proposed Recommendation.

These steps of the Recommendation Track process can take considerable time, so participants are encouraged to read the tips on getting to Recommendation faster [PUB27].

Refer to "How to Organize a Recommendation Track Transition" in the Member guide for practical information about preparing for the reviews and announcements of the various steps.

7.4.1 First Public Working Draft

Document maturity level: Working Draft.

Announcement: The Director MUST announce the first Working Draft publication to other W3C groups and to the public.

Purpose: The publication of the First Public Working Draft is a signal to the community to begin reviewing the document. See section 4.1 of the W3C Patent Policy [PUB33] for information about the policy implications of the First Public Working Draft.

Entrance criteria: The Chair MUST record the group's decision to request advancement. Since this is the first time that a document with this short name appears in the Technical Reports index, Director approval is REQUIRED for the transition.

Ongoing work: After publication of the First Public Working Draft, the Working Group generally revises the technical report (see the Working Group "Heartbeat" Requirement) in accordance with its charter.

In order to make Working Drafts available to a wide audience early in their development, the requirements for publication of a Working Draft are limited to an agreement by a chartered Working Group to publish the technical report and satisfaction of the Team's Publication Rules [PUB31]. Consensus is not a prerequisite for approval to publish; the Working Group MAY request publication of a Working Draft even if it is unstable and does not meet all Working Group requirements.

Working Groups SHOULD encourage early and wide review of the technical report, within and outside of W3C, especially from other Working Groups with dependencies on the technical report. Advisory Committee representatives SHOULD encourage review within their organizations as early as First Public Working Draft, i.e., before a Last Call announcement and well before a Call for Review of a Proposed Recommendation.

The Working Group SHOULD be responsive to and facilitate ongoing review by addressing issues in a timely manner and clearly indicating changes between drafts (e.g., by providing "diffs" and summaries of substantive changes).

Possible next steps:

7.4.2 Last Call Announcement

Document maturity level: Working Draft.

Announcement: The Working Group MUST announce the Last Call to other W3C groups and to the public. A Last Call announcement MUST:

  1. specify the deadline for review comments;
  2. identify known dependencies and solicit review from all dependent Working Groups;
  3. solicit public review.

Purpose: A Working Group's Last Call announcement is a signal that:

In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels.

A Working Group SHOULD work with other groups prior to a Last Call announcement to reduce the risk of surprise at Last Call.

Ideally, after a Last Call announcement, a Working Group receives only indications of support for the document, with no proposals for substantive change. In practice, Last Call announcements generate comments that sometimes result in substantive changes to a document. A Working Group SHOULD NOT assume that it has finished its work by virtue of issuing a Last Call announcement.

Entrance criteria: Before announcing a Last Call, the Working Group MUST do all of the following:

  1. Record the group's decision to request advancement.
  2. Fulfill the relevant requirements of the Working Group charter and those of any accompanying requirements documents, or report which relevant requirements have not been fulfilled.
  3. Indicate which dependencies with other groups the Working Group believes it has satisfied, and report which dependencies have not been satisfied.

Duration of the review: The announcement begins a review period that SHOULD last at least three weeks but MAY last longer if the technical report is complex or has significant external dependencies.

Ongoing work: During the review period, the Working Group solicits and responds to comments from the Team, the Members, other W3C groups, and the public.

It is important to ensure the proper integration of a technical report in the international community. Starting at this step in the Recommendation process, the technical report SHOULD include a statement about how the technology relates to existing international standards and to related work outside of W3C.

Possible next steps:

7.4.3 Call for Implementations

Document maturity level: Candidate Recommendation.

Announcement: The Director MUST announce the Call for Implementations to the Advisory Committee.

Purpose: At this step, W3C believes the technical report is stable and appropriate for implementation. The technical report MAY still change based on implementation experience.

Entrance criteria: The Director calls for implementation when satisfied that the Working Group has fulfilled the general requirements for advancement.

The Working Group is NOT REQUIRED to show that a technical report has two independent and interoperable implementations as part of a request to the Director to announce a Call for Implementations. However, the Working Group SHOULD include a report of present and expected implementations as part of the request.

In the Call for Implementations, the Working Group MAY identify specific features of the technical report as being "features at risk." General statements such as "We plan to remove any unimplemented feature" are not acceptable; the Working Group MUST precisely identify any features at risk. Thus, in response to a Call for Implementations, reviewers can indicate whether they would formally object to the removal of the identified features.

After gathering implementation experience, the Working Group MAY remove features from the technical report that were identified as being "at risk" and request that the Director Call for Review of a Proposed Recommendation. If the Working Group makes other substantive changes to the technical report, the Director MUST return it to the Working Group for further work.

The request to the Director to advance a technical report to Candidate Recommendation MUST indicate whether the Working Group expects to satisfy any Proposed Recommendation entrance criteria beyond the default requirements (described below).

Advisory Committee representatives MAY appeal the decision to advance the technical report.

Duration of the implementation period: The announcement MUST indicate a minimal duration, before which the Working Group MUST NOT request a Call for Review of a Proposed Recommendation; this minimal duration is designed to allow time for comment. The announcement SHOULD also include the Working Group's estimate of the time expected to gather sufficient implementation data.

Possible next steps:

7.4.4 Call for Review of a Proposed Recommendation

Document maturity level: Proposed Recommendation.

Announcement: The Director MUST announce the Call for Review to the Advisory Committee.

Purpose: At this step, W3C seeks endorsement of the stable technical report. The outcome of this review is taken as an indication of the organization's support for the technical report.

Entrance criteria: The Director calls for review when satisfied that the Working Group has:

  1. Fulfilled the general requirements for advancement;
  2. Shown that each feature of the technical report has been implemented. Preferably, the Working Group SHOULD be able to demonstrate two interoperable implementations of each feature. If the Director believes that immediate Advisory Committee review is critical to the success of a technical report, the Director MAY accept to Call for Review of a Proposed Recommendation even without adequate implementation experience;
  3. Satisfied any other announced entrance criteria (e.g., any included in the request to advance to Candidate Recommendation, or announced at Last Call if the Working Group does not intend to issue a Call for Implementations).

Advisory Committee representatives MAY appeal the decision to advance the technical report.

Duration of the review: The announcement begins a review period that MUST last at least four weeks.

Ongoing work: During the review period, the Working Group requests endorsement and support from Members (e.g., testimonials as part of a press release).

Possible next steps:

7.4.5 Publication of a W3C Recommendation

Document maturity level: Recommendation.

Announcement: The Director MUST announce the publication of a W3C Recommendation to the Advisory Committee.

Purpose: W3C publishes Recommendations when it believes that the ideas in the technical report are appropriate for widespread deployment and that they promote W3C's mission.

Entrance criteria: The Director publishes a W3C Recommendation when satisfied that there is significant support for the technical report from the Advisory Committee, the Team, W3C Working Groups, and the public. The decision to advance a document to Recommendation is a W3C decision.

If there was any dissent during the Member review, Advisory Committee representatives MAY appeal the decision to publish the Recommendation.

Possible next steps:

The Director MAY submit a W3C Recommendation to another standards body for adoption and formal approval by that body.

7.4.6 Returning a Document to a Working Group for Further Work

A technical report is returned to a Working Group for further work in either of the following situations:

  1. The Working Group makes substantive changes to the technical report at any time after a Last Call announcement and prior to Publication as a Recommendation, except when the changes involve the removal of features at risk identified in a Call for Implementations. In the case of substantive changes, the Working Group MUST republish the technical report as a Working Draft.
  2. The Director requires the Working Group to address important issues raised during a review or as the result of implementation experience. In this case, Director MAY request that the Working Group republish the technical report as a Working Draft, even if the Working Group has not made substantive changes.

The Director MUST inform the Advisory Committee and group Chairs when a technical report has been returned to a Working Group for further work.

After republication as a Working Draft, the next forward step available to the Working Group is a Last Call announcement. The Last Call announcement MAY occur at the same time as the publication of the Working Draft.

The Director MAY ask the Working Group to republish a technical report as a Candidate Recommendation. At the same time as publication, the Director issues a Call for Implementations.

7.5 Ending Work on a Technical Report

Work on a technical report MAY cease at any time. When a Working Group completes its work on a technical report, it publishes it either as a Recommendation or a Working Group Note. For example, a Working Group might publish several Working Drafts of a requirements document, and then indicate that it no longer plans to work on the requirements document by publishing a Working Group Note.

Work MAY also cease because W3C determines that it cannot productively carry the work any further. For instance, the Director might close a Working Group, the participants might lose interest in a technical report, or the ideas might be subsumed by another technical report. If W3C decides to discontinue work on a technical report before completion, the technical report SHOULD be published as a Working Group Note.

Possible next steps:

7.6 Modifying a W3C Recommendation

W3C makes every effort to maintain its Recommendations (e.g., by tracking errata, providing test-bed applications, and helping to create test suites) and to encourage widespread implementation. The following sections discuss the management of errors and the process for making normative changes to a Recommendation.

7.6.1 Errata Management

Tracking errors is an important part of a Working Group's ongoing care of a Recommendation; 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 class of mistake, from mere editorial to a serious error that may affect the conformance with the Recommendation by software or content (e.g., content validity). Note: Before a document becomes a Recommendation, the W3C Process focuses on substantive changes (those related to prior reviews). After a document has been published as Recommendation, the W3C Process focuses on those changes to a technical report that might affect the conformance of content or deployed software.

Working Groups MUST track errata on an "errata page." An errata page is a list of enumerated errors, possibly accompanied by corrections. Each Recommendation links to an errata page; see the Team's Publication Rules.

A correction is first "proposed" by the Working Group. A correction becomes normative -- of equal status as the text in the published Recommendation -- through one of the processes described below. An errata page MAY include both proposed and normative corrections. The Working Group MUST clearly identify which corrections are proposed and which are normative.

A Working Group SHOULD keep their errata pages up-to-date, as errors are reported by readers and implementers. A Working Group MUST report errata page changes to interested parties, notably when corrections are proposed or become normative, according to the Team's requirements. For instance, the Team might set up a mailing list per Recommendation where a Working Group reports changes to an errata page.

7.6.2 Classes of Changes to a Recommendation

This document distinguishes the following classes of changes to a Recommendation.

1. No changes to text content
These changes include fixing broken links or invalid markup.
2. Corrections that do not affect conformance
Editorial changes or clarifications that do not change the technical content of the specification.
3. Corrections that MAY affect conformance, but add no new features
These changes MAY affect conformance to the Recommendation. A change that affects conformance is one that:
  1. turns conforming data, processors, or other conforming agents into non-conforming agents, or
  2. turns non-conforming agents into conforming ones, or
  3. clears up an ambiguity or under-specified part of the specification in such a way that an agent whose conformance was once unclear becomes clearly conforming or non-conforming.
4. New features
For new features, W3C follows the full process of advancing a technical report to Recommendation.

The first two classes of change require no technical review of the proposed changes, although a Working Group MAY issue a Call for Review. The modified Recommendation is published according to the Team's requirements, including Publication Rules [PUB31].

For the third class of change, W3C requires:

  1. Review by the community to ensure the technical soundness of proposed corrections.
  2. Timely publication of the edited Recommendation, with corrections incorporated.

For the third class of change, the Working Group MUST either:

  1. Request that the Director issue a Call for Review of an Edited Recommendation, or
  2. Issue a Call for Review of Proposed Corrections that have not been incorporated into an edited draft (e.g., those listed on an errata page). After this review, the Director MAY announce that the proposed corrections are normative.

While the second approach is designed so that a Working Group can establish normative corrections quickly, it does not obviate the need to incorporate changes into an edited version of the Recommendation. In particular, when corrections are numerous or complex, integrating them into a single document is important for interoperability; readers might otherwise interpret the corrections differently.

7.6.3 Call for Review of an Edited Recommendation

Document maturity level: Proposed Edited Recommendation.

Announcement: The Director MUST announce the Call for Review to other W3C groups, the public, and the Advisory Committee. The announcement MUST clearly indicate that this is a proposal to edit a Recommendation and MUST:

  1. specify the deadline for review comments;
  2. identify known dependencies and solicit review from all dependent Working Groups;
  3. solicit public review.

Purpose: At this step, W3C seeks confirmation of proposed corrections to a Recommendation.

Entrance criteria: The Director calls for review when satisfied that, with respect to changes to the document, the Working Group has fulfilled the same entrance criteria as for a Call for Review of a Proposed Recommendation (e.g., the Working Group can show implementation experience that supports the changes). In the request to advance to this status, the Working Group MUST report any substantive issues about the technical report that have not been resolved.

Advisory Committee representatives MAY appeal the decision to advance the technical report.

Duration of the review: The announcement begins a formal Advisory Committee review period that MUST last at least four weeks.

Ongoing work: During the review period, the Working Group solicits and responds to comments from the Team, the Members, other W3C groups, and the public.

Possible next steps:

7.6.4 Call for Review of Proposed Corrections

Document maturity level: A Recommendation, plus a list of proposed corrections. The Working Group SHOULD also include a detailed description of how the Working Group plans to change the text of the Recommendation for each proposed correction.

Announcement: The Working Group MUST announce the Call for Review to other W3C groups, the public, and the Advisory Committee. This is not a formal Advisory Committee review. However, the announcement MUST clearly indicate that this is a proposal to make normative corrections to the Recommendation and MUST:

  1. specify the deadline for review comments;
  2. identify known dependencies and solicit review from all dependent Working Groups;
  3. solicit public review.

Purpose: At this step, W3C seeks confirmation of proposed corrections to a Recommendation.

Entrance criteria: The Working Group calls for review when, with respect to changes to the document, the group has fulfilled the same entrance criteria as for a Call for Review of a Proposed Recommendation.

Duration of the review: The announcement begins a review period that MUST last at least four weeks.

Ongoing work: Same as for a Proposed Edited Recommendation.

If there are no formal objections to the proposed corrections, W3C considers them normative. The Working Group MUST report formal objections to the Director, who assesses whether there is sufficient consensus to declare the proposed corrections to be normative.

Possible next steps:

7.7 Rescinding a W3C Recommendation

At times, W3C MAY rescind an entire Recommendation, for instance when W3C learns of significant errors in the Recommendation, when the Recommendation becomes outdated, or if W3C discovers burdensome patent claims that affect implementers; see the W3C Patent Policy [PUB33] and in particular section 5 (bullet 10) and section 7.5.

To deprecate part of a Recommendation, W3C follows the process for modifying a Recommendation.

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

7.7.1 Proposal to Rescind a Recommendation

Document maturity level: Recommendation, plus separate rationale for the proposal to rescind.

Announcement: The Director MUST announce the Proposal to Rescind a Recommendation to other W3C groups, the public, and the Advisory Committee. The announcement MUST clearly indicate that this is a Proposal to Rescind a Recommendation and MUST:

  1. specify the deadline for review comments;
  2. identify known dependencies and solicit review from all dependent Working Groups;
  3. solicit public review.

Purpose: At this step, W3C seeks confirmation of a Proposal to Rescind a Recommendation.

Entrance criteria: The Director proposes that W3C rescind a Recommendation when satisfied that there is sufficient reason.

Advisory Committee representatives MAY appeal the Proposal to Rescind the Recommendation.

Duration of the review: The announcement begins a review period that MUST last at least four weeks.

Ongoing work: During the review period, the Working Group solicits and responds to comments from the Team, the Members, other W3C groups, and the public.

Possible next steps:

7.7.2 Publication of a Rescinded Recommendation

Document maturity level: Rescinded Recommendation.

Announcement: The Director MUST announce the Publication of a Rescinded Recommendation to the Advisory Committee.

Purpose: At this step, W3C indicates that it no longer endorses a previously published Recommendation.

Entrance criteria: The Director publishes a Rescinded Recommendation when satisfied that there is significant support from the Advisory Committee, the Team, W3C Working Groups, and the public. The decision to advance a document to Rescinded Recommendation is a W3C decision.

The Team MAY publish one or more documents in order to best communicate what has been rescinded and its relation to previous Recommendations (e.g., the publication can be as simple as a cover sheet that refers to a previously published Recommendation).

If there was any dissent in the Proposed Rescinded Recommendation reviews, Advisory Committee representatives MAY appeal the decision to rescind the Recommendation.

Possible next step:

7.8 General Information about Technical Reports

Every document published as part of the Recommendation Track process MUST be a public document. The index of W3C technical reports [PUB11] is available at the W3C Web site. W3C will make every effort to make archival documents indefinitely available at their original address in their original form.

Every document published as part of the Recommendation Track process MUST clearly indicate its maturity level.

Every technical report published as part of the Recommendation Track process is edited by one or more editors appointed by a Working 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 for the TAG or Advisory Board who is not an elected or appointed participant in that group MUST fulfill the same participation requirements for that group, as a Member representative, Team representative, or Invited Expert. All other W3C Editors MUST be participants in the group responsible for the document(s) they are editing. Note that an Editor is NOT REQUIRED to be a Team representative.

The Team is NOT REQUIRED to publish a technical report that does not conform to the Team's Publication Rules (e.g., for naming, style, and copyright requirements). These rules are subject to change. The Team MUST inform group Chairs and the Advisory Board of any changes.

The Team reserves the right to reformat technical reports at any time so as to conform to changes in W3C practice (e.g., changes to technical report styles or the document status section).

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

7.8.1 Document Status Section

Each technical report MUST include a section about the status of the document. The status section SHOULD explain why W3C has published the technical report, expectations about next steps, who developed it, where to send comments about it, whether implementation experience is being sought, any significant changes from the previous version, why work on the technical report has ceased or been subsumed, and any other relevant information or rationale.

The Team's Publication Rules include status section requirements for each maturity level.

8 Advisory Committee Reviews, Appeals, and Votes

This section describes how the Advisory Committee reviews proposals from the Director and how Advisory Committee representatives appeal W3C decisions and decisions by the Director. A W3C decision is one where the Director (or the Director's delegate) has exercised the role of assessing consensus after an Advisory Committee review of an Activity Proposal, after a Call for Review of a Proposed Recommendation, after a Call for Review of a Proposed Recommendation, after a Proposal to Rescind a W3C Recommendation, and after a Proposed Process Document review.

8.1 Advisory Committee Reviews

The Advisory Committee reviews:

8.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 review form 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; this is the default channel for reviews.
  2. an archived Member-only channel.

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

8.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 documented objections, with attention to changing confidentiality level. This W3C decision is generally one of the following:

  1. The proposal is approved, possibly with minor 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 Proposed Recommendation review period. If, after three weeks, the Director has not announced the outcome, the Director SHOULD provide the Advisory Committee with an update.

8.2 Appeal by Advisory Committee Representatives

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

When Advisory Committee review immediately precedes a decision, Advisory Committee representatives MAY only appeal when there is dissent. These decisions are:

Advisory Committee representatives MAY always appeal the following decisions:

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 (explained in detail in the New Member Orientation). The Team MUST announce the appeal process to the Advisory Committee and provide an address for comments from Advisory Committee representatives. The archive of these comments MUST be Member-visible. 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 to approve or reject the decision.

8.3 Advisory Committee Votes

The Advisory Committee votes in elections for seats on the TAG or Advisory Board, and in the event of a formal appeal of a W3C decision. 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".

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

Note: In general, W3C does not organize conferences. Currently, W3C presents its work to the public at the annual World Wide Web Conference, which is coordinated by the International World Wide Web Conference Committee (IW3C2).

10 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. Note: W3C is one party in a liaison; in the remainder of this document, the term "Partner" refers to the other party.

The goals of formal liaison process described in this section are to:

  1. Enable both organizations to pursue related goals (e.g., technical specifications) to their mutual benefit.
  2. Facilitate development of complementary technologies, possibly resolving mutual dependencies.
  3. Document the commitment from both organizations, in resources and principle, to pursuing work in a particular area.
  4. Coordinate communication about the focus of the liaison.
  5. Allow synchronization of schedules and calendars.
  6. Ensure that technical progress can be made in a manner consistent with W3C's Patent Policy [PUB33], W3C Document License [PUB18], and other IPR policies.
  7. Prevent market fragmentation.
  8. Provide for specific benefits (such as mutual membership) enumerated in the liaison charter.

This process is minimally constraining since, in practice, liaisons take a variety of forms (e.g., the liaison involves W3C process more than the Partner's process or vice-versa). The process consists of:

  1. Liaison creation and modification
  2. Liaison charters
  3. Liaison status reports

Liaisons -- formal or informal -- 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 and sign a Memorandum of Understanding (MoU) with another organization. However, before doing so, the Team MUST announce the intention to sign to the Advisory Committee, who MAY appeal. A Memorandum of Understanding MUST be made available to Members and SHOULD be made public after approval.

A list of W3C liaisons with other organizations [PUB28] is available on the Web.

10.1 Formal Liaison Creation and Modification

The Director creates, modifies, or extends a formal liaison by announcement to the Advisory Committee. The announcement MUST include a reference to the liaison charter. Advisory Committee representatives MAY appeal the creation, modification, or extension of a liaison.

Liaisons are not meant to substitute for W3C membership. The formal liaison process is meant to improve coordination with similar (membership) organizations. If an organization wishes to participate in W3C work, that organization SHOULD join W3C.

10.1.1 Considerations in the Decision to Create a Formal Liaison

W3C's decision to pursue a liaison with a Partner is ultimately based on the perceived costs and benefits to W3C. Important considerations include:

  1. Will both organizations make available to each other all information pertinent to the joint effort?
  2. Will both organizations ensure public distribution of intermediate and final versions of technical reports?
  3. Will both organizations respect the confidentiality of sensitive information? Willingness by both parties to protect such information fosters trust and may allow Working Groups to get work done more quickly. However, those involved should not lose sight of the ultimate goal of open and public specifications.
  4. Will both organizations disclose any patent, copyright, and other IPR claims related to the joint effort? What happens when the Partner does not share the same IPR policies as W3C? When it's more strict or more loose? Is disclosure the minimum? How will the organization address patents as part of filling out the charter?
  5. Will both organizations coordinate all public statements and press releases related to the joint effort?
  6. Will both organizations encourage peer review at appropriate/documented milestones so as to ensure compatibility? Agree to negotiate changes deemed necessary by reviewers? Agree to solicit and respond to comments made during periods of public review?
  7. Will both organizations reach decisions by consensus and document objections when consensus is not possible?
  8. Will Members of both organizations commit to representing the parent organizations in work related to the joint effort?
  9. What copyright and distribution policies will govern deliverables? Will the publications be available according to the W3C Document License [PUB18]? Will software be available according to the W3C Software Notice and License [PUB19]?

Reasons not to pursue a liaison with another organization include:

  1. Does the other organization have selective or arbitrary membership policies that serve only to benefit pre-existing or dominant members?

10.2 Formal Liaison Charters

Each formal liaison has a public charter that MUST include all of the following information.

The organizations
The goals of the liaison
Process and policies
Resources
Schedule

10.3 Formal Liaison Status Reports

At least at each Advisory Committee meeting, the Team MUST present an update of each formal liaison that describes the state of the liaison, goals achieved or not, and deliverables produced or not. The update SHOULD highlight significant changes, successes, and failures since the previous update. The Team SHOULD also keep the Advisory Board regularly informed (e.g., once per quarter) of important events or changes regarding liaisons.

11 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 publish the material 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 publishes review comments on the Submitted materials 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 Submitter(s).

The Submission process consists of the following steps:

  1. One of the Submitter(s) 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:

Publication of a Member Submission by W3C 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 published by W3C MUST NOT be referred to as "work in progress" of the W3C.

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

11.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"). 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 publish the documents in the Member Submission 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 part of a W3C Activity.

11.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 an Activity Proposal or 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 [PUB15].

11.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 [PUB18] 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 of section 3.3 of the W3C Patent Policy [PUB33].

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" [MEM8].

11.2 Team Rights and Obligations

Although they are not technical reports, the documents in a Member Submission MUST fulfill the requirements established by the Team, including the Team's Publication Rules.

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.

11.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 published as the result of acknowledgment, the Submitter(s) MUST start the Submission process from the beginning, even just to correct editorial changes.

11.4 Rejection of a Submission Request

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 appeal the rejection 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.

12 Process Evolution

The W3C Process Document undergoes similar consensus-building processes as documents that are part of the Recommendation Track process, with the Advisory Board acting as the sponsoring Working Group.

The Advisory Board initiates review of a Process Document as follows:

  1. The Chair of the Advisory Board 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 of a Proposed Process Document. The review period MUST last at least four weeks.
  3. After the Advisory Committee review, if there is consensus, the Team enacts the new process officially by announcing the W3C decision to the Advisory Committee. If there was dissent, Advisory Committee representatives MAY appeal the decision.

W3C MAY also modify a Process Document by following the processes for modifying a Recommendation.

Reviews of the Process Document are not public reviews.

13 References

13.1 Public Resources

The following public information is available at the W3C Web site.

[PUB5]
How to Join W3C
[PUB6]
Membership Agreement
[PUB8]
The list of current W3C Members
[PUB9]
The list of W3C Activities
[PUB10]
The list of acknowledged Member Submissions
[PUB11]
The W3C technical reports index
[PUB12]
Public list of Activity Proposals. In this version of the Process Document, there is no public reference to the list of Activity Proposals.
[PUB13]
Submission request overview
[PUB14]
The W3C Team
[PUB15]
About the W3C includes the W3C mission statement some background information about W3C, and additional information about W3C Activities and organization.
[PUB16]
The list of published Team Submissions
[PUB17]
Invited expert and collaborators agreement
[PUB18]
W3C Document License
[PUB19]
W3C Software Notice and License
[PUB20]
Translations of W3C technical reports
[PUB21]
Public W3C mailing lists
[PUB23]
Conflict of Interest Policy for W3C Team Members Engaged in Outside Professional Activities
[PUB25]
Technical Architecture Group (TAG) Charter
[PUB26]
The TAG home page
[PUB27]
Tips for Getting to Recommendation Faster
[PUB28]
W3C liaisons with other organizations
[PUB30]
The Advisory Board home page
[PUB31]
Publication Rules
[PUB32]
W3C Fellows Program
[PUB33]
5 Feb 2004 version of the W3C Patent Policy. The latest version of the W3C Patent Policy is available at http://www.w3.org/Consortium/Patent-Policy/.

13.2 Member-only Resources

The following Member-only information is available at the W3C Web site.

[MEM1]
Current Advisory Committee representatives
[MEM2]
Group mailing lists
[MEM3]
The calendar of all scheduled official W3C events
[MEM4]
The New Member Orientation, which includes an introduction to W3C processes from a practical standpoint, including relevant email addresses.
[MEM5]
Advisory Committee meetings
[MEM6]
Member Web site
[MEM8]
How to send a Submission request
[MEM9]
The Art of Consensus, a guidebook for W3C Working Group Chairs and other collaborators
[MEM14]
Guidelines for Disciplinary Action
[MEM15]
How to Organize an Advisory Board or TAG election

13.3 Other References

[RFC2119]
"Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997.
[RFC2777]
"Publicly Verifiable Nomcom Random Selection", D. Eastlake 3rd, February 2000.

14 Acknowledgments

The following individuals participated in the preparation of this document while serving (at different times) on the W3C Advisory Board: Ann Bassetti (The Boeing Company), Jim Bell (Hewlett-Packard), Carl Cargill (Sun Microsystems), Paul Cotton (Microsoft), Don Deutsch (Oracle), David Fallside (IBM), Paul Grosso (Arbortext), Steve Holbrook (IBM), Renato Iannella (IPR Systems), Ken Laskey (MITRE), Ora Lassila (Nokia), Håkon Wium Lie (Opera Software), Larry Masinter (Adobe Systems), Bede McCall (MITRE), Thomas Reardon (Microsoft), David Singer (IBM), Lauren Wood, and Steve Zilles (Adobe Systems). Jean-François Abramatic was the W3C Chair and Chair of the Advisory Board.

Early drafts of the W3C Process Document were prepared by a special Process Working Group. The Working Group was elected by the Advisory Committee representatives on 16 September 1996 and closed in November 1997. The following individuals participated in the Process Working Group (with their affiliations at that time): Carl Cargill (Netscape), Wendy Fong (Hewlett-Packard), John Klensin (MCI), Tim Krauskopf (Spyglass), Kari Laihonen (Ericsson), Thomas Reardon (Microsoft), David Singer (IBM), and Steve Zilles (Adobe). The Team members involved in the Process Working Group were: Jean-François Abramatic, Tim Berners-Lee, Ian Jacobs, and Sally Khudairi.

Thanks also to Don Brutzman (Web3D) for his help drafting the liaison process.

[contents]