Source: https://w3c.github.io/w3process/
Timestamp: 2019-04-21 02:15:23+00:00

Document:
Copyright © 1996-2019 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.
The mission of the World Wide Web Consortium (W3C) is to lead the World Wide Web to its full potential by developing common protocols that promote its evolution and ensure its interoperability. The W3C Process Document describes the organizational structure of the W3C and processes, responsibilities and functions that enable W3C to accomplish its mission. This document does not describe the internal workings of the Team.
For more information about the W3C mission and the history of W3C, please refer to About W3C.
W3C, including all existing chartered groups, follows the most recent operative Process Document announced to the Membership. This document is developed by the Advisory Board’s Process Task Force working within the Revising W3C Process Community Group (which anyone can join). This is the 19 March 2019 Editor’s draft for the proposed next version of the W3C Process Document.
This document is based on the 1 March 2019 Process, which is the currently operative W3C Process.
This draft has been prepared for review by the W3C Advisory Board, to approve or change before proposing it to the W3C Advisory Committee for preliminary review. This revision incorporates changes to the currently operative Process that the editor believes reflect the decisions of the W3C Process Community Group. Further revision may take place following review by the W3C Process Community Group, the Advisory Board, and the Advisory Committee before this version is proposed to the Director as a formal revision to the operative Process Document. If that draft is accepted by the Director it will be the subject of an Advisory Committee Review as detailed in Section 11 Process Changes. Further revision of the W3C Process is expected to take place in subsequent versions of the Process as required. A history of substantial changes from previous versions of the Process Document is provided. Comment is invited on the draft. Please file comments as issues in the w3c/w3process GitHub Repository. If you are unable to do this you may send them in email to public-w3process@w3.org (publicly archived) or to process-issues@w3.org (Member-only archive).
W3C Members' attention is called to the fact that provisions of the Process Document are binding on Members per the Membership Agreement [MEMBER-AGREEMENT]. The Patent Policy W3C Patent Policy [PATENT-POLICY] is incorporated by normative reference as a part of the Process Document, and is thus equally binding.
In the Process Document, the term “participant” refers to an individual, not an organization.
The terms must, must not, should, should not, required, and may are used in accordance with RFC 2119. The term not required is equivalent to the term may as defined in RFC2119 [RFC2119].
Here is a general overview of how W3C standardizes a Web technology. In many cases, the goal of this work is a W3C Recommendation—a Web standard.
There are three types of Working Group participants: Member representatives, Invited Experts, and Team representatives. Team representatives both contribute to the technical work and help ensure the group’s proper integration with the rest of W3C. The Working Group charter sets expectations about each group’s deliverables (e.g., technical reports, test suites, and tutorials).
The W3C also operates Community and Business Groups, which are separately described in their own process document [BG-CG].
W3C’s mission is to lead the Web to its full potential. W3C Member organizations provide resources to this end, and the W3C Team provides the technical leadership and organization to coordinate the effort.
elects a majority (6) of the participants on the Technical Architecture Group.
W3C membership is open to all entities, as described in “How to Join W3C” [JOIN]; (refer to the public list of current W3C Members [MEMBER-LIST]). Organizations subscribe according to the Membership Agreement [MEMBER-AGREEMENT]. The Team must ensure that Member participation agreements remain Team-only and that no Member receives preferential treatment within W3C.
While W3C does not have a class of membership tailored to individuals, individuals may join W3C. Restrictions pertaining to related Members apply when the individual also represents another W3C Member.
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 the New Member Orientation [INTRO].
The rights and benefits of W3C membership are contingent upon conformance to the processes described in this document. The vast majority of W3C Members faithfully follow the spirit as well as the letter of these processes. When serious and/or repeated violations do occur, and repeated attempts to address these violations have not resolved the situation, the Director may take disciplinary action. Arbitration in the case of further disagreement is governed by paragraph 19 of the Membership Agreement [MEMBER-AGREEMENT]. Refer to the Guidelines for Disciplinary Action [DISCIPLINARY-GL].
A “Member Consortium” means a consortium, user society, or association of two or more individuals, companies, organizations or governments, or any combination of these entities which has the purpose of participating in a common activity or pooling resources to achieve a common goal other than participation in, or achieving certain goals in, W3C. A joint-stock corporation or similar entity is not a Member Consortium merely because it has shareholders or stockholders. If it is not clear whether a prospective Member qualifies as a Member Consortium, the Director may reasonably make the determination. For a Member Consortium, the rights and privileges of W3C Membership described in the W3C Process Document extend to the Member Consortium's paid staff and Advisory Committee representative.
Member Consortia may also designate up to four (or more at the Team’s discretion) individuals who, though not employed by the organization, may exercise the rights of Member representatives.
For Member Consortia that have individual people as members, these individuals must disclose their employment affiliation when participating in W3C work. Provisions for related Members apply. Furthermore, these individuals must represent the broad interests of the W3C Member organization and not the particular interests of their employers.
Related Members must disclose these relationships according to the mechanisms described in the New Member Orientation [INTRO].
When an organization joins W3C (see “How to Join W3C” [JOIN]), it must name its Advisory Committee representative as part of the Membership Agreement. The New Member Orientation [INTRO] explains how to subscribe or unsubscribe to Advisory Committee mailing lists, provides information about Advisory Committee Meetings, explains how to name a new Advisory Committee representative, and more. Advisory Committee representatives must follow the conflict of interest policy by disclosing information according to the mechanisms described in the New Member Orientation. See also the additional roles of Advisory Committee representatives described in the W3C Patent Policy [PATENT-POLICY].
Additional information for Members is available at the Member Web site [MEMBER-HP].
The Team must announce the date and location of each Advisory Committee meeting no later than at the end of the previous meeting; one year’s notice is preferred. The Team must announce the region of each Advisory Committee meeting at least one year in advance.
More information about Advisory Committee meetings [AC-MEETING] is available at the Member Web site.
The Team consists of the Director, CEO, W3C paid staff, unpaid interns, and W3C Fellows. W3C Fellows are Member employees working as part of the Team; see the W3C Fellows Program [FELLOWS]. The Team provides technical leadership about Web technologies, organizes and manages W3C activities to reach goals within practical constraints (such as resources available), and communicates with the Members and the public about the Web and W3C technologies.
The Director and CEO may delegate responsibility (generally to other individuals in the Team) for any of their roles described in this document, except participation in the TAG.
The Director is the lead technical architect at W3C, whose responsibilities are identified throughout this document in relevant places. Some key ones include: assessing consensus within W3C for architectural choices, publication of technical reports, and chartering new Groups; appointing group Chairs, adjudicating as "tie-breaker" for Group decision appeals, and deciding on the outcome of formal objections; the Director is generally Chair of the TAG.
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.
The Team must make available a mailing list, confidential to the Advisory Board and Team, for the Advisory Board to use for its communication.
Details about the Advisory Board (e.g., the list of Advisory Board participants, mailing list information, and summaries of Advisory Board meetings) are available at the Advisory Board home page [AB-HP].
The Advisory Board consists of nine to eleven elected participants and a Chair. The Team appoints the Chair of the Advisory Board, who is generally the CEO. The team also appoints a Team Contact for the AB, as described in §5.1 Requirements for All Working and Interest Groups.
The remaining nine to eleven Advisory Board participants are elected by the W3C Advisory Committee following the AB/TAG nomination and election process.
With the exception of the Chair, the terms of all Advisory Board participants are for two years. Terms are staggered so that each year, either five or six terms expire. If an individual is elected to fill an incomplete term, that individual’s term ends at the normal expiration date of that term. Regular Advisory Board terms begin on 1 July and end on 30 June.
The TAG's scope is limited to technical issues about Web architecture. The TAG should not consider administrative, process, or organizational policy issues of W3C, which are generally addressed by the W3C Advisory Committee, Advisory Board, and Team. Please refer to the TAG charter [TAG-CHARTER] for more information about the background and scope of the TAG, and the expected qualifications of TAG participants.
When the TAG votes to resolve an issue, each TAG participant (whether appointed, elected, or the Chair) has one vote; see also the section on voting in the TAG charter [TAG-CHARTER] and the general section on votes in this Process Document.
Details about the TAG (e.g., the list of TAG participants, mailing list information, and summaries of TAG meetings) are available at the TAG home page [TAG-HP].
Six participants elected by the Advisory Committee following the AB/TAG nomination and election process.
The Team appoints the Chair of the TAG, who must be one of the participants. The team also appoints a Team Contact [TEAM-CONTACT] for the TAG, as described in §5.1 Requirements for All Working and Interest Groups.
The terms of elected and Director-appointed TAG participants are for two years. Terms are staggered so that each year three elected terms, and either one or two appointed terms expire. If an individual is appointed or elected to fill an incomplete term, that individual’s term ends at the normal expiration date of that term. Regular TAG terms begin on 1 February and end on 31 January.
The Director may announce the appointed participants after the results for the Advisory Committee election of participants have been announced.
Individuals elected or appointed to the Advisory Board or TAG act in their personal capacity, to serve the needs of the W3C membership as a whole, and the Web community. Whether they are Member representatives or Invited Experts, their activities in those roles are separate and distinct from their activities on the Advisory Board or TAG.
An individual participates on the Advisory Board or TAG from the moment the individual’s term begins until the seat is vacated (e.g. because the term ends). Although Advisory Board and TAG participants do not advocate for the commercial interests of their employers, their participation does carry the responsibilities associated with Member representation, Invited Expert status, or Team representation (as described in the section on the AB/TAG nomination and election process). See also the licensing obligations on TAG participants in section 3 of the W3C Patent Policy [PATENT-POLICY], and the claim exclusion process of section 4.
Participation in the TAG or AB is afforded to the specific individuals elected or appointed to those positions, and a participant’s seat must not be delegated to any other person.
Two participants with the same primary affiliation per §2.5.2 Advisory Board and Technical Architecture Group Elections must not both occupy elected seats on the TAG except when this is caused by a change of affiliation of an existing participant. At the completion of the next regularly scheduled election for the TAG, the organization must have returned to having at most one seat.
Two participants with the same primary affiliation per §2.5.2 Advisory Board and Technical Architecture Group Elections must not both occupy elected seats on the AB. If, for whatever reason, these constraints are not satisfied (e.g., because an AB participant changes jobs), one participant must cease AB participation until the situation has been resolved. If after 30 days the situation has not been resolved, the Chair will apply the verifiable random selection procedure described below to choose one person for continued participation and declare the other seat(s) vacant.
The Advisory Board and a portion of the Technical Architecture Group are elected by the Advisory Committee, using a Single Transferable Vote system. An election begins when the Team sends a Call for Nominations to the Advisory Committee. Any Call for Nominations specifies the minimum and maximum number of available seats, the deadline for nominations, details about the specific vote tabulation system selected by the Team for the election, and operational information such as how to nominate a candidate. The Team may modify the tabulation system after the Call for Nominations but must stabilize it no later than the Call for Votes. The Director should announce appointments no later than the start of a nomination period as part of the Call for Nominations.
In the case of regularly scheduled elections of the TAG, the minimum and maximum number of avaiable seats are the same: the 3 seats of the terms expiring that year, plus any seat that is currently vacant from the prior year.
In the case of regularly scheduled elections of the AB, the minimum and maximum number of avaiable seats differ: The maximum number is the 5 or 6 seats of the terms expiring that year, plus any seat that is currently vacant from the prior year; the minimum number is such that when added to the occupied seats from the prior year, the minimum size of the AB (9) is reached.
Each Member (or group of related Members) may nominate one individual. A nomination must be made with the consent of the nominee. In order for an individual to be nominated as a Member representative, the individual must qualify for Member representation and the Member’s Advisory Committee representative must include in the nomination the (same) information required for a Member representative in a Working Group. In order for an individual to be nominated as an Invited Expert, the individual must provide the (same) information required for an Invited Expert in a Working Group and the nominating Advisory Committee representative must include that information in the nomination. In order for an individual to be nominated as a Team representative, the nominating Advisory Committee representative must first secure approval from Team management. A nominee is not required to be an employee of a Member organization, and may be a W3C Fellow. The nomination form must ask for the nominee’s primary affiliation, and this will be reported on the ballot. For most nominees, the primary affiliation is their employer and will match their affiliation in the W3C database. For contractors and invited experts, this will normally be their contracting company or their invited expert status; in some cases (e.g. where a consultant is consulting for only one organization) this may be the organization for whom the nominee is consulting. A change of affiliation is defined such that this field would carry a different answer if the nominee were to be re-nominated (therefore, terminating employment, or accepting new employment, are changes of affiliation). (Other formal relationships such as other contracts should be disclosed as potential conflicts of interest.) Each nomination should include a few informative paragraphs about the nominee.
Greater than or equal to the minimum number of available seats and less than or equal to the maximum number of available seats, those nominees are thereby elected. This situation constitutes a tie for the purpose of assigning short terms. Furthermore, if the number is less than the maximum number of available seats, the longest terms are filled first.
Less than the minimum 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 maximum number of available seats, the Team issues a Call for Votes that includes the names of all candidates, the (maxiumum) 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 of related Members) may submit one ballot that ranks candidates in the Member’s preferred order. Once the deadline for votes has passed, the Team announces the results to the Advisory Committee. In case of a tie the verifiable random selection procedure described below will be used to fill the available seats.
Refer to How to Organize an Advisory Board or TAG election [ELECTION-HOWTO] for more details.
When it is necessary to use a verifiable random selection process (e.g., in an AB or TAG election, to “draw straws” in case of a tie or to fill a short term), W3C uses the random and verifiable procedure defined in RFC 3797 [RFC3797]. The procedure orders an input list of names (listed in alphabetical order by family name unless otherwise specified) into a “result order”.
If a participant changes affiliation, but the participation constraints are met, that participant’s seat becomes vacant at the the next regularly scheduled election for that group.
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 Chair should not request such an election if the next regularly scheduled election is fewer than three months away.
The group Chair may request an election, and the election may begin, as soon as a current member gives notice of a resignation, including a resignation effective as of a given date in the future.
When such an election is held, the minimum number of available seat is such that when added to the number of continuing participants, the minimum total number of elected seats is met (6 for the TAG, 9 for the AB); and the maximum number corresponds to all unoccupied seats. Except for the number of available seats and the length of the terms, the usual rules for Advisory Board and Technical Architecture Group Elections apply.
Social competence in one’s role.
Participants in any W3C activity must abide by the terms and spirit of the W3C Code of Ethics and Professional Conduct [CEPC] and the participation requirements described in section 6 of the W3C Patent Policy [PATENT-POLICY].
The Director may suspend or remove for cause a participant in any group (including the AB and TAG), where cause includes failure to meet the requirements of this process, the membership agreement, or applicable laws.
Individuals participating materially in W3C work must disclose significant relationships when those relationships might reasonably be perceived as creating a conflict of interest with the individual’s role at W3C. These disclosures must be kept up-to-date as the individual’s affiliations change and W3C membership evolves (since, for example, the individual might have a relationship with an organization that joins or leaves W3C). Each section in this document that describes a W3C group provides more detail about the disclosure mechanisms for that group.
The ability of an individual to fulfill a role within a group without risking a conflict of interest depends on the individual’s affiliations. When these affiliations change, the individual’s assignment to the role must be evaluated. The role may be reassigned according to the appropriate process. For instance, the Director may appoint a new group Chair when the current Chair changes affiliations (e.g., if there is a risk of conflict of interest, or if there is risk that the Chair’s new employer will be over-represented within a W3C activity).
Team members are subject to the W3C Team conflict of interest policy [CONFLICT-POLICY].
Meeting announcements should be sent to all appropriate group mailing lists, i.e. those most relevant to the anticipated meeting participants.
Consensus is a core value of W3C. To promote consensus, the W3C process requires Chairs to ensure that groups consider all legitimate views and objections, and endeavor to resolve them, whether these views and objections are expressed by the active participants of the group or by others (e.g., another W3C group, a group in another organization, or the general public). Decisions may be made during meetings (face-to-face or distributed) as well as through email.
Note: The Director, CEO, and COO have the role of assessing consensus within the Advisory Committee.
A substantial number of individuals in the set support the decision and nobody in the set registers a Formal Objection. Individuals in the set may abstain. Abstention is either an explicit expression of no opinion or silence by an individual in the set.
The particular case of consensus where all individuals in the set support the decision (i.e., no individual in the set abstains).
At least one individual in the set registers a Formal Objection.
In some cases, even after careful consideration of all points of view, a group might find itself unable to reach consensus. The Chair may record a decision where there is dissent (i.e., there is at least one Formal Objection) so that the group can make progress (for example, to produce a deliverable in a timely manner). Dissenters cannot stop a group’s work simply by saying that they cannot live with a decision. When the Chair believes that the Group has duly considered the legitimate concerns of dissenters as far as is possible and reasonable, the group should move on.
In the W3C process, an individual may register a Formal Objection to a decision. A Formal Objection to a group decision is one that the reviewer requests that the Director consider as part of evaluating the related decision (e.g., in response to a request to advance a technical report).
Note: In this document, the term “Formal Objection” is used to emphasize this process implication: Formal Objections receive Director consideration. The word “objection” used alone has ordinary English connotations.
In the context of this document, a group has formally addressed an issue when it has sent a public, substantive response to the reviewer who raised the issue. A substantive response is expected to include rationale for decisions (e.g., a technical explanation, a pointer to charter scope, or a pointer to a requirements document). The adequacy of a response is measured against what a W3C reviewer would generally consider to be technically sound. If a group believes that a reviewer’s comments result from a misunderstanding, the group should seek clarification before reaching a decision.
As a courtesy, both Chairs and reviewers should set expectations for the schedule of responses and acknowledgments. The group should reply to a reviewer’s initial comments in a timely manner. The group should set a time limit for acknowledgment by a reviewer of the group’s substantive response; a reviewer cannot block a group’s progress. It is common for a reviewer to require a week or more to acknowledge and comment on a substantive response. The group’s responsibility to respond to reviewers does not end once a reasonable amount of time has elapsed. However, reviewers should realize that their comments will carry less weight if not sent to the group in a timely manner.
A group may vote for other purposes than to resolve a substantive issue. For instance, the Chair often conducts a “straw poll” vote as a means of determining whether there is consensus about a potential decision.
A group may also vote to make a process decision. For example, it is appropriate to decide by simple majority whether to hold a meeting in San Francisco or San Jose (there’s not much difference geographically). When simple majority votes are used to decide minor issues, voters are not required to state the reasons for votes, and the group is not required to record individual votes.
A W3C Member or Invited Expert may resign from a group. On written notification from an Advisory Committee representative or Invited Expert to the team, the Member and their representatives or the Invited Expert will be deemed to have resigned from the relevant group. The team must record the notification. See section 4.2. of the W3C Patent Policy [PATENT-POLICY] for information about obligations remaining after resignation from certain groups.
W3C technical reports whose publication has been approved by the Director. Per the Membership Agreement, W3C technical reports (and software) are available free of charge to the general public; (refer to the W3C Document License [DOC-LICENSE]).
A mission statement [MISSION] that explains the purpose and mission of W3C, the key benefits for Members, and the organizational structure of W3C.
Legal documents, including the Membership Agreement [MEMBER-AGREEMENT] and documentation of any legal commitments W3C has with other entities.
To keep the Members abreast of W3C meetings, Workshops, and review deadlines, the Team provides them with a regular (e.g., weekly) news service and maintains a calendar [CALENDAR]. of official W3C events. Members are encouraged to send schedule and event information to the Team for inclusion on this calendar.
While much information made available by W3C is public, “Member-only” information is available to authorized parties only, including representatives of Member organizations, Invited Experts, the Advisory Board, the TAG, and the Team. For example, the charter of some Working Groups may specify a Member-only confidentiality level for group proceedings.
“Team-only” information is available to the Team and other authorized parties.
Advisory Committee representatives may authorize Member-only access to Member representatives and other individuals employed by the Member who are considered appropriate recipients. For instance, it is the responsibility of the Advisory Committee representative and other employees and official representatives of the organization to ensure that Member-only news announcements are distributed for internal use only within their organization. Information about Member mailing lists is available in the New Member Orientation [INTRO].
The Team must not attribute the version for the new confidentiality level to the author without the author’s consent.
Working Groups typically produce deliverables (e.g., Recommendation Track technical reports, software, test suites, and reviews of the deliverables of other groups). There are additional participation requirements described in the W3C Patent Policy [PATENT-POLICY].
Each group must have a Chair (or co-Chairs) to coordinate the group’s tasks. The Director appoints (and re-appoints) Chairs for all groups. The Chair is a Member representative, a Team representative, or an Invited Expert (invited by the Director). The requirements of this document that apply to those types of participants apply to Chairs as well. The role of the Chair [CHAIR] is described in the Art of Consensus [GUIDE].
Each group must have a Team Contact, who acts as the interface between the Chair, group participants, and the rest of the Team. The role of the Team Contact [TEAM-CONTACT] is described in the Member guide [GUIDE]. The Chair and the Team Contact of a group should not be the same individual.
Each group must have an archived mailing list for formal group communication (e.g., for meeting announcements and minutes, documentation of decisions, and Formal Objections to decisions). It is the responsibility of the Chair and Team Contact to ensure that new participants are subscribed to all relevant mailing lists. Refer to the list of group mailing lists [GROUP-MAIL].
A Chair may form task forces (composed of group participants) to carry out assignments for the group. The scope of these assignments must not exceed the scope of the group’s charter. A group should document the process it uses to create task forces (e.g., each task force might have an informal "charter"). Task forces do not publish technical reports; the Working Group may choose to publish their results as part of a technical report.
A participant may represent more than one organization in a Working Group or Interest Group. Those organizations must all be members of the group.
An individual may become a Working or Interest Group participant at any time during the group’s existence. See also relevant requirements in section 4.3 of the W3C Patent Policy [PATENT-POLICY].
On an exceptional basis, a Working or Interest Group participant may designate a substitute to attend a meeting and should inform the Chair. The substitute may act on behalf of the participant, including for votes. For the substitute to vote, the participant must inform the Chair in writing in advance. As a courtesy to the group, if the substitute is not well-versed in the group’s discussions, the regular participant should authorize another participant to act as proxy for votes.
See also the licensing obligations on Working Group participants in section 3 of the W3C Patent Policy [PATENT-POLICY], and the patent claim exclusion process of section 4.
the Member resigns from the Working Group; this is done through the Member’s Advisory Committee representative.
if the individual’s employer (including a self-employed individual) or the organization the individual represents is not a W3C Member, indicate whether that organization intends to join W3C. If the organization does not intend to join W3C, indicate reasons the individual is aware of for this choice.
W3C management changes Team representation by sending email to the Chair, copying the group mailing list.
The Director must solicit Advisory Committee review of every new or substantively modified Working Group or Interest Group charter. The Director is not required to solicit Advisory Committee review prior to a charter extension or for minor changes. The review period must be at least 28 days.
The Director’s Call for Review of a substantively modified charter must highlight important changes (e.g., regarding deliverables or resource allocation) and include rationale for the changes.
As part of the Advisory Committee review of any new or substantively modified Working Group charter, any Advisory Committee representative may request an extended review period.
Such a request must be submitted with a Member’s comments in response to the Call for Review. Upon receipt of any such request, the Director must ensure that the Call for Participation for the Working Group occurs at least 60 days after the Call for Review of the charter.
For a new group, this announcement officially creates the group. The announcement must include a reference to the charter, the name(s) of the group’s Chair(s), and the name(s) of the Team Contact(s).
Advisory Committee representatives may initiate an Advisory Committee Appeal against a Director’s decision to create or substantially modify a Working Group or Interest Group charter.
To extend a Working Group or Interest Group charter with no other substantive modifications, the Director announces the extension to the Advisory Committee. The announcement must indicate the new duration. The announcement must also include rationale for the extension, a reference to the charter, the name(s) of the group’s Chair(s), the name of the Team Contact, and instructions for joining the group.
Advisory Committee representatives may initiate an Advisory Committee Appeal against a Director’s decision regarding the extension of a Working Group or Interest Group charter.
Expected milestone dates where available.
Intellectual property information. What are the intellectual property (including patents and copyright) considerations affecting the success of the Group? In particular, is there any reason to believe that it will be difficult to meet the Royalty-Free licensing goals of section 2 of the W3C Patent Policy [PATENT-POLICY]?
See also the charter requirements of section 2 and section 3 of the W3C Patent Policy [PATENT-POLICY].
The stable URL of the Working Group charter under which the Exclusion Draft was published (labeled the “Other Charter”).
All of the above data must be identified in the adopting Working Group’s charter using the labels indicated.
The Reference Draft is the latest Working Draft published within 90 days of the First Public Working Draft or if no Working Draft has been published within 90 days of the First Public Working Draft, it is that First Public Working Draft. It is the specific draft against which exclusions are made, as per section 4.1 of the W3C Patent Policy [PATENT-POLICY].
The Adopted Draft and the Exclusion Draft must each be adopted in their entirety and without any modification. The proposed charter must state that Exclusion Draft is deemed to be the Reference Draft or Candidate Recommendation of the Adopted Draft, and the date when the Exclusion Opportunity that arose on publishing the First Public Working Draft or Candidate Recommendation began and ended. As per section 4.3 of the W3C Patent Policy [PATENT-POLICY], this potentially means that exclusions can only be made immediately on joining a Working Group.
Closing a Working Group has implications with respect to the W3C Patent Policy [PATENT-POLICY].
See also the licensing goals for W3C Recommendations in section 2 of the W3C Patent Policy [PATENT-POLICY].
Publishing as used in this document refers to producing a version which is listed as a W3C Technical Report on its Technical Reports page https://www.w3.org/TR [TR].
Publication of the First Public Working Draft.
Publication of zero or more revised Working Drafts.
Possibly, Publication as an Edited or Amended Recommendation.
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 the document status section of a Working Draft for the group’s expectations. Any Working Draft not, or no longer, intended to advance to Recommendation should 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.
Provide an exclusion opportunity per the W3C Patent Policy [PATENT-POLICY]. Note: A Candidate Recommendation under this process corresponds to the Last Call Working Draft discussed in the Patent Policy.
Note: Advancing to Candidate Recommendation indicates that no further improvement is expected without additional implementation experience and testing. A Candidate Recommendation is expected to be as well-written, detailed, self-consistent, and technically complete as a Recommendation, and acceptable as such if and when the requirements for further advancement are met. Announcement of a different next step should include the reasons why the change in expectations comes at so late a stage.
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 triggers formal review by the Advisory Committee, who may recommend that the document be published as a W3C Recommendation, returned to the Working Group for further work, or abandoned. Substantive changes must not be made to a Proposed Recommendation except by publishing a new Working Draft or Candidate Recommendation.
A Working Group may make editorial or other minor changes to a Recommendation, and produce a new version which W3C publishes as a revised edition of the Recommendation.
An Amended Recommendation is a Recommendation that is amended to include substantive changes that do not add new features, and is produced by the W3C at a time when the Recommendation does not fit within the charter of any active Working Group. Since the W3C team rather than a Working Group moves it through the Process, there are implications regarding the scope of Royalty-Free IPR licenses granted under the W3C Patent Policy [PATENT-POLICY].
A Superseded Recommendation is a specification that has been replaced by a newer version that the W3C recommends for new adoption. An Obsolete or Superseded specification has the same status as a W3C Recommendation with regards to W3C Royalty-Free IPR Licenses granted under the Patent Policy.
An Obsolete Recommendation is a specification that the W3C has determined lacks sufficient market relevance to continue recommending it for implementation, but which does not have fundamental problems that would require it to be Rescinded. If an Obsolete specification gains sufficient market relevance, the W3C may decide to restore it to Recommendation status.
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 in section 5 of the W3C Patent Policy [PATENT-POLICY].
Only sufficiently technically mature work should be advanced.
Note: Should faster advancement to meet scheduling considerations be desired, this can be achieved by reducing the scope of the technical report to a subset that is adequately mature and deferring less stable features to other technical reports.
When publishing an updated version of an existing Candidate Recommendation or Recommendation, technical reports are expected to meet the same maturity criteria as when they are first published under that status. However, in the interest of replacing stale documents with improved ones in a timely manner, if flaws have been discovered in the technical report after its initial publication as a CR or REC that would have been severe enough to reject that publication had they be known in time, it is also permissible to publish an updated CR or REC following the usual process, even if only some of these flaws have been satisfactorily addressed.
Working Groups and Interest Groups may make available Editor’s drafts. Editor’s drafts (ED) have no official standing whatsoever, and do not necessarily imply consensus of a Working Group or Interest Group, nor are their contents endorsed in any way by W3C.
Every document published as part of the technical report development process must be a public document. The index of W3C technical reports [TR] is available at the W3C Web site. W3C strives to make archival documents indefinitely available at their original address in their original form.
Every Technical Report published as part of the Technical Report development process is edited by one or more editors appointed by a Group Chair. It is the responsibility of these editors to ensure that the decisions of the Group are correctly reflected in subsequent drafts of the technical report. An editor must be a participant, per §5.2.1 Working Group and Interest Group Participation Requirements in the Group responsible for the document(s) they are editing.
The Team is not required to publish a Technical Report that does not conform to the Team’s Publication Rules [PUBRULES] (e.g., for naming, status information, style, and copyright requirements). These rules are subject to change by the Team from time to time. The Team must inform group Chairs and the Advisory Committee of any changes to these rules.
The primary language for W3C Technical Reports is English. W3C encourages the translation of its Technical Reports. Information about translations of W3C technical reports [TRANSLATION] is available at the W3C Web site.
must record the group’s decision to request advancement.
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.
The requirements for wide review are not precisely defined by the W3C Process. The objective is to ensure that the entire set of stakeholders of the Web community, including the general public, have had adequate notice of the progress of the Working Group (for example through notices posted to public-review-announce@w3.org) and were able to actually perform reviews of and provide comments on the specification. A second objective is to encourage groups to request reviews early enough that comments and suggested changes can still be reasonably incorporated in response to the review. Before approving transitions, the Director will consider who has been explicitly offered a reasonable opportunity to review the document, who has provided comments, the record of requests to and responses from reviewers, especially W3C Horizontal Groups [CHARTER] and groups identified as dependencies in the charter or identified as liaisons [LIAISON], and seek evidence of clear communication to the general public about appropriate times and which content to review and whether such reviews actually occurred.
For example, inviting review of new or significantly revised sections published in Working Drafts, and tracking those comments and the Working Group's responses, is generally a good practice which would often be considered positive evidence of wide review. Working Groups should announce to other W3C Working Groups as well as the general public, especially those affected by this specification, a proposal to enter Candidate Recommendation (for example in approximately 28 days). By contrast a generic statement in a document requesting review at any time is likely not to be considered as sufficient evidence that the group has solicited wide review.
is there implementation experience at all levels of the specification’s ecosystem (authoring, consuming, publishing…)?
Examples of changes in this class include correcting non-normative code examples where the code clearly conflicts with normative requirements, clarifying informative use cases or other non-normative text, fixing typos or grammatical errors where the change does not change implementation requirements. If there is any doubt or disagreement as to whether requirements are changed, such changes do not fall into this class.
When a contributor who is not already obligated under the Patent Policy offers a change in class 3 or 4 (as described in §6.2.5 Classes of Changes) to a technical report under this process the Team must request from the contributor a recorded royalty-free patent commitment; for a change in class 4, the Team must secure such commitment. Such commitment should cover, at a minimum, all the contributor’s Essential Claims both in the contribution, and that become Essential Claims as a result of incorporating the contribution into the draft that existed at the time of the contribution, on the terms specified in section 5 (W3C Royalty-Free (RF) Licensing Requirements) of the W3C Patent Policy.
The first Working Draft of a technical report is called the First Public Working Draft (FPWD).
The Director must announce the publication of a First Public Working Draft to other W3C groups and to the public.
Publishing the First Public Working Draft triggers a Call for Exclusions, per section 4 of the W3C Patent Policy [PATENT-POLICY].
If 6 months elapse without significant changes to a specification, a Working Group should publish a revised Working Draft, whose status section should indicate reasons for the lack of change.
Work on a technical report may cease at any time. Work should cease if W3C or a Working Group determines that it cannot productively carry the work any further. If the Director closes a Working Group W3C must publish any unfinished specifications on the Recommendation track as Working 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 Group should publish the document as a Working Group Note.
may identify features in the document as at risk. These features may be removed before advancement to Proposed Recommendation without a requirement to publish a new Candidate Recommendation.
The Director must announce the publication of a Candidate Recommendation to other W3C groups and to the public.
A Candidate Recommendation corresponds to a Last Call Working Draft as used in the W3C Patent Policy [PATENT-POLICY]. Publishing a Candidate Recommendation triggers a Call for Exclusions, per section 4 of the W3C Patent Policy, except if the document is a candidate Amended Recommendation or contains only editorial changes.
If there are any substantive changes made to a Candidate Recommendation other than to remove features explicitly identified as at risk, the Working Group must obtain the Director's approval to publish a revision of a Candidate Recommendation. Substantive changes can require a new Exclusion Opportunity per section 4 of the W3C Patent Policy [PATENT-POLICY].
Note: approval is expected to be fairly simple compared to getting approval for a transition from Working Draft to Candidate Recommendation.
The status information must specify the deadline for Advisory Committee review, which must be at least 28 days after the publication of the Proposed Recommendation and should be at least 10 days after the end of the last Exclusion Opportunity per section 4 of the W3C Patent Policy [PATENT-POLICY].
may have removed features identified in the Candidate Recommendation document as at risk without republishing the specification as a Candidate Recommendation.
must announce the publication of a Proposed Recommendation to the Advisory Committee, and must begin an Advisory Committee Review on the question of whether the specification is appropriate to publish as a W3C Recommendation.
Recommendation status, including Edited or Amended Recommendation (The expected next step).
This section details the management of errors in, and the process for making changes to a Recommendation. Please see also the Requirements for modification of W3C Technical Reports [REPUBLISHING].
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 section §6.2.5 Classes of Changes..
Working Groups must keep a record as errors are reported by readers and implementers. Such error reports should be processed no less frequently than quarterly. Readers of the Recommendation should be able easily to find and see the errata that apply to that specific Recommendation with their associated tests.
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.
A Working group may request republication of a Recommendation, or if there is no Working Group chartered to maintain a Recommendation W3C may republish the Recommendation, to make corrections that do not result in any changes to the text of the specification.
To make corrections to a Recommendation that produce substantive changes but do not add new features, or where there were votes against publishing the corrections directly as a Recommendation, a Working Group may request publication of a Candidate Recommendation, or if no Working Group is chartered to maintain a Recommendation W3C may publish a candidate Amended Recommendation, without passing through earlier maturity levels.
If the publication was requested by a Working Group, the resulting Recommendation is called an Edited Recommendation. If the publication was requested by the W3C team in the absence of a Working Group, the resulting Recommendation is called an Amended Recommendation.
To make changes which introduce a new feature or features, W3C must follow the full process of advancing a technical report to Recommendation beginning with a new First Public Working Draft.
Note: The W3C Patent Policy [PATENT-POLICY] does not specify any licensing requirements or commitments for Working Group Notes.
It is possible that W3C decides that implementing a particular Recommendation is no longer recommended. There are three designations for such specifications, chosen depending on the advice W3C wishes to give about further use of the specification.
W3C may declare a Recommendation Superseded if a newer version exists which the W3C recommends for new adoption. The process for declaring a Recommendation Superseded is the same as for declaring it Obsolete, below; only the name and explanation change.
W3C may rescind a Recommendation if W3C believes there is no reasonable prospect of it being restored for example due to burdensome patent claims that affect implementers and cannot be resolved; see the W3C Patent Policy [PATENT-POLICY] and in particular section 5 (bullet 10) and section 7.5.
W3C only rescinds, supersedes, or obsoletes entire Recommendations. A Recommendation can be both superseded and obsolete. To rescind, supersede, or obsolete some part of a Recommendation, W3C follows the process for modifying a Recommendation.
Note: For the purposes of the W3C Patent Policy [PATENT-POLICY] an Obsolete or Superseded Recommendation has the status of an active Recommendation, although it is not recommended for future implementation; a Rescinded Recommendation ceases to be in effect and no new licenses are granted under the Patent Policy.
W3C must publish an Obsolete or Rescinded Recommendation with up to date status. The updated version may remove the main body of the document. The Status of this Document section should link to the explanation of Obsoleting and Rescinding W3C Specifications [OBS-RESC] as appropriate.
Refer to "How to Organize a Recommendation Track Transition" [TRANSITION] in the Member guide [GUIDE] for practical information about preparing for the reviews and announcements of the various steps, and tips on getting to Recommendation faster [REC-TIPS].
This section describes how the Advisory Committee reviews proposals from the Director and how Advisory Committee representatives initiate an Advisory Committee Appeal of a W3C decision or Director's decision. A W3C decision is one where the Director (or the Director’s delegate) has exercised the role of assessing consensus after an Advisory Committee review.
The proposal is approved, possibly with substantive changes integrated. In this case the Director’s announcement must include rationale for the decision to advance the document despite the proposal for a substantive change.
This document does not specify time intervals between the end of an Advisory Committee review period and the W3C decision. This is to ensure that the Members and Team have sufficient time to consider comments gathered during the review. The Advisory Committee should not expect an announcement sooner than two weeks after the end of a review period. If, after three weeks, the Director has not announced the outcome, the Director should provide the Advisory Committee with an update.
An Advisory Committee representative initiates an appeal by sending a request to the Team. The request should say “I appeal this Director’s Decision” and identify the decision. Within one week the Team must announce the appeal process to the Advisory Committee and provide a mechanism for Advisory Committee representatives to respond with a statement of positive support for this appeal. The archive of these statements must be Member-visible. If, within one week of the Team’s announcement, 5% or more of the Advisory Committee support the appeal request, the Team must organize an appeal vote asking the Advisory Committee “Do you approve of the Director’s Decision?” together with links to the Director's decision and the appeal support.
The ballot must allows for three possible responses: “Approve”, “Reject”, and “Abstain”, together with Comments.
The proposal is returned for additional work, after which the applicable decision process is re-initiated.
The Advisory Committee votes in elections for seats on the TAG or Advisory Board, and in the event of an Advisory Committee Appeal achieving the required support to trigger an appeal vote. Whenever the Advisory Committee votes, each Member or group of related Members has one vote. In the case of Advisory Board and TAG elections, “one vote” means “one vote per available seat”.
Workshops and Symposia generally last one to three days. If a Workshop is being organized to address the pressing concerns of Members, the Team must issue the Call for Participation no later than six weeks prior to the Workshop’s scheduled start date. For other Workshops and Symposia, the Team must issue a Call for Participation no later than eight weeks prior to the meeting’s scheduled start date. This helps ensure that speakers and authors have adequate time to prepare position papers and talks.
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.
The W3C Director may negotiate a Memorandum of Understanding with another organization. For the purposes of the W3C Process a Memorandum of Understanding (MoU) is a formal agreement or similar contractual framework between W3C and another party or parties, other than agreements between the Hosts or between Hosts and W3C members for the purposes of membership and agreements related to the ordinary provision of services for the purposes of running W3C, that specifies rights and obligations of each party toward the others. These rights and obligations may include joint deliverables, an agreed share of technical responsibilities with due coordination, and/or considerations for confidentiality and specific IPR. The agreement may be called something other than a “Memorandum of Understanding”, and something called a “Memorandum of Understanding” may not be an MoU for the purposes of the Process.
Before signing the MoU, the Team must inform the Advisory Committee of the intent to sign and make the MoU available for Advisory Committee review; Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to sign the MoU. Unless an appeal rejects the proposal to sign an MoU, the Director may sign the MoU on behalf of W3C. A signed Memorandum of Understanding should be made public.
Information about W3C liaisons with other organizations [LIAISON] and the guidelines W3C follows when creating a liaison is available on the Web.
The Member Submission process allows Members to propose technology or other ideas for consideration by the Team. After review, the Team may make the material available at the W3C Web site. The formal process affords Members a record of their contribution and gives them a mechanism for disclosing the details of the transaction with the Team (including IPR claims). The Team also makes review comments on the Submitted materials available for W3C Members, the public, and the media.
One or more Members (called the Submitter(s)) may participate in a Member Submission. Only W3C Members may be listed as Submitters.
One of the Submitters sends a request to the Team to acknowledge the Submission request. The Team and Submitter(s) communicate to ensure that the Member Submission is complete.
If acknowledged, the Team must make the Member Submission available at the public W3C Web site, in addition to Team comments about the Member Submission.
Documents in a Member Submission are developed outside of the W3C technical report development process (and therefore are not included in the index of W3C technical reports [TR]).
The Submission process is not a means by which Members ask for “ratification” of these documents as W3C Recommendations.
Making a Member Submission available at the W3C website does not imply endorsement by W3C, including the W3C Team or Members. The acknowledgment of a Submission request does not imply that any action will be taken by W3C. It merely records publicly that the Submission request has been made by the Submitter. A Member Submission made available by W3C must not be referred to as “work in progress” of the W3C.
The list of acknowledged Member Submissions [SUBMISSION-LIST] is available at the W3C Web site.
At any time prior to acknowledgment, any Submitter may withdraw support for a Submission request (described in "How to send a Submission request" [SUBMISSION-REQ]). A Submission request is “withdrawn” when no Submitter(s) support it. The Team must not make statements about withdrawn Submission requests.
Prior to acknowledgment, the Submitter(s) must not, under any circumstances, refer to a document as “submitted to the World Wide Web Consortium” or “under consideration by W3C” or any similar phrase either in public or Member communication. The Submitter(s) must not imply in public or Member communication that W3C is working (with the Submitter(s)) on the material in the Member Submission. The Submitter(s) may release the documents in the Member Submission to the public prior to acknowledgment (without reference to the Submission request).
After acknowledgment, the Submitter(s) must not, under any circumstances, imply W3C investment in the Member Submission until, and unless, the material has been adopted as a deliverable of a W3C Working Group.
When a technology overlaps in scope with the work of a chartered Working Group, Members should participate in the Working Group and contribute the technology to the group’s process rather than seek publication through the Member Submission process. The Working Group may incorporate the contributed technology into its deliverables. If the Working Group does not incorporate the technology, it should not publish the contributed documents as Working Group Notes since Working Group Notes represent group output, not input to the group.
Members should not submit materials covering topics well outside the scope of W3C’s mission [MISSION].
The Submitter(s) and any other authors of the submitted material must agree that, if the request is acknowledged, the documents in the Member Submission will be subject to the W3C Document License [DOC-LICENSE] and will include a reference to it. The Submitter(s) may hold the copyright for the documents in a Member Submission.
The request must satisfy the Member Submission licensing commitments of section 3.3 of the W3C Patent Policy [!!PATENT-POLICY]].
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 made available by W3C and therefore must satisfy the Communication Team’s Publication Rules [PUBRULES]. Submitters may hold the copyright for the material contained in these documents, but when made available by W3C, these documents must be subject to the provisions of the W3C Document License [DOC-LICENSE].
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.
For other administrative requirements related to Submission requests, see “How to send a Submission request” [MEMBER-SUB].
Although they are not technical reports, the documents in a Member Submission must fulfil the requirements established by the Team, including the Team’s Publication Rules [PUBRULES].
Make the Member Submission available at the W3C website.
Make the Team comments about the Submission request available at the W3C website.
If the Submitter(s) wishes to modify a document made available as the result of acknowledgment, the Submitter(s) must start the Submission process from the beginning, even just to correct editorial changes.
The IPR statement made by the Submitter(s) is inconsistent with the W3C’s Patent Policy [PATENT-POLICY] and in particular Section 3.3, Document License [DOC-LICENSE], or other IPR policies.
The ideas expressed in the request are poor, might harm the Web, or run counter to W3C’s mission [MISSION].
The ideas expressed in the request lie well outside the scope of W3C’s mission.
The Advisory Committee representative(s) of the Submitters(s) may initiate a Submission Appeal of the Team’s Decision to the TAG if the reasons are related to Web architecture, or to the Advisory Board if the request is rejected for other reasons. In this case the Team should make available its rationale for the rejection to the appropriate body. The Team will establish a process for such appeals that ensures the appropriate level of confidentiality.
After comments have been formally addressed and the document possibly modified, the Team seeks endorsement from the Members by initiating an Advisory Committee review of a Proposed Process Document. The review period must last at least 28 days.
The editors are grateful to the following people, who as interested individuals and/or with the affiliation(s) listed, have contributed to this proposal for a revised Process: Brian Kardell, Carine Bournez (W3C), Charles McCathie Nevile (ConsenSys), Chris Wilson (Google), David Singer (Apple), Delfí Ramírez, Dominique Hazaël-Massieux (W3C), Elika J. Etemad aka fantasai, Fuqiao Xue (W3C), Jeff Jaffe (W3C), Kevin Fleming (Bloomberg), Léonie Watson (The Paciello Group), Michael Champion (Microsoft), Nigel Megitt (BBC), Philippe Le Hégaret (W3C), Ralph Swick (W3C), Samuel Weiler (W3C), Sandro Hawke (W3C), Tantek Çelik (Mozilla), Virginia Fournier (Apple), Wendy Seltzer (W3C), Yves Lafon (W3C).
The editors are sorry for forgetting any names, and grateful to those who have listened patiently to conversations about this document without feeling a need to add more.
The following individuals contributed to the development of earlier versions of the Process: Alex Russell (Google), Andreas Tai (Institut fuer Rundfunktechnik), Andrew Betts (Fastly), Ann Bassetti (The Boeing Company), Anne van Kesteren, Art Barstow (Nokia, unaffiliated), Bede McCall (MITRE), Ben Wilson, Brad Hill (Facebook), Brian Kardell (JQuery), Carine Bournez (W3C), Carl Cargill (Netscape, Sun Microsystems, Adobe), Chris Lilley (W3C), Chris Wilson (Google), Claus von Riegen (SAP AG), Coralie Mercier (W3C), Cullen Jennings (Cisco), Dan Appelquist (Telefonica, Samsung), Dan Connolly (W3C), Daniel Dardailler (W3C), Daniel Glazman (Disruptive Innovations), David Baron (Mozilla), David Fallside (IBM), David Singer (Apple), David Singer (IBM), Delfí Ramírez, Dominique Hazaël-Massieux (W3C), Don Brutzman (Web3D), Don Deutsch (Oracle), Eduardo Gutentag (Sun Microsystems), Elika J. Etemad aka fantasai, Florian Rivoal, Fuqiao Xue (W3C), Geoffrey Creighton (Microsoft), Geoffrey Snedden, Giri Mandyam (Qualcomm), Gregg Kellogg, Hadley Beeman, Helene Workman (Apple), Henri Sivonen (Mozilla), Håkon Wium Lie (Opera Software), Ian Hickson (Google), Ian Jacobs (W3C), Ivan Herman (W3C), J Alan Bird (W3C), Jay Kishigami 岸上順一 (NTT), Jean-Charles Verdié (MStar), Jean-François Abramatic (IBM, ILOG, W3C), Jeff Jaffe (W3C), Jim Bell (HP), Jim Miller (W3C), Joe Hall (CDT), John Klensin (MCI), Josh Soref (BlackBerry, unaffiliated), Judy Brewer (W3C), Judy Zhu 朱红儒 (Alibaba), Kari Laihonen (Ericsson), Karl Dubost (Mozilla), Ken Laskey (MITRE), Kevin Fleming (Bloomberg), Klaus Birkenbihl (Fraunhofer Gesellschaft), Larry Masinter (Adobe Systems), Lauren Wood (unaffiliated), Liam Quin (W3C), Léonie Watson (The Paciello Group), Marcos Cáceres (Mozilla), Maria Courtemanche (IBM), Mark Crawford (SAP), Mark Nottingham, Michael Champion (Microsoft), Michael Geldblum (Oracle), Mike West (Google), Mitch Stoltz (EFF), Natasha Rooney (GSMA), Nigel Megitt (BBC), Olle Olsson (SICS), Ora Lassila (Nokia), Paul Cotton (Microsoft), Paul Grosso (Arbortext), Peter Linss, Peter Patel-Schneider, Philippe Le Hégaret (W3C), Qiuling Pan (Huawei), Ralph Swick (W3C), Renato Iannella (IPR Systems), Rigo Wenning (W3C), Rob Sanderson (J Paul Getty Trust), Robin Berjon (W3C), Sally Khudairi (W3C), Sam Ruby (IBM), Sandro Hawke (W3C), Sangwhan Moon (Odd Concepts), Scott Peterson (Google), Steve Holbrook (IBM), Steve Zilles (Adobe Systems) Steven Pemberton (CWI), TV Raman (Google), Tantek Çelik (Mozilla), Terence Eden (Her Majesty’s Government), Thomas Reardon (Microsoft), Tim Berners-Lee (W3C), Tim Krauskopf (Spyglass), Travis Leithead (Microsoft), Virginia Fournier (Apple), Virginie Galindo (Gemalto), Wayne Carr (Intel), Wendy Fong (Hewlett-Packard), Wendy Seltzer (W3C), Yves Lafon (W3C).
Converted the source code of the process to the Bikeshed document format, improving the ease of maintenance, and gaining better cross linking capabilities as well as an Index in the process. Note that while this makes no change to the text of the process, it is a large change of the source code, and source level diffs are unlikely to be of help to compare the before and after state.
Phrasing clarifications and removal of unnecessary text in §2.5.1 Advisory Board and Technical Architecture Group Participation Constraints and §7.1.2 After the Review Period.
Avoid using the specialized term “publish” to mean anything other than putting documents on TR.
Avoid using the specialized term “dissent” in situations that do not involve Formal Objections.
Retire the “Team Submissions” (not “Member Submissions”) mechanism, as it is unused, does not provide the Team with abilities it doesn’t already have, nor provides meaningful governance of the Team’s communications.
Mention the existence of Community Groups and Business Groups in §1 Introduction.
Change the size of the Advisory Board from a fixed 9 to a range of 9 to 11 elected members in §2.3.1 Advisory Board Participation, and adjust the election mechanics accordingly in §2.5.2 Advisory Board and Technical Architecture Group Elections and §2.5.3 Advisory Board and Technical Architecture Group Vacated Seats.
Clarify that AB and TAG members act in their personal capacity in §2.5 Advisory Board and Technical Architecture Group Participation.
Improve phrasing in §2.5.1 Advisory Board and Technical Architecture Group Participation Constraints to avoid suggesting that while member organizations were limited to one seat, non member organizations could have several.
Clarify what constitutes “affiliation” for the purposes of the “change of affiliation” provisions for TAG and AB members in §2.5.2 Advisory Board and Technical Architecture Group Elections.
In case of resignation from a group, require that the team records the resignation notification, in §3.6 Resignation from a Group.
Allow one person to represent (with disclosure) multiple organizations in a Working Group in §5.2.1 Working Group and Interest Group Participation Requirements.
Various phrasing clarifications to §6.1.2 Maturity Levels, and §6.2.2 Advancement on the Recommendation Track, and §6.3.1 First Public Working Draft.
Added new §6.2.6 Contributor License Grants to define the requirements for contributions made by non-WG members.
Clarify in §6.9 Declaring a W3C Recommendation Rescinded, Obsolete or Superseded that a Recommendation can be both superseded and obsolete.
Add an informative diagram about the process of obsoleting, rescinding, or restoring a Recommendation in §6.9 Declaring a W3C Recommendation Rescinded, Obsolete or Superseded.
Clarify in §6.9 Declaring a W3C Recommendation Rescinded, Obsolete or Superseded that the process to obsolete, rescind, or restore a Recommendation does not have to be initiated by the Director.
Rephrase part of §10 Member Submission Process to avoid statement about Member Submissions that appeared to negate the possibility of having work originate in Community Groups.
Remove meaningless claim from §11 Process Evolution that an alternative way to update the Process was to follow the REC track process.
Tim Berners-Lee is a Life Member of the TAG.
Clarify that a special election can begin if a candidate resigns as of some future date, rather than waiting for that resignation to take effect.
The Director can suspend or remove a participant from any Group or activity for failure to meet participation criteria.
An AC member may request at least 60 days to review any new or substantively modified working group charter, with such review period occurring between the Call for Review and the Call for Participation.
Charters must include documentation of any voting procedures additional to those defined in §3.4 Votes.
W3C can produce an Amended Recommendation to update a Recommendation, without adding new features, similar to the way a Working Group produces an Edited Recommendation.
A Recommendation can be declared Superseded.
Definition of MoU and conditions for approval.

References: §5
 §5
 §2
 §2
 §5
 §6
 §6
 §2
 §7
 §1
 §2
 §2
 §2
 §2
 §2
 §2
 §3
 §5
 §6
 §6
 §6
 §6
 §6
 §6
 §6
 §10
 §11
 §3