The mission of the World Wide Web Consortium (W3C)
is making the web work, for everyone.
W3C brings together global stakeholders to develop open standards that enable a World Wide Web that connects and empowers humanity.
The W3C Process Document describes the organizational structure of 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.
This document is developed by the Advisory Board’s Process Task Force
working within the W3C Process Community Group
(which anyone can join).
This is the 22 July 2026 Draft Community Group Report for the proposed next version of the W3C Process Document.
This document,
which is based on the 18 August 2025 Process,
is a work in progress
and further changes may occur before completion of this revision cycle.
As detailed in Section 11 Process Changes,
once the W3C Advisory Board considers it ready for adoption,
it will be offered for W3C Advisory Committee Review.
Relation of Process Document to Patent Policy and Other Policies
W3C Members' attention is called to the fact
that provisions of the Process Document are binding on Members
per their Membership Agreement[MEMBER-AGREEMENT].
The W3C Patent Policy[PATENT-POLICY]
and other policies
incorporated by normative reference as a part of the Process Document
are equally binding.
The Patent Policy and Code of Conduct place additional obligations on Members, Team, and other participants in W3C.
The Process Document does not restate those requirements but includes references to them.
The Process Document, Patent Policy, and Code of Conduct have been designed to allow each to evolve independently.
In the Process Document, the term “participant” refers to an individual, not an organization.
Conformance and specialized terms
The terms
must,
must not,
should,
should not,
required,
and may
are used in accordance with RFC 2119.
The term not required
is equivalent to the term may
as defined in RFC2119
[RFC2119].
Some terms have been capitalized in this document (and in other W3C materials)
to indicate that they are entities with special relevance to the W3C Process.
These terms are defined within this document,
and readers are reminded that the ordinary English definitions are insufficient
for the purpose of understanding this document.
1.
Introduction
W3C work revolves around the standardization of Web technologies.
To accomplish this work, W3C follows processes that promote the development of high-quality standards
based on the consensus of the Membership, Team, and public.
W3C processes promote fairness, responsiveness, and progress:
all facets of the W3C mission.
This document describes the processes W3C follows in pursuit of its mission.
The W3C Process promotes the goals of quality and fairness in technical decisions
by encouraging consensus,
soliciting reviews (by both Members and public),
incorporating implementation and interoperability experience,
and requiring Membership-wide approval as part of the technical report development process.
Participants in W3C include
representatives of its Members and the Team,
as well as Invited Experts
who can bring additional expertise or represent additional stakeholders.
Team representatives both contribute to the technical work
and help ensure each group’s proper integration with the rest of W3C.
In addition, several groups are formally established by the Consortium:
the W3C Advisory Committee, which has a representative from each Member,
and two oversight groups elected by its membership:
the Advisory Board (AB),
which helps resolve Consortium-wide non-technical issues and manages the evolution of the W3C process;
and the Technical Architecture Group (TAG),
which helps resolve Consortium-wide technical issues.
Here is a general overview of how W3C initiates standardization of a Web technology:
People generate interest in a particular topic.
For instance, Members express interest by developing proposals in Community Groups
or proposing ideas in Member Submissions.
Also, the Team monitors work inside and outside of W3C for signs of interest,
and helps organize Workshops to bring people together
to discuss topics that interest the W3C community.
When there is enough interest and an engaged community,
the Team works with the Membership
to draft proposed Interest Group or Working Group charters.
W3C Members review the proposed charters,
and when there is support within W3C for investing resources in the topic of interest,
W3C approves the group(s),
and they begin their work.
W3C’s mission is to make the web work — for everyone,
by bringing together global stakeholders to develop open standards
that enable a World Wide Web that connects and empowers humanity.
W3C Member organizations provide resources to this end,
and the W3C Team provides the technical leadership
and organization to coordinate the effort.
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]).
The Teammust ensure
that Member participation agreements remain Team-only
and that no Member receives preferential treatment within W3C.
While W3C does not have a class of membership tailored to individuals,
individuals may join W3C.
Restrictions pertaining to related Members apply
when the individual also represents another W3C Member.
2.1.1.
Rights of Members
Each Member organization enjoys the following rights and benefits:
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].
Furthermore, subject to further restrictions included in their Member Agreement,
representatives of Member organizations participate in W3C as follows:
A Workshop is an event whose goal 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.
(See Workshops in [GUIDE])
The rights and benefits of W3C membership [MEMBER-AGREEMENT]
are contingent upon conformance to the processes described in this document.
Disciplinary action for anyone participating in W3C activities is described in § 3.1.1.1 Expectations and Discipline.
A “Member Association” 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 Association
merely because it has shareholders or stockholders.
If it is not clear whether a prospective Member qualifies as a Member Association,
the CEO may reasonably make the determination.
For a Member Association, the rights and privileges of W3C Membership
described in the W3C Process Document extend to the Member Association’s paid staff
and Advisory Committee representative.
Member Associationsmay 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 Associations that have individual people as members,
these individuals must disclose their employment affiliation
when participating in W3C work.
Provisions for related Members apply.
Furthermore, these individuals must represent the broad interests of the W3C Member organization
and not the particular interests of their employers.
For Member Associations that have organizations as Members,
all such designated representatives must be an official representative of the Member organization
(e.g. a Committee or Task Force Chairperson)
and must disclose their employment affiliation when participating in W3C work.
Provisions for related Members apply.
Furthermore, these individuals must represent the broad interests of the W3C Member organization
and not the particular interests of their employers.
For all representatives of a Member Association,
IPR commitments are made on behalf of the Member Association,
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:
The Team consists of
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 CEO may delegate responsibility
(generally to other individuals in the Team)
for any of their roles described in this document.
Team Decisions derive from the CEO’s authority,
even when they are carried out by other members of the Team.
Oversight over the Team,
budgeting,
and other business decisions,
is provided by the W3C Board of Directors,
rather than managed directly by the Process.
Note: See the W3C Bylaws for more details
on the Board and overall governance of W3C.
There are three qualities an individual is expected to demonstrate in order to participate in W3C:
Technical competence in one’s role;
The ability to act fairly;
Social competence in one’s role.
Advisory Committee representatives who nominate individuals from their organization for participation in W3C activities
are responsible for assessing and attesting to the qualities of those nominees.
Participants in any W3C activity must abide
by the terms and spirit of the W3C Code of Conduct[COC]
and the participation requirements described in
“Disclosure”
in the W3C Patent Policy [PATENT-POLICY].
The CEOmay take disciplinary action,
including suspending or removing for cause
a participant in any group (including the AB and TAG)
if serious and/or repeated violations occur,
such as failure to meet the requirements on individual behavior of
(a) this process
and in particular the Code of Conduct,
(b) their membership agreement, or
(c) applicable laws.
Refer to the Guidelines to suspend or remove participants from groups.
3.1.1.2.
Conflict of Interest Policy
Individuals participating materially in W3C work must disclose significant relationships
when those relationships might reasonably be perceived as creating a conflict of interest with the individual’s role at W3C.
These disclosures must be kept up-to-date
as the individual’s affiliations change and W3C membership evolves
(since, for example, the individual might have a relationship with an organization that joins or leaves W3C).
Each section in this document that describes a W3C group
provides more detail about the disclosure mechanisms for that group.
The ability of an individual to fulfill a role within a group
without risking a conflict of interest depends on the individual’s affiliations.
When these affiliations change,
the individual’s assignment to the role must be evaluated.
The role may be reassigned according to the appropriate process.
For instance,
the Teammay 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 a 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 matters should contact the Team.
3.1.1.3.
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 representatives must disclose
relevant affiliations to the Team and to any group in which the individual participates.
In exceptional circumstances
(e.g., situations that might jeopardize the progress of a group or create a conflict of interest),
the CEOmay decline
to allow an individual designated by an Advisory Committee representative to participate in a group.
A group charter may limit
the number of individuals representing a W3C Member
(or group of related Members).
3.1.2.
Meetings
The requirements in this section apply to the official meetings of any W3C group,
as well as to official W3C meetings with open-ended participation from the Membership and/or the public,
such as Workshops.
W3C distinguishes two types of meetings:
A face-to-face meeting is one
where most of the attendees are expected to participate in the same physical location.
A distributed meeting is one
where most of the attendees are expected to participate from remote locations
(e.g., by telephone, video conferencing, or IRC).
A Chairmay invite an individual with a particular expertise
to attend a meeting on an exceptional basis.
This person is a meeting guest,
not a group participant.
Meeting guests do not have voting rights.
It is the responsibility of the Chair to ensure
that all meeting guests respect the chartered level of confidentiality
and other group requirements.
3.1.2.1.
Meeting Scheduling and Announcements
Meeting announcements should be sent to all appropriate group mailing lists,
i.e. those most relevant to the anticipated meeting participants.
The following table lists recommendations for organizing a meeting:
Face-to-face meetings
Distributed meetings
Meeting announcement (before)
eight weeks*
one week*
Agenda available (before)
two weeks
24 hours (or longer if a meeting is scheduled after a weekend or holiday)
* 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.
In the case of Workshops,
shorter notice is not allowed.
3.1.2.2.
Meeting Minutes
Groups should take and retain minutes of their meetings,
and must record
any official group decisions made during the meeting discussions.
Details of the discussion leading to such decisions are not required,
provided that the rationale for the group decision is nonetheless clear.
3.1.2.3.
Meeting Recordings and Transcripts
No-one may take an audio or video recording of a meeting,
or retain an automated transcript,
unless the intent is announced at the start of the meeting,
and no-one participating in the recorded portion of the meeting withholds consent.
If consent is withheld by anyone, recording/retention must not occur.
The announcement must cover:
(a) who will have access to the recording or transcript and
(b) the purpose/use of it and
(c) how it will be retained (e.g. privately, in a cloud service) and for how long.
3.1.3.
Tooling and Archiving for Discussions and Publications
For W3C Groups operating under this Process,
a core operating principle is to allow access across disabilities,
across country borders,
and across time.
Thus in order to allow all would-be participants to effectively participate,
to allow future participants and observers to understand the rationale and origins of current decisions,
and to guarantee long-lived access to its publications,
W3C requires that:
All reports, publications, or other deliverables
produced by the group for public consumption
(i.e. intended for use or reference outside its own membership)
should be published and promoted at a W3C-controlled URL,
and backed up by W3C systems
such that if the underlying service is discontinued,
W3C can continue to serve such content without breaking incoming links
or other key functionality.
All reports, publications, or other deliverables
produced by the group for public consumption
should follow best practices for internationalization
and for accessibility to people with disabilities.
Network access to W3C-controlled domains may be assumed.
Official meeting minutes and other records of decisions made must
be archived by W3C for future reference;
and other persistent text-based discussions
sponsored by the group,
pertaining to their work
and intended to be referenceable by all group members
should be.
This includes discussions conducted over email lists
or in issue-tracking services
or any equivalent fora.
Materials referenced from discussions
and necessary to understand them
should be available at a stable URL,
at a level of confidentiality no stricter than the discussion minutes.
Note: The lack, or loss, of such archives does not by itself
invalidate an otherwise-valid decision.
Any tooling used by the group
for producing its documentation and deliverables
or for official group discussions
should be usable
(without additional cost)
by all who wish to participate,
including people with disabilities,
to allow their effective participation.
Note: If a new participant joins who cannot use the tool,
this can require the Working Group to change its tooling
or operate some workaround.
All tools and archives used by the group
for its discussions and recordkeeping
should be documented
such that new participants and observers
can easily find the group’s tools and records.
The Team is responsible for ensuring adherence to these rules
and for bringing any group not in compliance into compliance.
3.1.4.
Resignation from a Group
A W3C Member or Invited Expert may resign from a group.
On written notification from an Advisory Committee representative
or Invited Expert
to the Team,
the Member and their representatives
or the Invited Expert
will be deemed to have resigned from the relevant group.
The Teammust record the notification.
See “Exclusion and Resignation from the Working Group” in the W3C Patent Policy [PATENT-POLICY]
for information about obligations remaining after resignation from certain groups.
3.2.
The Advisory Committee (AC)
3.2.1.
Role of the Advisory Committee
The Advisory Committee represents
the Members of W3C at large.
It is responsible for:
The AC representative may share their rights and responsibilities under this Process
with an alternate,
except the ability to designate an alternate.
Note: The above does not establish an ability to delegate rights and responsibilities
pertaining to the role of “Consortium Member Representative”
as defined by the W3C Bylaws.
Such rights and responsibilities are out of scope for the Process.
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.
One for discussion among Advisory Committee representatives.
Though this list is primarily for Advisory Committee representatives,
the Teammust monitor discussion
and should participate in discussion when appropriate.
Ongoing detailed discussions should be moved to other appropriate lists
(new or existing, such as a mailing list created for a Workshop).
An Advisory Committee representativemay request
that additional individuals from their organization be subscribed to these lists.
Failure to contain distribution internally
may result in suspension of additional email addresses,
at the discretion of the Team.
3.2.4.
Advisory Committee Meetings
The Team organizes a face-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 Team should provide an update to the Advisory Committee about:
Resources
The number of W3C Members at each level.
An overview of the financial status of W3C.
Allocations
The allocation of the annual budget, including size of the Team and their approximate deployment.
A list of all activities (including but not limited to Working and Interest Groups)
and brief status statement about each,
in particular those started or terminated since the previous Advisory Committee meeting.
The allocation of resources to pursuing liaisons with other organizations.
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 Team must announce the region of each Advisory Committee meeting
at least one year in advance.
The Advisory Board
is elected by the Membership to advance the effectiveness of W3C as a
standards development organization (SDO).
The Advisory Board:
Provides ongoing guidance to the Team
on issues of strategy,
management,
legal matters,
process,
community engagement,
and conflict resolution,
that arise during the the work of the W3C community;
Serves the Members by
tracking issues raised between Advisory Committee meetings,
soliciting Member comments on such issues,
and proposing actions to resolve these issues;
Is responsible for the development of the Process Document,
including considering proposals,
identifying changes and areas for improvement,
and publishing new versions.
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].
3.3.1.2.
Composition of the Advisory Board
The Advisory Board consists of nine to eleven elected participants and one Chair
(who may be one of the elected participants).
With the input of the AB,
the Team appoints the Chair,
who should choose a co-chair among the elected participants.
Upon appointment,
the Chair(s) are subject to ratification by secret ballot,
requiring approval by two thirds of the elected participants.
Chair selection must be run
at least at the start of each regular term,
as well as when a majority of the participants request it;
and may be run at other times when initiated by the current chairs or the Team,
for example if a chair steps down or if a minority of the participants make such a request.
The terms of elected 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.
3.3.1.3.
Communications of the Advisory Board
The Teammust make available a mailing list,
confidential to the Advisory Board and Team,
for the Advisory Board to use for its communication.
The Advisory Boardshould send a summary of each of its meetings
to the Advisory Committee and other group Chairs.
The Advisory Board should also report on its activities
at each Advisory Committee meeting.
3.3.2.
Technical Architecture Group (TAG)
3.3.2.1.
Role of the Technical Architecture Group
The mission of the TAG is stewardship of the Web architecture.
There are three aspects to this mission:
to document and build consensus around principles of Web architecture
and to interpret and clarify these principles when necessary;
to resolve issues involving general Web architecture brought to the TAG;
to help coordinate cross-technology architecture developments inside and outside W3C.
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.
When the TAG votes to resolve an issue,
each TAG participant
(whether appointed, elected, or the Chair)
has one vote;
see also 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].
3.3.2.2.
Composition of the Technical Architecture Group
Participants in the TAG choose by consensus their Chair or co-Chairs;
in the absence of consensus, the Team appoints the Chair or co-Chairs of the TAG.
The Chair or co-Chairs must be selected from the participants of the TAG.
Chair selection must be run
at least at the start of each regular term,
as well as when a majority of the participants request it;
and may be run at other times when initiated by the current chairs or the Team,
for example if a chair steps down or if a minority of the participants make such a request.
The terms of TAG participants last for two years.
Terms are staggered so that four elected terms
and either one or two appointed terms expire each year.
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.
3.3.2.3.
Communications of the Technical Architecture Group
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.
a Member-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., a Submission Appeal),
the TAG may use a list that will be Member-only.
The TAGshould send a summary of each of its meetings
to the Advisory Committee and other group Chairs.
The TAGshould also report on its activities at each Advisory Committee meeting.
3.3.3.
Participation in Elected Groups
3.3.3.1.
Expectations for Elected Groups Participants
Advisory Board and TAG participants have a special role within W3C:
they are elected by the Membership and appointed by the Team
with the expectation that they will use their best judgment
to find the best solutions for the Web,
not just for any particular network,
technology,
vendor,
or user.
Advisory Board and TAG participants are expected to participate regularly and fully.
Advisory Board and TAG participants should attend Advisory Committee meetings.
Individuals elected or appointed to the Advisory Board or TAG act in their personal capacity,
to serve the needs of the W3C membership as a whole,
and the Web community.
Whether they are Member representatives or Invited Experts,
their activities in those roles are separate and distinct from their activities on the Advisory Board or TAG.
An individual participates on the Advisory Board or TAG
from the moment the individual’s term begins until the seat is vacated
(e.g. because the term ends).
Although Advisory Board and TAG participants do not advocate for the commercial interests of their employers,
their participation does carry the responsibilities associated with Member representation,
Invited Expert status,
or Team representation
(as described in the section on the AB/TAG nomination and election process).
Participation in the TAG or AB is afforded to the specific individuals elected or appointed to those positions,
and a participant’s seat must not be delegated to any other person.
3.3.3.2.
Elected Groups 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:
Two (or more) participants with the same primary affiliation per § 3.3.3.3 Advisory Board and Technical Architecture Group Elections
must not occupy elected seats on the same Elected Group,
except when this is caused by a change of affiliation of an existing participant.
At the completion of the next regularly scheduled election for that group,
the organization must have returned to having at most one seat.
Otherwise, the Team will apply
the verifiable random selection procedure described below
to choose one person for continued participation and declare the other seat(s) vacant
as of that election.
An individual must not participate on both the TAG and the AB.
3.3.3.3.
Advisory Board and Technical Architecture Group Elections
The Advisory Board and a portion of the Technical Architecture Group are elected by the Advisory Committee,
using a Single Transferable Vote system.
An election begins when the Team sends a Call for Nominations to the Advisory Committee.
Any Call for Nominations specifies the minimum and maximum number of available seats,
the deadline for nominations,
details about the specific vote tabulation system selected by the Team for the election,
and operational information such as how to nominate a candidate.
The Teammay modify the tabulation system after the Call for Nominations
but must stabilize it no later than the Call for Votes.
The Team announces appointments
after the results of the election are known,
and before the start of the term,
as described in § 3.3.3.4 Technical Architecture Group Appointments.
In the case of regularly scheduled elections of the TAG,
the minimum and maximum number of available seats are the same:
the 4 seats of the terms expiring that year,
plus the number of other seats that are vacant or will be vacant by the time the newly elected members take their seats.
In the case of regularly scheduled elections of the AB,
the minimum and maximum number of available seats differ:
The maximum number is the 5 or 6 seats of the terms expiring that year,
plus the number of other seats that are vacant or will be vacant by the time the newly elected members take their seats;
the minimum number is such that when added to the occupied seats from the prior year,
the minimum size of the AB (9) is reached.
Each Member (or group of related Members)
may nominate one individual.
A nomination must be made with the consent of the nominee.
In order for an individual to be nominated as a Member representative,
the individual must qualify for Member representation
and the Member’s Advisory Committee 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 individual must 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 is not required to be an employee of a Member organization,
and may be a W3C Fellow.
The nomination form must ask for the nominee’s primary affiliation,
and this will be reported on the ballot.
For most nominees,
the primary affiliation is their employer and will match their affiliation in the W3C database.
For contractors and invited experts,
this will normally be their contracting company
or their invited expert status;
in some cases
(e.g. where a consultant is consulting for only one organization)
this may be the organization for whom the nominee is consulting.
A change of affiliation is defined
such that this field would carry a different answer
if the nominee were to be re-nominated
(therefore,
terminating employment,
or accepting new employment,
are changes of affiliation).
(Other formal relationships such as other contracts should be disclosed as potential conflicts of interest.)
Each nomination should include
a few informative paragraphs about the nominee.
If an identified candidate’s nomination information is only partially complete
as of the deadline for nominations,
the Teammay allow extra time for that candidate’s nomination to be completed,
so long as it does not delay the election as a whole.
If, after the deadline for nominations, the number of nominees is:
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 incomplete 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 (maximum) 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 in Good Standing
(or group of related Members)
may submit one ballot that ranks candidates in the Member’s preferred order.
Once the deadline for votes has passed,
the Team announces the results to the Advisory Committee.
In case of a tie the verifiable random selection procedure described below
will be used to fill the available seats.
The shortest incomplete 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 incomplete term,
the verifiable random selection procedure described below
will be used to assign the incomplete term.
3.3.3.4.
Technical Architecture Group Appointments
The Team is responsible for appointing
3 of the participants to the Technical Architecture Group.
This mechanism complements the election process.
The Teamshould use its appointments to support
a diverse and well-balanced TAG,
including diversity of technical background, knowledge, and skill sets.
The Teamshould actively seek
candidates for appointment to the TAG,
and must make available to
the W3C community at large
a means to propose candidates for consideration,
explicitly soliciting input from at least
current and incoming TAG members, the Advisory Committee, and Working GroupChairs.
Note: Since there are no limits on elected terms,
this limit on appointed terms does not constrain
term-limited appointees
from running for election at any time.
The Team’s choice of appointee(s)
is subject to ratification by secret ballot
by the TAG,
requiring two-thirds approval.
In the case of regularly scheduled elections,
the TAG participants in this ratification are
its members for the upcoming term.
For regularly scheduled elections,
selection begins once the results of the elections are known,
and the Teamshould announce the ratified appointment(s)
no later than the start of the regularly scheduled term.
When an appointed seat is vacated outside of a regularly scheduled election,
the Teamshould seek to appoint a replacement
unless a regular Call for Nominations is scheduled within 2 months,
and it must announce the ratified appointment
no later than the Call for Nominations of the next scheduled election.
3.3.3.5.
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 incomplete term),
W3C uses the random and verifiable procedure defined in RFC 3797[RFC3797].
The procedure orders an input list of names
(listed in alphabetical order by family name unless otherwise specified)
into a “result order”.
W3C applies this procedure as follows:
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.
After all elected individuals have been identified,
when N people are eligible for M (less than N) incomplete terms.
In this case, only the names of those N individuals are provided as input to the procedure.
The incomplete terms are assigned in result order.
If a participant changes affiliation,
but the participation constraints are met,
that participant’s seat becomes vacant at the next regularly scheduled election for that group.
Vacated seats are filled according to this schedule:
When an appointed TAG seat is vacated,
the Teamappoints a replacement.
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 scheduled to begin within 3 months.
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 seats is such that
when added to the number of continuing participants,
the minimum total number of elected seats is met
(8 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.
3.4.
Chartered Groups: Working Groups and Interest Groups
This document defines two types of chartered groups:
Interest Groups.
The primary goal of an Interest Group
is to bring together people who wish to evaluate potential Web technologies and policies.
An Interest Group is a forum for the exchange of ideas.
Each group must have a charter.
Requirements for the charter depend on the group type.
All group charters must be public
(even if other proceedings of the group are Member-only).
Each group must have a Chair (or co-Chairs)
to facilitate effective discussion and coordinate the group’s activities.
The Team appoints (and re-appoints) Chairs for all groups.
The Chair is a Member representative,
a Team representative,
or an Invited Expert
(invited by the Team).
The requirements of this document that apply to those types of participants apply to Chairs as well.
Each group must have a Staff Contact
(also known as Team Contact),
who acts as the interface between the Chair,
group participants,
and the rest of the Team.
The Chair and the Staff 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 Staff Contact
to ensure that new participants are subscribed to all relevant mailing lists.
Refer to the list of group mailing lists[GROUP-MAIL].
A Chairmay 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.
There are four types of individual participants in an Interest Group:
the same three types as for Working Groups plus,
for an Interest Group where the only participation requirement is mailing list subscription,
public participants.
Except where noted in this document or in a group charter,
all participants share the same rights and responsibilities in a group;
see also the individual participation criteria.
A participant may represent more than one organization
in a Working Group or Interest Group.
Those organizations must all be members of the group.
An individual may become
a Working or Interest Group participant
at any time during the group’s existence.
See also relevant requirements in
“Joining an Already Established Working Group”
in the W3C Patent Policy [PATENT-POLICY].
On an exceptional basis,
a Working or Interest Group participant may designate
a substitute
to attend a meeting
and should inform the Chair.
The substitute may act on behalf of the participant,
including for votes.
For the substitute to vote,
the participant must inform the Chair in writing in advance.
To allow rapid progress,
Working Groups are intended to be small
(typically fewer than 15 people)
and composed of experts in the area defined by the charter.
In principle,
Interest Groups have no limit on the number of participants.
When a Working Group grows too large to be effective,
W3C may split it into an Interest Group
(a discussion forum)
and a much smaller Working Group
(a core group of highly dedicated participants).
3.4.3.
Types of Participants in Chartered Groups
3.4.3.1.
Member Representative in a Working Group
An individual is a Member representative in a Working Group
if all of the following conditions are satisfied:
the Advisory Committee representative of the Member in question
has designated the individual as a Working Group participant, and
The name of the W3C Member the individual represents
and whether the individual is an employee of that Member organization;
A statement that the individual accepts the participation terms
set forth in the charter
(with an indication of charter date or version);
A statement that the Member will provide the necessary financial support for participation
(e.g., for travel, telephone calls, and conferences).
A Member participates in a Working Group
from the moment the first Member representative joins the group
until either of the following occurs:
the group closes, or
the Member resigns from the Working Group;
this is done through the Member’s Advisory Committee representative.
3.4.3.2.
Member Representative in an Interest Group
When the participation requirements exceed Interest Group mailing list subscription,
an individual is a Member representative in an Interest Group
if all of the following conditions are satisfied:
Member participation in an Interest Group ceases under the same conditions as for a Working Group.
3.4.3.3.
Invited Expert in a Working Group
The Chairmay invite an individual with a particular expertise
to participate in a Working Group.
This individual may represent an organization in the group
(e.g., if acting as a liaison with another organization).
An individual is an Invited Expert in a Working Group if all of the following conditions are satisfied:
the Chair has designated the individual as a group participant,
the Staff Contact has agreed with the Chair’s choice, and
To designate an individual as an Invited Expert in a Working Group,
the Chairmust inform the Staff Contact
and provide rationale for the choice.
When the Chair and the Staff Contact disagree about a designation,
the CEO determines
whether the individual will be invited to participate in the Working Group.
To participate in a Working Group as an Invited Expert,
an individual must:
identify the organization, if any, the individual represents as a participant in this group,
accept the participation terms set forth in the charter,
including the participation requirements of
the W3C Patent Policy [PATENT-POLICY],
especially in “Note on Licensing Commitments for Invited Experts”
and in “Disclosure”,
indicating a specific charter date or version,
provide a statement of who will provide the necessary financial support
for the individual’s participation
(e.g., for travel, telephone calls, and conferences), and
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.
The Chairshould not designate as an Invited Expert in a Working Group
an individual who is an employee of a W3C Member.
The Chair must not use Invited Expert status
to circumvent participation limits imposed by the charter.
An Invited Expert participates in a Working Group
from the moment the individual joins the group
until any of the following occurs:
the group closes, or
the Chair or CEO withdraws the invitation to participate, or
An individual is a Team representative in a Working Group
when so designated by W3C management.
Team representatives both contribute to the technical work
and help ensure the group’s proper integration with the rest of W3C.
A Team representative participates in a Working Group
from the moment the individual joins the group
until any of the following occurs:
the group closes, or
W3C management changes Team representation by sending email to the Chair,
copying the group mailing list.
The Team participates in a Working Group
from the moment the creation of the group is announced
until the group closes.
3.4.3.6.
Team Representative in an Interest Group
When the participation requirements exceed Interest Group mailing list subscription,
an individual is a Team representative in an Interest Group when so designated by W3C management.
4.
Lifecycle of Chartered Groups
W3C creates charters for chartered groups based on W3C community interest.
W3C fosters awareness of charters,
improves their quality,
and gauges Membership support in two formal phases:
Charters can originate in many venues,
including existing Working or Interest Groups,
Community Groups,
and from the Membership.
Prior to the formal refinement phase,
the Team engages with those various parties
to help prepare charters for broader audiences.
The Team is responsible for initiating charter refinement
at its discretion, in consideration of discussions with the community.
An Advisory Committee representativemay formally request
that the Team initiate charter refinement.
The Team may deny such a request
if it thinks the proposal is insufficiently mature,
does not align with W3C’s scope and mission,
or otherwise does not meet the charter assessment criteria
described in the Guide (see How to Create a Working Group or Interest Group),
and must reply with its rationale.
This rejection is a Team Decision,
and can be appealed only by 5 or more Members,
through their Advisory Committee representative,
formally objecting to the decision within 8 weeks of the decision being announced.
In this case the Teammust start an appeal vote
on whether to overturn the Team Decision.
(No action is required to be taken when fewer than 5 members object.)
4.2.
Charter Refinement
During charter refinement,
the W3C community,
under the guidance of the Team,
further develops the charter draft
with the goal of achieving consensus on the proposal.
The Chartering Facilitator—who is chosen (and may be replaced) by the Team—is responsible for seeking community consensus among those participating in the refinement process
and making decisions reflecting that consensus.
In cases where consensus cannot be found,
the Chartering Facilitatormay ask the Team to make a Team Decision,
and must document the rationale for the decision.
All issues filed against the charter draft must be formally addressed,
and their resolutions tracked in a disposition of comments
highlighting any issues not resolved by consensus.
The Teammust announce its decision
with the same visibility as the initial charter review notice,
and must include a rationale
if they are not initiating AC Review.
Reaching the end of the announced period (including any announced extension)
with no announced decision
is considered a de-facto Team decision to abandon the proposal.
The Teammay revise such a decision
by announcing an alternative decision.
Objections to decisions pertaining to the content of the charter,
as well as objections to initiating the AC Review,
are considered registered at the close of the Advisory Committee Review of the charter,
and are registered against that W3C Decision.
Objections to abandoning the proposal or to extending the refinement period can be appealed only if 5 or more Members,
through their Advisory Committee representative,
formally object to the decision within 8 weeks of the decision.
In this case,
the Teammust do one of the following:
Abide by the objectors' request, if they all agree on the
alternative course of action (e.g., to abandon,
extend, or complete charter refinement).
Initiate an AC Review to formally solicit the input of
the community and take a W3C Decision on the subsequent
course of action.
Convene a Council to decide the subsequent course of action.
(No action is required to be taken when fewer than 5 members object.)
A Working Group or Interest Group charter
must include all of the following information.
The group’s mission
(e.g., develop a technology or process, review the work of other groups).
The scope of the group’s work and criteria for success.
The duration of the proposed charter for the group.
The nature of any deliverables (technical reports, reviews of the deliverables of other groups, or software).
Expected milestone dates where available.
Note: A charter does not need to include
schedules for review of other group’s deliverables.
The process for the group to approve the release of deliverables
(including intermediate results).
Any dependencies by groups within or outside of W3C on the deliverables of this group.
For any dependencies, the charter must specify
the mechanisms for communication about the deliverables.
Any dependencies of this group on other groups within or outside of W3C.
Such dependencies include interactions with
W3C Horizontal Groups[HR-GROUPS].
The name and affiliation of the Chair or co-Chairs.
Meeting mechanisms and expected frequency.
If known,
the date of the first face-to-face meeting.
The date of the first face-to-face meeting of a proposed group
must not be sooner than eight weeks
after the date of the proposal.
Communication mechanisms to be employed within the group,
between the group and the rest of W3C,
and with the general public.
An estimate of the expected time commitment from participants.
The expected time commitment and level of involvement by the Team
(e.g., to track developments,
write and edit technical reports,
develop code,
or organize pilot experiments).
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
in “Licensing Goals for W3C Specifications”
in the W3C Patent Policy [PATENT-POLICY]?
See also the charter requirements in “Licensing Goals for W3C Specifications”
in the W3C Patent Policy [PATENT-POLICY].
For every Recommendation Track deliverable
that continues work on a technical report
published under any other Charter (including a predecessor group of the same name),
for which there is at least an existing First Public Working Draft
the description of that deliverable in the proposed charter of the adopting Working Group
must provide the following information:
The title,
stable URL,
and publication date of the Working Draft
or other Recommendation-track document
that will serve as the basis for work on the deliverable
(labeled “Adopted Draft”);
The title,
stable URL,
and publication date of the document
that was used as the basis for its most recent Exclusion Opportunity
as per
the W3C Patent Policy [PATENT-POLICY].
(labeled “Exclusion Draft”); and
The stable URL of the Working Group charter
under which the Exclusion Draft was published
(labeled the “Exclusion Draft Charter”).
All of the above data must be identified
in the adopting Working Group’s charter using the labels indicated.
The Adopted Draft and the Exclusion Draftmust each be adopted in their entirety and without any modification.
The proposed charter must state
the dates on which the Exclusion Opportunity
that arose on publishing the Exclusion Draft
began and ended.
As per “Joining an Already Established Working Group”
in the W3C Patent Policy [PATENT-POLICY],
this potentially means that exclusions can only be made immediately on joining a Working Group.
An Interest Group charter
may include provisions regarding participation,
including specifying
that the only requirement for participation (by anyone) in
the Interest Group is subscription to the Interest Group mailing list.
This type of Interest Group
may have public participants.
A charter may include
provisions other than those required by this document.
The charter should highlight
whether additional provisions impose constraints
beyond those of the W3C Process Document
(e.g., limits on the number of individuals in a Working Group
who represent the same Member organization or group of related Members).
The review period must be at least 28 days.
Any Advisory Committee representativemay request an extended review period
in response to the Call for Review;
upon receipt of any such request,
the Teammust extend the review period
to at least 60 days.
The Call for Review of a modified charter
must highlight important changes
(e.g., regarding changes in scope, deliverables, or resource allocation)
and must include rationale for those changes.
The Call for Review of a new or modified charter
must include a disposition of comments received during the charter refinement process,
highlighting any issues that were closed despite sustained objections.
4.4.2.
Minor Changes to Active Charters
Editorial changes or substantive changes to a charter (including extensions)
that do not affect the scope of the group’s work
or the way the group functions in any significant way
are deemed minor changes and
may be approved by a Team Decision,
in which case they do not require charter refinement nor Advisory Committee Review.
Any change to the scope of the charter
or addition of a new REC track deliverable
that does not fall within the scope of an existing deliverable
is a major, not minor, change.
The following are examples of minor changes:
the renaming or restructuring (e.g. splitting or combining) of existing in-scope deliverables,
the addition of new Note track deliverables that help explain the group’s work,
a change of Staff Contact,
or a change of Chair.
Minor changes, other than a change of Staff Contact,
should have the consensus of the group.
If the decision is to charter the group,
the Teammust issue a Call for Participation to the Advisory Committee.
For a new group, this announcement officially creates the group.
The announcement must include a reference to the charter,
the name(s) of the group’s Chair(s),
and the name(s) of the Staff Contact(s).
After a Call for Participation,
any Member representatives
and Invited Expertsmust be designated (or re-designated).
When a group is re-chartered,
individuals participating in the Working Group or Interest Group before the new Call for Participation
may attend any meetings held within forty-five (45) days of the Call for Participation
even if they have not yet formally rejoined the group
(i.e., committed to the terms of the charter and patent policy).
Advisory Committee representatives may initiate
an Advisory Committee Appeal
against the decision to create
or substantially modify
a Working Group or Interest Group charter.
4.6.
Charter Extension
The Teammay decide
to extend a Working Group or Interest Group charter
with no other substantive modifications.
The Teammust announce
such extensions
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,
and the Group homepage
(which includes at least
the name(s) of the group’s Chair(s),
the name of the Staff Contact,
and instructions for joining the group).
Advisory Committee representatives may initiate
an Advisory Committee Appeal against a Team decision
regarding the extension of a Working Group or Interest Group charter.
The TAG or AB determined that continuing operation of the chartered group or its work
would be detrimental to W3C or its mission.
The group produced all chartered deliverables ahead of schedule.
Such a proposal to close a group must be accompanied by rationale,
and the proposal must be confirmed by an AC Review as a W3C Decision.
Closing a Working Group has implications
with respect to the W3C Patent Policy [PATENT-POLICY].
5.
Decisions
W3C attempts to resolve issues through dialog.
Individuals who disagree strongly with a decision
should register with the Chair any Formal Objections.
5.1.
Types of Decisions
The Chair of a Working Group or Interest Group has the prerogative
to make certain decisions based on their own judgment.
Such decisions are called chair decisions.
Decisions made by members of the Team
in connection with this Process,
based on their own individual or collective judgement,
are called Team Decisions.
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 persistent text-based discussions.
The following terms are used in this document
to describe the level of support for a decision among a set of eligible individuals:
Consensus:
A substantial number of individuals in the set
support the decision
and there is no sustained objection from anybody in the set.
Individuals in the set may abstain.
Abstention is either an explicit expression of no opinion
or silence by an individual in the set.
Unanimity:
The particular case of consensus
where all individuals in the set support the decision
(i.e., no individual in the set abstains).
Dissent:
At least one individual in the set sustains an objection.
Note: A Formal Objection always indicates a sustained objection,
but isn’t necessary to express it
(except in the context of formal AC Reviews).
Disagreement with a proposed decision,
however, does not always rise to the level of sustained objection,
as individuals could be willing to accept a decision
while expressing disagreement.
By default, the set of individuals eligible to participate in a decision is the set of group participants.
The Process Document does not require a quorum for decisions
(i.e., the minimal number of eligible participants required to be present before the Chair can call a question).
A charter may include a quorum requirement for consensus decisions.
Where unanimity is not possible,
a group should strive to make consensus decisions
where there is significant support and few abstentions.
The Process Document does not require a particular percentage of eligible participants
to agree to a motion in order for a decision to be made.
To avoid decisions where there is widespread apathy,
(i.e., little support and many abstentions),
groups should set minimum thresholds of active support before a decision can be recorded.
The appropriate percentage may vary depending on the size of the group
and the nature of the decision.
A charter may include threshold requirements for consensus decisions.
For instance, a charter might require a supermajority of eligible participants
(i.e., some established percentage above 50%)
to support certain types of consensus decisions.
Note: Chairs have substantial flexibility
in how they obtain and assess consensus among their groups.
Unless otherwise constrained by charter,
they can use modes including but not limited to explicit calls for consensus,
polls of participants,
“lazy consensus” in which lack of objection after sufficient notice is taken as assent;
they can also delegate and empower a document editor
to assess consensus on their behalf,
whether in general
or for specific pre-determined circumstances
(e.g. in non-controversial situations, for specific types of issues, etc.).
If questions or disagreements arise,
the final determination of consensus remains with the chair.
5.2.2.
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
so that the group can make progress
(for example, to produce a deliverable in a timely manner).
Dissenters cannot stop a group’s work
simply by saying that they cannot live with a decision.
When the Chair believes that the Group has duly considered
the legitimate concerns of dissenters as far as is possible and reasonable,
the group should move on.
Groups should favor proposals that create the weakest objections.
This is preferred over proposals that are supported by a large majority
but that cause strong objections from a few people.
As part of making a decision where there is dissent,
the Chair is expected to be aware of which participants work for the same
(or related)
Member organizations and weigh their input accordingly.
Note: Dissenters can escalate their sustained objection to a decision by registering a Formal Objection.
5.2.3.
Deciding by Vote
A group should only conduct a vote to resolve a substantive issue
after the Chair has determined that all available means of reaching consensus
through technical discussion and compromise have failed,
and that a vote is necessary to break a deadlock.
In this case the 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 individual must be a group participant.
Each organization represented in the group must have at most one vote,
even when the organization is represented by several participants in the group
(including Invited Experts).
For the purposes of voting:
A Member or group of related Members is considered a single organization.
Unless the charter states otherwise,
Invited Expertsmay vote.
If a participant is unable to attend a vote,
that individual may authorize anyone at the meeting
to act as a proxy.
The absent participant must inform the Chair in writing
who is acting as proxy, with written instructions on the use of the proxy.
For a Working Group or Interest Group,
see the related requirements regarding an individual
who attends a meeting as a substitute for a participant.
A group may vote for other purposes than to resolve a substantive issue.
For instance, the Chair often conducts a “straw poll” vote
as a means of determining whether there is consensus about a potential decision.
A group may also vote to make a process decision.
For example,
it is appropriate to decide by simple majority
whether to hold a meeting in San Francisco or San Jose
(there’s not much difference geographically).
When simple majority votes are used to decide minor issues,
voters are not required to state the reasons for votes,
and the group is not required to record individual votes.
A group charter may include formal voting procedures
(e.g., quorum or threshold requirements)
for making decisions about substantive issues.
5.3.
Formally Addressing an Issue
In the context of this document,
a group has formally addressed an issue when it has sent a public, substantive response
to the reviewer who raised the issue.
A substantive response is expected to include rationale for decisions
(e.g., a technical explanation, a pointer to charter scope, or a pointer to a requirements document).
The adequacy of a response is measured
against what a W3C reviewer would generally consider to be technically sound.
If a group believes that a reviewer’s comments result from a misunderstanding,
the group should seek clarification before reaching a decision.
As a courtesy,
both Chairs and reviewers should set expectations
for the schedule of responses and acknowledgments.
The group should reply to a reviewer’s initial comments
in a timely manner.
The group should set a time limit
for acknowledgment by a reviewer of the group’s substantive response;
a reviewer cannot block a group’s progress.
It is common for a reviewer to require a week or more
to acknowledge and comment on a substantive response.
The group’s responsibility to respond to reviewers
does not end once a reasonable amount of time has elapsed.
However, reviewers should realize
that their comments will carry less weight
if not sent to the group in a timely manner.
Substantive responses should be recorded.
The group should maintain an accurate summary
of all substantive issues and responses to them
(e.g., in the form of an issues list with links to mailing list archives).
5.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,
and must do so upon request from a group participant.
5.5.
Registering Formal Objections
Any individual
(regardless of whether they are associated with a Member)
may appeal any decision made in connection with this Process
(except those having a different appeal process)
by registering a Formal Objection with the Team.
Group participants should inform
their Staff Contact as well as the group’s Chair(s).
The Staff Contact must inform the CEO
when a group participant has also raised concerns about due process.
Note: In this document, the term Formal Objection is used to emphasize this process implication:
Formal Objections receive formal consideration and a formal response.
The word “objection” used alone has its ordinary English connotations.
See § 5.2 Consensus Building.
A Formal Objectionmust include a summary of
the issue (whether technical or procedural),
the decision being appealed,
and the rationale for the objection.
It should cite technical arguments
and propose changes that would remove the Formal Objection;
these proposals may be vague or incomplete.
Formal Objections that do not provide substantive arguments
or rationale are unlikely to receive serious consideration.
Counter-arguments,
rationales,
and decisions should also be recorded.
Registering a Formal Objection initiates the process of
addressing the Formal Objection.
The resolution of a recorded Formal Objection—whether by a Council decision, adoption of a consensus proposal, retraction of the Formal Objection, etc.—must be recorded and made available at the same level of visibility as the record of the Formal Objection itself.
5.6.
Addressing Formal Objections
5.6.1.
Investigation and Mediation by the Team
The Team considers the Formal objection,
researches the question,
interviews parties,
and so on,
to make sure the problem and the various viewpoints are well understood,
and to the extent possible,
to arrive at a recommended disposition.
In parallel, the Team should start the steps necessary
to convene a Council.
If the Team can resolve the issue
to the satisfaction of the individual that filed the Formal Objection,
the individual withdraws the objection and the disposition process terminates.
Otherwise,
upon concluding that consensus cannot be found,
and no later than 90 days after the Formal Objection being registered,
the Teammust
deliver to the Council a report
documenting its findings and attempts to find consensus,
and hand over the matter to the W3C Council.
5.6.2.
W3C Council
A W3C Council is the body convened to resolve Formal Objections
by combining the capabilities and perspectives of the AB, the TAG, and the Team,
and is tasked with doing so in the best interests of the Web and W3C.
A distinct instance of the W3C Council is convened for each decision being appealed or objected to.
The list of potential Council members evolves
as AB and TAG terms start and end
until dismissal and renunciation are concluded,
at which point the membership of the Council is fixed.
However, if the number of active members in a Council falls so low as to hinder effective and balanced deliberations,
the Council Chairshould dissolve the Council
and call for a new one to be convened.
Note: TAG and AB elections have no effect on the Council’s membership
once it is fixed.
A Team member is assigned
to act as the Council Staff Contact,
to support this Council
and to facilitate adherence to this Process.
5.6.2.2.
Extraordinary Delegation
In extraordinary cases,
if they feel a Council would not be the appropriate deciding body,
a member of the Team (particularly the Legal Counsel) or
any potential Council member
may suggest that the decision for that specific Formal Objection be delegated
to the W3C Board of Directors,
to an officer of its corporation (such as the Legal Counsel),
or to one or more specific individuals from the Team.
The potential Council members then may confidentially discuss
and must vote
whether to delegate the decision for that specific Formal Objection.
A decision to delegate must be supported by a two-thirds supermajority vote
(i.e., at least twice as many votes in favor as against).
Delegation in such cases cannot be later revoked.
5.6.2.3.
Council Participation, Dismissal, and Renunciation
A potential Council member may be dismissed from the Council.
In order to apply consistent criteria,
the potential Council members decide collectively
which reasons against service
rise to a sufficient level for a potential member to be dismissed.
No-one is automatically dismissed,
and individual recusal is not used in the Council.
Dismissal applies to an individual person in the context of a specific Council,
and should be used rarely in order to preserve the greatest diversity on the Council.
Note: A W3C Council is a deliberative body whose purpose is
to find the best way forward for the Web and for W3C.
It is not a judicial body tasked with determining right or wrong.
The Teammust draft a list of potential Council members,
with annotations of possible reasons for dismissal against each one.
The W3C community,
including members and team, and potential council members,
must be given an opportunity to contribute possible reasons to this list.
Affected members must be given
an opportunity to respond to such comments about themselves.
The Team may report comments verbatim
or may paraphrase them while preserving their intent;
they may also elide inappropriate comments,
such as any that violate applicable laws or the [COC].
Before a Council forms,
the Team presents the entire list of potential members
and collected reasons and responses
to the potential Council members,
who then consider for each potential member
whether that individual’s participation
would compromise the integrity of the Council decision,
and vote whether to dismiss that potential member.
No one is allowed to vote on their own dismissal;
each dismissal is enacted if there are at least as many ballots for as against.
Note: Since dismissal is individual,
when the decision being objected to was made by the TAG or AB acting as a body,
the entire TAG or AB is not expected to be dismissed.
An individual may also renounce their seat on a Council, for strong reason,
such as being forbidden by their employer to serve. The individual chooses the extent to which they explain
their renunciation.
Renunciation is disqualification from participation,
not abstention,
and should not be used
to excuse an absence of participation.
Any person who has been dismissed
or who renounces their seat
does not receive Council materials,
take part in its deliberations,
help in the determination of consensus,
or vote.
The W3C Councilmay still solicit and hear their testimony,
as they can of anyone else in the W3C community.
5.6.2.4.
Short Circuit
The full Council process may be short-circuited if
the Team recommends a resolution
and potential members of a Council who are not renouncing their seat
confirm it by a vote which results in both of the following:
at least 80% of them vote affirmatively to adopt this resolution
none of them vote against adopting the resolution
The request for confirmation must be open for a period of at least two weeks,
or until every potential member of the Council not renouncing their seat
has voted,
whichever is shortest.
Note: This is intended for exceptional cases
that don’t seem to warrant a full Council response
because they are, for instance, too trivial, duplicative, etc.
5.6.2.5.
Council Chairing
The Chair of each W3C Council is chosen by its members,
by consensus if possible,
falling back to a vote if that fails.
The chair must be a member of that W3C Council.
Chair selection happens during formation of each Council,
and must be re-run
if requested by the Council Staff Contact or by the Chair
during the Council’s operation.
Once convened,
the Council may conduct additional research or analysis,
or request additional information or interviews from anyone,
including the Team.
The Council may
further attempt to broker consensus on one or more of the formal objections,
which, if successful, would allow them to be resolved.
Otherwise,
after sufficient deliberation,
and with due consideration of each argument in the applicable Formal Objections,
the W3C Council decides whether to
affirm or overturn the decision being objected to.
The W3C Councilmayaffirm the decision
even if it agrees with some of the arguments made as part of a Formal Objection.
When a decision is affirmed,
all Formal Objections against it are said to be overruled.
Conversely,
aspects of Formal Objections that are found by the Council
to justify overturning a decision
are said to be upheld.
When overturning a decision,
the Councilshould recommend a way forward.
If the overturned decision has already had consequences
pertaining to upheld aspects of the Formal Objection(s)
(e.g., if the objection concerns material already in a published document)
the Council should suggest how these consequences might be mitigated.
The Team is responsible for making sure that adequate mitigations are enacted in a timely fashion;
and the upheld aspects of the Formal Objection(s) (as identified in the Council Report) are not considered fully addressed until then.
Note: This does not create new powers for the Team,
such as the ability to “unpublish” documents.
The Team’s role is to ensure the responsible parties enact adequate mitigations,
by whatever means they already have at their disposal.
A Council may form sub-groups for deliberation,
who may return with a recommendation,
but the full Council issues the final decision.
The decision of the W3C Councilshould be unanimous,
and may be issued under consensus.
However, if despite careful deliberation
a W3C Council is unable to reach consensus,
the W3C Council Chair may instead resort to voting.
In that case,
the decision is adopted if there are more ballots for than against;
in case of a tie,
the W3C Council Chair determines the outcome.
However,
if the decision or proposal being objected to
originated with the TAG or AB,
then members of that group at the time the decision or proposal was made
must abstain in such a vote.
In case of a vote,
if multiple members of a Council who share the same affiliation cast identical ballots,
then these identical ballots count as a single vote.
In the case of non-unanimous decisions,
members of a W3C Council who disagree with the Council’s decision
may write a Minority Opinion
explaining the reason for their disagreement.
Note: This confidentiality requirement is put in place so that
the Council can receive sensitive information in confidence
and to enable Council members to speak freely in their individual expert capacity
without pressure or fear of retaliation
by those involved in the dispute, business relations, their employer, etc.
A Council terminates by issuing a Council Report,
which:
must state whether the Council affirms or overturns the decision being objected to.
must provide a rationale supporting its conclusion,
which should address each argument raised in the Formal Objection(s).
must include any recommendation decided by the Council.
if the decision has been overturned,
must identify which aspects of the Formal Objection(s) are being upheld, and
should include any suggested mitigations.
The Councilmay also issue a Supplemental Confidential Council Report
with a more restricted level of confidentiality than its main report
when it believes that additional commentary on confidential aspects of the case
would be informative.
However, the main Council Reportshould be self-sufficient
and understandable without reference to Supplemental Confidential Council Reports.
Each Advisory Committee review period
begins with a Call for Review from the Team to the Advisory Committee.
The Call for Review describes the proposal,
raises attention to deadlines,
estimates when the decision will be available,
and includes other practical information.
The Teammay share its perspective on the proposal
in the Call for Review.
Each Member organization may send one review,
which must be returned by its Advisory Committee representative.
The Call for Reviewmust specify
which channel is the default for review comments on that Call.
Reviewers may send information
to either or both channels.
A reviewer may also share their own reviews
with other Members on the Advisory Committee discussion list,
and may also make it available to the public.
A Member organization may modify its review
during a review period
(e.g., in light of comments from other Members).
The proposal is adopted,
possibly with additional changes integrated
in order to address the comments of the AC
(see below).
The proposal is returned for additional work,
with a request to the initiator to make desirable changes identified during the review
and to resubmit.
If the proposal is adopted with changes other than class 1 (markup) changes,
then those changes must be announced to the AC
and to the Group that owns the document (if any).
Additionally, when adopting a proposal with substantive changes integrated,
the announcement must include rationale
for the substantive changes.
Substantive changes to the proposal may be adopted
only if the revised proposal has consensus
of the subset of the AC that voted on the initial proposal
(including anyone who explicitly abstained),
or if all Formal Objections against the revised proposal are retracted or overruled
and the revised proposal otherwise has sufficient support to achieve consensus.
For clarity,
the Teamshould seek a response from this subset of the AC
using the same tooling and degree of formality as it did for the AC Review;
and as is the case during AC Reviews,
dissent in this context must be expressed as a Formal Objection.
Any Formal Objection raised at this stage against the revised proposal
is handled by the same Council responsible for Formal Objections raised against the initial proposal,
if any.
Such a Council has the ability to affirm
either the original or the revised proposal for advancement,
thereby overruling all Formal Objections against the original or revised proposal,
respectively.
For publications which have conditions in addition to AC approval
for introducing substantive changes
(such as Group consensus or implementation experience
or going through a patent Exclusion Opportunity),
those other conditions must also be re-fulfilled.
For example, if substantive changes to a technical report
are requested when assessing the transition from
Candidate Recommendation to Recommendation,
the technical report would need to go through a new Update Request
and be republished as a new Candidate Recommendation;
that new version would then need to satisfy the criteria for advancement.
Alternatively, the desired changes can be introduced as non-substantive amendments
using the process for revising a Recommendation.
However, with the exception of the removal of at-risk features,
they cannot be directly integrated between CRS and REC,
because that would fail to trigger a patent exclusion opportunity.
For charters,
substantive changes from the initial proposal that underwent AC Reviewmust not include any increase to the scope.
If any such change is desired,
it must be returned for additional work
and go through a complete new AC Review.
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 Committeeshould not expect an announcement
sooner than two weeks after the end of a review period.
If, after three weeks, the outcome has not been announced,
the Teamshould provide the Advisory Committee with an update.
In all cases,
an appealmust be initiated within three weeks of the decision.
An Advisory Committee representative initiates an appeal by sending a request to the Team,
and should also share this request with the Advisory Committee.
The request should say “I appeal this Decision”
and identify the decision,
and may also include their rationale for appealing the decision.
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 positive support for this appeal.
The archive of these statements must be member-only.
If, within one week of the Team’s announcement,
5% or more of the Advisory Committee support the appeal request,
the Team must organize an appeal vote
asking the Advisory Committee
“Do you approve of the Decision?”
together with links to the decision and the appeal support.
The ballot must allow for three possible responses:
“Approve”,
“Reject”,
and “Abstain”,
together with Comments.
if at least 5% but no more than 15% participate,
and the number of “Approve” ballots exceeds three times (3x) the number of “Reject” ballots,
the vote passes.
if more than 15% but fewer than 20% participate,
and the number of “Approve” ballots exceeds twice (2x) the number of “Reject” ballots,
the vote passes.
if 20% or more participate,
and the number of “Approve” ballots exceeds the number of “Reject” ballots,
the vote passes.
If the vote passes,
the decision is overturned.
Following such rejection,
those who had initiated the proposal may revise it
to address the causes of rejection
and follow the ordinary applicable process
to submit the revised proposal.
6.
W3C Technical Reports
The W3C technical report development process is the set of steps and requirements
followed by W3C Working Groups to standardize Web technology.
The W3C technical report development process is designed to:
support multiple specification development methodologies
maximize consensus 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 “licensing goals for W3C Specifications”
in the W3C Patent Policy [PATENT-POLICY].
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.2.
General Requirements for Technical Reports
6.2.1.
Publication of Technical Reports
Publishing as used in this document
refers to producing a version which is listed as a W3C Technical Report
on its Technical Reports index at https://www.w3.org/TR[TR].
Every document published as part of the technical report development process
must be a public document.
W3C strives to make archival documents indefinitely available
at their original address in their original form.
Every document published as part of the technical report development process
must clearly indicate its maturity stage,
and must 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 editor must be a participant,
per § 3.4.2 Participation in Chartered Groups
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.
A document is available for review
from the moment it is first published.
Working Groups shouldformally addressany substantive review comment
about a technical report in a timely manner.
Reviewers should send substantive technical reviews as early as possible.
Working Groups are often reluctant to make substantive changes to a mature document,
particularly if this would cause significant compatibility problems
due to existing implementation.
Working Groupsshould record substantive
or interesting proposals raised by reviews
but not incorporated into a current specification.
6.2.2.1.
Wide Review
The requirements for wide review are not precisely defined by the W3C Process.
The objective is to ensure that the entire set of stakeholders of the Web community,
including the general public,
have had adequate notice of the progress of the Working Group
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 Team 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[HR-GROUPS]
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 Groupsshould follow the W3C Horizontal Groups’ review processes,
and should announce to other W3C Working Groups
as well as the general public,
especially those affected by this specification,
a proposal to enter Candidate Recommendation
(for example in approximately 28 days).
By contrast a generic statement in a document
requesting review at any time
is likely not to be considered as sufficient evidence
that the group has solicited wide review.
A Working Group could present evidence that wide review has been received,
irrespective of solicitation.
But it is important to note that receiving many detailed reviews
is not necessarily the same as wide review,
since they might only represent comment
from a small segment of the relevant stakeholder community.
6.2.3.
Classes of Changes
This document distinguishes the following 5 classes of changes to a document.
The first two classes of change are considered editorial changes,
the next two substantive changes,
and the last one registry changes.
No changes to text content
These changes include fixing broken links, style sheets, or invalid markup.
Changes that do not functionally affect interpretation of the document
For Recommendation-tracktechnical reports specifically,
this constitutes changes that do not affect conformance,
i.e. 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 examples
which clearly conflict with normative requirements,
clarifying various other non-normative text,
fixing typos or grammatical errors
where the change does not change requirements.
If there is any doubt or disagreement
as to whether a change functionally affects interpretation,
that change does not fall into this class.
Other changes that do not add new features
For Recommendation-track documents,
these changes may affect conformance to the specification.
A change that affects conformance is one that:
makes conforming data, processors, or other conforming agents become non-conforming according to the new version,
or
makes non-conforming data, processors, or other agents become conforming,
or
clears up an ambiguity or under-specified part of the specification
in such a way that data,
a processor,
or an agent
whose conformance was once unclear
becomes clearly either conforming or non-conforming.
New features
Changes that add new functionality,
such as new elements, new APIs, new rules, etc.
Tracking errors is an important part of a Working Group’s ongoing care of a technical report;
for this reason,
the scope of a Working Group charter generally allows time
for work after publication of a Recommendation.
In this Process Document,
the term “erratum”
(plural “errata”) refers to any error
that can be resolved by one or more changes in classes 1-3
of section § 6.2.3 Classes of Changes.
Working Groupsmust keep
a public record of errors
that are reported by readers and implementers
for Recommendations.
Such error reports should be compiled
no less frequently than quarterly.
Working Groups decide how to document errata.
Such documentation must identify
the affected technical report text
and describe the error;
it may also describe some possible solution(s).
Readers of the technical reportshould be able easily
to find and see the errata
that apply to that specific technical report with their associated tests.
Errata may be documented
in a separate errata page or tracking system.
They may,
in addition or alternatively,
be annotated inline
alongside the affected technical report text
or at the start or end of the most relevant section(s).
Inline errata are treated as class 2 changes,
and are published accordingly.
A candidate amendment is a non-normative annotation,
marked as such,
integrated into a technical report by group decision
to indicate a potential substantive change
that has not yet been formally adopted.
They are treated as class 2 changes,
and are published accordingly.
Note: Annotating changes in this way allows more mature documents
such as Recommendations and Candidate Recommendations
to be updated quickly with the Working Group’s most current thinking,
even when the candidate amendments have not yet received
sufficient review or implementation experience
to be normatively incorporated into the specification proper.
To avoid any potential doubt or disagreement
about whether changes really do fall into class 2,
the Teamshould be conservative,
limiting itself to obvious and limited fixes,
and must avoid substantial rephrasing,
even of non-normative examples and notes.
If any such change is desired,
the Teammust mark it as a Team correction.
When a party who is not already obligated under the Patent Policy
offers a change in class 3 or 4
(as described in § 6.2.3 Classes of Changes) to a technical report under this process
the Teammust request
a recorded royalty-free patent commitment;
for a change in class 4, the Team mustsecure such commitment.
Such commitment should cover,
at a minimum,
all the party’s Essential Claims both in the contribution,
and that become Essential Claims as a result of incorporating the contribution into the draft
that existed at the time of the contribution,
on the terms specified in the “W3C Royalty-Free (RF) Licensing Requirements” section of the W3C Patent Policy [PATENT-POLICY].
6.3.
The W3C Recommendation Track
Working Groups create specifications and guidelines
to complete the scope of work envisioned by a Working Group’s charter.
These technical reports undergo cycles of revision and review
as they advance towards W3C Recommendation status.
Once review suggests the Working Group has met their requirements for a new standard,
including wide review,
a Candidate Recommendation phase
allows the Working Group to formally collect implementation experience
to demonstrate that the specification works in practice.
At the end of the process,
the Advisory Committee reviews the mature technical report,
and if there is support from its Membership,
W3C publishes it as a Recommendation.
In summary, the main steps of the W3C Recommendation Track are:
Only sufficiently technically mature work should be advanced.
As described in § 6.3.3 Advancement on the Recommendation Track,
the Team will decline a request to advance in maturity stage
and return the specification to a Working Group for further work
if it determines that the requirements for advancement
have not been met.
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.
6.3.1.
Maturity Stages on the Recommendation Track
A W3C Recommendation Track document
is any document whose current status is one of those described in this section.
Working Draft (WD)
A Working Draft is a document that W3C has published
on the W3C’s Technical Reports page[TR]
for review by the community (including W3C Members), the public,
and other technical organizations,
and for simple historical reference.
Some, but not all, Working Drafts are meant to advance to Recommendation;
see the document status section of a Working Draft
for the group’s expectations.
Working Drafts do not necessarily represent a consensus of the Working Group with respect to their content,
and do not imply any endorsement by W3C
or its members beyond agreement to work on a general area of technology.
Nevertheless the Working Group decided to adopt the Working Draft
as the basis for their work at the time of adoption.
A Working Draft is suitable for gathering wide review
prior to advancing to the next stage of maturity.
For all Working Drafts a Working Group:
should document outstanding issues,
and parts of the document on which the Working Group does not have consensus,
and
may request publication of a Working Draft
even if its content is considered unstable
and does not meet all Working Group requirements.
The first Working Draft of a technical report is called the First Public Working Draft (FPWD),
and has patent implications as defined in the W3C Patent Policy [PATENT-POLICY].
Candidate Recommendation (CR)
A Candidate Recommendation is a document that satisfies the technical
requirements of the Working Group that produced it and their dependencies,
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
Note: Advancing to Candidate Recommendation indicates
that the document is considered complete and fit for purpose,
and that no further refinement to the text is expected
without additional implementation experience and testing;
however, additional features might be expected in a later revision.
A Candidate Recommendation is expected to be as well-written,
detailed,
self-consistent,
and technically complete
as a Recommendation,
and acceptable as such
if and when the requirements for further advancement are met.
Candidate Recommendation publications take one of two forms:
Candidate Recommendation Snapshot (CRS)
A Candidate Recommendation Snapshot
corresponds to a Patent Review Draft
as used in the W3C Patent Policy [PATENT-POLICY].
Publishing a Patent Review Draft triggers a Call for Exclusions,
per “Exclusion From W3C RF Licensing Requirements”
in the W3C Patent Policy.
Candidate Recommendation Draft (CRD)
A Candidate Recommendation Draft
is published
to solicit review of intended changes from the previous Candidate Recommendation Snapshot.
This allows for wider review of the changes
and for ease of reference to the integrated specification.
Any changes published directly into a Candidate Recommendation Draft
should be at the same level of quality as a Candidate Recommendation Snapshot.
However, the process requirements are minimized
so that the Working Group can easily keep the specification up to date.
A Rescinded Candidate Recommendation
is a Candidate Recommendation in which significant problems have been discovered
such that W3C cannot endorse it or continue work on it,
for example due to burdensome patent claims that affect implementers and cannot be resolved
(see the W3C Patent Policy [PATENT-POLICY]
and in particular “PAG Conclusion”).
There is no path to restoration for a Rescinded Candidate Recommendation.
See “W3C Royalty-Free (RF) Licensing Requirements”
in the W3C Patent Policy [PATENT-POLICY]
for implication on patent licensing obligations.
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 and its Members.
W3C recommends the wide deployment
of its Recommendations as standards for the Web.
The W3C Royalty-Free IPR licenses
granted under the W3C Patent Policy [PATENT-POLICY]
apply to W3C Recommendations.
A Superseded Recommendation
A Superseded Recommendation is a specification
that has been replaced by a newer version
that W3C recommends for new adoption.
An Obsolete or Superseded specification
has the same status as a W3C Recommendation
with regards to W3C Royalty-Free IPR Licenses granted under the Patent Policy.
Note: When a Technical Report which had previously been published as a Recommendation
is again published as a Recommendation
after following the necessary steps to revise it,
the latest version replaces the previous one,
without the need to invoke the steps of § 6.3.12.3 Abandoning a W3C Recommendation:
it is the same document, updated.
Explicitly declaring a documented superseded, using the process documented in § 6.3.12.3 Abandoning a W3C Recommendation,
is intended for cases where a Recommendation is superseded by a separate Technical Report
(or by a document managed outside of W3C).
An Obsolete Recommendation
An Obsolete Recommendation is a specification
that 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,
W3C may decide to restore it to Recommendation status.
Rescinded Recommendation
A Rescinded Recommendation is an entire Recommendation that W3C no longer endorses,
and believes is unlikely to ever be restored to Recommendation status.
See also “W3C Royalty-Free (RF) Licensing Requirements”
in the W3C Patent Policy [PATENT-POLICY].
Discontinued Draft
A technical report representing the state of a Recommendation-track document
at the point at which work on it was discontinued.
See § 6.3.12.1 Abandoning an Unfinished Recommendation.
This Process defines certain Recommendation Track publications as Patent Review Drafts.
Under the 2004 Patent Policy (and its 2017 update) [PATENT-POLICY-2004],
these correspond to “Last Call Working Draft” in the Patent Policy;
Starting from the 2020 Patent Policy [PATENT-POLICY-2020],
these correspond to “Patent Review Draft” in the Patent Policy [PATENT-POLICY].
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.
6.3.2.
Implementation Experience
Implementation experience is required to show that a specification is sufficiently clear,
complete,
and relevant to market needs,
to ensure that independent interoperable implementations
of each feature of the specification will be realized.
While no exhaustive list of requirements is provided here,
when assessing that there is adequate implementation experience
the Team 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.3.3.
Advancement on the Recommendation Track
For all requests to advance a specification
to a new maturity stage
(called Transition Requests),
the Working Group:
must record the group’s decision to request advancement.
must obtain Team verification.
Team verification (a Team decision)
must be withheld if any Process requirements are not met
or if there remain any unresolved Formal Objections
(including any aspect upheld by a Council but not yet fully addressed),
or if the document does not adequately reflect all relevant decisions of the W3C Council (or its delegates).
If the Team rejects a Transition Request
it must indicate its rationale
to the Advisory Committee and the Working Group.
must publicly document all new features
(class 4 changes) to the technical report
since the previous publication.
must publicly document if other substantive changes
(class 3 changes) have been made,
and should document the details of such changes.
should publicly document if editorial changes have been made,
and may document the details of such changes.
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 stage”,
so many requirements do not apply,
and verification is normally fairly straightforward.
For later stages,
especially transitions to Candidate or Recommendation,
there is usually a formal review meeting
to verify that the requirements have been met.
6.3.4.
Updating Mature Publications on the Recommendation Track
Certain requests to re-publish a specification
within its current maturity stage
(called Update Requests)
require extra verification.
For such update requests, the Working Group:
must record the group’s decision to request the update.
must show that the changes have received wide review.
should be withheld
if any Process requirements are not met,
may be withheld
in consideration of unresolved Formal Objections
(including any aspect upheld by a Council but not yet fully addressed),
may be withheld
if the document does not adequately reflect
all relevant decisions of a W3C Council (or its delegates),
may be withheld
if the Team believes the Group is not making reasonable progress
on addressing issues raised by individuals external to the Group.
If the Team rejects an Update Request,
it must indicate its rationale to the Working Group.
If it waives any Process requirements,
it must indicate its rationale to the AC.
A Working Groupshouldpublish 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.
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 specify the deadline for comments,
delineating the Candidate Recommendation review period,
which must be at least 28 days after publication,
and should be longer for complex documents,
must show that the specification has received wide review, and
may identify features in the document as at risk.
These features may be removed
before advancement to Recommendation
without requiring an Update Request.
must specify the deadline for further comments,
which must be at least 28 days after publication,
and should be longer for complex documents,
may identify features in the document as at risk.
These features may be removed
before advancement to Recommendation
without requiring an Update Request.
To provide timely updates and patent protection,
a Candidate Recommendation Snapshotshould be published
within 24 months of the Working Group accepting
any proposal for a substantive change
(and preferably sooner).
To make scheduling reviews easier,
a Candidate Recommendation Snapshotshould not be published
more often than approximately once every 6 months.
Note:Substantive changes trigger a new Exclusion Opportunity
per “Exclusion From W3C RF Licensing Requirements”
in the W3C Patent Policy [PATENT-POLICY].
A Working Groupshouldpublish an Update Draft
to the W3C Technical Reports page
when there have been significant changes
to the previous published document
that would benefit from review beyond the Working Group.
Note:
In earlier version of the Process,
new features (class 4 changes) could only be added to Recommendations
that had explicitly opted into this ability
prior to their first publication as Recommendation.
Otherwise,
new features could only be added by creating a new technical report
and following the full process of advancing that technical report to Recommendation—beginning with a new First Public Working Draft.
For simplicity, this restriction has been lifted.
6.3.10.3.
Incorporating Candidate Amendments
A Last Call for Review of Proposed Amendments
verifies acceptance by the W3C community of candidate amendments
by combining an AC Review with a patent exclusion opportunity.
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.
It is possible that W3C decides
that implementing a particular Recommendation is no longer recommended.
There are three designations for such specifications,
chosen depending on the advice W3C wishes to give about further use of the specification.
W3C may obsolete a Recommendation,
for example if the W3C Community decides that the Recommendation no longer represents best practices,
or is not adopted and is not apparently likely to be adopted.
An Obsolete Recommendationmay be restored to normal Recommendation,
for example because despite marking it Obsolete the specification is later more broadly adopted.
W3C may declare a Recommendation Superseded
if a newer version exists which W3C recommends for new adoption.
The process for declaring a Recommendation Superseded is the same as for declaring it Obsolete, below;
only the name and explanation change.
W3C may rescind a Recommendation
if W3C believes there is no reasonable prospect of it being restored
for example due to burdensome patent claims that affect implementers and cannot be resolved;
see the W3C Patent Policy [PATENT-POLICY]
and in particular “W3C Royalty-Free (RF) Licensing Requirements”
and “PAG Conclusion”.
W3C only rescinds, supersedes, or obsoletes entire Recommendations.
A Recommendation can be both superseded and obsolete.
To rescind, supersede, or obsolete some part of a Recommendation,
W3C follows the process for modifying a Recommendation.
Non-Normative Summary of the Paths to Retiring a W3C Recommendation
6.3.12.4.
Process for Rescinding, Obsoleting, Superseding, Restoring a Recommendation
The process of rescinding, obsoleting,
superseding,
or restoring
a Recommendation can be initiated
either by a request from the Team
or via a request from any of the following:
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, supersede, or restore a Recommendation,
where the request was not answered within 90 days
supporting documentation for a specification,
such as explanations of design principles
or use cases and requirements
non-normative guides to good practices
Some Notes are developed through successive Note Drafts
before publication as a full Notes,
while others are published directly as a Note.
There are few formal requirements to publish a document as a Note or Note Draft,
and they have no standing as a recommendation of W3C
but are simply documents preserved for historical reference.
Note: The W3C Patent Policy [PATENT-POLICY]
does not apply any licensing requirements or commitments for Notes or Note Drafts.
A Note specifying implementable technology should not be elevated to W3C Statement status;
if it does,
the request to publish as a Statementmust include rationale
for why it should be elevated,
and why it is not on the Recommendation track.
Once these conditions are fulfilled,
the Teammust then
begin an Advisory Committee Review on the question of
whether the document is appropriate to publish as a W3C Statement.
During this review period,
the Notemust not be updated.
A registry documents a data set
consisting of one or more registry tables,
each table representing an updatable collection
of logically independent, consistently-structured registry entries.
A registry consists of:
one or more registry tables, holding the data set represented by the registry (the registry data)
The purposes of maintaining a registry can include:
non-collision
Avoiding the problem
of two entities using the same value with different semantics.
non-duplication
Avoiding the problem
of having two or more different values in use with the same semantics.
information
Providing a central index
where anyone can find out
what a value means
and what its formal definition is
(and where it is).
submission
Ease of adding new terms,
including by stakeholders external to the custodian organization.
consensus
Promoting a clear consensus of the community on the terms.
This section of the W3C Process provides a specialized process
facilitating the publication and maintenance of such registry tables,
particularly those required by or closely related to W3C Recommendations.
Note: Not every table in a specification is a potential registry.
If the intent or effect is that the table enumerates
all the possibilities the authors of the specification expect or envisage,
then the table by itself is enough.
Similarly, if the table is managed by the Working Group
and only updated as part of specification update,
then the complexities of registry management are not needed.
6.5.1.
Registry Definitions
A registry definition
defines what each registry table is and how it is maintained.
It must:
Define the fields of each registry table
and their constraints
(e.g. values must be drawn from a defined set, or be unique,
or only reference publicly available resources,
etc.)
Define the policy for changes to existing entries, such as
whether entries can be deleted or deprecated
whether entries can be changed after being published, and what kinds of changes are allowed
whether previously-deleted unique identifiers can be re-used, or are reserved indefinitely
Define the method and criteria by which changes are proposed, approved, and incorporated.
(For example, a registry could define
that changes to registry entries can be proposed using a particular web form or email address,
that they must be accompanied by certain background information,
or that they do or do not need to be approved by any member of a particular Working Group.)
Identify the custodian of the registry table:
the entity to which requests for registry changes must be sent,
and which is responsible for evaluating whether such requests
satisfy the criteria defined in the registry definition.
Including the entire contents of each registry table,
either inline in the report
(e.g. formatted as a table, or list, or other appropriate representation),
or in a machine-readable file published as part of the technical report,
or (preferably) both.
Linking to one or more standalone Registry Data Reports
containing the registry tables
in human-readable form, machine-readable form,
or (preferably) both.
Include, if the registry table is provided in a machine-readable file,
a definition of the format of that file.
The Teammust make available
a means for interested parties to be notified of any updates to a registry table.
Note: Since the Process does not impose requirements
on changes to the contents of a registry table
other than those imposed by the registry definition,
acceptance of proposed registry changes on behalf of the custodian and
publication of an updated registry report that contains
only registry changes since the previous publication
can be automated
if satisfaction of those rules can be automatically verified.
Rules for publication and advancement on the Registry Track
are identical to that of the Recommendation Track
with the following exceptions:
Changes that add new features (i.e., class 4 changes) are allowed
in all W3C Registries,
without needing them to explicitly indicate that this is allowed.
6.5.3.
Updating Registry Tables
Changes to the contents of a registry table that are in accordance with the registry definition,
(i.e. Class 5 changes)
can be made by re-publishing the technical report that contains the affected table,
without needing to satisfy any other requirements for the publication
(not even a group decision, unless this is required by the registry definition).
Such registry changes do not trigger new Advisory Committee Reviews,
nor Exclusion Opportunities,
and do not require verification via an update request,
even for technical reports at maturities where this would normally be expected.
Such publications can be made
even in the absence of a group chartered to maintain the registry
when the custodian is another entity.
Note: The custodian is only empowered to make registry changes.
If the group establishing the registry wishes
to empower the custodian to add commentary on individual entries,
this needs to be part of the registry table’s definition.
If other changes are desired,
they need to be requested of the group responsible for maintaining the registry definition—or in the absence of such a group, of the Team.
May contain non-normative introductory text, examples, and notes
about the registry tables and entries that it contains.
(Changes to these parts are deemed to be editorial changes).
Anytime a change is made to a registry definition,
the group maintaining the registry definitionmust update and republish
any document holding the corresponding registry tables
to make it consistent with these changes.
Registries document values,
they do not define any architectural or interoperability requirements
related to those values.
All architectural and interoperability requirements
pertaining to registry entriesmust be contained in the specifications that reference the registry,
and are therefore subject to the processes
(including approval and intellectual property provisions)
applicable to those referencing specifications.
If there are entries that must be implemented,
or any other such restrictions,
they must be defined or documented
in the referencing specification
without dependency on the registry.
For example,
“All implementations must implement the Basic-Method as defined in the registry”
is not acceptable because
a change to the definition of the Basic-Method in the registry would then affect conformance.
Instead, the requirement has to be complete in the specification,
directly or by reference to another specification.
For example
“All implementations must recognize the name Basic-Method,
and implement it as defined by section yy of IETF RFC xxxx”.
(The Registry is nonetheless expected to contain Basic-Method as an entry.)
A technical report should not switch away from the Recommendation Track
without due consideration of the Patent Policy implications
and approval of W3C’s legal counsel
if the Working Group envisions a likelihood of returning to it later.
Technical reports that switch tracks start at
their new track’s initial maturity stage,
while retaining any established identity (url, shortname, etc.).
The Team is responsible for managing communication within W3C
and with the general public
(e.g., news services, press releases, managing the website and access privileges, and managing calendars).
Members should solicit review by the Team
prior to issuing press releases about their work within W3C.
The Team makes every effort to ensure the persistence and availability of the following public information:
W3C technical reports whose publication has been approved.
Per W3C IPR Policies,
W3C technical reports (and software) are available free of charge to the general public.
A mission statement[MISSION]
that explains the purpose and mission of W3C,
the key benefits for Members,
and the organizational structure of W3C.
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.
7.2.
Confidentiality Levels
There are three principal levels of access to W3C information
(on the W3C website, in W3C meetings, etc.):
public,
Member-only,
and Team-only.
While much information made available by W3C is public,
“Member-only” information
is available to authorized parties only,
including representatives of Member organizations,
Invited Experts (as described in https://www.w3.org/invited-experts/#memaccess),
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.
must treat the information as confidential within W3C,
must use reasonable efforts to preserve that confidentiality, and
must not release this information to the general public or press,
nor beyond the designated level of access.
The Teammust provide mechanisms
to protect the confidentiality of Member-only information
and ensure that authorized parties have proper access to this information.
Documents should clearly indicate
whether they require Member-only confidentiality.
Individuals uncertain of the confidentiality level of a piece of information
should contact the Team.
Advisory Committee representativesmay 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].
7.3.
Changing Confidentiality Level
As a benefit of membership,
W3C provides some Team-only and Member-only channels
for certain types of communication.
For example, Advisory Committee representatives
can send reviews to a Team-only channel.
However, for W3C processes with a significant public component,
such as the technical report development process,
it is also important for information that affects decision-making to be publicly available.
The Team may need to communicate Team-only information to a Working Group or the public.
Similarly, a Working Group whose proceedings are Member-onlymust make public
information pertinent to the technical report development process.
This document clearly indicates which information must be available to Members or the public,
even though that information was initially communicated on Team-only or Member-only channels.
Only the Team and parties authorized by the Team
may change the level of confidentiality of this information.
When doing so:
The Teammust use a version of the information
that was expressly provided by the author for the new confidentiality level.
In Calls for Review and other similar messages,
the Team should remind recipients to provide such alternatives.
The Teammust not attribute the version
for the new confidentiality level to the author without the author’s consent.
If the author has not conveyed to the Team a version
that is suitable for another confidentiality level,
the Team may make available a version that reasonably communicates what is required,
while respecting the original level of confidentiality,
and without attribution to the original author.
8.
Liaisons
W3C uses the term liaison
to refer to coordination of activities with a variety of organizations,
through a number of mechanisms
ranging from very informal
(e.g., an individual from another organization participates in a W3C Working Group,
or just follows its work)
to mutual membership,
to even more formal agreements.
Liaisons are not meant to substitute for W3C membership.
All liaisons must be coordinated by the Team
due to requirements for public communication;
patent,
copyright,
and other IPR policies;
confidentiality agreements;
and mutual membership agreements.
W3C may negotiate
technical agreements with another organization.
For purposes of the W3C Process,
a technical agreement is a formal contract,
or a Memorandum of Understanding (MoU),
or a similar document,
between W3C and another party or parties,
that relates to the technical activity of the Consortium
(e.g., its publications, groups, or liaisons).
It 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.
Non-technical agreements, including
those between W3C and its Members for the purposes of membership,
between W3C and its Partners for the purposes of partnership [BYLAWS],
and other agreements related to the operation of the Consortium
or to the ordinary provision of services,
are not subject to these Process provisions.
When considering a technical agreement
(i.e., before the decision whether to sign is made),
the Team should provide
the Advisory Committee with a draft of the proposed agreement,
along with an explanation of how W3C would benefit from signing this agreement,
for their review and discussion.
After addressing any comments,
and subject to any management or governance procedures that apply
(e.g., formal review of proposed contracts by legal counsel or by the Board),
if the Team decides to proceed with signing the agreement,
the Team must announce the intent to sign,
and provide the final text of the agreement,
with an explanation of signing rationale, to
the Advisory Committee.
Advisory Committee representativesmay initiate an Advisory Committee Appeal
of the decision to sign the agreement.
If the proposal is rejected on appeal,
the Teammust not sign the agreement on behalf of W3C
unless directed to do so by the Board.
A signed agreementshould be made public.
A Member Submission is a document or set of documents
developed outside of W3C,
and submitted to W3C
by one or more Members (the Submitter(s))
to propose technology or other ideas.
After review,
the Teammay make the material available at the W3C website.
Making a Member Submission available at the W3C website
does not indicate endorsement, acceptance, or adoption by W3C,
its Team, or its 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 has been made by the Submitter(s).
A Member Submission made available by W3C
is not a W3C technical report and
must not be referred to as
an output or “work in progress” of W3C.
Submission
One of the Submitters,
copying the Advisory Committee representatives of the other Submitters (if any),
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.
Review
The Team reviews the Submission
to evaluate its scope, quality, and compliance with the Submission requirements,
including licensing requirements:
Revision of the W3C Process and related documents (see below) undergoes similar consensus-building processes as for technical reports,
with the Advisory Board
acting as the sponsoring Working Group.
The documents may be developed by the AB or by another group to whom the AB has delegated development.
Review includes
soliciting input from the W3C community,
and in particular the Team.
After comments have been formally addressed and the document possibly modified,
the Team seeks endorsement from the Members by initiating an Advisory Committee review.
The review period must last at least 28 days.
Previous versions of this process defined and used various concepts and document statuses
that have since been retired or renamed.
For ease of reference,
this appendix lists the more notable ones,
and it links to the the definition or relevant section
in the most recent version of the Process that used them,
and gives the more recent equivalent term when there is one.
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:
Brent Zundel (Yubico),
Chris Needham (BBC),
Daniel Montalvo (W3C),
Elika J. Etemad aka fantasai,
Jeffrey Yasskin (Google),
Nigel Megitt (BBC),
Philippe Le Hegaret (W3C),
Tantek Çelik (Mozilla),
Ted Thibodeau Jr (OpenLink Software),
Theresa O’Connor (Apple).
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:
Adam Basha,
Alex Russell (Google),
Andreas Tai (Institut fuer Rundfunktechnik),
Andrew Betts (Fastly),
Ann Bassetti (The Boeing Company),
Anna Weinberg (Apple)
Anne van Kesteren,
Art Barstow (Nokia, unaffiliated),
Bede McCall (MITRE),
Ben Wilson,
Brad Hill (Facebook),
Brian Kardell (JQuery, Igalia),
Carine Bournez (W3C),
Carl Cargill (Netscape, Sun Microsystems, Adobe),
Charles McCathie Nevile,
Chris Lilley (W3C),
Chris Needham (BBC),
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 (IBM),
David W. Singer (Apple),
Delfí Ramírez,
Denis Ah-Kang (W3C),
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),
Giri Mandyam (Qualcomm),
Gregg Kellogg,
Hadley Beeman,
Håkon Wium Lie (Opera Software),
Helene Workman (Apple),
Henri Sivonen (Mozilla),
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),
Jeffrey Yasskin (Google),
Jill Schmidt (Apple),
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),
Léonie Watson (The Paciello Group),
Liam Quin (W3C),
Marcos Cáceres,
Maria Courtemanche (IBM),
Mark Crawford (SAP),
Mark Nottingham,
Martin Thomson (Mozilla),
Michael Champion,
Michael Geldblum (Oracle),
Michael Sirtori (Intel),
Mike Smith (W3C),
Mike West (Google),
Mitch Stoltz (EFF),
Natasha Rooney (GSMA),
Nick Doty (Center for Democracy and Technology),
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),
Sam Sneddon,
Samuel Weiler (W3C),
Sandro Hawke (W3C),
Sangwhan Moon (Odd Concepts),
Scott Peterson (Google),
Shawn Lawton Henry (W3C),
Steve Holbrook (IBM),
Steve Zilles (Adobe Systems)
Steven Pemberton (CWI),
Tantek Çelik (Mozilla),
Ted Thibodeau Jr (OpenLink Software),
Terence Eden (Her Majesty’s Government),
Theresa O’Connor (Apple),
Thomas Reardon (Microsoft),
Tim Berners-Lee (W3C),
Tim Krauskopf (Spyglass),
Travis Leithead (Microsoft),
TV Raman (Google),
Virginia Fournier (Apple),
Virginie Galindo (Gemalto),
Vivien Lacourba (W3C),
Wayne Carr (Intel),
Wendy Fong (Hewlett-Packard),
Wendy Seltzer (W3C),
Yves Lafon (W3C).
In addition to a number of editorial adjustments and minor tweaks, the following is a summary of the main differences:
Generalize the phrasing about how to handle votes in the council
when several people share an affiliation
to handle more than 2.
(See Issue 1018)
Clarify timing of guidance as when to run (or not) an election for vacated seats.
(See Pull Request 1038)
Give the Advisory Board a mission statement.
(See Pull Request 1021)
If Member organizations have a Consortium Member Representative,
that person is that company’s Advisory Committee Representative.
Organizations that wants different individuals to exercise different subsets
of the corresponding responsibilities
can use the alternate AC representative mechanism.
(See Pull Request 937)
Harmonize the affiliation constraints for the AB and TAG.
(See Issue 817)
Allow alternate AC Reps to attend AC meetings as a matter of course
(See Issue 1092)
Remove AB Liaisons to the Board, as the Board has terminated the AB Liaison program
(See Pull Request 1179)
Remove the AB involvement from TAG appointee ratification
(See Issue 810)
Stop distinguishing between Recommendations that allow new features and those that cannot,
by always allowing new features,
and simplify terminology accordingly.
(See Pull Request 1168)