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 theconsensus of the Membership, Team, and public. W3C processes promote fairness, responsiveness, and progress: all facets of the W3C mission. This document describes the processes W3C follows in pursuit of its mission.

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

1. People generate interest in a particular topic. For instance, Members express interest in the form ofMember Submissions, and theTeam monitors work inside and outside of W3C for signs of interest. Also, W3C is likely to organize aWorkshop to bring people together to discuss topics that interest the W3C community.
2. When there is enough interest in a topic (e.g., after a successful Workshop and/or discussion on anAdvisory Committee mailing list), the Director announces the development of a proposal for one or more newInterest Group or Working Group charters, depending on the breadth of the topic of interest. W3C Membersreview the proposed charters. When there is support within W3C for investing resources in the topic of interest, the Director approves the group(s) and they begin their work.
3. There are three types of Working Group participants:Member representatives,Invited Experts, andTeam representatives. Team representatives both contribute to the technical work and help ensure the group's proper integration with the rest of W3C. TheWorking 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 theyadvance 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 aRecommendation.

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

The other sections of the Process Document:

1. set forthpolicies for participation in W3C groups,
2. establish two permanent groups within W3C: theTechnical Architecture Group (TAG), to help resolve Consortium-wide technical issues; and theAdvisory Board (AB), to help resolve Consortium-wide non-technical issues, and to manage theevolution of the W3C process, and
3. describe other interactions between theMembers (as represented by theW3C 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. W3CMember organizations provide resources to this end, and the W3CTeam provides the technical leadership and organization to coordinate the effort.

2.1 Members

W3C Members are primarily represented in W3C processes as follows:

1. TheAdvisory Committee is composed of one representative from each Member organization (refer to theMember-only list ofcurrent Advisory Committee representatives [MEM1]). The Advisory Committee:
   • reviews plans for W3C at eachAdvisory Committee meeting;
   • reviews formal proposals from the W3C Director:Charter Proposals,Proposed Recommendations, andProposed Process Documents.
   • elects theAdvisory Board participants other than the Advisory Board Chair.
   • elects 5 of the 9 participants on theTechnical Architecture Group.
   Advisory Committee representativesmay initiate anAdvisory Committee Appeal in some cases described in this document.
2. Representatives of Member organizations participate inWorking Groups and Interest Groups and author and reviewtechnical reports.

W3C membership is open to all entities, as described in "How to Join W3C" [PUB5]; (refer to the public list ofcurrent W3C Members [PUB8]). Organizations subscribe according to theMembership Agreement [PUB6]. TheTeammust ensure that Member participation agreements remainTeam-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 individualmay join W3C as an Affiliate Member. In this case the same restrictions pertaining torelated Members apply when the individual alsorepresents another W3C Member.

2.1.1 Rights of Members

Each Member organization enjoys the following rights and benefits:

• A seat on theAdvisory Committee;
• Access toMember-only information;
• TheMember Submission process;
• Use of the W3C Member logo on promotional material and to publicize the Member's participation in W3C. For more information, please refer to the Member logo usage policy described in theNew Member Orientation [MEM4].

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

• InWorking Groups and Interest Groups.
• InWorkshops and Symposia;
• On the Team, asW3C Fellows.

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 Directormay take disciplinary action. Arbitration in the case of further disagreement is governed by paragraph 19 of the Membership Agreement. Refer to theGuidelines for Disciplinary Action [MEM14].

2.1.2 Membership Consortia and related Members

2.1.2.1 Membership Consortia

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

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

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

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

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

2.1.2.2 Related Members

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

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

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

Related Membersmust disclose these relationships according to the mechanisms described in theNew Member Orientation [MEM4].

2.1.3 Advisory Committee (AC)

When an organization joins W3C (see "How to Join W3C" [PUB5]), itmust name its Advisory Committee representative as part of the Membership Agreement. TheNew 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 representativesmust follow theconflict 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 theW3C Patent Policy [PUB33].

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

2.1.3.1 Advisory Committee Mailing Lists

The Teammust 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 Teammust monitor discussion andshould participate in discussion when appropriate. Ongoing detailed discussionsshould be moved to other appropriate lists (new or existing, such as a mailing list created for aWorkshop).

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

2.1.3.2 Advisory Committee Meetings

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

Resources

• The number of W3C Members at each level.
• An overview of the financial status of W3C.

Allocations

• The allocation of the annual budget, including size of the Team and their approximate deployment.
• A list of all activities (including but not limited to Working and Interest Groups) and brief status statement about each, in particular those started or terminated since the previous Advisory Committee meeting.
• The allocation of resources to pursuingliaisons with other organizations.

Each Member organizationshould send onerepresentative to each Advisory Committee Meeting. In exceptional circumstances (e.g., during a period of transition between representatives from an organization), the meeting Chairmay allow a Member organization to send two representatives to a meeting.

The Teammust 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 Teammust announce the region of each Advisory Committee meeting at leastone year in advance.

More information aboutAdvisory Committee meetings [MEM5] is available at the Member Web site.

2.2 The W3C Team

The Team consists of the Director, CEO, W3C paid staff, unpaid interns, and W3C Fellows.W3C Fellows are Member employees working as part of the Team; see theW3C 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 Director and CEOmay delegate responsibility (generally to other individuals in the Team) for any of their roles described in this document.

TheDirector is the lead technical architect at W3C. His responsibilities are identified throughout this document in relevant places. Some key ones include: assessingconsensus within W3C for architectural choices, publication oftechnical reports, and chartering new Groups; appointing groupChairs; adjudicating as "tie-breaker" forGroup decision appeals and deciding on the outcome of formal objections; the Director is generally Chair of theTAG.

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

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

2.2.1 Team Submissions

Team membersmay 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 toMember Submissions (e.g., inexpected scope). However, there is no additional Team comment. Thedocument status section of a Team Submission indicates the level of Team consensus about the published material.

Team Submissions arenot part of thetechnical report development process.

The list ofpublished 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 theevolution of the Process Document. The Advisory Board hears aSubmission Appeal when a Member Submission is rejected for reasons unrelated to Web architecture; see also theTAG.

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

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

The Advisory Boardshould send a summary of each of its meetings to the Advisory Committee and other group Chairs. The Advisory Boardshould also report on its activities at eachAdvisory 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 theAdvisory 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 theAdvisory Board, who is generally the CEO.

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

With the exception of the Chair, the terms of all Advisory Board participants are fortwo 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 aSubmission Appeal when a Member Submission is rejected for reasons related to Web architecture; see also theAdvisory Board.

The TAG's scope is limited to technical issues about Web architecture. The TAGshould 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 theTAG charter [PUB25] for more information about the background and scope of the TAG, and the expected qualifications of TAG participants.

The Teammust make available two mailing lists for the TAG:

• a public discussion (not just input) list for issues of Web architecture. The TAG will conduct its public business on this list.
• aMember-only list for discussions within the TAG and for requests to the TAG that, for whatever reason, cannot be made on the public list.

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

The TAGshould send a summary of each of itsmeetings to the Advisory Committee and other group Chairs. The TAGshould also report on its activities at eachAdvisory 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 onvoting in the TAG charter [PUB25] and the general section onvotes 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 theTAG 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 theDirector.

Three TAG participants are appointed by the Director. Appointees arenot required to be on the W3C Team. The Directormay appointW3C Fellows to the TAG.

The remaining five TAG participants are elected by the W3C Advisory Committee following theAB/TAG nomination and election process.

With the exception of the Chair, the terms of all TAG participants are fortwo 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. Advisory Board and TAG participantsshould attendAdvisory 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 isvacated. 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 theAB/TAG nomination and election process). See also the licensing obligations on TAG participants insection 3 of theW3C Patent Policy [PUB33], and the claim exclusion process ofsection 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:

• A Member organization is permitted at most one participant on the TAG except when having more than one participant is caused by a change of affiliation of an existing participant. At the completion of the next regularly scheduled election for the TAG, the Member organizationmust have returned to having at most one participant.
• A Member organization is permitted at most one participant on the AB.
• An individualmust not participate on both the TAG and the AB.

If, for whatever reason, these constraints are not satisfied (e.g., because an AB participant changes jobs), one participantmust cease AB participation until the situation has been resolved. If after30 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, theverifiable 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, using a Single Transferable Vote system. An election begins when the Team sends a Call for Nominations to the Advisory Committee. Any Call for Nominations specifies the number of available seats, the deadline for nominations, details about the specific vote tabulation system selected by the Team for the election, and operational information such as how to nominate a candidate. The Teammay modify the tabulation system after the Call for Nominations butmust stabilize it no later than the Call for Votes. The Directorshould announce appointments no later than the start of a nomination period as part of the Call for Nominations.

Each Member (or group ofrelated Members)may nominate one individual. A nominationmust be made with the consent of the nominee. In order for an individual to be nominated as a Member representative, the individualmust qualify forMember representation and the Member's Advisory Committee representativemust 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 individualmust provide the (same)information required for an Invited Expert in a Working Group and the nominating Advisory Committee representativemust include that information in the nomination. In order for an individual to be nominated as a Team representative, the nominating Advisory Committee representativemust first secure approval from Team management. A nominee isnot required to be an employee of a Member organization, andmay be aW3C Fellow. Each nominationshould include a few informative paragraphs about the nominee.

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

• Equal to the number of available seats, those nominees are thereby elected. This situation constitutes a tie for the purposes of assigningshort terms.
• Less than the number of available seats, Calls for Nominations are issued until a sufficient number of people have been nominated. Those already nominated do not need to be renominated after a renewed call.
• Greater than the number of available seats, the Team issues a Call for Votes that includes the names of all candidates, the number of available seats, the deadline for votes, details about the vote tabulation system selected by the Team for the election, and operational information.

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

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

Refer toHow 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 inRFC 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 (less than N) seats. In this case, only the names of the N individuals who tied are provided as input to the procedure. The M seats are assigned in result order.
2. After all elected individuals have been identified, when N people are eligible for M (less than N) short terms. In this case, only the names of those N individuals are provided as input to the procedure. The short terms are assigned in result order.

2.5.3 Advisory Board and Technical Architecture Group Vacated Seats

An Advisory Board or TAG participant's seat is vacated when either of the following occurs:

• the participantresigns, or
• the Chair asks the participant toresign.

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

Vacated seats are filled according to this schedule:

• When an appointed TAG seat is vacated, the Directormay re-appoint someone immediately, but no later than the next regularly scheduled election.
• When an elected seat on either the AB or TAG is vacated, the seat is filled at the next regularly scheduled election for the group unless the group Chair requests that W3C hold an election before then (for instance, due to the group's workload). The group Chairshould not request an exceptional election if the next regularly scheduled election is fewer than three months away.

3 General Policies for W3C Groups

This section describes general policies for W3C groups regarding participation, meeting requirements, and decision-making. These policies apply toparticipants in the following groups:Advisory Committee,Advisory Board,TAG,Working Groups, andInterest 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 theW3C Code of Ethics and Professional Conduct [PUB38] and the participation requirements described insection 6 of theW3C Patent Policy [PUB33].

3.1.1 Conflict of Interest Policy

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

The ability of an individual to fulfill a role within a group without risking a conflict of interest depends on the individual's affiliations. When these affiliations change, the individual's assignment to the rolemust be evaluated. The rolemay be reassigned according to the appropriate process. For instance, the Directormay 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:

• Paid consulting for an organization whose activity is relevant to W3C, or any consulting compensated with equity (shares of stock, stock options, or other forms of corporate equity).
• A decision-making role/responsibility (such as participating on the Board) in other organizations relevant to W3C.
• A position on a publicly visible advisory body, even if no decision making authority is involved.

Individuals seeking assistance on these mattersshould contact the Team.

Team members are subject to theW3C 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 representativemay designate a non-employee to represent the Member. Non-employee Member representativesmust 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 aconflict of interest), theDirectormay decline to allow an individual designated by an Advisory Committee representative to participate in a group.

A group chartermay limit the number of individuals representing a W3C Member (or group ofrelated Members).

3.2 Meetings

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

W3C distinguishes two types of meetings:

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

A Chairmay invite an individual with a particular expertise to attend a meeting on an exceptional basis. This person is a meeting guest, not a groupparticipant. Meeting guests do not havevoting rights. It is the responsibility of the Chair to ensure that all meeting guests respect the charteredlevel of confidentiality and other group requirements.

Meeting announcementsshould 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:

^* 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). Decisionsmay be made during meetings (face-to-face ordistributed) as well as through email.Note: The Director, CEO, and COO have the role of assessing consensus within the Advisory Committee.

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

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

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

Where unanimity is not possible, a groupshould strive to make consensus decisions where there is significant support and few abstentions. The Process Document does not require a particular percentage of eligible participants to agree to a motion in order for a decision to be made. To avoid decisions where there is widespread apathy, (i.e., little support and many abstentions), groupsshould set minimum thresholds of active support before a decision can be recorded. The appropriate percentagemay vary depending on the size of the group and the nature of the decision. A chartermay 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 Chairmay record a decision where there is dissent (i.e., there is at least oneFormal Objection) so that the group can make progress (for example, to produce a deliverable in a timely manner). Dissenters cannot stop a group's work simply by saying that they cannot live with a decision. When the Chair believes that the Group has duly considered the legitimate concerns of dissenters as far as is possible and reasonable, the groupshould move on.

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

3.3.2 Recording and Reporting Formal Objections

In the W3C process, an individualmay register a Formal Objection to a decision. AFormal Objection to a group decision is one that the reviewer requests that the Director consider as part of evaluating the related decision (e.g., in response to arequest to advance a technical report).Note: In this document, the term "Formal Objection" is used to emphasize this process implication: Formal Objections receive Director consideration. The word "objection" used alone has ordinary English connotations.

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

A record of each Formal Objectionmust bepublicly available. A Call for Review (of a document) to the Advisory Committeemust identify any Formal Objections.

3.3.3 Formally Addressing an Issue

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

As a courtesy, both Chairs and reviewersshould set expectations for the schedule of responses and acknowledgments. The groupshould reply to a reviewer's initial comments in a timely manner. The groupshould 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, reviewersshould realize that their comments will carry less weight if not sent to the group in a timely manner.

Substantive responsesshould be recorded. The groupshould 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 Chairmay reopen a decision when presented with new information, including:

• additional technical information,
• comments by email from participants who were unable to attend a scheduled meeting,
• comments by email from meeting attendees who chose not to speak out during a meeting (e.g., so they could confer later with colleagues or for cultural reasons).

The Chairshould record that a decision has been reopened, andmust do so upon request from a group participant.

3.4 Votes

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

• an explanation of the issue being voted on;
• the decision to conduct a vote (e.g., a simple majority vote) to resolve the issue;
• the outcome of the vote;
• any Formal Objections.

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

• A Member or group ofrelated Members is considered a single organization.
• TheTeam is considered an organization.

Unless the charter states otherwise,Invited Expertsmay vote.

If a participant is unable to attend a vote, that individualmay authorize anyone at the meeting to act as aproxy. The absent participantmust 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 asubstitute for a participant.

A groupmay 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 groupmay 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 arenot required to state the reasons for their dissent, and the group isnot required to record individual votes.

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

Procedures forAdvisory Committee votes are described separately.

3.5 Appeal of a Chair's Decision

Groups resolve issues through dialog. Individuals who disagree strongly with a decisionshould register with the Chair anyFormal Objections (e.g., to a decision made as the result of avote).

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

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

Procedures forAdvisory Committee appeals are described separately.

3.6 Resignation from a Group

A W3C Member or Invited Expertmay resign from a group. On written notification from an Advisory Committee representative or Invited Expert to the team, the Member and their representatives or the Invited Expert will be deemed to have resigned from the relevant group. See section 4.2. of theW3C Patent Policy [PUB33] for information about obligations remaining after resignation from certain groups.

6 W3C Technical Report Development Process

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

• support multiple specification development methodologies
• maximizeconsensus about the content of stable technical reports
• ensure high technical and editorial quality
• promote consistency among specifications
• facilitate royalty-free, interoperable implementations of Web Standards, and
• earn endorsement by W3C and the broader community.

See also the licensing goals for W3C Recommendations insection 2 of theW3C Patent Policy [PUB33].

6.1 W3C Technical Reports

Please note thatpublishing as used in this document refers to producing a version which is listed as a W3C Technical Report on itsTechnical Reports page https://www.w3.org/TR.

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

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

Groups can also publish documents as W3C Notes, typically either to document information other than technical specifications, such as use cases motivating a specification and best practices for its use, or to clarify the status of work that is abandoned.

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

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

6.1.1 Recommendations and Notes

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

1. Publication of theFirst Public Working Draft,
2. Publication of zero or more revisedPublic Working Drafts.
3. Publication of aCandidate Recommendation.
4. Publication of aProposed Recommendation.
5. Publication as aW3C Recommendation.
6. Possibly, Publication as anEdited Recommendation

W3Cmayend work on a technical report at any time.

The Directormay decline a request to advance in maturity level, requiring a Working Group to conduct further work, andmay require the specification to return to a lowermaturity level. The Directormust inform theAdvisory Committee and Working Group Chairs when a Working Group's request for a specification to advance in maturity level is declined and the specification is returned to a Working Group for further work.

6.1.2 Maturity Levels

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. Some, but not all, Working Drafts are meant to advance to Recommendation; see thedocument status section of a Working Draft for the group's expectations. Any Working Draft not, or no longer, intended to advance to Recommendationshould be published as a Working Group Note. Working Drafts do not necessarily represent a consensus of the Working Group, and do not imply any endorsement by W3C or its members beyond agreement to work on a general area of technology.

Candidate Recommendation (CR)

A Candidate Recommendation is a document that satisfies the Working Group's technical requirements, and has already received wide review. W3C publishes a Candidate Recommendation to

• signal to the wider community that it is time to do a final review
• gatherimplementation experience
• begin formal review by the Advisory Committee, whomay recommend that the document be published as a W3C Recommendation, returned to the Working Group for further work, or abandoned.
• Provide an exclusion opportunity per theW3C Patent Policy [PUB33].Note: A Candidate Recommendation under this process corresponds to the "Last Call Working Draft" discussed in the Patent Policy.

Note: Candidate Recommendations are expected to be acceptable as Recommendations. Announcement of a different next stepshould include the reasons why the change in expectations comes at so late a stage.

Proposed Recommendation

A Proposed Recommendation is a document that has been accepted by the W3C Director as of sufficient quality to become a W3C Recommendation. This phase establishes a deadline for the Advisory Committee review that begins with Candidate Recommendation. Substantive changesmust not be made to a Proposed Recommendation except by publishing a new Working Draft or Candidate Recommendation.

W3C Recommendation (REC)

A W3C Recommendation is a specification or set of guidelines or requirements that, after extensive consensus-building, has received the endorsement of W3C Members and the Director. W3C recommends the wide deployment of its Recommendations as standards for the Web. The W3C Royalty-Free IPR licenses granted under theW3C Patent Policy [PUB33] apply to W3C Recommendations.

Obsolete Recommendation

An Obsolete Recommendation is a specification that W3C does not believe has sufficient market relevance to continue recommending that the community implement it, but does not consider that there are fundamental problems that require the Recommendation be Rescinded. It is possible for an Obsolete Recommendation to receive sufficient market uptake that W3C decides to restore it to Recommendation status. An Obsolete Recommendation has the same status as a W3C Recommendation with regards to W3C Royalty-Free IPR licenses granted under the Patent Policy.

Rescinded Recommendation

A Rescinded Recommendation is an entire Recommendation that W3C no longer endorses, and believes is unlikely to ever be restored to Recommendation Status. See also clause 10 of the licensing requirements for W3C Recommendations insection 5 of theW3C Patent Policy [PUB33].

Working Group Note, Interest Group Note (NOTE)

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

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

6.2 General requirements and definitions

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

6.2.1 General requirements for Technical Reports

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

Every document published as part of the technical report development processmust clearly indicate itsmaturity level, andmust include information about the status of the document. This status information

• must be unique each time a specification is published,
• must state which Working Group developed the specification,
• must state how to send comments or file bugs, and where these are recorded,
• must include expectations about next steps,
• should explain how the technology relates to existing international standards and related work inside or outside W3C, and
• should explain or link to an explanation of significant changes from the previous version.

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

The Team isnot required to publish a Technical Report that does not conform to the Team'sPublication Rules [PUB31](e.g., fornaming, status information, style, andcopyright requirements). These rules are subject to change by the Team from time to time. The Teammust inform group Chairs and the Advisory Committee of any changes to these rules.

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

6.2.2 Advancement on the Recommendation Track

ForallTransition Requests, to advance a specification to a new maturity level other than Note, the Working Group:

• must record the group's decision to request advancement.
• must obtain Director approval.
• must provide public documentation of allsubstantive changes to the technical report since the previous publication.
• mustformally address all issues raised about the document since the previous maturity level.
• must provide public documentation of anyFormal Objections.
• should provide public documentation of changes that are not substantive.
• should report which, if any, of the Working Group's requirements for this document have changed since the previous step.
• should report any changes in dependencies with other groups.
• should provide information about implementations known to the Working Group.

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

Transition Requests to First Public Working Draft orCandidate Recommendation will not normally be approved while a Working Group's charter is undergoing or awaiting a Director's decision on an Advisory Committee Review.

6.2.3 Reviews and Review Responsibilities

A document is available for review from the moment it is first published. Working Groupsshouldformally addressany substantive review comment about a technical report in a timely manner.

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

6.2.3.1 Wide Review

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

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

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

6.2.4 Implementation Experience

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

• is each feature of the current specification implemented, and how is this demonstrated?
• are there independent interoperable implementations of the current specification?
• are there implementations created by people other than the authors of the specification?
• are implementations publicly deployed?
• is there implementation experience at all levels of the specification's ecosystem (authoring, consuming, publishing…)?
• are there reports of difficulties or problems with implementation?

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

6.2.5 Classes of Changes

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

1. No changes to text content

These changes include fixing broken links, style sheets or invalid markup.

2. Corrections that do not affect conformance

Changes that reasonable implementers would not interpret as changing architectural or interoperability requirements or their implementation. Changes which resolve ambiguities in the specification are considered to change (by clarification) the implementation requirements and do not fall into this class.

Examples of changes in this class include correcting non-normative code examples where the code clearly conflicts with normative requirements, clarifying informative use cases or other non-normative text, fixing typos or grammatical errors where the change does not change implementation requirements. If there is any doubt or dissent as to whether requirements are changed, such changes do not fall into this class.

3. Corrections that do not add new features

These changesmay affect conformance to the specification. A change that affects conformance is one that:

• makes conforming data, processors, or other conforming agents become non-conforming according to the new version, or
• makes non-conforming data, processors, or other agents become conforming, or
• clears up an ambiguity or under-specified part of the specification in such a way that data, a processor, or an agent whose conformance was once unclear becomes clearly either conforming or non-conforming.

4. New features

Changes that add a new functionality, element, etc.

6.3 Working Draft

A Public Working Draft is published on theW3C's Technical Reports page [PUB11] for review, and for simple historical reference. For all Public Working Drafts a Working Group:

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

6.3.1 First Public Working Draft

To publish the First Public Working Draft of a document, a Working Groupmust meet the applicablegeneral requirements for advancement.

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

Publishing the First Public Working Draft triggers a Call for Exclusions, persection 4 of theW3C Patent Policy [PUB33].

6.3.2 Revising Public Working Drafts

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

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

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

• must record the group's decision to request publication. Consensus is not required, as this is a procedural step,
• must provide public documentation ofsubstantive changes to the technical report since the previous Working Draft,
• should provide public documentation of significanteditorial changes to the technical report since the previous step,
• should report which, if any, of the Working Group's requirements for this document have changed since the previous step,
• should report any changes in dependencies with other groups,

Possible next steps for any Working Draft:

• RevisedPublic Working Draft
• Candidate recommendation.
• Working Group Note

6.3.3 Stopping Work on a specification

Work on a technical reportmay cease at any time. Workshould cease if W3C or a Working Group determines that it cannot productively carry the work any further. If the Directorcloses a Working Group W3Cmust publish any unfinished specifications on the Recommendation track asWorking Group Notes. If a Working group decides, or the Director requires, the Working Group to discontinue work on a technical report before completion, the Working Groupshould publish the document as aWorking Group Note.

6.4 Candidate Recommendation

To publish a Candidate recommendation, in addition to meeting thegeneral requirements for advancement a Working Group:

• must show that the specification has met all Working Group requirements, or explain why the requirements have changed or been deferred,
• must document changes to dependencies during the development of the specification,
• must document how adequate implementation experience will be demonstrated,
• must specify the deadline for comments, whichmust beat least four weeks after publication, andshould be longer for complex documents,
• must show that the specification has receivedwide review, and
• may identify features in the document as "at risk". These featuresmay be removed before advancement to Proposed Recommendation without a requirement to publish a new Candidate Recommendation.

The Directormust announce the publication of a Candidate Recommendation to other W3C groups and to the public, andmust begin an Advisory Committee Review on the question of whether the specification is appropriate to publish as a W3C Recommendation.

A Candidate Recommendation corresponds to a "Last Call Working Draft" as used in theW3C Patent Policy [PUB33]. Publishing a Candidate Recommendation triggers a Call for Exclusions, persection 4 of theW3C Patent Policy [PUB33].

Possible next steps:

• Return toWorking Draft
• A revisedCandidate Recommendation
• Proposed Recommendation (The expected next step)
• Working Group Note

Advisory Committee representativesmay initiate anAdvisory Committee Appeal of the decision to advance the technical report.

6.4.1 Revising a Candidate Recommendation

If there are anysubstantive changes made to a Candidate Recommendation other than to remove features explicitly identified as "at risk", the Working Groupmust obtain the Director's approval to publish a revision of a Candidate Recommendation. This is because substantive changes will generally require a new Exclusion Opportunity persection 4 of theW3C Patent Policy [PUB33]. Note that approval isexpected to be fairly simple compared to getting approval for a transition from Working Draft to Candidate Recommendation.

In addition the Working Group:

• must show that the revised specification meets all Working Group requirements, or explain why the requirements have changed or been deferred,
• must specify the deadline for further comments, whichmust beat least four weeks after publication, andshould be longer for complex documents,
• must document the changes since the previous Candidate Recommendation,
• must show that the proposed changes have receivedwide review, and
• may identify features in the document as "at risk". These featuresmay be removed before advancement to Proposed Recommendation without a requirement to publish a new Candidate Recommendation.

The Directormust announce the publication of a revised Candidate Recommendation to other W3C groups and the Public.

6.5 Proposed Recommendation

In addition to meeting thegeneral requirements for advancement,

• The status informationmust specify the deadline for Advisory Committee review, whichmust beat least 28 days after the publication of the Proposed Recommendation andshould be at least 10 days after the end of the last Exclusion Opportunity persection 4 of theW3C Patent Policy [PUB33].

A Working Group:

• must show adequateimplementation experience except where an exception is approved by the Director,
• must show that the document has receivedwide review,
• must show that all issues raised during the Candidate Recommendation review period other than by Advisory Committee representatives acting in their formal AC representative role have beenformally addressed,
• mustidentify any substantive issues raised since the close of the Candidate Recommendation review period by parties other than Advisory Committee representatives acting in their formal AC representative role,
• may have removed features identified in the Candidate Recommendation document as "at risk" without republishing the specification as a Candidate Recommendation.

The Director:

• must announce the publication of a Proposed Recommendation to theAdvisory Committee, and
• may approve a Proposed Recommendation with minimal implementation experience where there is a compelling reason to do so. In such a case, the Directorshould explain the reasons for that decision.

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

Possible Next Steps:

• Return toWorking Draft
• Return toCandidate Recommendation
• Recommendation status (The expected next step)
• Working Group Note

Advisory Committee representativesmay initiate anAdvisory Committee Appeal of the decision to advance the technical report.

6.6 W3C Recommendation

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

In addition to meeting thegeneral requirements for advancement,

• A Recommendationmust identify where errata are tracked, and
• A Recommendationmust not include any substantive changes from the Proposed Recommendation on which it is based.
• If there was anydissent in Advisory Committee reviews, the Directormust publish the substantive content of the dissent to W3C and the general public, andmustformally address the comment at least 14 days before publication as a W3C Recommendation.
• Advisory Committee representativesmay initiate anAdvisory Committee Appeal of the W3C decision
• The Directormust announce the publication of a W3C Recommendation toAdvisory Committee, other W3C groups and to the public.

Possible next steps:

A W3C Recommendation normally retains its status indefinitely. However it

• may be republished as an(Edited) Recommendation, or
• may berescinded.

6.7 Modifying a W3C Recommendation

This section details the management of errors in, and the process for making changes to a Recommendation. Please see also theRequirements for modification of W3C Technical Reports [PUB35].

6.7.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 error that can be resolved by one or more changes in classes 1-3 of section7.2.5 Classes of Changes.

Working Groupsmust keep a record as errors are reported by readers and implementers. Such error reportsshould be processed no less frequently than quarterly. Readers of the Recommendationshould be able easily to find and see the errata that apply to that specific Recommendation.

Working Groups decide how to document errata. The best practice is a document that identifies itself as based on the Recommendation text and clearly identifies the errata and any proposed corrections; other approaches include various forms of an errata page, possibly auto-generated from a database.

An erratum is resolved by an informative, "proposed" correction generated by the Working Group. A correction becomes part of the Recommendation by the process for Revising a Recommendation described in the next section.

6.7.2 Revising a Recommendation

A Working groupmay request republication of a Recommendation, or W3Cmay republish a Recommendation, to make corrections that do not result in any changes to the text of the specification.

Editorial changes to a Recommendation require no technical review of the proposed changes. A Working Group, provided there are no votes against the resolution to publishmay request publication of aRecommendation or W3Cmay publish aRecommendation to make this class of change without passing through earlier maturity levels. Such publications are calledEdited Recommendations.

To make corrections to a Recommendation that producesubstantive changes but do not add new features, or where there were votes against publishing the corrections directly as aRecommendation, a Working Groupmay request publication of aCandidate Recommendation, without passing through earlier maturity levels.

In the latter two cases, the resulting Recommendation is called anEdited Recommendation.

When requesting the publication of an Edited Recommendation as described in this section, in addition to meeting the requirements for the relevant maturity level, a Working Group

• must show that the changes to the document have receivedwide review, and
• should address all recorded errata.

For changes which introduces a new feature or features, W3Cmust follow the full process ofadvancing a technical report to Recommendation beginning with a new First Public Working Draft.

6.8 Publishing a Working Group or Interest Group Note

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

• supporting documentation for a specification, such as explanations of design principles or use cases and requirements,
• non-normative guides to good practices,
• specifications where work has been stopped and there is no longer consensus for making them a new standard.

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

• may publish a Note with or without its prior publication as a Working Draft.
• must record the group's decision to request publication as a Note, and
• should publish documentation of significant changes to the technical report since any previous publication.

Possible next steps:

• End state: A technical reportmay remain a Working or Interest Group Note indefinitely
• A Working Groupmay resume work on technical report within the scope of its charter at any time, at the maturity level the specification had before publication as a Note

TheW3C Patent Policy [PUB33] does not specify any licensing requirements or commitments for Working Group Notes.

6.9 Obsoleting or Rescinding a W3C Recommendation

It is possible that W3C decides that implementing a particular Recommendation is no longer recommended. There are two designations for such specifications, chosen depending on how strongly W3C wishes to advise against using the specification.

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

W3Cmay rescind a Recommendation if W3C believes there is no reasonable prospect of it being restored for example due to burdensome patent claims that affect implementers and cannot be resolved; see theW3C Patent Policy [PUB33] and in particularsection 5 (bullet 10) andsection 7.5.

W3C only rescinds or obsoletes entire Recommendations. To rescind or obsolete some part of a Recommendation, W3C follows the process formodifying a Recommendation.

For the purposes of theW3C Patent Policy [PUB33] an Obsolete Recommendation has the status of an active Recommendation, although it is not recommended for future implementation; a Rescinded Recommendation ceases to be in effect and no new licenses are granted under the Patent Policy.

The Directormay recommend obsoleting, rescinding, or restoring a Recommendation. The Directormust begin anAdvisory Committee review of a proposal to obsolete, rescind, or restore a Recommendation when requested to do so by any of the following:

• The Working Group who produced, or is chartered to maintain, the Recommendation.
• The TAG, if there is no such Working Group
• Any individual who made a request to the relevant Working Group as described above, or the TAG if such a group does not exist, to obsolete, rescind, or restore a Recommendation, where the request was not answered within 90 days
• 5% of the members of the Advisory Committee

For anyAdvisory Committee review of a proposal to obsolete, rescind, or restore a Recommendation the Directormust:

• announce the proposal to all Working Group Chairs, and to the Public, as well as to the Advisory Committee
• indicate that this is a proposal to Rescind, Obsolete, or restore, a Recommendation as appropriate
• identify the Recommendation by URL
• publish a rationale for the proposal
• identify known dependencies and solicit review from all dependent Working Groups
• solicit public review
• specify the deadline for review comments, whichmust be at least four weeks after the Director's announcement

andshould

• identify known implementations.

If there was anydissent in the Advisory Committee review, the Directormust publish the substantive content of the dissent to W3Cand the public, andmustformally address the dissent at least 14 days before publication as an Obsolete or Rescinded Recommendation.

TheAdvisory Committeemay initiate anAdvisory Committee Appeal of the Director's decision.

W3Cmust publish an Obsolete or Rescinded Recommendation with up to date status. The updated versionmay remove the main body of the document. The Status of this Document sectionshould link to the explanation ofObsoleting and Rescinding W3C Specifications [PUB39] as appropriate.

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

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

6.10 Further reading

Refer to"How to Organize a Recommendation Track Transition" in theMember guide for practical information about preparing for the reviews and announcements of the various steps, andtips on getting to Recommendation faster [PUB27].

7 Advisory Committee Reviews, Appeals, and Votes

This section describes how the Advisory Committee reviews proposals from the Director and how Advisory Committee representatives initiate an Advisory Committee Appeal of a W3C decision or Director's decision. AW3C decision is one where the Director (or the Director's delegate) has exercised the role of assessing consensus after anAdvisory Committee review.

7.1 Advisory Committee Reviews

The Advisory Committee reviews:

• new and modified Working and Interest Groups,
• Proposed Recommendations,Proposed Edited Recommendations,Proposal to Rescind a Recommendation, and
• Proposed changes to the W3C process.

7.1.1 Start of a Review Period

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

The Teammust provide two channels for Advisory Committee review comments:

1. an archivedTeam-only channel;
2. an archivedMember-only channel.

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

Reviewersmay send information to either or both channels. Theymay also share their reviews with other Members on theAdvisory Committee discussion list.

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

7.1.2 After the Review Period

After the review period, the Directormust announce to the Advisory Committee the level of support for the proposal (consensus ordissent). The Directormust also indicate whether there were any Formal Objections, with attention tochanging confidentiality level. ThisW3C decision is generally one of the following:

1. The proposal is approved, possibly with minor changes integrated.
2. The proposal is approved, possibly withsubstantive changes integrated. In this case the Director's announcementmust 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 toformally 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 theW3C decision. This is to ensure that the Members and Team have sufficient time to consider comments gathered during the review. The Advisory Committeeshould not expect an announcement sooner thantwo weeks after the end of a Proposed Recommendation review period. If, afterthree weeks, the Director has not announced the outcome, the Directorshould provide the Advisory Committee with an update.

7.2 Appeal by Advisory Committee Representatives

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

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

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

In all cases, an appealmust be initiated withinthree weeks of the decision.

An Advisory Committee representative initiates an appeal by sending a request to the Team. Within one week the Teammust announce the appeal process to the Advisory Committee and provide a mechanism for Advisory Committee representatives to respond with a statement of support (yes, no, or abstain) and comments, as desired. The archive of these commentsmust be Member-visible. If, withinone week of the Team's announcement, 5% or more of the Advisory Committee support the appeal request, the Teammust organize an appeal vote asking the Advisory Committee to approve or reject the decision.

7.3 Advisory Committee Votes

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

8 Workshops and Symposia

The Team organizesWorkshops andSymposia 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 Workshopmay solicit position papers for the Workshop program andmay 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 Symposiummay 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, butmay 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 Teammust issue the Call for Participation no later thansix weeks prior to the Workshop's scheduled start date. For other Workshops and Symposia, the Teammust issue a Call for Participation no later thaneight weeks prior to the meeting's scheduled start date. This helps ensure that speakers and authors have adequate time to prepare position papers and talks.

9 Liaisons

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

All liaisonsmust 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 Directormay negotiate and sign aMemorandum of Understanding (MoU) with another organization. Before signing the MoU, the Teammust inform the Advisory Committee of the intent to sign and make the MoU available for Advisory Committee review; Advisory Committee representativesmay initiate anAdvisory Committee Appeal of the decision to sign the MoU. Once approved, a Memorandum of Understandingshould be made public.

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

10 Member Submission Process

The Member Submission process allows Members to propose technology or other ideas for consideration by the Team. After review, the Teammay 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.

AMember Submission consists of:

• One or more documents developed outside of the W3C process, and
• Information about the documents, provided by the Submitter.

One or more Members (called the "Submitter(s)")may participate in a Member Submission. Only W3C Membersmay 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 Directormust either acknowledge or reject the Submission request.
   • Ifacknowledged, the Teammust publish the Member Submission at the public W3C Web site, in addition to Team comments about the Member Submission.
   • Ifrejected, the Submitter(s)may initiate aSubmission Appeal to either theTAG or theAdvisory Board.

Note: To avoid confusion about the Member Submission process, please note that:

• Documents in a Member Submission are developed outside of W3C. These documents arenot part of thetechnical report development process (and therefore are not included in theindex of W3C technical reports). Members wishing to have documents developed outside of W3C published by W3Cmust follow the Member Submission process.
• The Submission process isnot a means by which Members ask for "ratification" of these documents asW3C Recommendations.
• There is no requirement or guarantee that technology which is part of an acknowledged Submission request will receive further consideration by W3C (e.g., by a W3C Working Group).

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 W3Cmust not be referred to as "work in progress" of the W3C.

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

10.1 Submitter Rights and Obligations

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

At any time prior to acknowledgment, any Submittermay 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 Teammust 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 a deliverable of a W3C Working Group

10.1.1 Scope of Member Submissions

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

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

Membersshould not submit materials covering topics well outside the scope ofW3C's mission [PUB15].

10.1.2 Information Required in a Submission Request

The Submitter(s) and any other authors of the submitted materialmust agree that, if the request is acknowledged, the documents in the Member Submission will be subject to theW3C 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 requestmust satisfy the Member Submission licensing commitments ofsection 3.3 of theW3C Patent Policy [PUB33].

The Submitter(s)must include the following information:

• The list of all submitting Members.
• Position statements from all submitting Members (gathered by the Submitter). All position statementsmust appear in a separate document.
• Complete electronic copies of any documents submitted for consideration (e.g., a technical specification, a position paper, etc.) If the Submission request is acknowledged, these documents will be published by W3C and thereforemust satisfy the Communication Team'sPublication Rules [PUB31]. Submittersmay hold the copyright for the material contained in these documents, but when published by W3C, these documentsmust be subject to the provisions of theW3C Document License [PUB18].

The requestmust also answer the following questions.

• What proprietary technology is required to implement the areas addressed by the request, and what terms are associated with its use? Again, many answers are possible, but the specific answer will affect the Team's decision.
• What resources, if any, does the Submitter intend to make available if the W3C acknowledges the Submission request and takes action on it?
• What action would the Submitter like W3C to take if the Submission request is acknowledged?
• What mechanisms are there to make changes to the specification being submitted? This includes, but is not limited to, stating where change control will reside if the request is acknowledged.

For other administrative requirements related to Submission requests, see "How to send a Submission request" [MEM8].

10.2 Team Rights and Obligations

Although they are not technical reports, the documents in a Member Submissionmust fulfil the requirements established by the Team, including the Team'sPublication Rules.

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

Prior to a decision toacknowledge orreject the request, the request isTeam-only, and the Teammust hold it in the strictest confidentiality. In particular, the Teammust not comment to the media about the Submission request.

10.3 Acknowledgment of a Submission Request

The Directoracknowledges a Submission request by sending an announcement to the Advisory Committee. Though the announcementmay be made at any time, the Submitter(s) can expect an announcement betweenfour to six weeks after thevalidation notice. The Teammust keep the Submitter(s) informed of when an announcement is likely to be made.

Once a Submission request has been acknowledged, the Teammust:

• Publish the Member Submission.
• Publish Team comments about the Submission request.

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.

10.4 Rejection of a Submission Request, and Submission Appeals

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

• The ideas expressed in the request overlap in scope with the work of a chartered Working Group, and acknowledgment might jeopardize the progress of the group.
• The IPR statement made by the Submitter(s) is inconsistent with the W3C'sPatent Policy [PUB33],Document License [PUB18], or other IPR policies.
• The ideas expressed in the request are poor, might harm the Web, or run counter toW3C's mission.
• The ideas expressed in the request lie well outside the scope of W3C's mission.

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

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

11 Process Evolution

TheW3C Process Document undergoes similar consensus-building processes as technical reports, with theAdvisory Board acting as the sponsoring Working Group.

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

1. The Team sends a Call for Review to the Advisory Committee and other W3C groups.
2. After comments have beenformally addressed and the document possibly modified, the Team seeks endorsement from the Members by initiating anAdvisory Committee review of a Proposed Process Document. The review periodmust last at leastfour weeks.
3. After the Advisory Committee review, if there is consensus, the Team enacts the new process officially by announcing theW3C decision to the Advisory Committee. Advisory Committee representativesmay initiate anAdvisory Committee Appeal to the W3C.

W3Cmay also modify a Process Document by following the processes formodifying a Recommendation.

Reviews of the Process Document are not public reviews.

12 References

12.1 Public Resources

The following public information is available at theW3C 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

[PUB13]

Submission request overview

[PUB14]

The W3C Team

[PUB15]

About the World Wide Web Consortium

[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. Thelatest version of the W3C Patent Policy is available at https://www.w3.org/Consortium/Patent-Policy/.

[PUB35]

In-place modification of W3C Technical Reports

[PUB36]

Thecalendar of all scheduled official W3C events replaced theformer member-confidential version [MEM3].

[PUB37]

The Art of Consensus, a guidebook for W3C Working Group Chairs and other collaborators

[PUB38]

W3C Code of Ethics and Professional Conduct

[PUB39]

Obsoleting and Rescinding W3C Specifications

12.2Member-only Resources

The followingMember-only information is available at theW3C Web site.

[MEM1]

Current Advisory Committee representatives

[MEM2]

Group mailing lists

[MEM3]

The Member-onlycalendar of all scheduled official W3C events is no longer maintained. The information is now maintained in the public calendar [PUB36]

[MEM4]

There is aMember intro and FAQ as well as theProcess, Patent Policy, Finances Guide previously known as 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, is now a Public resource [PUB37]

[MEM14]

Guidelines for Disciplinary Action

[MEM15]

How to Organize an Advisory Board or TAG election

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

13 Acknowledgments

The following individuals (some as individuals, others with the affiliation listed) have contributed to this proposal for a revised Process: Daniel Appelquist, David Baron (Mozilla), J Alan Bird (W3C), Carine Bournez (W3C), Wayne Carr (Intel), Tantek Çelik (Mozilla), Michael Champion (Microsoft), Maria Courtemanche (IBM), Donald Deutsch (Oracle), Geoffrey Creighton (Microsoft), Kevin Fleming (Bloomberg), Virginia Fournier (Apple), Virginie Galindo (Gemalto), Daniel Glazman (Disruptive Innovations), Michael Geldblum (Oracle), Ian Jacobs (W3C), Jeff Jaffe (W3C), Jay Kishigami 岸上順一 (NTT), Philippe LeHégaret (W3C), Coralie Mercier (W3C), Mark Nottingham, Peter Patel-Schneider, Scott Peterson (Google), Delfí Ramírez, Florian Rivoal, Wendy Seltzer (W3C), David Singer (Apple), Geoffrey Snedden, Josh Soref, Ralph Swick (W3C), Léonie Watson (The Paciello Group), Ben Wilson, Chris Wilson (Google), Rigo Wenning (W3C), Helene Workman (Apple), Judy Zhu 朱红儒 (Alibaba), Steve Zilles (Adobe).
The editor is sorry for forgetting any names, and grateful to those who have listened patiently to conversations about this document, without feeling a need to add more.

The following individuals contributed to the development of earlier versions of the Process: Jean-François Abramatic (IBM, and previously ILOG and W3C), Dan Appelquist (Telefonica), Art Barstow (Nokia, unaffiliated), Ann Bassetti (The Boeing Company), Jim Bell (HP), Robin Berjon (W3C), Tim Berners-Lee (W3C), Klaus Birkenbihl (Fraunhofer Gesellschaft), Judy Brewer (W3C), Don Brutzman (Web3D), Carl Cargill (Netscape, Sun Microsystems), Wayne Carr (Intel), Marcos Cáceres (Mozilla), Michael Champion (Microsoft), Paul Cotton (Microsoft), Mark Crawford (SAP), Tantek Çelik (Mozilla), Don Deutsch (Oracle), Karl Dubost (Mozilla), David Fallside (IBM), Fantasai (Mozilla), Wendy Fong (Hewlett-Packard), Virginie Galindo (Gemalto), Daniel Glazman (Disruptive Innovations), Paul Grosso (Arbortext), Eduardo Gutentag (Sun Microsystems), Joe Hall (CDT), Ivan Herman (W3C), Ian Hickson (Google), Brad Hill (Facebook), Steve Holbrook (IBM), Renato Iannella (IPR Systems), Ian Jacobs (W3C), Jeff Jaffe (W3C), Cullen Jennings (Cisco), Brain Kardell (JQuery), Sally Khudairi (W3C), John Klensin (MCI), Tim Krauskopf (Spyglass), Kari Laihonen (Ericsson), Ken Laskey (MITRE), Ora Lassila (Nokia), Håkon Wium Lie (Opera Software), Chris Lilley (W3C), Peter Linss (HP), Bede McCall (MITRE), Giri Mandyam (Qualcomm), Larry Masinter (Adobe Systems), Nigel Megitt (BBC), Olle Olsson (SICS), Mark Nottingham, Qiuling Pan (Huawei), TV Raman (Google), Thomas Reardon (Microsoft), Claus von Riegen (SAP AG), Natasha Rooney (GSMA), Sam Ruby (IBM), David Singer (Apple), David Singer (IBM), Henri Sivonen (Mozilla), Josh Soref (BlackBerry), Ralph Swick (W3C), Anne van Kesteren, Jean-Charles Verdié (MStar), Mike West (Google), Chris Wilson (Google), Lauren Wood (unaffiliated), and Steve Zilles (Adobe Systems).

14 Changes

Detailed logs of all changes are available.

Substantive changes compared to the1 September 2015 Process include:

• Added link to document explaining Obsolete and Rescinded Recommendations - section6.9
• Allow Edited Recommendations to incorporate editorial changes without Advisory Committee review -Section 6.7.2
• Replace diagrams of Recommendation track with new versions to improve accessibility and accuracy - section6.1.1 and section6.7
• Remove statement that W3C does not organise conferences - section8
• Added a process to make a Recommendation Obsolete - section6.9
• Clarified the process to rescind a Recommendation, aligning with with obsoleting a Recommendation - section6.9
• Clarified the process for continuing work on a specification initially developed under another charter - sections5.2.3,5.2.4,5.2.6,6.2.2.
• Changed the voting for AB and TAG elections to Single Transferable Vote - section2.5.2
• Clarified the rights and obligations of Member Consortia and their representatives - section2.1.1
• Renumber: 5.2.8 becomes 5.2.7 because there was no section 5.2.7
• Simplify Appeals, so they can occur whether there was dissent or not, and in a broader range of cases - sections6.4,6.6,6.9,7,7.2,7.3,10,10.4,11