W3C Process Document
W3C Process Document
18 August 2025
More details about this document
This version:
Latest published version:
Editor’s Draft:
Previous Versions:
Feedback:
Github (preferred)
Public mailing list
Member-only mailing list
Editors:
Elika J. Etemad / fantasai
Apple
Florian Rivoal
Invited Expert
Former Editors:
Natasha Rooney
Invited Expert
Charles McCathie Nevile
Yandex
Ian Jacobs
W3C
World Wide Web Consortium
W3C
liability
trademark
and
permissive document license
rules apply.
Abstract
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
Status of this document
This document is the
18 August 2025 Process
W3C, including all existing chartered groups,
follows the
most recent operative Process Document
announced to the Membership.
This document is developed by the Advisory Board’s Process Task Force
working within the
W3C Process Community Group
(which anyone can join).
history of substantial changes
from previous versions of the Process Document is provided.
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.
W3C’s technical standards, called
W3C Recommendations
are developed by its
Working Groups
W3C also has other types of publications,
all described in
§ 6 W3C Technical Reports
W3C has various types of groups;
this document describes the formation and policies
of its chartered
Working Groups
and
Interest Groups
see
§ 3.1 Policies for Participation in W3C Groups
and
§ 3.4 Chartered Groups: Working Groups and Interest Groups
W3C also operates Community and Business Groups,
which are separately described in
their own process document
[BG-CG]
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.
Further sections of this Process Document deal with topics including
liaisons (
§ 8 Liaisons
),
confidentiality (
§ 7 Dissemination Policies
),
and formal decisions and appeals (
§ 5 Decisions
).
2.
Members and the Team
W3C’s mission is to lead the Web to its full potential.
W3C
Member
organizations provide resources to this end,
and the W3C
Team
provides the technical leadership
and organization to coordinate the effort.
2.1.
Members
W3C Members
are
organizations subscribed according to a
Membership Agreement
[MEMBER-AGREEMENT]
They are represented in W3C processes as follows:
One representative per Member organization participates
in the
Advisory Committee
which oversees the work of W3C.
Representatives of Member organizations participate
in
Working Groups and Interest Groups
where they author and review
technical reports
W3C membership is open to all entities,
as described in “
How to Join W3C
[JOIN]
(refer to the public list of
current W3C Members
[MEMBER-LIST]
).
The
Team
must
ensure
that Member participation agreements remain
Team-only
and that no Member receives preferential treatment within W3C.
While W3C does not have a class of membership tailored to individuals,
individuals
may
join W3C.
Restrictions pertaining to
related Members
apply
when the individual also
represents
another W3C Member.
2.1.1.
Rights of Members
Each Member organization enjoys the following rights and benefits:
A seat on the
Advisory Committee
Access to
Member-only
information;
The
Member Submission
process;
Use of the W3C Member logo on promotional material and to publicize the Member’s participation in W3C.
For more information, please refer to the Member logo usage policy
described in the
New Member Orientation
[INTRO]
Furthermore, subject to further restrictions included in their Member Agreement,
representatives of Member organizations participate in W3C as follows:
In
Working Groups and Interest Groups
In
Workshops
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]
On the Team, as
W3C Fellows
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
Additional information for Members is available at the
Member website
[MEMBER-HP]
2.1.2.
Member Associations and Related Members
2.1.2.1.
Membership Associations
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 Associations
may
also designate
up to four (or more at the Team’s discretion) individuals
who, though not employed by the organization,
may
exercise the rights of
Member representatives
For
Member 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:
Either Member is a
subsidiary
of the other, or
Both Members are
subsidiaries
of a common entity, or
The Members have an employment contract or consulting contract that affects W3C participation.
subsidiary
is an organization of which effective control and/or majority ownership rests with another,
single organization.
Related Members
must
disclose these relationships
according to the mechanisms described in the
New Member Orientation
[INTRO]
2.1.3.
Good Standing
Members
who have not lost Good Standing as defined in the
Amended and Restated Bylaws of World Wide Web Consortium, Inc.
are considered, for the purposes of this Process,
to be in
Good Standing
A group of
related Members
is in Good Standing if
at least one of them is in Good Standing.
2.2.
The W3C Team
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.
3.
Groups and Participation
For the purposes of this Process, a
W3C Group
is one of W3C’s
Working Groups
Interest Groups
Advisory Committee
Advisory Board
or
TAG
and a
participant
is a member of such a group.
3.1.
Policies for Participation in W3C Groups
3.1.1.
Individual Participation Criteria
3.1.1.1.
Expectations and Discipline
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
CEO
may
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
Team
may
appoint a new group
Chair
when the current Chair changes affiliations
(e.g., if there is a risk of conflict of interest,
or if there is risk that the Chair’s new employer will be over-represented within a W3C activity).
The following are some scenarios where disclosure is appropriate:
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
Team
members are subject to the
Conflict of Interest Policy for the W3C Team
[CONFLICT-POLICY]
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 representative
may
designate a non-employee
to represent the Member.
Non-employee Member representatives
must
disclose
relevant affiliations to the Team and to any group in which the individual participates.
In exceptional circumstances
(e.g., situations that might jeopardize the progress of a group or create a
conflict of interest
),
the
CEO
may
decline
to allow an individual designated by an Advisory Committee representative to participate in a group.
A group charter
may
limit
the number of individuals representing a W3C Member
(or group of
related Members
).
3.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:
face-to-face meeting
is one
where most of the attendees are expected to participate in the same physical location.
distributed meeting
is one
where most of the attendees are expected to participate from remote locations
(e.g., by telephone, video conferencing, or
IRC
).
Chair
may
invite an individual with a particular expertise
to attend a meeting on an exceptional basis.
This person is a meeting guest,
not a group
participant
Meeting guests do not have
voting rights
It is the responsibility of the Chair to ensure
that all meeting guests respect the chartered
level of confidentiality
and other group requirements.
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)
Participation confirmed (before)
three days
24 hours
Action items available (after)
three days
24 hours
Minutes
available (after)
two weeks
48 hours
To allow proper planning (e.g., travel arrangements),
the Chair is responsible for giving sufficient advance notice
about the date and location of a meeting.
Shorter notice for a meeting is allowed
provided that there are no objections from group participants.
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
Team
must
record the notification.
See “Exclusion and Resignation from the Working Group” in the W3C Patent Policy
[PATENT-POLICY]
for information about obligations remaining after resignation from certain groups.
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:
reviewing plans for W3C at each
Advisory Committee meeting
reviewing formal proposals
of W3C:
Charter Proposals
transitions to Recommendation
and
proposed Process Documents
electing the
Advisory Board
participants other than the Advisory Board Chair.
electing a majority (6) of the participants on the
Technical Architecture Group
Advisory Committee representatives
may
initiate
an
Advisory Committee Appeal
of a
W3C decision
or
Team
’s decision.
See also the additional roles of
Advisory Committee representatives
described in the W3C Patent Policy
[PATENT-POLICY]
3.2.2.
Participation in the Advisory Committee
The
Advisory Committee
is composed of one
representative
from each Member organization
(refer to the
Member-only
list
of
current Advisory Committee representatives
[CURRENT-AC]
When an organization joins W3C
(see “
How to Join W3C
[JOIN]
),
it
must
name its Advisory Committee representative as part of their Membership Agreement.
The
New Member Orientation
[INTRO]
explains how to subscribe or unsubscribe to Advisory Committee mailing lists,
provides information about
Advisory Committee Meetings
explains how to name a new
Advisory Committee representative
and more.
Advisory Committee representatives
must
follow the
conflict of interest policy
by disclosing information according to the mechanisms described in the New Member Orientation.
The AC representative may delegate any of their rights and responsibilities
to an
alternate
(except the ability to designate an alternate).
3.2.3.
Advisory Committee Mailing Lists
The
Team
must
provide two mailing lists for use by the
Advisory Committee
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
Team
must
monitor discussion
and
should
participate in discussion when appropriate.
Ongoing detailed discussions
should
be moved to other appropriate lists
(new or existing, such as a mailing list created for a
Workshop
).
An
Advisory Committee representative
may
request
that additional individuals from their organization be subscribed to these lists.
Failure to contain distribution internally
may
result in suspension of additional email addresses,
at the discretion of the Team.
3.2.4.
Advisory Committee Meetings
The
Team
organizes a
face-to-face meeting
for the
Advisory Committee
twice a year
The
Team
appoints the Chair of these meetings (generally the CEO).
At each Advisory Committee meeting,
the Team
should
provide an update to the Advisory Committee about:
Resources
The number of W3C Members at each level.
An overview of the financial status of W3C.
Allocations
The allocation of the annual budget, including size of the Team and their approximate deployment.
A list of all activities (including but not limited to Working and Interest Groups)
and brief status statement about each,
in particular those started or terminated since the previous Advisory Committee meeting.
The allocation of resources to pursuing
liaisons
with other organizations.
Each Member organization
should
send one
representative
to each Advisory Committee Meeting.
In exceptional circumstances
(e.g., during a period of transition between representatives from an organization),
the meeting Chair
may
allow a Member organization to send two representatives to a meeting.
The
Team
must
announce the date and location of each Advisory Committee meeting
no later than at the end of the previous meeting;
one year’s
notice is preferred.
The Team
must
announce the region of each Advisory Committee meeting
at least
one year
in advance.
More information about
Advisory Committee meetings
[AC-MEETING]
is available at the Member website.
3.3.
Elected Groups: The AB and the TAG
The W3C Process defines two types of
elected groups
the
Advisory Board
(AB) and
the
Technical Architecture Group
(TAG),
both elected by the
Advisory Committee
3.3.1.
Advisory Board (AB)
3.3.1.1.
Role of the Advisory Board
The
Advisory Board
provides ongoing guidance to the Team
on issues of strategy,
management,
legal matters,
process,
and conflict resolution.
The Advisory Board also serves the Members
by tracking issues raised between Advisory Committee meetings,
soliciting Member comments on such issues,
and proposing actions to resolve these issues.
The Advisory Board manages the
evolution of the Process Document
As part of a
W3C Council
members of the
Advisory Board
hear and adjudicate on
Submission Appeals
and
Formal Objections
The
Advisory Board
is distinct from the
Board of Directors
and has no decision-making authority within W3C;
its role is strictly advisory.
Note:
While the
AB
as such does not have decision-making authority,
its members do when sitting as part of a
W3C Council
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 team also appoints a
Staff Contact
as described in
§ 3.4.1 Requirements for All Chartered Groups
The CEO and Staff Contact have a standing invitation
to all regular Advisory Board sessions.
The nine to eleven
Advisory Board
participants are elected by the W3C
Advisory Committee
following the
AB/TAG nomination and election process
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
Team
must
make available a mailing list,
confidential to the Advisory Board and Team,
for the Advisory Board to use for its communication.
The
Advisory Board
should
send a summary of each of its meetings
to the Advisory Committee and other group Chairs.
The Advisory Board
should
also report on its activities
at each
Advisory Committee meeting
3.3.1.4.
Liaisons between the Advisory Board and the Board of Directors
To ensure good communication between the
AB
and the
Board of Directors
and facilitate operational and management consistency,
the
AB
may
appoint up to two of its participants as liaisons to the
Board
Such appointees are expected to attend and participate in
Board
meetings
and access
Board
materials
as Non-voting Observers.
[BYLAWS]
They do not form part of the
Board
’s decision-making body,
and may be excluded from such participation
in accordance with applicable Board procedures.
The
Advisory Board
should
reevaluate
who is assigned to this role
at least at the beginning of each term,
and
may
swap its appointees more frequently
as they deem appropriate.
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.
As part of a
W3C Council
the members of the
TAG
hear and adjudicate on
Submission Appeals
and
Formal Objections
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
The
TAG
consists of:
Tim Berners-Lee, who is a life member;
Three participants
appointed by the Team
Eight participants elected by the
Advisory Committee
following the
AB/TAG nomination and election process
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
Team
also appoints a
Staff Contact
[TEAM-CONTACT]
for the TAG,
as described in
§ 3.4.1 Requirements for All Chartered Groups
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
Team
must
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.
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
TAG
may
also request the creation of additional topic-specific, public mailing lists.
For some TAG discussions (e.g., a
Submission Appeal
),
the TAG
may
use a list that will be
Member-only
The
TAG
should
send a summary of each of its
meetings
to the Advisory Committee and other group Chairs.
The
TAG
should
also report on its activities at each
Advisory Committee meeting
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 participants with the same
primary affiliation
per
§ 3.3.3.3 Advisory Board and Technical Architecture Group Elections
must not both occupy elected seats on the TAG
except when this is caused by a change of affiliation of an existing participant.
At the completion of the next regularly scheduled election for the TAG,
the organization
must
have returned to having at most one seat.
Two participants with the same
primary affiliation
per
§ 3.3.3.3 Advisory Board and Technical Architecture Group Elections
must not both occupy elected seats on the AB.
If, for whatever reason, these constraints are not satisfied
(e.g., because an
AB
participant changes jobs),
one participant
must
cease
AB
participation
until the situation has been resolved.
If after
30 days
the situation has not been resolved,
the Chair will apply
the
verifiable random selection procedure
described below
to choose one person for continued participation and declare the other seat(s) vacant.
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
Team
may
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 representative
must
include in the nomination
the (same)
information required for a Member representative in a Working Group
In order for an individual to be nominated as an Invited Expert,
the individual
must
provide
the (same)
information required for an Invited Expert in a Working Group
and the nominating
Advisory Committee representative
must
include that information in the nomination.
In order for an individual to be nominated as a
Team
representative,
the nominating
Advisory Committee representative
must
first secure approval from
Team
management.
A nominee is
not required
to be an employee of a Member organization,
and
may
be a
W3C Fellow
The nomination form
must
ask for the nominee’s
primary affiliation
and this will be reported on the ballot.
For most nominees,
the
primary affiliation
is their employer and will match their affiliation in the W3C database.
For contractors and invited experts,
this will normally be their contracting company
or their invited expert status;
in some cases
(e.g. where a consultant is consulting for only one organization)
this
may
be the organization for whom the nominee is consulting.
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
Team
may
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.
Refer to
How to Organize an Advisory Board or TAG election
[ELECTION-HOWTO]
for more details.
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
Team
should
use its appointments to support
a diverse and well-balanced
TAG
including diversity of technical background, knowledge, and skill sets.
The
Team
should
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 Group
Chairs
The constraints for appointment to the
TAG
are
the same as for elected participants
(see
§ 3.3.3.2 Elected Groups Participation Constraints
and
§ 3.3.3.3 Advisory Board and Technical Architecture Group Elections
),
with the additional constraint that
a person
must not
be appointed
for more than two
consecutive
terms.
(Partial terms used to fill a vacated seat do not count towards this limit.)
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 both the
AB
and the
TAG
requiring a two-thirds approval from each.
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
Team
should
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
Team
should
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.
3.3.3.6.
Elected Groups Vacated Seats
An
Advisory Board
or
TAG
participant’s seat is vacated when:
the participant resigns, or
an Advisory Board or TAG participant changes affiliations
such that the
Advisory Board and TAG participation constraints
are no longer met,
or
the
CEO
dismisses the participant
for failing to meet the criteria in section
§ 3.1.1 Individual Participation Criteria
or
their term ends.
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
Team
appoints
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 fewer than three months away.
The group Chair
may
request an election,
and the election may begin, as soon as a current member gives notice of a resignation,
including a resignation effective as of a given date in the future.
When such an election is held,
the minimum number of available 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
Working Groups
Working Groups typically produce deliverables
(e.g.,
Recommendation Track technical reports
software,
test suites,
and reviews of the deliverables of other groups)
as defined in their
charter
Working Groups have additional participation requirements
described in the W3C Patent Policy
[PATENT-POLICY]
see particularly the “
Licensing Obligations of Working Group Participants
and the patent claim exclusion process
in “
Exclusion From W3C RF Licensing Requirements
”.
Interest Groups
The primary goal of an Interest Group
is to bring together people who wish to evaluate potential Web technologies and policies.
An Interest Group is a forum for the exchange of ideas.
Interest Groups do not publish
Recommendation Track technical reports
but can publish
technical reports on the Note Track
3.4.1.
Requirements for All Chartered Groups
Each group
must
have a
charter
Requirements for the charter depend on the group type.
All group charters
must
be public
(even if other proceedings of the group are
Member-only
).
Each group
must
have a
Chair
(or co-Chairs)
to 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
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.
Note:
The
role of the Chair
[CHAIR]
is described
in the
Art of Consensus
[GUIDE]
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
Note:
The
role of the Staff Contact
[TEAM-CONTACT]
is described in the
Art of Consensus
[GUIDE]
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]
Chair
may
form task forces
(composed of group participants)
to carry out assignments for the group.
The scope of these assignments
must not
exceed the scope of the group’s charter.
A group
should
document the process it uses
to create task forces
(e.g., each task force might have an informal "charter").
Task forces do not publish
technical reports
the Working Group
may
choose to publish their results as part of a technical report.
3.4.2.
Participation in Chartered Groups
There are three types of individual
participants in a Working Group
Member representatives
Invited Experts
and
Team representatives
(including the
Staff Contact
).
There are four types of individual
participants in an Interest Group
the same three types as for Working Groups plus,
for an Interest Group where the only
participation requirement is mailing list subscription
public participants
Except where noted in this document or in a group charter,
all participants share the same rights and responsibilities in a group;
see also the
individual participation criteria
A participant
may
represent more than one organization
in a
Working Group
or
Interest Group
Those organizations
must
all be members of the group.
An individual
may
become
a Working or Interest Group participant
at any time during the group’s existence.
See also relevant requirements in
“Joining an Already Established Working Group”
in the W3C Patent Policy
[PATENT-POLICY]
On an exceptional basis,
a Working or Interest Group participant
may
designate
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 individual qualifies for
Member representation
To designate an individual as a Member representative in a
Working Group
an
Advisory Committee representative
must
provide the
Chair
and
Staff Contact
with all of the following
information
in addition to any other information required by the
Call for Participation
and charter
(including the participation requirements of the W3C Patent Policy
[PATENT-POLICY]
):
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:
the
Advisory Committee representative
of the Member in question has designated the individual
as an Interest Group participant, and
the individual qualifies for
Member representation
To designate an individual as a
Member representative in an Interest Group
the Advisory Committee representative
must
follow the instructions
in the
Call for Participation
and charter.
Member participation in an Interest Group ceases under the same conditions as for a Working Group.
3.4.3.3.
Invited Expert in a Working Group
The
Chair
may
invite an individual with a particular expertise
to participate in a Working Group.
This individual
may
represent an organization in the group
(e.g., if acting as a liaison with another organization).
An individual is an
Invited Expert in a Working Group
if all of the following conditions are satisfied:
the Chair has designated the individual as a group participant,
the Staff Contact has agreed with the Chair’s choice, and
the individual has provided the
information required of an Invited Expert
to the Chair and Staff Contact.
To designate an individual as an Invited Expert in a Working Group,
the
Chair
must
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,
agree to the terms of the
invited expert and collaborators agreement
[COLLABORATORS-AGREEMENT]
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,
disclose whether the individual is an employee of a W3C Member;
see the
conflict of interest policy
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
Chair
should not
designate as an
Invited Expert in a Working Group
an individual who is an employee of a W3C Member.
The Chair
must not
use Invited Expert status
to circumvent participation limits imposed by the
charter
An Invited Expert participates in a Working Group
from the moment the individual joins the group
until any of the following occurs:
the group closes, or
the Chair or
CEO
withdraws the invitation to participate, or
the individual
resigns
3.4.3.4.
Invited Expert in an Interest Group
When the participation requirements exceed
Interest Group mailing list subscription
the participation requirements for an
Invited Expert in an Interest Group
are the same as those for an
Invited Expert in a Working Group
3.4.3.5.
Team Representative in a Working Group
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:
refinement
phase helps ensure
charters
are mission-aligned,
reflect community input and
consensus
and have been well-socialized
and
widely reviewed
Charters
then are formally approved through an
AC Review
and
W3C Decision
(see
§ 4.4 Charter Review and Approval
).
4.1.
Initiating Charter Refinement
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.
Formal
charter refinement
(see below) is initiated
by the
Team
sending a
charter review notice
to the
Advisory Committee
to the public,
and, in the case of rechartering, to the affected
Group
This
charter review notice
must include:
A short summary of the proposal.
The location of the
charter draft
, which must be public.
How to participate in the discussion of this
charter draft
and where to file issues.
The expected duration of the
charter refinement
phase,
which must not be less than 28 days,
and should not be more than 6 months.
Who the
Chartering Facilitator
is.
The
Team
is responsible for initiating
charter refinement
at its discretion, in consideration of discussions with the community.
An
Advisory Committee representative
may
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
Team
must
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 Facilitator
may
ask the
Team
to make a
Team Decision
and
must
document the rationale for the decision.
Note:
The
Chartering Facilitator
is not necessarily the
Chair
of the
group
being chartered.
During
charter refinement
Wide review
of the
charter draft
is initiated and completed.
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.
Before the end of the announced duration
for the
charter refinement
phase,
the
Team
(informed by the work of the
Chartering Facilitator
must
decide
which of the following to do:
Complete charter refinement by initiating
AC Review
of the
charter draft
Abandon the proposal.
Extend the charter refinement period.
The
Team
must
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
Team
may
revise such a decision
by announcing an alternative decision.
Formal Objections
filed during the
charter refinement
phase
are specially handled:
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
Note:
This enables all
Formal Objections
on the same proposed
charter
to be handled together.
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
Team
must
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.)
Any other objections are processed normally (See
§ 5.6 Addressing Formal Objections
).
4.3.
Content of a Charter
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
[CHARTER]
The
level of confidentiality
of the group’s proceedings and deliverables.
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.
Any voting procedures or requirements
other than those specified in
§ 5.2.3 Deciding by Vote
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 Draft
must
each be adopted in their entirety and without any modification.
The proposed charter
must
state
the dates on which the Exclusion Opportunity
that arose on publishing the
Exclusion Draft
began and ended.
As per “Joining an Already Established Working Group”
in the W3C Patent Policy
[PATENT-POLICY]
this potentially means that exclusions can only be made immediately on joining a Working Group.
An Interest Group charter
may
include provisions regarding participation,
including specifying
that the
only requirement for participation (by anyone) in
the Interest Group is subscription to the Interest Group mailing list
This type of Interest Group
may
have
public participants
A charter
may
include
provisions other than those required by this document.
The charter
should
highlight
whether additional provisions impose constraints
beyond those of the W3C Process Document
(e.g., limits on the number of individuals in a Working Group
who represent the same Member organization or group of
related Members
).
4.4.
Charter Review and Approval
4.4.1.
New Charters and Major Changes
Any new
charter
(including re-chartering of existing
chartered groups
and any change that is not a
minor change
(per
§ 4.4.2 Minor Changes to Active Charters
) to an already-approved
charter
of a
Working Group
or
Interest Group
must
be approved by a
W3C Decision
following an
AC Review
of that
charter
Modifications to a
charter
should
have the
consensus
of the group.
The review period
must
be at least 28 days.
Any
Advisory Committee representative
may
request an extended review period
in response to the Call for Review;
upon receipt of any such request,
the
Team
must
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.
The
Team
may
nevertheless choose
to initiate
charter refinement
and/or
Advisory Committee Review
when it thinks the changes would benefit from more scrutiny or explicit buy-in.
Though
Advisory Committee Review
is not required,
such changes
must
still be announced
to the
Advisory Committee
and to participants in the
Working
or
Interest
Group,
and a rationale must be provided.
4.5.
Call for Participation in a Chartered Group
Deciding whether to adopt a proposed
Working Group
or
Interest Group
charter
is a
W3C Decision
Charters
may
be amended based on review comments
per
§ 5.7.2 Determining the W3C Decision
before the Call for Participation.
If the decision is to charter the group,
the
Team
must
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 Experts
must
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
Team
may
decide
to extend a Working Group or Interest Group charter
with no other substantive modifications.
The
Team
must
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).
After a charter extension,
Advisory Committee representatives
and the
Chair
are
not required
to re-designate
Member representatives
and
Invited Experts
Advisory Committee representatives
may
initiate
an
Advisory Committee Appeal
against a
Team decision
regarding the extension of a Working Group or Interest Group charter.
4.7.
Chartered Group Closure
Working Group
or
Interest Group
charter specifies a duration for the group.
The
Team
, the
TAG
, or the
AB
may
propose to close a group
prior to the date specified in the charter in any of the following circumstances:
There are insufficient member resources to produce chartered deliverables
or to maintain the group,
according to priorities established within W3C.
Patent Advisory Group
concluded that the work
should
be terminated.
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
In contrast,
decisions taken by the
Chair
of a
Working Group
or
Interest Group
on the basis of having assessed the
consensus
of the group
or following a vote (see
§ 5.2.3 Deciding by Vote
are called
group decisions
(also known as group “resolutions”).
Decisions made by members of the
Team
in connection with this Process,
based on their own individual or collective judgement,
are called
Team Decisions
In contrast,
W3C decision
is
determined by the
Team
on behalf of the W3C community
by
assessing the consensus of the W3C Community
after an
Advisory Committee review
5.2.
Consensus Building
5.2.1.
Consensus
Consensus is a core value of W3C.
To promote consensus,
the W3C process requires Chairs to ensure
that groups consider all legitimate views and objections,
and endeavor to resolve them,
whether these views and objections are expressed by the active participants of the group
or by others
(e.g., another W3C group,
a group in another organization,
or the general public).
Decisions
may
be made during meetings
face-to-face
or
distributed
as well as through
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:
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
Chair
may
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
Chair
must
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.
The
Team
is considered an organization.
Unless the charter states otherwise,
Invited Experts
may
vote.
If a participant is unable to attend a vote,
that individual
may
authorize anyone at the meeting
to act as a proxy.
The absent participant
must
inform the Chair in writing
who is acting as proxy, with written instructions on the use of the proxy.
For a Working Group or Interest Group,
see the related requirements regarding an individual
who attends a meeting as a
substitute
for a participant.
A group
may
vote for other purposes than to resolve a substantive issue.
For instance, the Chair often conducts a “straw poll” vote
as a means of determining whether there is consensus about a potential decision.
A group
may
also vote to make a process decision.
For example,
it is appropriate to decide by simple majority
whether to hold a meeting in San Francisco or San Jose
(there’s not much difference geographically).
When simple majority votes are used to decide minor issues,
voters are
not required
to state the reasons for votes,
and the group is
not required
to record individual votes.
A group charter
may
include formal voting procedures
(e.g., quorum or threshold requirements)
for making decisions about substantive issues.
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
Chair
may
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
Chair
should
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
Formal Objection
must
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.
No later than when the
relevant Council is initiated
a record of each
Formal Objection
against a decision regarding a publicly-available document
must
be made
publicly available
likewise, a record of each
Formal Objection
against a
Member-visible
decision
must
be made
available to Members
A Call for Review to the Advisory Committee
must
identify any
Formal Objections
related to that review.
These requirements are waived
if the
Formal Objection
is resolved to the satisfaction of the objector
before its
confidentiality is changed
Note:
Formal Objections
against matter in a
technical report
are expected to be fully addressed
before
requesting advancement
of the
technical report
Formal Objection
filed during an
Advisory Committee Review
is considered registered at the close of the review period.
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
Team
must
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
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.
5.6.2.1.
Council Composition
Each
W3C Council
is composed of the following members (excepting any
renounced or dismissed
):
the
CEO
or their chosen
Team
delegate
the members of the
Advisory Board
the elected and appointed members of the
Technical Architecture Group
Participation in a
W3C Council
must not
require attendance of
face-to-face meetings
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 Chair
should
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.
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.
The
Team
must
inform the
Advisory Committee
when a
Formal Objection
has been delegated,
and to whom it has been delegated.
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
Team
must
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 Council
may
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.
This step
may
be run concurrently with
§ 5.6.2.3 Council Participation, Dismissal, and Renunciation
and prior to choosing a
Chair
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.
5.6.2.6.
Convening the Council
When
dismissal
renunciation
, and
appointment of the
W3C Council Chair
have concluded,
and the
Team
’s report has been delivered,
the
W3C Council
is considered to be
convened
and can start
deliberations
If a
W3C Council
has not yet been
convened
within 90 days of a Formal Objection
being
registered
the
Chairs
of the
TAG
and
AB
may
take independent action to ensure
that the
dismissal
renunciation
and
chair selection
processes have been run.
If a report from the Team is not delivered within those 90 days,
the
Council
is considered
convened
upon selection of the
Council Chair
5.6.2.7.
Council Deliberations
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 Council
may
affirm
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
Council
should
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 Council
should
be unanimous,
and
may
be issued under consensus.
However, if despite careful deliberation
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 two members of a Council who share the same affiliation cast an identical ballot,
then their ballots count as a one vote,
not two.
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.
The deliberations of a
W3C Council
are confidential to that
W3C Council
and its
Council Staff Contact
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.
If a
W3C Council
is unable to come to a conclusion within 45 days of being
convened
the
W3C Council Chair
must
inform the
AC
of this delay
and of the status of the discussions.
The
W3C Council Chair
may
additionally make this report
public
5.6.2.8.
Council Decision Report
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
must
include the
Minority Opinion(s)
, if any.
must
report the names of those who were
dismissed
or
renounced
their seat as well as those who were qualified to serve.
must
report the names of the individuals who participated in the final Council decision.
must
report the number of votes for/against dismissing each participant.
may
report vote totals for the Council’s decision, if a formal vote was held.
must not
attribute any position to any individual on the Council.
The
Team
must
maintain a
public page on the W3C website
indexing all completed
Council Reports
If a Council decision is later overturned by an
AC Appeal
this
must
also be mentioned.
Council Reports
must
be no more confidential
than the decision or document being objected to.
The
Council
may
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 Report
should
be self-sufficient
and understandable without reference to Supplemental Confidential Council Reports.
5.6.2.9.
Appealing Council Decisions
Advisory Committee representatives
may
initiate an
Advisory Committee Appeal
of a Council decision issued in a
Council Report
5.7.
Advisory Committee Reviews and W3C Decisions
The
Advisory Committee
formally confers its approval
on
charters
technical reports
and other matters
through an
Advisory Committee review
and its resulting
W3C Decision
5.7.1.
Initiating an Advisory Committee Review
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
Team
may
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
For clarity,
in the context of an
AC Review
dissent
must
be expressed as a
Formal Objection
The Team
must
provide two channels for Advisory Committee review comments:
an archived
Team-only
channel;
an archived
Member-only
channel.
The
Call for Review
must
specify
which channel is the default for review comments on that Call.
Reviewers
may
send information
to either or both channels.
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).
5.7.2.
Determining the W3C Decision
After the review period,
the
Team
determines the appropriate
W3C Decision
which they
must
announce to the
Advisory Committee
The announcement
must
indicate
the level of support for the proposal
consensus
or
dissent
),
and specifically
whether there were any
Formal Objections
with attention to
changing the confidentiality level
of the
Formal Objections
If there were
Formal Objections
, at least some of which were
upheld
or if there is not
consensus
because of insufficient support,
W3C Decision
must
be one of:
The proposal is returned for additional work,
with a request to the initiator to improve the proposal.
The proposal is rejected.
If the proposal has
consensus
or if all
Formal Objections
are retracted or
overruled
and the proposal otherwise has sufficient support to achieve
consensus
this
W3C Decision
must
be one of:
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
Team
should
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 Review
must 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 Committee
should 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
Team
should
provide the
Advisory Committee
with an update.
5.8.
Advisory Committee Votes
The
Advisory Committee
votes in
elections for seats on the TAG or Advisory Board
and in the event of an
Advisory Committee Appeal
achieving the required support to trigger an
appeal vote
Whenever the
Advisory Committee
votes,
each Member or group of
related Members
has one vote.
5.9.
Appeal by Advisory Committee Representatives
Advisory Committee representatives
may
appeal certain decisions,
though appeals are only expected to occur in extraordinary circumstances.
For the purpose of this section, only
Advisory Committee representatives
of
Members
in
Good Standing
are counted.
When a
W3C decision
is made following an
Advisory Committee review
Advisory Committee representatives
may
initiate
an
Advisory Committee Appeal
These
W3C decisions
include those related to group creation and modification,
and transitions to new maturity stages for Recommendation Track documents
and the Process document.
Advisory Committee representatives
may
also initiate an appeal
for decisions of a
W3C Council
, and
for certain decisions that do not involve an
Advisory Committee review
These cases are identified in the sections
which describe the requirements for the decision
and include
additional (non-reviewed) maturity stages of Recommendation Track documents,
group
charter extensions
and closures,
and
technical agreements
In all cases,
an
appeal
must
be initiated within
three weeks
of the decision.
An
Advisory Committee representative
initiates an
appeal
by sending a request to the
Team
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.
Note:
See
Appealing a W3C Decision
for a recommendation
on how to communicate an appeal request to the
Team
and the
AC
Within one week the
Team
must
announce the appeal process
to the
Advisory Committee
and provide a mechanism for
Advisory Committee representatives
to respond with a statement of positive support for this appeal.
The archive of these statements
must
be
member-only
If, within
one week
of the Team’s announcement,
5% or more of the
Advisory Committee
support the appeal request,
the Team
must
organize an
appeal vote
asking the
Advisory Committee
“Do you approve of the 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.
The level of support needed for an
Advisory Committee Appeal
to pass
depends on the level of ballot participation
(including explicit “abstain” ballots)
by
Advisory Committee Representatives
if fewer than 5% participate,
the vote fails.
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]
6.1.
Types of Technical Reports
This chapter describes the formal requirements
for
publishing
and maintaining a
W3C Recommendation
Note
or
Registry
Recommendations
Working Groups
develop technical reports on the
W3C Recommendation Track
in order to produce normative specifications or guidelines
as standards for the Web.
The
Recommendation Track
process incorporates requirements for
wide review
adequate implementation experience
and
consensus
-building,
and is subject to the W3C Patent Policy
[PATENT-POLICY]
under which participants commit to Royalty-Free IPR licenses for implementations.
See
§ 6.3 The W3C Recommendation Track
for details.
Notes
Groups can also publish documents as
Group Notes
and
W3C Statements
typically either to document information
other than technical specifications,
such as use cases motivating a specification
and best practices for its use.
See
§ 6.4 The Note Track (Notes and Statements)
for details.
Registries
Chartered
and
elected groups
can also publish
registries
in order to document collections of values or other data.
A registry can be published either as a distinct
registry report
or directly within a
Recommendation Track
document
as an
embedded registry
Defining a registry
requires
wide review
and
consensus
but once set up, changes to registry entries are lightweight
and can even be done without the initiating group’s involvement.
See
§ 6.5 The Registry Track
for details.
Individual
Working Groups
and
Interest Groups
should
adopt additional processes
for developing publications,
so long as they do not conflict with the requirements in this chapter.
6.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.
The primary language for W3C
Technical Reports
is English.
W3C encourages the translation of its
Technical Reports
Information about translations of W3C technical reports
[TRANSLATION]
is available at the W3C website.
6.2.2.
Reviews and Review Responsibilities
A document is available for review
from the moment it is first
published
Working Groups
should
formally address
any
substantive review comment
about a technical report in a timely manner.
Reviewers
should
send substantive technical reviews as early as possible.
Working Groups
are often reluctant to make
substantive changes
to a mature document,
particularly if this would cause significant compatibility problems
due to existing implementation.
Working Groups
should
record substantive
or interesting proposals raised by reviews
but not incorporated into a current specification.
6.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
[CHARTER]
and groups identified as dependencies in the charter
or identified as
liaisons
[LIAISON]
and seek evidence of clear communication to the general public
about appropriate times and which content to review
and whether such reviews actually occurred.
Note:
The Team documents
best practices for wide review
in the Guidebook.
[GUIDE]
For example,
inviting review of new or significantly revised sections published in Working Drafts,
and tracking those comments
and the
Working Group
’s responses,
is generally a good practice which would often be considered positive evidence of wide review.
Working Groups
should
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.
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-track
technical 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.
Changes to the contents of a
registry table
Changes that add, remove, or alter
registry entries
in a
registry table
6.2.4.
Errata Management
Tracking errors is an important part of a
Working Group
’s ongoing care of a
technical report
for this reason,
the scope of a
Working Group
charter generally allows time
for work after publication of a
Recommendation
In this Process Document,
the term “
erratum
(plural “errata”) refers to any error
that can be resolved by one or more changes in classes 1-3
of section
§ 6.2.3 Classes of Changes
Working Groups
must
keep
a public record of errors
that are reported by readers and implementers
for
Recommendations
Such error reports
should
be compiled
no less frequently than quarterly.
Working Groups
decide how to document errata.
Such documentation
must
identify
the affected
technical report
text
and describe the error;
it
may
also describe some possible solution(s).
Readers of the
technical report
should
be able easily
to find and see the errata
that apply to that specific
technical report
with their associated tests.
Errata
may
be documented
in a separate errata page or tracking system.
They
may
in addition or alternatively,
be annotated inline
alongside the affected
technical report
text
or at the start or end of the most relevant section(s).
6.2.5.
Candidate Amendments
An
erratum
may
be accompanied by a non-normative,
candidate correction
approved by
group decision
When annotated inline,
errata—including their
candidate corrections
—must be marked as such,
are treated as
class 2 changes
and are published accordingly.
Note:
Annotating changes in this way allows more mature documents
such as
Recommendations
and
Candidate Recommendations
to be updated quickly with the Working Group’s most current thinking,
even when the
candidate amendments
have not yet received
sufficient review or implementation experience
to be normatively incorporated into the specification proper.
candidate addition
is similar to a
candidate correction
except that it proposes a new feature
rather than an error correction.
Candidate corrections
and
candidate additions
are collectively known as
candidate amendments
In addition to their actual
maturity stage
published
REC Track
documents with
candidate amendments
are also considered,
for the purpose of the W3C Patent Policy
[PATENT-POLICY]
to be
Working Drafts
with those
candidate amendments
treated as normative.
6.2.6.
Maintenance Without a Group
For all
types of technical reports
and all
maturity stages
if there is no
group
chartered to maintain a
technical report
the
Team
may
republish it
at the same
maturity stage
integrating as needed:
class 1 changes
inline
errata
candidate corrections
which
must
be marked as
Team correction
class 2 changes
other than inline
errata
and
Team corrections
To avoid any potential doubt or disagreement
about whether changes really do fall into
class 2
the
Team
should
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
Team
must
mark it as a
Team correction
Team corrections
do not constitute
a normative portion of the Recommendation,
as defined in the Patent Policy
[PATENT-POLICY]
(i.e., they are not covered by the Patent Policy).
For
Candidate Recommendations
W3C Recommendations
Candidate Registries
W3C Registries
as well as
W3C Statements
the
Team
must
solicit
wide review
on
Team corrections
that it produces.
6.2.7.
License Grants from Non-Participants
When a party who is not already obligated under the Patent Policy
offers a change in class 3 or 4
(as described in
§ 6.2.3 Classes of Changes
) to a technical report under this process
the
Team
must
request
a recorded royalty-free patent commitment;
for a change in class 4, the Team
must
secure such commitment.
Such commitment
should
cover,
at a minimum,
all the party’s Essential Claims both in the contribution,
and that become Essential Claims as a result of incorporating the contribution into the draft
that existed at the time of the contribution,
on the terms specified in the “W3C Royalty-Free (RF) Licensing Requirements” section of the W3C Patent Policy
[PATENT-POLICY]
6.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
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:
Publication of the
First Public Working Draft
Publication of zero or more revised
Working Drafts
Publication of one or more
Candidate Recommendations
Publication as a
W3C Recommendation
Non-Normative Summary of the
Recommendation Track
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.
W3C
may
end work on a technical report
at any time.
6.3.1.
Maturity Stages on the Recommendation Track
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.
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
gather
implementation experience
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.
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.
Publication as a
Candidate Recommendation Snapshot
requires verification of either a
Transition Request
(for the first
Candidate Recommendation
publication from another maturity stage)
or an
Update Request
(for subsequent
Candidate Recommendation Snapshots
).
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.
Candidate Recommendation Draft
does not
provide an exclusion opportunity;
instead, it is considered a
Working Draft
for the purpose of the
W3C Patent Policy
[PATENT-POLICY]
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
After its initial publication,
W3C Recommendation
may
be revised
(in accordance with
§ 6.3.10 Revising a W3C Recommendation
to address
editorial
or
substantive
issues
that are discovered later.
However,
new features
can only be added
if the document already identifies itself
as intending to
allow new features
Adding or removing this allowance is a
substantive change
Such an allowance cannot be added
to a
technical report
previously published as a
Recommendation
that did not allow such changes;
this requires a new
technical report
(which could, for example, be similarly named but with an incremented version number).
As technology evolves,
W3C Recommendation
may become:
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
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]
Working Groups
and
Interest Groups
may
make available
Editor’s drafts
Editor’s drafts
ED
) have no official standing whatsoever,
and do not necessarily imply consensus of a
Working Group
or
Interest Group
nor are their contents endorsed in any way by W3C.
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.
must
formally address
all issues
raised about the document since the previous
maturity stage
must
provide public documentation of any
Formal Objections
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.
Transition Requests
to
First Public Working Draft
or
Candidate Recommendation
will not normally be approved
while a
Working Group
’s
charter
is undergoing or awaiting a decision
on an
Advisory Committee Review
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
must
obtain
Team
verification.
Team
verification (a
Team decision
):
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
must
provide public documentation of any
Formal Objections
must
publicly document of 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
changes have been made,
and
may
document the details of such changes.
must
show that the revised specification
meets all
Working Group
requirements,
or explain why the requirements have changed or been deferred,
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
There is usually a formal review meeting
to verify that the requirements have been met.
Note:
Update request
verification is expected to be fairly simple
compared to verification of a
transition request
The
Team
must
announce the publication
of the revised specification
to other W3C groups and the Public.
6.3.5.
Publishing a First Public Working Draft
To publish the
First Public Working Draft
of a document,
Working Group
must
meet the applicable
requirements for advancement
The
Team
must
announce
the publication of a
First Public Working Draft
to other W3C groups and to the public.
6.3.6.
Revising a Working Draft
Working Group
should
publish
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
provide public documentation
of
substantive changes
to the technical report
since the previous
Working Draft
should
provide public documentation
of significant
editorial changes
to the technical report
since the previous step,
should
report which,
if any,
of the Working Group’s requirements for this document
have changed since the previous step,
should
report any changes in dependencies with other groups,
Possible next steps for any Working Draft:
Revised
Working Draft
Candidate Recommendation
Discontinued Draft
6.3.7.
Transitioning to Candidate Recommendation
To publish a
Candidate Recommendation
in addition to meeting the
requirements for advancement
Working Group
must
show that the specification
has met all
Working Group
requirements,
or explain why the requirements have changed or been deferred,
must
document changes to dependencies during the development of the specification,
must
document
how
adequate implementation experience
will be demonstrated,
must
specify the deadline for comments,
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
The first Candidate Recommendation publication
after verification of having met the requirements for a
Transition Request
is always a
Candidate Recommendation Snapshot
The
Team
must
announce
the publication of the
Candidate Recommendation Snapshot
to other W3C groups
and to the public.
Possible next steps after a
Candidate Recommendation Snapshot
Return to
Working Draft
A revised
Candidate Recommendation Snapshot
A revised
Candidate Recommendation Draft
Recommendation
Discontinued Draft
Advisory Committee
representatives
may
initiate an
Advisory Committee Appeal
of the decision to advance the technical report.
6.3.8.
Revising a Candidate Recommendation
6.3.8.1.
Publishing a
Candidate Recommendation Snapshot
If there are any
substantive changes
made to a
Candidate Recommendation
since the previous
Candidate Recommendation Snapshot
other than to remove features explicitly identified as
at risk
the
Working Group
must
meet the requirements of an
update request
in order to republish.
In addition the Working Group:
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
The
Team
must
announce
the publication of a revised
Candidate Recommendation Snapshot
to other W3C groups
and to the public.
To provide timely updates and patent protection,
Candidate Recommendation Snapshot
should
be published
within 24 months of the Working Group accepting
any proposal for a substantive change
(and preferably sooner).
To make scheduling reviews easier,
Candidate Recommendation Snapshot
should not
be published
more often than approximately once every 6 months.
Note:
Substantive changes
trigger a new Exclusion Opportunity
per “Exclusion From W3C RF Licensing Requirements”
in the W3C Patent Policy
[PATENT-POLICY]
6.3.8.2.
Publishing a
Candidate Recommendation Draft
Working Group
should
publish
an
Update Draft
to the W3C Technical Reports page
when there have been significant changes
to the previous published document
that would benefit from review beyond the Working Group.
To publish a revision of a
Candidate Recommendation Draft
a Working Group:
must
record the group’s decision to request publication,
must
provide public documentation
of
substantive changes
to the technical report
since the previous
Candidate Recommendation Snapshot
should
provide public documentation
of significant
editorial changes
to the technical report
since the previous
Candidate Recommendation Snapshot
should
document outstanding issues,
and parts of the document on which the Working Group does not have consensus,
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.
Note:
A Working Group
does not
need to
meet the requirements of a
Candidate Recommendation Snapshot
update request
in order to publish a
Candidate Recommendation Draft
Possible next steps after a
Candidate Recommendation Draft
Return to
Working Draft
A revised
Candidate Recommendation Snapshot
A revised
Candidate Recommendation Draft
Recommendation
if there are no
substantive change
other than dropping
at risk
features
Discontinued Draft
6.3.9.
Transitioning to Recommendation
When a
Working Group
estimates
that a
Candidate Recommendation
has fulfilled all the relevant criteria,
it
may
decide
to request advancement to
W3C Recommendation
6.3.9.1.
Requirements for Transition
In addition to meeting the
requirements for advancement
the Working Group:
must
show
adequate implementation experience
except where an exception is approved by a
Team Decision
The
Team
may
approve a
Candidate Recommendation
with minimal
implementation experience
where there is a compelling reason to do so.
In such a case, the
Team
must
explain the reasons for that decision,
and that information
must
be included in the
Call for Review
proposing advancement to
W3C Recommendation
must
show that the document has received
wide review
must
show that all issues
raised during the
Candidate Recommendation review period
have been
formally addressed
must
identify any substantive issues
raised since the close of the
Candidate Recommendation review period
must
identify, in the document, where errata are tracked.
Additionally,
if the document has previously been published as a
W3C Recommendation
, the
Working Group
must not
include any
class 4 change
to that publication
unless it was explicitly marked as
allowing new features
and
must not
include any such marking
if not already present.
If the document’s most recent publication is a
Candidate Recommendation Draft
the
Team
must
verify
that it contains no changes since the previous
Candidate Recommendation Snapshot
other than:
editorial changes
the addition or removal of a statement as to whether the document will
allow new features
after its publication as a
Recommendation
dropping
at risk
features
Otherwise, the
Working Group
must
republish it
as a
Candidate Recommendation Snapshot
prior to initiating the review.
6.3.9.2.
Initiating Review
If all the criteria above are fulfilled,
the
Team
must
begin an
Advisory Committee Review
on the question of whether the identified
Candidate Recommendation
is appropriate to
publish
as a
W3C Recommendation
The deadline for
Advisory Committee review
must
allow
at least
28 days,
and
must
end at least 10 days
after the end of the last Exclusion Opportunity
per ”Exclusion From W3C RF Licensing Requirements”
in the W3C Patent Policy
[PATENT-POLICY]
6.3.9.3.
Resolution of Review
If there was any
Formal Objection
during the
Advisory Committee Review
the
Team
must
publish the substantive content of the
dissent
to W3C and the general public,
and the
W3C Recommendation
must not
be published
unless all
Formal Objections
to the document have been retracted or
overruled
and at least 14 days have elapsed since the publication of the corresponding
Council Report
The decision to advance a document to
Recommendation
is a
W3C Decision
The
Team
must
announce the publication of a
W3C Recommendation
to the
Advisory Committee
to other W3C groups
and to the public.
Advisory Committee representatives
may
initiate an
Advisory Committee Appeal
of the decision to advance the technical report.
The newly published
Recommendation
must not
make any
substantive changes
to the document
compared to the
Candidate Recommendation Snapshot
submitted for AC Review,
other than dropping features identified
at risk
6.3.9.4.
Next Steps from W3C Recommendation
Possible next steps:
W3C Recommendation
normally retains its status indefinitely.
However it
may
be:
republished as a
revised Recommendation
, or
republished as a
Candidate Recommendation
or
Working Draft
to be developed towards a revised
Recommendation
, or
declared
superseded or obsolete
, or
rescinded
6.3.10.
Revising a W3C Recommendation
6.3.10.1.
Revising a Recommendation: Editorial Changes
Editorial changes
to a
Recommendation
require no technical review of the intended changes.
Working Group
provided there are no votes against the
decision
to publish,
may
request publication of a
Recommendation
to make this class of change without passing through earlier maturity stages.
(See
class 1
and
class 2 changes
.)
6.3.10.2.
Revising a Recommendation: Substantive Changes
Tentative corrections (see
class 3 changes
may
be annotated into a
Recommendation
using
candidate corrections
Note:
Candidate corrections
do not normatively modify the document;
they editorially indicate how one might do so.
They are therefore published following the provisions of
§ 6.3.10.1 Revising a Recommendation: Editorial Changes
candidate correction
can be made normative
and be folded into the main text of the
Recommendation
once it has satisfied all the same criteria
as the rest of the
Recommendation
including review by the community to ensure
its technical and editorial soundness.
To validate this, the
Working Group
must request
Last Call for Review of Proposed Amendments
followed by an
update request
See
§ 6.3.10.4 Incorporating Candidate Amendments
Alternatively,
Working Group
may
incorporate the changes
and
publish as a Working Draft
—or, if the relevant criteria are fulfilled,
publish as a Candidate Recommendation
—and advance the specification from that state.
(See
class 3 changes
.)
6.3.10.3.
Revising a Recommendation: New Features
For
Recommendations
explicitly identified as
allowing new features
tentative new features (see
class 4 changes
may
be added as
candidate additions
in annotations,
and
class 4 changes
may be normatively incorporated
in the same fashion as
class 3 changes
in
§ 6.3.10.2 Revising a Recommendation: Substantive Changes
Note:
Limiting the addition of new features to
Recommendations
that explicitly allow them
enables third parties to depend on a stable feature-set for
Recommendations
that do not advertise that ability,
as was the case for all
Recommendations
prior to the 2020 revision of this Process.
Note:
When a
Recommendation
does not
allow new features
new features can 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
Such
technical reports
could be written to represent
additional modules building on top of the original
Recommendation
of the core technology,
or an expanded replacement of the original
Recommendation
of the core technology
(in which case the new
technical report
will typically have the same name as the original,
with an incremented version number).
6.3.10.4.
Incorporating Candidate Amendments
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.
The
Last Call for Review of Proposed Amendments
must be announced to other W3C groups, the public, and the
Advisory Committee
The announcement
must
Identify whether this is a
Last Call for Review of Proposed Corrections
Last Call for Review of Proposed Additions
or
Last Call for Review of Proposed Corrections and Additions
Identify the specific
candidate amendments
under review
as
proposed amendments
proposed corrections
proposed additions
).
Specify the deadline for review comments,
which must not be any sooner than 60 days from the Call for Review.
Solicit review and, if it does not already have it, implementation experience.
The combination of the existing
Recommendation
with the
proposed amendments
included in the
Last Call for Review of Proposed Amendments
is considered a
Patent Review Draft
for the purposes of the Patent Policy
[PATENT-POLICY]
Also, the review initiated by the
Last Call for Review of Proposed Amendments
is an
Advisory Committee Review
Note:
Last Call for Review of Proposed Additions
and
Last Call for Review of Proposed Corrections and Additions
can only be issued for
Recommendations
that
allow new features
Working Group
may
batch
multiple
proposed amendments
into a single
Last Call for Review of Proposed Amendments
To facilitate review,
Last Call for Review of Proposed Amendments
on a given specification
should not
be issued more frequently
than approximately once every 6 months.
At the end of the
Last Call for Review of Proposed Amendments
the
W3C Decision
may either be
to reject the
proposed amendment
or to clear the
proposed amendment
for advancement as is,
or to return the proposal to the
Working Group
with a request to
formally address
comments made on the changes under review.
If the
Working Group
needs to amend a
proposed amendment
in response to review feedback
it must issue another
Last Call for Review of Proposed Amendments
on the revised change
before it can be incorporated into the main text.
Once all comments on a
proposed amendment
have been
formally addressed
and after the
Working Group
can show
adequate implementation experience
and the fulfillment of all other requirements of Recommendation text,
it may incorporate the
proposed amendment
into the normative
Recommendation
by issuing an
update request
for publication of the updated
Recommendation
To ensure adequate review of
proposed amendment
combinations,
only
proposed amendments
included in the most recent
Last Call for Review of Proposed Amendments
can be incorporated into the normative
Recommendation
text.
(Thus if incorporation of a
proposed amendment
is postponed,
it may need to be included in multiple Last Calls for Review of Proposed Amendments.)
6.3.11.
Regression on the Recommendation Track
Working Group
may republish a
Recommendation-track
technical report
at a lower
maturity stage
by fulfilling the requirements to transition to that maturity stage,
as described above.
Additionally,
with the approvals (by
group decision
) of each of the
TAG
and the
AB
the
Team
may
return
the
technical report
to a lower
maturity stage
in response to
wide review
or a
formal objection
6.3.12.
Retiring Recommendation Track Documents
Work on a technical report
may
cease at any time.
Work
should
cease
if W3C or a
Working Group
determines
that it cannot productively carry the work any further.
6.3.12.1.
Abandoning an Unfinished Recommendation
Any
Recommendation-track
technical report
no longer intended
to advance or to be maintained,
and that is not being rescinded,
should
be
published
as a
Discontinued Draft
with no
substantive change
compared to the previous publication.
This can happen if
the
Working Group
decided
to abandon work on the report,
or as the result of an
AC Review
requiring the
Working Group
to discontinue work on the technical report before completion.
If a
Working Group
is made to
close
W3C
must
re-
publish
any unfinished
technical report
on the Recommendation track as
Discontinued Draft
Such a document should include in its status section
an explanation of why it was discontinued.
Working Group
may
resume work
on such a
technical report
within the scope of its charter
at any time,
by re-
publishing
it as a
Working Draft
6.3.12.2.
Rescinding a Candidate Recommendation
The process for rescinding a
Candidate Recommendation
is the same as for rescinding a
Recommendation
6.3.12.3.
Abandoning a W3C Recommendation
It is possible that W3C decides
that implementing a particular
Recommendation
is no longer recommended.
There are three designations for such specifications,
chosen depending on the advice W3C wishes to give about further use of the specification.
W3C
may
obsolete a
Recommendation
for example if the W3C Community decides that the
Recommendation
no longer represents best practices,
or is not adopted and is not apparently likely to be adopted.
An
Obsolete Recommendation
may
be restored to normal
Recommendation
for example because despite marking it Obsolete the specification is later more broadly adopted.
W3C
may
declare a Recommendation Superseded
if a newer version exists which 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.
Recommendation
can be both superseded and obsolete.
To rescind, supersede, or obsolete some part of a Recommendation,
W3C follows the process for
modifying a Recommendation
Note:
For the purposes of the W3C Patent Policy,
[PATENT-POLICY]
an
Obsolete
or
Superseded Recommendation
has the status of an active
Recommendation
although it is not advised for future implementation;
Rescinded Recommendation
ceases to be in effect
and no new licenses are granted under the Patent Policy.
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
Recommendation
can be initiated
either by a request from the
Team
or via a request from any of the following:
The
Working Group
who produced,
or is chartered to maintain,
the
Recommendation
The
TAG
, if there is no such
Working Group
Any individual who made a request to the relevant
Working Group
as described above,
or the
TAG
if such a group does not exist, to obsolete, rescind, supersede, or restore a
Recommendation
where the request was not answered within 90 days
5% of
Advisory Committee representatives
of
Members
in
Good Standing
The
Team
must
then
submit the request to the
Advisory Committee
for review.
For any
Advisory Committee review
of a proposal to
rescind,
obsolete,
supersede,
or restore
Recommendation
the
Team
must
announce the proposal to all
Working Group
Chairs
and to the Public,
as well as to the
Advisory Committee
indicate that this is a proposal to
Rescind,
Obsolete,
Supersede,
or restore,
Recommendation
as appropriate
identify the
Recommendation
by URL
publish a rationale for the proposal
identify known dependencies
and solicit review from all dependent
Working Groups
solicit public review
specify the deadline for review comments,
which
must
be at least 28 days
after the announcement
and
should
identify known implementations.
If there was any
dissent
in the
Advisory Committee review
the
Team
must
publish
the substantive content of the dissent to W3C
and the public
and
must
formally address
the dissent
at least 14 days
before publication as an
Obsolete
or
Rescinded Recommendation
The
Advisory Committee
may
initiate an
Advisory Committee Appeal
of the
Team
’s decision.
W3C
must
publish an
Obsolete
or
Rescinded Recommendation
with up to date status.
The updated version
may
remove the main body of the document.
The Status of this Document section
should
link
to the explanation of
Obsoleting and Rescinding W3C Specifications
[OBS-RESC]
as appropriate.
Once W3C has published a Rescinded Recommendation,
future W3C technical reports
must not
include normative references
to that technical report.
Note:
W3C strives to ensure that all Technical Reports
will continue to be available at their version-specific URL.
6.4.
The Note Track (Notes and Statements)
6.4.1.
Group Notes
Group Note
NOTE
is published
to provide a stable reference for a useful document
that is not intended to be a formal standard.
Working Groups
Interest Groups
the
TAG
and the
AB
may
publish work as
Notes
Examples include:
supporting documentation for a specification,
such as explanations of design principles
or use cases and requirements
non-normative guides to good practices
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
6.4.2.
Publishing Notes
In order to publish a
Note
or
Note Draft
the group:
must
record their decision
to request publication as a
Note
or
Note Draft
, and
should
publish documentation
of significant changes to the technical report
since any previous publication.
Both
Notes
and
Note Drafts
can be updated by republishing
as a
Note
or
Note Draft
technical report
may
remain
Note
indefinitely.
6.4.3.
Elevating Group Notes to W3C Statement status
W3C Statement
is a
Note
that has been endorsed by W3C as a whole.
In order to elevate a
Note
to
W3C Statement
status,
A group
must
show that the document has received
wide review
record the group’s decision to request publication as a
W3C Statement
show that all issues raised against the document
since its first publication as a
Note
have been
formally addressed
provide public documentation of any
Formal Objections
Note
specifying implementable technology
should not
be elevated to
W3C Statement
status;
if it does,
the request to publish as a
Statement
must
include rationale
for why it should be elevated,
and why it is not on the
Recommendation track
Once these conditions are fulfilled,
the
Team
must
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
Note
must not
be updated.
The decision to advance a document to
W3C Statement
is a
W3C Decision
Advisory Committee representatives
may initiate an
Advisory Committee Appeal
of the decision.
The
Team
must announce the publication of a
W3C Statement
to the
Advisory Committee
, other W3C groups, and the public.
6.4.4.
Revising W3C Statements
Given a recorded
group decision
to do so,
groups can request publication of a
W3C Statement
with
editorial changes
—including
candidate amendment
—without any additional process.
candidate amendment
can be folded into the main text of the
W3C Statement
once it has satisfied all the same criteria
as the rest of the
Statement
including review by the community to ensure
the substantive and editorial soundness of the
candidate amendments
To validate this, the group must request
an
Advisory Committee review
of the changes it wishes to incorporate.
The specific
candidate amendments
under review
must
be identified as
proposed amendments
just as in a
Last Call for Review of Proposed Corrections
The decision to incorporate
proposed amendments
into
W3C Statement
is a
W3C Decision
Advisory Committee representatives
may initiate an
Advisory Committee Appeal
of the decision.
6.5.
The Registry Track
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:
the
registry definition
, defining how the
registry tables
are structured and maintained
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
registry definition
defines what each
registry table
is and how it is maintained.
It
must
Define the scope and purpose of each
registry table
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
The
custodian
may be the initiating group, the
Team
, or a delegated entity.
The
custodian
for all
registry tables
in a single
registry
should
generally be the same entity.
If the
custodian
of a
registry table
ceases to exist or to operate as a custodian
(e.g., the relevant group is disbanded, or
the custodian is unresponsive to repeated attempts to make contact),
and the
chartered
or
elected group
that owns the
registry definition
is itself
closed
or
unresponsive,
the
Team
should
propose replacing the
custodian
which
must
be confirmed
by an
AC Review
as a
W3C Decision
6.5.2.
Publishing Registries
chartered
or
elected group
can publish a
registry
as a stand-alone
technical report
on the
Registry Track
where it is called a
registry report
Working Groups
have the additional option of
incorporating a
registry
as part of a
Recommendation
as an
embedded registry
The
registry report
or
embedded registry
must
Clearly label the
registry report
or
embedded registry
its
tables
and its
registry definitions
as such,
including a link to
§ 6.5 The Registry Track
in this Process.
Include the
registry definition
for each of its
registry tables
Provide the
registry data
by either:
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
Team
must
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:
Registry reports
are not subject to the
[PATENT-POLICY]
and therefore none of their publications correspond,
to
First Public Working Draft
Working Draft
or
Patent Review Draft
for the purposes of the
[PATENT-POLICY]
For the same reason,
there is no equivalent to
Rescinded Recommendation
nor to
Rescinded Candidate Recommendation
for
Registries
The equivalent of
Working Draft
is called
Registry Draft
The equivalent of
Candidate Recommendation
is called
Candidate Registry
with
Candidate Recommendation Snapshot
and
Candidate Recommendation Draft
corresponding to
Candidate Registry Snapshot
and
Candidate Registry Draft
The equivalent of
W3C Recommendation
is called
W3C Registry
Obsolete Recommendation
and
Superseded Recommendation
correspond to
Obsolete Registry
and
Superseded Registry
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.
Changes to the
registry tables
made in accordance with
candidate
or
proposed amendments
to the
registry definition
which would not be allowed by the unamended
registry definition
must
be identified as such.
6.5.4.
Registry Data Reports
When the
registry data
is published in a separate
technical report
from its
registry definition
that
report
is called a
Registry Data Report
This
technical report
Must
link to the
registry definition
establishing the
registry tables
that it contain.
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
).
Registry Data Reports
do not have maturity stages in and of themselves;
The maturity stage of the
registry
whose
data
they record
is that of the
technical report
holding the
registry definition
Anytime a change is made to a
registry definition
the group maintaining the
registry definition
must
update and republish
any document holding the corresponding
registry tables
to make it consistent with these changes.
Given a recorded
group decision
to do so,
the group maintaining the
registry definition
may
republish the
Registry Data Report
to incorporate
editorial changes
6.5.5.
Specifications that Reference Registries
Registries document values,
they do not define any architectural or interoperability requirements
related to those values.
All architectural and interoperability requirements
pertaining to
registry entries
must
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.)
6.5.6.
Registries and Patents
registry report
or
embedded registry
is not subject to the W3C Patent Policy,
and
must not
define any requirements on implementations.
For the purposes of the Patent Policy
[PATENT-POLICY]
(only),
any
embedded registry
in a
Recommendation track
document
is not a normative portion of that specification.
6.6.
Switching Tracks
Given a
Group decision
to do so,
Working Groups
can republish a
technical report
on a different track than the one it is on,
under the following restrictions:
technical report
that is or was
W3C Recommendation
W3C Statement
, or
Patent Review Draft
cannot switch tracks.
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.).
Note:
The initial maturity stage of the
Recommendation track
is
Working Draft
First Public Working Draft
designates a specific type of
Working Draft
and is not a separate maturity stage.
A document which switches to the
Recommendation track
is only published as a
First Public Working Draft
if it was never previously published as such;
otherwise, it is simply a
Working Draft
6.7.
Further reading
Refer to
"How to Organize a Recommendation Track Transition"
[TRANSITION]
in the
Art of Consensus
[GUIDE]
for practical information about preparing for the reviews
and announcements of the various steps,
and
tips on getting to Recommendation faster
[REC-TIPS]
Please see also the
Requirements for modification of W3C Technical Reports
[REPUBLISHING]
7.
Dissemination Policies
7.1.
Public Communication
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.
mission statement
[MISSION]
that explains the purpose and mission of W3C,
the key benefits for Members,
and the organizational structure of W3C.
Legal documents,
including
Membership Agreements
[MEMBER-AGREEMENT]
and documentation of any legal commitments W3C has with other entities.
The Process Document.
Public results of W3C activities and
Workshops
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
),
the Advisory Board,
the TAG,
and the Team.
For example,
the
charter
of some Working Groups
may
specify a
Member-only
confidentiality level for group proceedings.
Team-only
” information
is available to the Team and other authorized parties.
Those authorized to access
Member-only
and
Team-only
information:
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
Team
must
provide mechanisms
to protect the confidentiality of
Member-only
information
and ensure that authorized parties have proper access to this information.
Documents
should
clearly indicate
whether they require
Member-only
confidentiality.
Individuals uncertain of the confidentiality level of a piece of information
should
contact the Team.
Advisory Committee representatives
may
authorize
Member-only
access to
Member representatives
and other individuals employed by the Member
who are considered appropriate recipients.
For instance,
it is the responsibility of the
Advisory Committee representative
and other employees
and official representatives of the organization
to ensure that Member-only news announcements
are distributed for internal use only within their organization.
Information about Member mailing lists is available
in the
New Member Orientation
[INTRO]
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-only
must
make public
information pertinent to the technical report development process.
This document clearly indicates which information
must
be available to Members or the public,
even though that information was initially communicated on
Team-only
or
Member-only
channels.
Only the
Team
and parties authorized by the Team
may change the level of confidentiality of this information.
When doing so:
The
Team
must
use a version of the information
that was expressly provided by the author for the new confidentiality level.
In Calls for Review and other similar messages,
the Team
should
remind recipients to provide such alternatives.
The
Team
must 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,
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 representatives
may
initiate an
Advisory Committee Appeal
of the decision to sign the
agreement
If the proposal is rejected on
appeal
the
Team
must not
sign the
agreement
on behalf of W3C
unless directed to do so by the
Board
A signed
agreement
should
be made public.
Information about
W3C liaisons with other organizations
[LIAISON]
and the guidelines W3C follows when creating a liaison is available on the Web.
9.
Member Submissions
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
Team
may
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.
The
Member Submission
process consists of the following steps:
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:
The
Submitter(s)
and any other authors of the submitted material
must
agree
to license the Submission under the
W3C Document License
[DOC-LICENSE]
The request
must
satisfy the Member Submission licensing commitments
in
The W3C Patent Policy § sec-submissions
Detailed procedures and requirements are defined by the
Team
and documented in the “
Member submissions guidebook
[MEMBER-SUB]
Decision
After review, the
Team
must
either
acknowledge
or
reject
the Submission request.
If
acknowledged
the Team
must
make the
Member Submission
available
at the public W3C website
alongside other
acknowledged Member Submissions
[SUBMISSION-LIST]
If
rejected
the
Team
must
inform the
Advisory Committee representative(s)
of the
Submitter(s)
and
must
provide rationale if requested by the
Submitter(s)
The
Submitter(s)
may
initiate a
Submission Appeal
The
Advisory Committee representative(s)
of the
Submitter(s)
may
initiate a
Submission Appeal
The procedure for handling
Submission Appeals
is the same as for
Formal Objections
except that an
AC Appeal
is not possible
and both the Formal Objection and the
Council Report
are confidential to the
Team
TAG
, and
AB
10.
Process Evolution
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.
The documents covered by this section are:
the W3C Process (this document)
the W3C Patent Policy
[PATENT-POLICY]
the W3C Code of Conduct
[COC]
The W3C Document License
[DOC-LICENSE]
The
Advisory Board
initiates review as follows:
The
Team
sends a Call for Review to the
Advisory Committee
and other W3C groups.
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
After the Advisory Committee review
following a
W3C decision
to adopt the document(s),
the Team does so
and sends an announcement to the
Advisory Committee
Advisory Committee representatives
may
initiate
an
Advisory Committee Appeal
to W3C.
Note:
As of June 2020,
the
Patent Policy
is developed in the
Patents and Standards Interest Group
the
Code of Conduct
in the
Positive Work Environment Community Group
and the Process in the
W3C Process Community Group
Appendix A: Retired Terminology
This section is non-normative.
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.
Amended Recommendation
(retired term)
Last defined
in section 6.2.1 of the 2020 Process
Edited Recommendation
(retired term)
Last defined
in section 6.1.2 of the 2019 Process
Last Call
(retired term)
Last defined
in section 7.4.2 of the 2005 Process
Maturity level
(renamed term)
Last defined
in section 6.3.1 of the 2021 Process
now called
maturity stage
Member Consortium
, plural: Member Consortia
(renamed term)
Last defined
in section 2.1.2.1 of the 2021 Process
now called
Member Association
Memorandum of Understanding
, plural: Memoranda of Understanding, abbreviation: MoU
(renamed term)
Last defined
in section 9 of the 2021 Process
now called
technical agreement
Other Charter
(renamed term)
Last used
in section 5.2.6 of the 2020 Process
now called
Exclusion Draft Charter
Proposed Recommendation
(retired term)
Last defined
in section 6.3.1 of the 2023 Process
Team Submissions
(retired term)
Last defined
in section 2.2.1 of the 2019 Process
W3C Chair
(renamed term)
Last defined
in section 2.2 of the 2014 Process
now called
CEO
Appendix B: Acknowledgments
This section is non-normative.
The editors are grateful to the following people,
who as interested individuals and/or with the affiliation(s) listed,
have contributed to this proposal for a revised Process:
Adam Basha,
Anna Weinberg (Apple)
Charles McCathie Nevile,
Chris Lilley (W3C),
Chris Needham (BBC),
Chris Wilson (Google),
Coralie Mercier (W3C),
David W. Singer (Apple),
Denis Ah-Kang (W3C),
Dominique Hazael-Massieux (W3C),
Ian Jacobs (W3C),
Jeffrey Yasskin (Google),
Jill Schmidt (Apple),
Marcos Cáceres (Apple),
Mark Nottingham,
Martin Thomson (Mozilla),
Michael Champion,
Michael Sirtori (Intel),
Mike Smith (W3C),
Nick Doty (Center for Democracy and Technology),
Nigel Megitt (BBC),
Philippe Le Hégaret (W3C),
Sam Sneddon (Apple),
Shawn Lawton Henry (W3C),
Tantek Çelik (Mozilla),
Ted Thibodeau Jr (OpenLink Software),
Theresa O’Connor (Apple),
Vivien Lacourba (W3C).
The editors are sorry for forgetting any names,
and grateful to those who have listened patiently to conversations about this document
without feeling a need to add more.
The following individuals contributed to the development of earlier versions of the Process:
Alex Russell (Google),
Andreas Tai (Institut fuer Rundfunktechnik),
Andrew Betts (Fastly),
Ann Bassetti (The Boeing Company),
Anne van Kesteren,
Art Barstow (Nokia, unaffiliated),
Bede McCall (MITRE),
Ben Wilson,
Brad Hill (Facebook),
Brian Kardell (JQuery, Igalia),
Carine Bournez (W3C),
Carl Cargill (Netscape, Sun Microsystems, Adobe),
Charles McCathie Nevile (ConsenSys),
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 W. Singer (Apple),
David Singer (IBM),
Delfí Ramírez,
Dominique Hazaël-Massieux (W3C),
Don Brutzman (Web3D),
Don Deutsch (Oracle),
Eduardo Gutentag (Sun Microsystems),
Elika J. Etemad
aka
fantasai,
Florian Rivoal,
Fuqiao Xue (W3C),
Geoffrey Creighton (Microsoft),
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),
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 (Mozilla),
Maria Courtemanche (IBM),
Mark Crawford (SAP),
Mark Nottingham,
Michael Champion (Microsoft),
Michael Geldblum (Oracle),
Mike West (Google),
Mitch Stoltz (EFF),
Natasha Rooney (GSMA),
Nigel Megitt (BBC),
Olle Olsson (SICS),
Ora Lassila (Nokia),
Paul Cotton (Microsoft),
Paul Grosso (Arbortext),
Peter Linss,
Peter Patel-Schneider,
Philippe Le Hégaret (W3C),
Qiuling Pan (Huawei),
Ralph Swick (W3C),
Renato Iannella (IPR Systems),
Rigo Wenning (W3C),
Rob Sanderson (J Paul Getty Trust),
Robin Berjon (W3C),
Sally Khudairi (W3C),
Sam Ruby (IBM),
Sam Sneddon,
Samuel Weiler (W3C),
Sandro Hawke (W3C),
Sangwhan Moon (Odd Concepts),
Scott Peterson (Google),
Shawn Lawton Henry,
Steve Holbrook (IBM),
Steve Zilles (Adobe Systems)
Steven Pemberton (CWI),
TV Raman (Google),
Tantek Çelik (Mozilla),
Ted Thibodeau Jr (OpenLink Software),
Terence Eden (Her Majesty’s Government),
Thomas Reardon (Microsoft),
Tim Berners-Lee (W3C),
Tim Krauskopf (Spyglass),
Travis Leithead (Microsoft),
Virginia Fournier (Apple),
Virginie Galindo (Gemalto),
Wayne Carr (Intel),
Wendy Fong (Hewlett-Packard),
Wendy Seltzer (W3C),
Yves Lafon (W3C).
Appendix C: Changes
This section is non-normative.
Changes since the
3 November 2023 Process
This document is based on the
3 November 2023 Process
list of issues addressed
diff from Process 2023 to this latest version
as well as
detailed log of all changes since then
are available.
In addition to a number of editorial adjustments and minor tweaks, the following is a summary of the main differences:
Changes to technical reports and their publication
Retire the Proposed Recommendation phase of the Recommendation track.
It was only used as a short-lived transition
during which various verifications and votes about CR were done.
These can be done on a CR
without having to republish it as a separate thing.
This simplifies the Process without changing the actual quality or consensus expectations.
(See
Issue 861
Retire “
Streamlined Publication Approval
”.
This was meant to enable REC track publication with fewer/faster approval steps
when some stricter than usual criteria were fulfilled.
However, regular REC track publication have improved enough
that this became unnecessary,
and nobody was using it.
(See
Issue 856
Add a requirement to make progress on external issues for update requests
(See
Issue 781
Drop the requirement to publish every 6 months if nothing has changed.
(See
Issue 1013
Enable Team to replace defunct registry custodians when no-one else can.
(See
Issue 699
Allow registries to be published by Interest Groups, the Advisory Board, and the TAG,
in addition to Working Groups.
(See
Issue 902
Rename “registry sections” to
embedded registries
to avoid confusion over whether they can be split across multiple sections of a
Recommendation
(See
Issue 800
Rename "Draft Note" into "Note Draft",
and "Draft Registry" into "Registry Draft"
to be consistent with other statuses that uses the word "Draft",
and to make that word stand out more.
(See
Issue 779
Clarify the definition of a Registry (see
Issue 800
and of Recommendation Track Documents (see
Pull Request 831
).
Consolidate and harmonize into
one section
the various parts of the Process
that described whether and how the Team can maintain technical reports
that no longer have a Group chartered to maintain them.
(See
Pull Request 860
Changes to chartering
Introduce a formal
Charter Refinement
phase prior to the
AC Review
(See
Issue 580
Be more specific about which types of changes to a charter must go through AC Review.
(See
Pull Request 1042
Require Chairs to be listed in Charters.
(See
Issue 823
Reorganize and rephrase
§ 4.4 Charter Review and Approval
for readability and ease of understanding.
This change, while moderate in size, is purely editorial.
(See
Pull Request 850
Changes to formal decision making and escalation
Adjust the rules guiding initiation of Councils,
to make the deadline strict,
and to provide a fallback mechanism if they are not met.
(See
Pull Request 925
Make the Council’s short-circuit a little more flexible.
(See
Issue 852
Exclude TAG/AB Members from voting on TAG/AB proposals in Councils.
(See
Issue 749
Limit the involvement of Tim Berners-Lee to the TAG proper,
not including the Council.
(See
Pull Request 792
Council dismissal vote counts must be reported.
(See
Issue 748
Require documentation of how Formal Objections get resolved.
(See
Issue 953
Put constraints on the timing of making Formal Objections public.
(See
Issue 735
Fine-tune the rules about
how changes can be incorporated into a proposal
following an AC Review.
(See
Issue 825
Adjust AC appeal vote threshold based on participation,
aligning with the thresholds and super majority requirements
for "Requisite Member Vote" from the W3C Bylaws.
(See
Issue 886
Let the originator of a proposal decide whether to try again
after addressing feedback
following an AC Appeal.
(See
Issue 844
Simplify provisions regarding substitute representatives and proxies.
(See
Issue 373
Other changes
Reuse the bylaws’ notion of Good Standing,
and restrict TAG and AB elections
as well as AC Votes where a decision is made based on counting ballots
to Members in Good Standing.
(See
Issue 935
and
Pull Request 954
The section on Member Submissions was significantly shortened and simplified,
reducing the complexity under formal Process authority,
and shifting much of the material to /Guide,
under Team authority.
(See
Issue 412
and
Pull Request 936
Clarify how the outcome of certain ballots are determined.
(See
Issue 836
Issue 838
Stop citing the superseded TAG charter.
(See
Issue 794
Clarify amount of leeway around incomplete nominations to TAG or AB elections.
(See
Issue 464
Shift most of the non-normative discussion about Workshops to
[GUIDE]
and reorganize the remaining normative requirements.
(See
Pull Request 876
The URL of this document was changed
from /Consortium/Process/ to /policies/process/
for better integration in the W3C website architecture.
Changes since earlier versions
Changes since earlier versions of the Process are detailed
in the
changes section of the previous version
of the Process.
Index
Terms defined by this specification
AB
, in § 3.3.1.1
AC
, in § 3.2.1
AC Appeal
, in § 5.9
acknowledged
, in § 9
AC representative
, in § 3.2.2
AC Review
, in § 5.7
adequate implementation experience
, in § 6.3.2
Adopted Draft
, in § 4.3
Advisory Board
, in § 3.3.1.1
Advisory Committee
, in § 3.2.1
Advisory Committee Appeal
, in § 5.9
Advisory Committee representative
, in § 3.2.2
Advisory Committee review
, in § 5.7
affirm
, in § 5.6.2.7
agreement
, in § 8
allow new features
, in § 6.3.1
alt AC rep
, in § 3.2.2
alternate AC representative
, in § 3.2.2
alternate Advisory Committee representative
, in § 3.2.2
Amended Recommendation
, in § Unnumbered section
Appeal
, in § 5.9
appeal vote
, in § 5.9
at risk
, in § 6.3.7
Board
, in § 2.2
Board of Directors
, in § 2.2
BoD
, in § 2.2
Call for Review
, in § 5.7.1
candidate addition
, in § 6.2.5
candidate amendment
, in § 6.2.5
candidate correction
, in § 6.2.5
Candidate Recommendation
, in § 6.3.1
Candidate Recommendation Draft
, in § 6.3.1
Candidate Recommendation review period
, in § 6.3.7
Candidate Recommendation Snapshot
, in § 6.3.1
Candidate Registry
, in § 6.5.2
Candidate Registry Draft
, in § 6.5.2
Candidate Registry Snapshot
, in § 6.5.2
CEO
, in § 2.2
Chair
, in § 3.4.1
chair decisions
, in § 5.1
charter
, in § 4.3
charter draft
, in § 4.1
chartered groups
, in § 3.4
charter extension
, in § 4.6
Chartering Facilitator
, in § 4.2
charter refinement
, in § 4.2
charter review notice
, in § 4.1
Consensus
, in § 5.2.1
convened
, in § 5.6.2.6
Council
, in § 5.6.2
Council Chair
, in § 5.6.2.5
Council Report
, in § 5.6.2.8
Council Staff Contact
, in § 5.6.2.1
CR
, in § 6.3.1
CRD
, in § 6.3.1
CRS
, in § 6.3.1
custodian
, in § 6.5.1
Discontinued Draft
, in § 6.3.1
dismiss
, in § 5.6.2.3
dismissal
, in § 5.6.2.3
dismissed
, in § 5.6.2.3
Dissent
, in § 5.2.1
distributed meeting
, in § 3.1.2
ED
, in § 6.3.1
Edited Recommendation
, in § Unnumbered section
Editor Draft
, in § 6.3.1
editorial change
, in § 6.2.3
Editor's Draft
, in § 6.3.1
elected groups
, in § 3.3
embedded registry
, in § 6.5.2
errata
, in § 6.2.4
erratum
, in § 6.2.4
Exclusion Draft
, in § 4.3
Exclusion Draft Charter
, in § 4.3
face-to-face meeting
, in § 3.1.2
First Public Working Draft
, in § 6.3.1
formally addressed
, in § 5.3
Formal Objection
, in § 5.5
fully addressed
, in § 5.6.2.7
Good Standing
, in § 2.1.3
group
, in § 3
group decision
, in § 5.1
Group Note
, in § 6.4.1
Interest Groups
, in § 3.4
Invited Expert in an Interest Group
, in § 3.4.3.4
Invited Expert in a Working Group
, in § 3.4.3.3
Last Call
, in § Unnumbered section
Last Call for Review of Proposed Additions
, in § 6.3.10.4
Last Call for Review of Proposed Amendments
, in § 6.3.10.4
Last Call for Review of Proposed Corrections
, in § 6.3.10.4
Last Call for Review of Proposed Corrections and Additions
, in § 6.3.10.4
liaison
, in § 8
Maturity level
, in § Unnumbered section
Member
, in § 2.1
Member Association
, in § 2.1.2.1
Member Associations
, in § 2.1.2.1
Member Consortium
, in § Unnumbered section
Member-Only
, in § 7.2
Member representative in an Interest Group
, in § 3.4.3.2
Member representative in a Working Group
, in § 3.4.3.1
Member Submission
, in § 9
Memorandum of Understanding
, in § Unnumbered section
minor changes
, in § 4.4.2
Minority Opinion
, in § 5.6.2.7
minutes
, in § 3.1.2.2
Note
, in § 6.4.1
Note Draft
, in § 6.4.1
not required
, in § Unnumbered section
Obsolete Recommendation
, in § 6.3.1
Obsolete Registry
, in § 6.5.2
Other Charter
, in § Unnumbered section
overrule
, in § 5.6.2.7
overturn
, in § 5.6.2.7
participant
, in § 3
participants in an Interest Group
, in § 3.4.2
participants in a Working Group
, in § 3.4.2
participate in a Working Group as an Invited Expert
, in § 3.4.3.3
Patent Review Drafts
, in § 6.3.1
primary affiliation
, in § 3.3.3.3
proposed additions
, in § 6.3.10.4
proposed amendments
, in § 6.3.10.4
proposed corrections
, in § 6.3.10.4
Proposed Recommendation
, in § Unnumbered section
public participants
, in § 3.4.2
publish
, in § 6.2.1
REC
, in § 6.3.1
Recommendation
, in § 6.3.1
Recommendation Track
, in § 6.3
Recommendation-track
, in § 6.3
Recommendation Track document
, in § 6.3.1
Recommendation-track document
, in § 6.3.1
REC Track
, in § 6.3
REC Track document
, in § 6.3.1
registry
, in § 6.5
registry change
, in § 6.2.3
registry data
, in § 6.5
Registry Data Report
, in § 6.5.4
registry definition
, in § 6.5.1
Registry Draft
, in § 6.5.2
registry entry
, in § 6.5
registry report
, in § 6.5.2
registry table
, in § 6.5
Registry Track
, in § 6.5.2
rejected
, in § 9
Related Member
, in § 2.1.2.2
renounce
, in § 5.6.2.3
renunciation
, in § 5.6.2.3
Rescinded Candidate Recommendation
, in § 6.3.1
Rescinded Recommendation
, in § 6.3.1
resolution
, in § 5.1
Staff Contact
, in § 3.4.1
Statement
, in § 6.4.3
Submission Appeals
, in § 9
submitter
, in § 9
subsidiary
, in § 2.1.2.2
substantive change
, in § 6.2.3
substitute
, in § 3.4.2
Superseded Recommendation
, in § 6.3.1
Superseded Registry
, in § 6.5.2
Supplemental Confidential Council Report
, in § 5.6.2.8
TAG
, in § 3.3.2.1
Team
, in § 2.2
Team Contact
, in § 3.4.1
Team correction
, in § 6.2.6
Team Decision
, in § 5.1
Team-Only
, in § 7.2
Team representative in an Interest Group
, in § 3.4.3.6
Team representative in a Working Group
, in § 3.4.3.5
Team's Decision
, in § 5.1
Team Submissions
, in § Unnumbered section
technical agreement
, in § 8
Technical Architecture Group
, in § 3.3.2.1
Technical Report
, in § 6.2.1
Transition Requests
, in § 6.3.3
Unanimity
, in § 5.2.1
Update Requests
, in § 6.3.4
upheld
, in § 5.6.2.7
W3C Board of Directors
, in § 2.2
W3C Candidate Recommendation
, in § 6.3.1
W3C Chair
, in § Unnumbered section
W3C Council
, in § 5.6.2
W3C Council Chair
, in § 5.6.2.5
W3C decision
, in § 5.1
W3C Fellows
, in § 2.2
W3C Group
, in § 3
W3C Member
, in § 2.1
W3C Recommendation
, in § 6.3.1
W3C Recommendation Track
, in § 6.3
W3C Recommendation Track document
, in § 6.3.1
W3C Registry
, in § 6.5.2
W3C Statement
, in § 6.4.3
W3C Team
, in § 2.2
W3C Working Draft
, in § 6.3.1
WD
, in § 6.3.1
wide review
, in § 6.2.2.1
Working Draft
, in § 6.3.1
Working Groups
, in § 3.4
Workshop
, in § 2.1.1
Terms defined by reference
[W3C-PATENT-POLICY]
defines the following terms:
Exclusion Opportunity
Patent Advisory Group
References
Normative References
[COC]
W3C Code of Conduct
. URL:
[COLLABORATORS-AGREEMENT]
Invited expert and collaborators agreement
. URL:
[CONFLICT-POLICY]
Conflict of Interest Policy for the W3C Team
. URL:
[DOC-LICENSE]
W3C Document License
. URL:
[PATENT-POLICY]
The W3C Patent Policy
. URL:
[PATENT-POLICY-2004]
The W3C 2004 Patent Policy, Updated 2017
. URL:
[PATENT-POLICY-2020]
The W3C 2020 Patent Policy
. URL:
[PUBRULES]
Publication Rules
. URL:
[RFC2119]
S. Bradner.
Key words for use in RFCs to Indicate Requirement Levels
. March 1997. Best Current Practice. URL:
[RFC3797]
D. Eastlake 3rd.
Publicly Verifiable Nominations Committee (NomCom) Random Selection
. June 2004. Informational. URL:
[W3C-PATENT-POLICY]
Wendy Seltzer.
W3C Patent Policy
. 15 September 2020. URL:
Informative References
[AB-HP]
The Advisory Board home page
. URL:
[AC-MEETING]
Advisory Committee meetings (Member-only access)
. URL:
[BG-CG]
Community and Business Group Process
. URL:
[BYLAWS]
Amended and Restated Bylaws of World Wide Web Consortium, Inc.
. URL:
[CALENDAR]
Calendar of all scheduled official W3C events
. URL:
[CHAIR]
W3C Working/Interest Group Chair
. URL:
[CHARTER]
How to Create a Working Group or Interest Group
. URL:
[COUNCIL-REPORT-INDEX]
Council Report Index
. URL:
[CURRENT-AC]
Current Advisory Committee representatives (Member-only access)
. URL:
[DECISION-APPEAL]
Appealing a W3C Decision
. URL:
[ELECTION-HOWTO]
How to Organize an Advisory Board or TAG election
. URL:
[FELLOWS]
W3C Fellows Program
. URL:
[GROUP-MAIL]
Group mailing lists
. URL:
[GUIDE]
The Art of Consensus, a guidebook for W3C Working Group Chairs and other collaborators
. URL:
[INTRO]
Process, Patent Policy, Finances, Specs management, Strategic vision (Member-only access)
. URL:
[JOIN]
How to Join W3C
. URL:
[LIAISON]
W3C liaisons with other organizations
. URL:
[MEMBER-AGREEMENT]
W3C Membership Agreement
. URL:
[MEMBER-HP]
Member website (Member-only access)
. URL:
[MEMBER-LIST]
The list of current W3C Members
. URL:
[MEMBER-SUB]
Member submissions guidebook
. URL:
[MISSION]
The W3C Mission statement
. URL:
[OBS-RESC]
Obsoleting and Rescinding W3C Specifications
. URL:
[REC-TIPS]
Tips for Getting to Recommendation Faster
. URL:
[REPUBLISHING]
In-place modification of W3C Technical Reports
. URL:
[SUBMISSION-LIST]
The list of acknowledged Member Submissions
. URL:
[TAG-HP]
The TAG home page
. URL:
[TEAM-CONTACT]
Role of the Team Contact
. URL:
[TR]
The W3C technical reports index
. URL:
[TRANSITION]
Organize a Technical Report Transition
. URL:
[TRANSLATION]
Translations of W3C technical reports
. URL:
[W3C-IPR]
W3C IPR Policies
. URL:
US