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
the
Membership
Agreement
[MEMBER-AGREEMENT]
.
The
W3C
Patent
Policy
[PATENT-POLICY]
and
other
policies
is
incorporated
by
normative
reference
as
a
part
of
the
Process
Document
are
Document,
and
is
thus
equally
binding.
The
Patent
Policy
and
Code
of
Conduct
place
places
additional
obligations
on
Members,
Team,
and
other
participants
in
W3C.
The
Process
Document
does
not
restate
those
requirements
but
includes
references
to
them.
The
Process
Document,
Patent
Policy,
Document
and
Code
of
Conduct
Patent
Policy
have
been
designed
to
allow
each
them
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, the W3C approves the group(s), and they begin their work.
Further sections of this Process Document deal with topics including liaisons ( § 9 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 the Membership Agreement [MEMBER-AGREEMENT] . They are represented in W3C processes as follows:
-
One
representative
per
Member
organization
participatesparticiaptes in the Advisory Committee which oversees the work of the 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 the Member Agreement, representatives of Member organizations participate in W3C as follows:
- In Working Groups and Interest Groups .
- In Workshops and Symposia ;
- 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
Web
site
[MEMBER-HP]
.
2.1.2.
Member
Associations
Consortia
and
Related
Members
2.1.2.1.
Membership
Associations
Consortia
A
“
Member
Association
Consortium
”
means
a
consortium,
user
society,
or
association
of
two
or
more
individuals,
companies,
organizations
or
governments,
or
any
combination
of
these
entities
which
has
the
purpose
of
participating
in
a
common
activity
or
pooling
resources
to
achieve
a
common
goal
other
than
participation
in,
or
achieving
certain
goals
in,
W3C.
A
joint-stock
corporation
or
similar
entity
is
not
a
Member
Association
Consortium
merely
because
it
has
shareholders
or
stockholders.
If
it
is
not
clear
whether
a
prospective
Member
qualifies
as
a
Member
Association
Consortium
,
the
CEO
may
reasonably
make
the
determination.
For
a
Member
Association
Consortium
,
the
rights
and
privileges
of
W3C
Membership
described
in
the
W3C
Process
Document
extend
to
the
Member
Association
Consortium
's
paid
staff
and
Advisory
Committee
representative.
Member
Associations
Consortia
may
also
designate
up
to
four
(or
more
at
the
Team’s
discretion)
individuals
who,
though
not
employed
by
the
organization,
may
exercise
the
rights
of
Member
representatives
.
For
Member
Associations
Consortia
that
have
individual
people
as
members,
these
individuals
must
disclose
their
employment
affiliation
when
participating
in
W3C
work.
Provisions
for
related
Members
apply.
Furthermore,
these
individuals
must
represent
the
broad
interests
of
the
W3C
Member
organization
and
not
the
particular
interests
of
their
employers.
For
Member
Associations
Consortia
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,
Consortium,
IPR
commitments
are
made
on
behalf
of
the
Member
Association,
Consortium,
unless
a
further
IPR
commitment
is
made
by
the
individuals'
employers.
2.1.2.2. Related Members
In the interest of ensuring the integrity of the consensus process, Member involvement in some of the processes in this document is affected by related Member status. As used herein, two Members are related if:
- 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.
A subsidiary is an organization of which effective control and/or majority ownership rests with another, single organization.
Related Members must disclose these relationships according to the mechanisms described in the New Member Orientation [INTRO] .
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
and
not
subject
to
the
Process.
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
Ethics
and
Professional
Conduct
[COC]
[CEPC]
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,
such
as
failure
to
meet
the
requirements
on
individual
behavior
of
(a)
this
process
and
in
particular
the
Code
of
Conduct,
CEPC,
or
(b)
the
membership
agreement,
or
(c)
applicable
laws,
occur.
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
athe 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 W3C Team conflict of interest policy [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 .
W3C distinguishes two types of meetings:
- A face-to-face meeting is one where most of the attendees are expected to participate in the same physical location.
- A distributed meeting is one where most of the attendees are expected to participate from remote locations (e.g., by telephone, video conferencing, or IRC ).
A 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.
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
,
team,
the
Member
and
their
representatives
or
the
Invited
Expert
will
be
deemed
to
have
resigned
from
the
relevant
group.
The
Team
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 the W3C at large. It is responsible for:
- reviewing plans for W3C at each Advisory Committee meeting .
- reviewing formal proposals of the W3C: Charter Proposals , Proposed Recommendations , 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 the Membership Agreement. The New Member Orientation [INTRO] explains how to subscribe or unsubscribe to Advisory Committee mailing lists, provides information about Advisory Committee Meetings , explains how to name a new Advisory Committee representative , and more. Advisory Committee representatives must follow the conflict of interest policy by disclosing information according to the mechanisms described in the New Member Orientation.
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.
Web
site.
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
Together
with
the
CEO
and
the
members
of
a
W3C
Council
the
TAG
,
members
of
the
Advisory
Board
hear
and
adjudicate
on
Submission
Appeals
and
Formal
Objections
.
The
Advisory
Board
is
distinct
from
the
Board
not
a
board
of
Directors
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
seating
as
part
of
a
the
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
The
Chair(s)
are
subject
to
ratification
by
secret
ballot,
requiring
approval
ballot
by
two
thirds
of
the
elected
participants.
Chair
selection
must
be
run
at
least
AB
upon
appointment
and
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.
AB
term.
The
team
also
appoints
a
Team
Contact
,
as
described
in
§ 3.4.1
Requirements
for
All
Chartered
Groups
.
The
CEO
and
Team
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.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
Together
with
the
CEO
and
members
of
a
W3C
Council
the
AB
,
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. Please refer to the TAG charter [TAG-CHARTER] for more information about the background and scope of the TAG, and the expected qualifications of TAG participants.
When the TAG votes to resolve an issue, each TAG participant (whether appointed, elected, or the Chair) has one vote; see also the section on voting in the TAG charter [TAG-CHARTER] and the general section on votes in this Process Document.
Details about the TAG (e.g., the list of TAG participants, mailing list information, and summaries of TAG meetings) are available at the TAG home page [TAG-HP] .
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 ;
-
EightSix 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
Team
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
three
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.
- a Member-only list for discussions within the TAG and for requests to the TAG that, for whatever reason, cannot be made on the public list.
The 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
3
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. A change of affiliation is defined such that this field would carry a different answer if the nominee were to be re-nominated (therefore, terminating employment, or accepting new employment, are changes of affiliation). (Other formal relationships such as other contracts should be disclosed as potential conflicts of interest.) Each nomination should include a few informative paragraphs about the nominee.
If, 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 (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
Individuals
who
have
reached
the
limit
on
of
two
consecutive
appointed
terms
does
not
constrain
term-limited
appointees
from
running
may
freely
run
for
election
at
any
time.
if
they
wish
to
continue
serving
on
the
TAG
.
The
Team
's
choice
of
appointee(s)
is
subject
to
ratification
by
secret
ballot
by
both
the
AB
and
two
thirds
of
the
TAG
,
requiring
a
two-thirds
approval
from
each.
.
In
the
case
of
regularly
scheduled
elections,
election,
ratification
is
by
the
TAG
participants
in
this
ratification
are
its
members
for
of
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(6 for the TAG , 9 for the AB ); and the maximum number corresponds to all unoccupied seats. Except for the number of available seats and the length of the terms, the usual rules for Advisory Board and Technical Architecture Group Elections apply.
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
coordinate
the
group’s
tasks.
The
Team
appoints
(and
re-appoints)
Chairs
for
all
groups.
The
Chair
is
a
Member
representative
,
a
Team
representative
,
or
an
Invited
Expert
,
(invited
by
the
Team
).
The
requirements
of
this
document
that
apply
to
those
types
of
participants
apply
to
Chairs
as
well.
Note:
The
role
of
the
Chair
[CHAIR]
is
described
in
the
Art
of
Consensus
[GUIDE]
.
Each
group
must
have
a
Team
Contact
,
who
acts
as
the
interface
between
the
Chair
,
group
participants,
and
the
rest
of
the
Team.
Note:
The
role
of
the
Team
Contact
[TEAM-CONTACT]
is
described
in
the
Art
of
Consensus
[GUIDE]
.
The
Chair
and
the
Team
Contact
of
a
group
should
not
be
the
same
individual.
Each group must have an archived mailing list for formal group communication (e.g., for meeting announcements and minutes , documentation of decisions, and Formal Objections to decisions). It is the responsibility of the Chair and Team Contact to ensure that new participants are subscribed to all relevant mailing lists. Refer to the list of group mailing lists [GROUP-MAIL] .
A Chair may form task forces (composed of group participants) to carry out assignments for the group. The scope of these assignments must not exceed the scope of the group’s charter. A group should document the process it uses to create task forces (e.g., each task force might have an informal "charter"). Task forces do not publish technical reports ; the Working Group may choose to publish their results as part of a technical report.
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 Team Contact ).
There are four types of individual participants in an Interest Group : the same three types as for Working Groups plus, for an Interest Group where the only participation requirement is mailing list subscription , public participants .
Except where noted in this document or in a group charter, all participants share the same rights and responsibilities in a group; see also the individual participation criteria .
A participant may represent more than one organization in a Working Group or Interest Group . Those organizations must all be members of the group.
An individual may become a Working or Interest Group participant at any time during the group’s existence. See also relevant requirements in “Joining an Already Established Working Group” in the W3C Patent Policy [PATENT-POLICY] .
On an exceptional basis, a Working or Interest Group participant may designate a substitute to attend a meeting and should inform the Chair . The substitute may act on behalf of the participant, including for votes . For the substitute to vote, the participant must inform the Chair in writing in advance. As a courtesy to the group, if the substitute is not well-versed in the group’s discussions, the regular participant should authorize another participant to act as proxy for votes.
To allow rapid progress, Working Groups are intended to be small (typically fewer than 15 people) and composed of experts in the area defined by the charter. In principle, Interest Groups have no limit on the number of participants. When a Working Group grows too large to be effective, W3C may split it into an Interest Group (a discussion forum) and a much smaller Working Group (a core group of highly dedicated participants).
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 Team Contact with all of the following information , in addition to any other information required by the Call for Participation and charter (including the participation requirements of the W3C Patent Policy [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 Team Contact has agreed with the Chair’s choice, and
- the individual has provided the information required of an Invited Expert to the Chair and Team Contact.
To designate an individual as an Invited Expert in a Working Group, the Chair must inform the Team Contact and provide rationale for the choice. When the Chair and the Team Contact disagree about a designation, the 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
4.1. Initiating Charter Development
W3C creates charters for chartered groups based on interest from the Members and Team. The Team must notify the Advisory Committee when a charter for a new Working Group or Interest Group is in development. This is intended to raise awareness, even if no formal proposal is yet available. Advisory Committee representatives may provide feedback on the Advisory Committee discussion list or via other designated channels.
W3C may begin work on a Working Group or Interest Group charter at any time.
4.2. 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 group (typically from six months to two years).
- The nature of any deliverables (technical reports, reviews of the deliverables of other groups, or software).
-
Expected
milestone
dates
where
available.
Note: A charter
doesis notneedrequired 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.
- 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 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.3.
Charter
Advisory
Committee
Review
and
Approval
of
a
Charter
The
review
period
Team
must
be
at
least
28
days.
Any
solicit
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
every
new
or
substantively
modified
charter
must
highlight
important
changes
(e.g.,
regarding
deliverables
Working
Group
or
resource
allocation)
and
include
rationale
Interest
Group
charter,
except
for
the
changes.
either:
-
Substantivea charter extension substantive changes to a charter
(including extensions )that do not affect the way the group functions in any significantwayway.
The
review
period
may
must
be
approved
by
a
Team
Decision
,
in
which
case
they
do
at
least
28
days.
The
following
are
examples
of
substantive
changes
that
would
not
require
an
Advisory
Committee
Review
.
The
following
are
examples
of
such
changes:
:
the
addition
of
an
in-scope
deliverable,
a
change
of
Team
Contact
,
or
a
change
of
Chair
.
Though
Advisory
Committee
Review
is
not
required,
such
Such
changes
must
still
nonetheless
be
announced
to
the
Advisory
Committee
,
and
to
participants
in
the
Working
or
in
the
Interest
Group,
Group
,
and
a
rationale
must
be
provided.
The Call for Review of a substantively modified charter must highlight important changes (e.g., regarding deliverables or resource allocation) and include rationale for the changes.
As part of the Advisory Committee review of any new or substantively modified Working Group charter, any Advisory Committee representative may request an extended review period.
Such a request must be submitted with a Member’s comments in response to the Call for Review. Upon receipt of any such request, the Team must ensure that the Call for Participation for the Working Group occurs at least 60 days after the Call for Review of the charter.
4.4. 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
After
the
W3C
Decision
Review
Period
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 Team 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.5. 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 Team Contact , and instructions for joining the group).
After a charter extension, Advisory Committee representatives and the Chair are not required to re-designate Member representatives and Invited Experts .
Advisory Committee representatives may initiate an Advisory Committee Appeal against a Team decision regarding the extension of a Working Group or Interest Group charter.
4.6. Chartered Group Closure
A Working Group or Interest Group charter specifies a duration for the group.
In
exceptional
circumstances,
The
Team
,
the
TAG
,
or
the
AB
may
propose
through
an
AC
Review
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.
A
charter.
This
may
occur
for
instance
when
a
Patent
Advisory
Group
concluded
that
the
work
should
be
terminated.
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,
a
A
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 .
Note: The CEO has the role of assessing consensus within the Advisory Committee.
The following terms are used in this document to describe the level of support for a decision among a set of eligible individuals:
- Consensus :
- A substantial number of individuals in the set support the decision and there is no sustained objection from anybody in the set. Individuals in the set may abstain. Abstention is either an explicit expression of no opinion or silence by an individual in the set.
- Unanimity :
- The particular case of consensus where all individuals in the set support the decision (i.e., no individual in the set abstains).
- Dissent :
- At least one individual in the set sustains an objection.
Note:
A
Formal
Objection
always
indicates
a
sustained
objection,
disagreement,
but
isn’t
necessary
to
express
it
(except
it,
except
in
the
context
of
som
formal
contexts
such
as
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.
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
In
the
W3C
process,
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)
decision
by
registering
a
Formal
Objection
with
the
Team
.
when
they
believe
that
their
concerns
are
not
being
duly
considered.
Group
participants
should
inform
their
Team
Contact
as
well
as
the
group’s
Chair(s).
The
Team
Contact
must
inform
the
CEO
when
a
group
participant
has
also
raised
concerns
about
due
process.
Note:
In
this
document,
the
term
Formal
Objection
is
used
to
emphasize
this
process
implication:
Formal
Objections
receive
formal
consideration
and
a
formal
response.
The
word
“objection”
used
alone
has
its
ordinary
English
connotations.
See
§ 5.2
Consensus
Building
.
A Formal 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
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.
This
requirement
is
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
required
to
be
fully
addressed
before
requesting
advancement
of
the
technical
report
.
A Formal Objection filed during an Advisory Committee Review is considered registered at the close of the review period.
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. 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
initiate
formation
of
a
the
W3C
Council
,
which
should
be
convened
within
45
days
of
being
initiated.
Concurrently,
it
must
prepare
a
report
for
the
Council
documenting
its
findings
and
attempts
to
find
consensus.
5.6.2. The W3C Council
A
The
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
The
W3C
Council
is
composed
consists
of
the
following
members
(excepting
members,
with
the
exception
of
any
renounced
or
who
are
dismissed
):
or
who
formally
renounce
their
positions:
-
the members of the Advisory Board
-
the members of the Technical Architecture Group
Participation
in
a
the
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.
Membership
of
each
an
instance
the
Council
instance
is
be
fixed
at
formation,
and
is
not
changed
by
any
AB
or
TAG
elections
occurring
before
that
Council
has
reached
a
conclusion.
However,
if
participation
in
a
Council
falls
so
low
as
to
hinder
effective
and
balanced
deliberations,
the
W3C
Council
Chair
should
dissolve
the
Council
and
call
for
a
new
one
to
be
convened.
A
Team
member
is
assigned
to
act
as
the
Council
Team
Contact
,
to
support
this
Council
and
to
facilitate
adherence
to
this
Process.
the
Council.
5.6.2.2. Extraordinary Delegation
In
extraordinary
cases,
if
they
feel
a
the
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
The
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]
[CEPC]
.
Before
a
the
Council
forms,
the
Team
presents
the
entire
list
of
potential
members
and
collected
reasons
and
responses
to
the
potential
Council
members,
who
members.
They
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.
decided
by
simple
majority
of
those
not
abstaining.
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 or required to be dismissed.
An
individual
may
also
renounce
their
seat
on
a
the
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.
Unanimous
Short
Circuit
The
full
Council
process
may
be
short-circuited
if
the
Team
recommends
a
resolution
and
every
potential
member
of
a
Council
who
is
not
renouncing
their
seat
votes
affirmatively
(no
abstentions)
to
adopt
this
resolution.
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
Team
Contact
or
by
the
Chair
during
the
Council’s
operation.
5.6.2.6.
5.6.2.5.
Council
Deliberations
Upon appointment of the W3C Council Chair and delivery of the Team ’s report, the W3C Council is considered to be convened and can start deliberations.
Having reviewed the information gathered by the Team , 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, which, if successful, disposes the formal objection.
Otherwise,
after
sufficient
deliberation,
the
W3C
Council
decides
whether
to
uphold
sustain
or
overrule
the
objection.
The
W3C
Council
may
overrule
the
Formal
Objection
even
if
it
agrees
with
some
of
the
supportive
arguments.
When
upholding
sustaining
an
objection,
it
should
recommend
a
way
forward.
If
the
overturned
decision
has
already
had
consequences
(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
Formal
Objection
is
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
The
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
a
the
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,
made
by
simple
majority,
with
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.
breaking
any
tie.
In
case
of
a
vote,
if
two
members
of
a
the
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
the
W3C
Council
who
disagree
with
the
decision
may
write
a
Minority
Opinion
explaining
the
reason
for
their
disagreement.
The
deliberations
of
a
the
W3C
Council
are
confidential
to
that
the
W3C
Council
and
its
Council
Team
Contact
.
If
a
the
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.7.
5.6.2.6.
Council
Decision
Report
A
The
Council
terminates
by
issuing
a
Council
Report
,
which:
-
must state whether the Council
upholdssustains or overrules theobjection(s).objection. -
must provide a rationale supporting the decision, which should address each argument raised in the Formal Objection(s).
-
must include any recommendation decided by the Council .
-
if the Formal Objection has been
upheld,sustained, 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 decision.
-
must report the number of votes for/against dismissing each participant.may report votetotals for the Council’s decision,totals, ifa formalany 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
have
the
decision
or
document
being
objected
to.
The
Council
may
also
issue
a
Supplemental
Confidential
Council
Report
with
a
more
restricted
same
level
of
confidentiality
than
its
main
report
when
it
believes
that
additional
commentary
on
confidential
aspects
of
the
case
would
be
informative.
However,
as
the
main
Council
Report
should
be
self-sufficient
and
understandable
without
reference
to
Supplemental
Confidential
Council
Reports.
Formal
Objection
.
5.6.2.8.
5.6.2.7.
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
review
is
the
process
by
which
the
Advisory
Committee
formally
confers
its
approval
on
charters
,
technical
reports
,
and
other
matters
through
an
Advisory
Committee
review
and
its
resulting
W3C
Decision
.
matters.
5.7.1.
Initiating
an
Advisory
Committee
Start
of
a
Review
Period
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. 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
After
the
W3C
Decision
Review
Period
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
is
dissent
(i.e.,
there
were
Formal
Objections
,
at
least
some
of
which
were
upheld
,
sustained)
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 any 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, and those changes must have the consensus of the subset of the AC that voted on the proposal (including anyone who explicitly abstained). For publications which have conditions in addition to AC approval for introducing substantive changes (such as Group consensus or implementation experience), those other conditions must also be re-fulfilled.
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.
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
the
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
Memoranda
of
Understanding
.
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.
If the number of votes to reject exceeds the number of votes to approve, the decision is overturned. In that case, there are the following possible next steps:
- The proposal is rejected.
- The proposal is returned for additional work, after which the applicable decision process is re-initiated.
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 Report .
- 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 W3C 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
-
Working
Groups
can
also
publish
registries
in
order
to
document
collections
of
values
or
other
data.
A registry can beThese are typically publishedeither asin adistinctseparate registry report ,oralthough they can also be directlywithin aembedded in Recommendation Trackdocumentdocuments asan embeddeda registry section . Defining a registry requires wide review and consensus , but once set up, changes to registry entries are lightweight and can even be done without a Working Group . 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.
Web
site.
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 (for example through notices posted to public-review-announce@w3.org ) and were able to actually perform reviews of and provide comments on the specification. A second objective is to encourage groups to request reviews early enough that comments and suggested changes can still be reasonably incorporated in response to the review. Before approving transitions, the 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.
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.
A Working Group could present evidence that wide review has been received, irrespective of solicitation. But it is important to note that receiving many detailed reviews is not necessarily the same as wide review, since they might only represent comment from a small segment of the relevant stakeholder community.
6.2.3. Classes of Changes
This document distinguishes the following 5 classes of changes to a document. The first two classes of change are considered editorial changes , the next two substantive changes , and the last one registry changes .
-
-
No changes to text content
-
- These changes include fixing broken links, style sheets, or invalid markup.
-
-
Changes that do not functionally affect interpretation of the document
-
-
For
Recommendation-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 informative use cases or 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.
- Examples of changes in this class include correcting non-normative examples which clearly conflict with normative requirements, clarifying informative use cases or other non-normative text, fixing typos or grammatical errors where the change does not change requirements.
-
-
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
an
informative,
candidate
correction
approved
by
group
decision
.
When
annotated
inline,
errata—including
errata—
—must
—
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.
A candidate addition is similar to a candidate correction , except that it proposes a new feature rather than an error correction.
If there is no group chartered to maintain a technical report , the Team may maintain its errata and associated candidate corrections . Such corrections must be marked as Team correction , and 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). The Team must solicit wide review on Team corrections that it produces.
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. 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 , a Candidate Recommendation phase allows the Working Group to formally collect implementation experience to demonstrate that the specification works in practice. At the end of the process, the Advisory Committee reviews the mature technical report, and if there is support from its Membership, W3C publishes it as a Recommendation .
In summary, the W3C Recommendation Track consists of:
- Publication of the First Public Working Draft .
- Publication of zero or more revised Working Drafts .
- Publication of one or more Candidate Recommendations .
- Publication of a Proposed Recommendation .
- Publication as a W3C 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] .
W3C may end work on a technical report at any time.
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.
6.3.1. Maturity Stages on the Recommendation Track
- Working Draft ( WD )
-
A
Working
Draft
is
a
document
that
W3C
has
published
on
the
W3C’s
Technical
Reports
page
[TR]
for
review
by
the
community
(including
W3C
Members),
the
public,
and
other
technical
organizations,
and
for
simple
historical
reference.
Some,
but
not
all,
Working
Drafts
are
meant
to
advance
to
Recommendation
;
see
the
document
status
section
of
a
Working
Draft
for
the
group’s
expectations.
Working
Drafts
do
not
necessarily
represent
a
consensus
of
the
Working
Group
with
respect
to
their
content,
and
do
not
imply
any
endorsement
by
W3C
or
its
members
beyond
agreement
to
work
on
a
general
area
of
technology.
Nevertheless
the
Working
Group
decided
to
adopt
the
Working
Draft
as
the
basis
for
their
work
at
the
time
of
adoption.
A
Working
Draft
is
suitable
for
gathering
wide
review
prior
to
advancing
to
the
next
stage
of
maturity.
For all Working Drafts a Working Group:
- should document outstanding issues, and parts of the document on which the Working Group does not have consensus, and
- may request publication of a Working Draft even if its content is considered unstable and does not meet all Working Group requirements.
The first Working Draft of a technical report is called the First Public Working Draft ( FPWD ), and has patent implications as defined in the W3C Patent Policy [PATENT-POLICY] .
- Candidate Recommendation ( CR )
-
A
Candidate
Recommendation
is
a
document
that
satisfies
the
technical
requirements
of
the
Working
Group
that
produced
it
and
their
dependencies,
and
has
already
received
wide
review.
W3C
publishes
a
Candidate
Recommendation
to
- signal to the wider community that it is time to do a final review
- 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 featuresmight be expectedin a laterrevision.revision may however be expected. A Candidate Recommendation is expected to be as well-written, detailed, self-consistent, and technically complete as a Recommendation , and acceptable as such if and when the requirements for further advancement are met.Candidate Recommendation publications take one of two forms:
- Candidate Recommendation Snapshot ( CRS )
-
A
Candidate
Recommendation
Snapshot
corresponds
to
a
Patent
Review
Draft
as
used
in
the
W3C
Patent
Policy
[PATENT-POLICY]
.
Publishing
a
Patent
Review
Draft
triggers
a
Call
for
Exclusions,
per
“Exclusion
From
W3C
RF
Licensing
Requirements”
in
the
W3C
Patent
Policy.
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
on
the
W3C’s
Technical
Reports
page
[TR]
to
integrate
changes
from
the
previous
Candidate
Recommendation
Snapshot
that
the
Working
Group
intends
to
include
in
a
subsequent
Candidate
Recommendation
Snapshot
.
This
allows
for
wider
review
of
the
changes
and
for
ease
of
reference
to
the
integrated
specification.
Any changes published directly into a Candidate Recommendation Draft should be at the same level of quality as a Candidate Recommendation Snapshot . However, the process requirements are minimized so that the Working Group can easily keep the specification up to date.
A 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] .
A Rescinded Candidate Recommendation is a Candidate Recommendation in which significant problems have been discovered such that W3C cannot endorse it or continue work on it, for example due to burdensome patent claims that affect implementers and cannot be resolved (see the W3C Patent Policy [PATENT-POLICY] and in particular “PAG Conclusion”). There is no path to restoration for a Rescinded Candidate Recommendation . See “W3C Royalty-Free (RF) Licensing Requirements” in the W3C Patent Policy [PATENT-POLICY] for implication on patent licensing obligations.
- Proposed Recommendation ( PR )
- A Proposed Recommendation is a document that has been accepted by W3C as of sufficient quality to become a W3C Recommendation . This phase triggers formal review by the Advisory Committee , who may recommend that the document be published as a W3C Recommendation , returned to the Working Group for further work, or abandoned. Substantive changes must not be made to a Proposed Recommendation except by publishing a new Working Draft or Candidate Recommendation .
- 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
.
As
technology
evolves,
a
W3C
Recommendation
may
become:
- A Superseded Recommendation
-
A
Superseded
Recommendation
is
a
specification
that
has
been
replaced
by
a
newer
version
that
W3C
recommends
for
new
adoption.
An
Obsolete
or
Superseded
specification
has
the
same
status
as
a
W3C
Recommendation
with
regards
to
W3C
Royalty-Free
IPR
Licenses
granted
under
the
Patent
Policy.
Note: When a Technical Report which had previously been published as a Recommendation is again published as a Recommendation after following the necessary steps to revise it, the latest version replaces the previous one, without the need to invoke the steps of § 6.3.13.3 Abandoning a W3C Recommendation : it is the same document, updated. Explicitly declaring a documented superseded, using the process documented in § 6.3.13.3 Abandoning a W3C Recommendation , is intended for cases where a Recommendation is superseded by a separate Technical Report (or by a document managed outside of W3C).
- An Obsolete Recommendation
- An Obsolete Recommendation is a specification that W3C has determined lacks sufficient market relevance to continue recommending it for implementation, but which does not have fundamental problems that would require it to be Rescinded . If an Obsolete specification gains sufficient market relevance, W3C may decide to restore it to Recommendation status.
- Rescinded Recommendation
- A Rescinded Recommendation is an entire Recommendation that W3C no longer endorses, and believes is unlikely to ever be restored to Recommendation status. See also “W3C Royalty-Free (RF) Licensing Requirements” in the W3C Patent Policy [PATENT-POLICY] .
- Discontinued Draft
- A technical report representing the state of a Recommendation-track document at the point at which work on it was discontinued. See § 6.3.13.1 Abandoning an Unfinished Recommendation .
Only sufficiently technically mature work should be advanced.
Note: Should faster advancement to meet scheduling considerations be desired, this can be achieved by reducing the scope of the technical report to a subset that is adequately mature and deferring less stable features to other technical reports.
When publishing an updated version of an existing Candidate Recommendation or Recommendation , technical reports are expected to meet the same maturity criteria as when they are first published under that status. However, in the interest of replacing stale documents with improved ones in a timely manner, if flaws have been discovered in the technical report after its initial publication as a CR or REC that would have been severe enough to reject that publication had they be known in time, it is also permissible to publish an updated CR or REC following the usual process, even if only some of these flaws have been satisfactorily addressed.
Working Groups and Interest Groups may make available Editor’s drafts . Editor’s drafts ( ED ) have no official standing whatsoever, and do not necessarily imply consensus of a Working Group or Interest Group , nor are their contents endorsed in any way by W3C.
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
upheldsustained byathe 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 transition to Candidate or Proposed 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.verification, or fulfill the criteria for § 6.3.4.1 Streamlined Publication Approval . Team verification (a Team decision):), should be withheld if any Process requirements are not met, and may be withheld in consideration of unresolved Formal Objections (including anyupheldsustained byathe Council but not yet fully addressed), may be withheld) or if the document does not adequately reflect all relevant decisions ofathe W3C Council (or itsdelegates), may be withheld if the Team believes the Group is not making reasonable progress on addressing issues raised by individuals external to the Group.delegates). 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.4.1. Streamlined Publication Approval
Note: These criteria are intentionally stricter than the general requirements for an update request . This is in order to minimize ambiguities and the need for expert judgment, and to make self-evaluation practical.
In order to streamline the publication process in non-controversial cases, verification of an update request is automatically granted without formal review when the following additional criteria are fulfilled:
- There must have been no changes to Working Group requirements about this document.
- For each of the W3C Horizontal Groups [CHARTER] , if the Horizontal Review Group has made available a set criteria under which their review is not necessary, the Working Group must document that these criteria have been fulfilled. Otherwise, the Working Group must show that review from that group has been solicited and received.
- No Formal Objection has been registered against the document.
-
The
Working
Group
must
have
formally
addressed
:
all issues raised against the document that resulted in changes since the previous publication
all issues raised against changes since the previous publication
all issues raised against the document that were closed since the previous publication with no change to the document
The response to each of these issues must be to the satisfaction of the person who raised it: their proposal has been accepted, or a compromise has been found, or they accepted the Working Group’s rationale for rejecting it.
Note: This is stricter than the general Transition Request criteria.
Additionally, for updates to Recommendations with substantive changes or with new features :
- Changes to the document are limited to proposed corrections that were included in a Last Call for Review of Proposed Corrections possibly combined with class 1 or 2 changes , and/or (in the case of a Recommendation that allows new features ) proposed additions that were included in a Last Call for Review of Proposed Additions .
-
The
Working
Group
must
show
that
all
changes
have
been
implemented
in
at
least
2
distinct
products
by
2
different
implementers,
as
evidenced
by
passing
tests
of
a
test
suite
providing
extensive
coverage
of
the
changes,
or
an
alternative
streamlined
verification
implementation
requirement
described
in
the
working
Group
charter
has
been
met.
Note: This is stricter than the general criteria for adequate implementation experience .
The Working Group must provide written evidence for these claims, and the Team must make these answers publicly and permanently available.
After publication, if an AC Representative or Team member doubts that the evidence presented supports the claims, they may request that a formal review meeting be convened post facto. If that review finds that the requirements were not fulfilled, the Team may revert the changes by updating in place the status section to indicate that it has been reverted, and by republishing the previously approved version of the technical report.
6.3.5. Publishing a First Public Working Draft
To publish the First Public Working Draft of a document, a 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
A Working Group should publish a Working Draft to the W3C Technical Reports page when there have been significant changes to the previous published document that would benefit from review beyond the Working Group.
If 6 months elapse without significant changes to a specification, a Working Group should publish a revised Working Draft , whose status section should indicate reasons for the lack of change.
To publish a revision of a Working draft, a Working Group:
- must record the group’s decision to request publication. Consensus is not required, as this is a procedural step,
- must provide public documentation 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:
6.3.7. Transitioning to Candidate Recommendation
To publish a Candidate Recommendation , in addition to meeting the requirements for advancement a Working Group :
- must show that the specification has met all Working Group requirements, or explain why the requirements have changed or been deferred,
- must document changes to dependencies during the development of the specification,
- must document how adequate implementation experience will be demonstrated,
-
must
specify
the
deadline
for
comments,
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 Proposed Recommendation without a requirement to publish a new Candidate Recommendation .
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
- Proposed 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 Proposed Recommendation without a requirement to publish a new Candidate Recommendation .
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, a 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, a 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
A 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
- Proposed Recommendation , if there are no substantive change other than dropping at risk features
- Discontinued Draft
6.3.9. Transitioning to Proposed Recommendation
In addition to meeting the requirements for advancement ,
- The status information must specify the deadline for Advisory Committee review , which must be at least 28 days after the publication of the Proposed Recommendation and should be at least 10 days after the end of the last Exclusion Opportunity per ”Exclusion From W3C RF Licensing Requirements” in the W3C Patent Policy [PATENT-POLICY] .
A Working Group:
- must show adequate implementation experience except where an exception is approved by a Team Decision ,
- 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 ,period, - must not have made any substantive changes to the document since the most recent Candidate Recommendation Snapshot , other than dropping features identified at risk .
- may have removed features identified in the Candidate Recommendation Snapshot document as at risk without republishing the specification as a Candidate Recommendation Snapshot .
The Team :
- must announce the publication of a Proposed Recommendation to the Advisory Committee , and must begin an Advisory Committee Review on the question of whether the specification is appropriate to publish as a W3C Recommendation .
- may approve a Proposed 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 .
Since a W3C Recommendation must not include any substantive changes from the Proposed Recommendation it is based on, to make any substantive change to a Proposed Recommendation the Working Group must return the specification to Candidate Recommendation or Working Draft .
A Proposed Recommendation may identify itself as intending to allow new features ( class 4 changes ) after its initial publication as a Recommendation , as described in § 6.3.11.4 Revising a Recommendation: New Features . Such an allowance cannot be added to a technical report previously published as a Recommendation that did not allow such changes.
Possible Next Steps:
- Return to Working Draft
- Return to Candidate Recommendation
- Recommendation status , (the expected next step).
- Discontinued Draft
Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to advance the technical report.
6.3.10. Transitioning to W3C Recommendation
The decision to advance a document to Recommendation is a W3C Decision .
In addition to meeting the requirements for advancement ,
- A Recommendation must identify where errata are tracked, and
- A Recommendation must not include any substantive changes from the Proposed Recommendation on which it is based.
- If there was any dissent in Advisory Committee reviews, the Team must publish the substantive content of the dissent to W3C and the general public, and must formally address the comment at least 14 days before publication as a W3C Recommendation .
- Advisory Committee representatives may initiate an Advisory Committee Appeal of the W3C decision
- The Team must announce the publication of a W3C Recommendation to Advisory Committee , other W3C groups and to the public.
Possible next steps: A W3C Recommendation normally retains its status indefinitely. However it may be:
- republished as a revised Recommendation , or
- republished as a Candidate Recommendation to be developed towards a revised Recommendation , or
- declared superseded or obsolete , or
- rescinded .
6.3.11. Revising a W3C Recommendation
This section details the process for making changes to a Recommendation .
6.3.11.1. Revising a Recommendation: Markup Changes
A Working group may request republication of a Recommendation to make corrections that do not result in any changes to the text of the specification. (See class 1 changes .)
If there is no Working Group chartered to maintain a Recommendation , the Team may republish the Recommendation with such changes incorporated.
6.3.11.2. Revising a Recommendation: Editorial Changes
Editorial changes to a Recommendation require no technical review of the intended changes. A 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 2 changes .)
If there is no Working Group chartered to maintain a Recommendation , the Team may republish the Recommendation with such changes incorporated, including errata and Team corrections .
6.3.11.3. Revising a Recommendation: Substantive Changes
A 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 the technical and editorial soundness of the candidate amendments . To validate this, the Working Group must request a Last Call for Review of Proposed Amendments , followed by an update request . See § 6.3.11.5 Incorporating Candidate Amendments .
Alternatively,
a
Working
Group
may
incorporate
the
changes
and
publish
as
a
Working
Draft
—or,
—
—and
—
Note: If there is no Working Group chartered to maintain a Recommendation the Team cannot make substantive changes and republish the Recommendation . It can, however, informatively highlight problems and desirable changes using errata and candidate corrections and republish as described in the previous section .
6.3.11.4. Revising a Recommendation: New Features
New features (see class 4 changes ) may be incorporated into a Recommendation explicitly identified as allowing new features using candidate additions . A candidate addition can be made normative and be folded into the main text of the Recommendation using the same process as for candidate amendments , as detailed in § 6.3.11.3 Revising a Recommendation: Substantive Changes .
Note: This prohibition against new features unless explicitly allowed enables third parties to depend on Recommendations having a stable feature-set, as they have prior to the 2020 revision of this Process.
To make changes which introduce a new feature to a Recommendation that does not allow new features , W3C must create a new technical report , following the full process of advancing a technical report to Recommendation beginning with a new First Public Working Draft .
6.3.11.5. Incorporating Candidate Amendments
A Last Call for Review of Proposed Amendments verifies acceptance by the W3C community of candidate amendments by combining an AC Review with a patent exclusion opportunity.
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 .
A Working Group may batch multiple proposed amendments into a single Last Call for Review of Proposed Amendments . To facilitate review, a 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.12. Regression on the Recommendation Track
A 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
approval
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.13. 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.13.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.
A 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.13.2. Rescinding a Candidate Recommendation
The process for rescinding a Candidate Recommendation is the same as for rescinding a Recommendation .
6.3.13.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. A Recommendation can be both superseded and obsolete. To rescind, supersede, or obsolete some part of a Recommendation, W3C follows the process for modifying a Recommendation .
Note:
For
the
purposes
of
the
W3C
Patent
Policy,
Policy
[PATENT-POLICY]
an
Obsolete
or
Superseded
Recommendation
has
the
status
of
an
active
Recommendation
,
although
it
is
not
advised
recommended
for
future
implementation;
a
Rescinded
Recommendation
ceases
to
be
in
effect
and
no
new
licenses
are
granted
under
the
Patent
Policy.
6.3.13.4. Process for Rescinding, Obsoleting, Superseding, Restoring a Recommendation
The process of rescinding, obsoleting, superseding, or restoring a Recommendation can be initiated either by a request from the Team or via a request from any of the following:
- 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 the members of the Advisory Committee
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 a 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, a Recommendation as appropriate
- identify the Recommendation by URL
- publish a rationale for the proposal
- identify known dependencies and solicit review from all dependent Working Groups
- solicit public review
- specify the deadline for review comments, 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
A 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
Draft
Notes
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
Note
,
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
Draft
Notes
.
6.4.2. Publishing Notes
In
order
to
publish
a
Note
or
Note
Draft
Note
,
the
group:
-
must
record
their
decision
to
request
publication
as
a
Note
or
NoteDraft Note , and - should publish documentation of significant changes to the technical report since any previous publication.
Both
Notes
and
Note
Drafts
Draft
Notes
can
be
updated
by
republishing
as
a
Note
or
Note
Draft
Note
.
A
technical
report
may
remain
a
Note
indefinitely.
If a Note produced by a chartered group is no longer in scope for any group, the Team may republish the Note with class 1 changes incorporated, as well as with errata and Team corrections annotated.
6.4.3. Elevating Group Notes to W3C Statement status
A 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 .
A 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
—
—without
—
A 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
A
registry
documents
a
data
set
consisting
of
one
or
more
associated
registry
tables
,
each
table
representing
an
updatable
collection
of
logically
independent,
consistently-structured
registry
entries
.
A
registry
consists
of:
has
three
associated
components:
- 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 )
- one or more referencing specifications, which make use of the registry
The purposes of maintaining a registry can include:
- non-collision
- Avoiding the problem of two entities using the same value with different semantics.
- non-duplication
- Avoiding the problem of having two or more different values in use with the same semantics.
- information
- Providing a central index where anyone can find out what a value means and what its formal definition is (and where it is).
- submission
- Ease of adding new terms, including by stakeholders external to the custodian organization.
- consensus
- Promoting a clear consensus of the community on the terms.
This section of the W3C Process provides a specialized process facilitating the publication and maintenance of such registry tables , particularly those required by or closely related to W3C Recommendations .
Note: Not every table in a specification is a potential registry. If the intent or effect is that the table enumerates all the possibilities the authors of the specification expect or envisage, then the table by itself is enough. Similarly, if the table is managed by the Working Group and only updated as part of specification update, then the complexities of registry management are not needed.
6.5.1. Registry Definitions
A registry definition defines what each registry table is and how it is maintained. It must :
- Define the 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 Working 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 Working 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
Registries
can
be
published
either
as
a
stand-alone
technical
report
on
the
Registry
Track
called
a
registry
report
,
or
incorporated
as
part
of
a
Recommendation
as
an
embedded
a
registry
section
.
The
A
registry
report
or
embedded
registry
section
is
purely
documentational,
is
not
subject
to
the
W3C
Patent
Policy,
and
must
not
contain
any
requirements
on
implementations.
For
the
purposes
of
the
Patent
Policy
[PATENT-POLICY]
,
any
registry
section
in
a
Recommendation
track
document
is
not
a
normative
portion
of
that
specification.
The registry report or registry section must :
-
Clearly
label
the
registry
report
or embedded registry/ section , 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
RegistryDraft Registry . - 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 .
- There is no equivalent to the Proposed Recommendation phase. Instead, an Advisory Committee Review is started upon publication of each Candidate Registry Snapshot .
- Changes that add new features (i.e. class 4 changes ) are allowed in all W3C Registries , without needing the 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 Working Group consensus, 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 Working Group chartered to maintain the registry when the custodian is another entity.
Note:
The
custodian
is
only
empowered
to
make
registry
changes
.
If
the
Working
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.
defintion.
If
other
changes
are
desired,
they
need
to
must
be
requested
of
the
responsible
Working
Group—or
Group—
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 informative 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 Working Group 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 Working Group may republish the Registry Data Report to incorporate editorial changes . If there is no Working Group chartered to maintain this registry, the Team may do so instead.
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.
Basic-Method
as
defined
in
the
registry”
is
not
Basic-Method
in
the
registry
would
then
affect
conformance.
Instead,
the
requirement
Basic-Method
,
and
implement
it
as
defined
by
section
yy
of
IETF
RFC
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:
- A technical report that is or was a W3C Recommendation , W3C Statement , or Patent Review Draft cannot switch tracks.
- A technical report should not switch away from the Recommendation Track without due consideration of the Patent Policy implications and approval of the 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.).
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
Web
site
and
access
privileges,
and
managing
calendars).
Members
should
solicit
review
by
the
Team
prior
to
issuing
press
releases
about
their
work
within
W3C.
The Team makes every effort to ensure the persistence and availability of the following public information:
-
W3C
technical
reports
whose
publication
has
been
approved.
Per
W3C IPR Policies ,the Membership Agreement, W3C technical reports (and software) are available free of charge to the generalpublic.public; (refer to the W3C Document License [DOC-LICENSE] ). - A mission statement [MISSION] that explains the purpose and mission of W3C, the key benefits for Members, and the organizational structure of W3C.
- Legal documents, including the Membership Agreement [MEMBER-AGREEMENT] and documentation of any legal commitments W3C has with other entities.
- 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,
Web
site,
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 , 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 thatmaintain the proper level of confidentiality, and -
must
not
release
this
information
to
the
general
public
or
press, nor beyond the proper level of access.press.
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. Workshops and Symposia
The Team organizes Workshops and Symposia to promote early involvement in the development of W3C activities from Members and the public.
The goal of a Workshop is usually either to convene experts and other interested parties for an exchange of ideas about a technology or policy, or to address the pressing concerns of W3C Members. Organizers of the first type of Workshop may solicit position papers for the Workshop program and may use those papers to choose attendees and/or presenters.
The goal of a Symposium is usually to educate interested parties about a particular subject.
The Call for Participation in a Workshop or Symposium may indicate participation requirements or limits, and expected deliverables (e.g., reports and minutes ). Organization of an event does not guarantee further investment by W3C in a particular topic, but may lead to proposals for new activities or groups.
Workshops and Symposia generally last one to three days. If a Workshop is being organized to address the pressing concerns of Members, the Team must issue the Call for Participation no later than six weeks prior to the Workshop’s scheduled start date. For other Workshops and Symposia, the Team must issue a Call for Participation no later than eight weeks prior to the meeting’s scheduled start date. This helps ensure that speakers and authors have adequate time to prepare position papers and talks.
9. Liaisons
W3C uses the term liaison to refer to coordination of activities with a variety of organizations, through a number of mechanisms ranging from very informal (e.g., an individual from another organization participates in a W3C Working Group, or just follows its work) to mutual membership, to even more formal agreements. Liaisons are not meant to substitute for W3C membership.
All 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
The
CEO
may
negotiate
technical
agreements
a
Memorandum
of
Understanding
with
another
organization.
For
purposes
of
the
W3C
Process,
a
technical
agreement
is
a
formal
contract,
or
a
Memorandum
of
Understanding
(
MoU
),
or
)
is
a
formal
agreement
or
similar
document,
contractual
framework
between
W3C
and
another
party
or
parties,
that
relates
other
than
between
W3C
and
W3C
members
for
the
purposes
of
membership,
and
other
agreements
related
to
the
technical
activity
ordinary
provision
of
services
for
the
Consortium
(e.g.,
its
publications,
groups,
or
liaisons).
It
purpose
of
running
W3C,
that
specifies
rights
and
obligations
of
each
party
toward
the
others.
These
rights
and
obligations
may
include
joint
deliverables,
an
agreed
share
of
technical
responsibilities
with
due
coordination,
and/or
considerations
for
confidentiality
and
specific
IPR.
Non-technical
agreements,
including
those
between
W3C
and
its
Members
for
the
purposes
The
agreement
may
be
called
something
other
than
a
“Memorandum
of
membership,
between
W3C
Understanding”,
and
its
Partners
something
called
a
“Memorandum
of
Understanding”
might
not
be
an
MoU
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.
Process.
When
considering
a
technical
agreement
an
MoU
(i.e.,
before
the
decision
whether
to
sign
is
made),
the
Team
should
provide
the
Advisory
Committee
with
a
draft
of
the
proposed
agreement
,
MoU,
along
with
an
explanation
of
how
W3C
would
benefit
from
signing
this
agreement
,
MoU,
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
,
MoU,
the
Team
must
announce
the
intent
to
sign,
and
provide
the
final
text
of
the
agreement
,
MoU
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
MoU
.
If
the
proposal
is
rejected
on
Unless
an
appeal
,
rejects
the
Team
proposal
to
sign
an
MoU,
the
CEO
must
not
may
sign
the
agreement
MoU
on
behalf
of
W3C
unless
directed
to
do
so
by
the
Board
.
W3C.
A
signed
agreement
Memorandum
of
Understanding
should
be
made
public.
Information about W3C liaisons with other organizations [LIAISON] and the guidelines W3C follows when creating a liaison is available on the Web.
10. Member Submission Process
The
Member
Submission
process
allows
Members
to
propose
technology
or
other
ideas
for
consideration
by
the
Team
.
After
review,
the
Team
may
make
the
material
available
at
the
W3C
website.
Web
site.
The
formal
process
affords
Members
a
record
of
their
contribution
and
gives
them
a
mechanism
for
disclosing
the
details
of
the
transaction
with
the
Team
(including
IPR
claims).
The
Team
also
makes
review
comments
on
the
Submitted
materials
available
for
W3C
Members,
the
public,
and
the
media.
A Member Submission consists of:
- One or more documents developed outside of the W3C process, and
- Information about the documents, provided by the Submitter.
One or more Members (called the Submitter(s) ) may participate in a Member Submission. Only W3C Members may be listed as Submitters .
The Submission process consists of the following steps:
- One of the Submitters sends a request to the Team to acknowledge the Submission request. The Team and Submitter (s) communicate to ensure that the Member Submission is complete.
-
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,Web site, in addition to Team comments about the Member Submission . - If rejected , the Submitter (s) may initiate a Submission Appeal to either the TAG or the Advisory Board .
-
If
acknowledged
,
the
Team
must
make
the
Member
Submission
available
at
the
public
W3C
- Documents in a Member Submission are developed outside of the W3C technical report development process (and therefore are not included in the index of W3C technical reports [TR] ).
- The Submission process is not a means by which Members ask for “ratification” of these documents as W3C Recommendations .
- There is no requirement or guarantee that technology which is part of an acknowledged Submission request will receive further consideration by W3C (e.g., by a W3C Working Group ).
Making
a
Member
Submission
available
at
the
W3C
website
Web
site
does
not
imply
endorsement
by
W3C,
including
the
W3C
Team
or
Members.
The
acknowledgment
of
a
Submission
request
does
not
imply
that
any
action
will
be
taken
by
W3C.
It
merely
records
publicly
that
the
Submission
request
has
been
made
by
the
Submitter.
A
Member
Submission
made
available
by
W3C
must
not
be
referred
to
as
“work
in
progress”
of
W3C.
The
list
of
acknowledged
Member
Submissions
[SUBMISSION-LIST]
is
available
at
the
W3C
website.
Web
site.
10.1. Submitter Rights and Obligations
When more than one Member jointly participates in a Submission request, only one Member formally sends in the request. That Member must copy each of the Advisory Committee representatives of the other participating Members, and each of those Advisory Committee representatives must confirm (by email to the Team) their participation in the Submission request.
At any time prior to acknowledgment, any Submitter may withdraw support for a Submission request (described in " How to send a Submission request " [SUBMISSION-REQ] ). A Submission request is “withdrawn” when no Submitter(s) support it. The Team must not make statements about withdrawn Submission requests.
Prior to acknowledgment, the Submitter (s) must not , under any circumstances , refer to a document as “submitted to the World Wide Web Consortium” or “under consideration by W3C” or any similar phrase either in public or Member communication. The Submitter (s) must not imply in public or Member communication that W3C is working (with the Submitter (s)) on the material in the Member Submission . The Submitter (s) may release the documents in the Member Submission to the public prior to acknowledgment (without reference to the Submission request).
After acknowledgment, the Submitter (s) must not , under any circumstances , imply W3C investment in the Member Submission until, and unless, the material has been adopted as a deliverable of a W3C Working Group .
10.1.1. Scope of Member Submissions
When a technology overlaps in scope with the work of a chartered Working Group, Members should participate in the Working Group and contribute the technology to the group’s process rather than seek publication through the Member Submission process. The Working Group may incorporate the contributed technology into its deliverables. If the Working Group does not incorporate the technology, it should not publish the contributed documents as Working Group Notes since Working Group Notes represent group output, not input to the group.
On the other hand, while W3C is in the early stages of developing a charter, Members should use the Submission process to build consensus around concrete proposals for new work.
Members should not submit materials covering topics well outside the scope of W3C’s mission [MISSION] .
10.1.2. Information Required in a Submission Request
The Submitter (s) and any other authors of the submitted material must agree that, if the request is acknowledged, the documents in the Member Submission will be subject to the W3C Document License [DOC-LICENSE] and will include a reference to it. The Submitter (s) may hold the copyright for the documents in a Member Submission.
The request must satisfy the Member Submission licensing commitments in “Licensing Commitments in W3C Submissions” in the W3C Patent Policy [PATENT-POLICY] .
The Submitter (s) must include the following information:
- The list of all submitting Members.
- Position statements from all submitting Members (gathered by the Submitter). All position statements must appear in a separate document.
- Complete electronic copies of any documents submitted for consideration (e.g., a technical specification, a position paper, etc.) If the Submission request is acknowledged, these documents will be made available by W3C and therefore must satisfy the Team’s Publication Rules [PUBRULES] . Submitters may hold the copyright for the material contained in these documents, but when made available by W3C, these documents must be subject to the provisions of the W3C Document License [DOC-LICENSE] .
The request must also answer the following questions.
- What proprietary technology is required to implement the areas addressed by the request, and what terms are associated with its use? Again, many answers are possible, but the specific answer will affect the Team’s Decision .
- What resources, if any, does the Submitter intend to make available if W3C acknowledges the Submission request and takes action on it?
- What action would the Submitter like W3C to take if the Submission request is acknowledged?
- What mechanisms are there to make changes to the specification being submitted? This includes, but is not limited to, stating where change control will reside if the request is acknowledged.
For other administrative requirements related to Submission requests, see “ How to send a Submission request ” [MEMBER-SUB] .
10.2. Team Rights and Obligations
Although
they
are
not
technical
reports,
the
documents
in
a
Member
Submission
must
fulfill
fulfil
the
requirements
established
by
the
Team
,
including
the
Team’s
Publication
Rules
[PUBRULES]
.
The Team sends a validation notice to the Submitter (s) once the Team has reviewed a Submission request and judged it complete and correct.
Prior to a decision to acknowledge or reject the request, the request is Team-only , and the Team must hold it in the strictest confidentiality. In particular, the Team must not comment to the media about the Submission request.
10.3. Acknowledgment of a Submission Request
The Team acknowledges a Submission request by sending an announcement to the Advisory Committee . Though the announcement may be made at any time, the Submitter (s) can expect an announcement between four to six weeks after the validation notice . The Team must keep the Submitter (s) informed of when an announcement is likely to be made.
Once a Submission request has been acknowledged, the Team must :
-
Make
the
Member
Submission
available
at
the
W3C
website.Web site. -
Make
the
Team
comments
about
the
Submission
request
available
at
the
W3C
website.Web site.
If the Submitter (s) wishes to modify a document made available as the result of acknowledgment, the Submitter(s) must start the Submission process from the beginning, even just to correct editorial changes .
10.4. Rejection of a Submission Request, and Submission Appeals
The Team may reject a Submission request for a variety of reasons, including any of the following:
- The ideas expressed in the request overlap in scope with the work of a chartered Working Group, and acknowledgment might jeopardize the progress of the group.
- The IPR statement made by the Submitter (s) is inconsistent with the W3C’s Patent Policy [PATENT-POLICY] and in particular the “Licensing Commitments in W3C Submissions”, Document License [DOC-LICENSE] , or other IPR policies.
- The ideas expressed in the request are poor, might harm the Web, or run counter to W3C’s mission [MISSION] .
- The ideas expressed in the request lie well outside the scope of W3C’s mission.
In case of a rejection, the Team must inform the Advisory Committee representative (s) of the Submitter (s). If requested by the Submitter (s), the Team must provide rationale to the Submitter (s) about the rejection. Other than to the Submitter (s), the Team must not make statements about why a Submission request was rejected.
The Advisory Committee representative (s) of the Submitters (s) may 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 .
11. 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
—
The documents covered by this section are:
-
the W3C Process (this document)
-
the W3C Patent Policy [PATENT-POLICY]
-
the W3C Code of Ethics and Professional Conduct
[COC][CEPC] -
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 Ethics and Professional Conduct in the Positive Work Environment Community Group , and the Process in the W3C Process Community Group .
12. 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:
Brian
Kardell,
Carine
Bournez
(W3C),
Charles
McCathie
Nevile
(ConsenSys),
Chris
Needham
(BBC),
Chris
Wilson
(Google),
David
Singer
(Apple),
Delfí
Ramírez,
Dominique
Hazaël-Massieux
(W3C),
Elika
J.
Etemad
aka
fantasai,
Fuqiao
Xue
(W3C),
Jeff
Jaffe
(W3C),
Jeffrey
Yasskin
(Google),
Kevin
Fleming
(Bloomberg),
Léonie
Watson
(The
Paciello
Group),
Mark
Nottingham
(Cloudflare),
Michael
Champion
(Microsoft),
Nigel
Megitt
(BBC),
Philippe
Le
Hégaret
(W3C),
Ralph
Swick
(W3C),
Samuel
Weiler
(W3C),
Sandro
Hawke
(W3C),
Shawn
Lawton
Henry,
Tantek
Çelik
(Mozilla),
Ted
Thibodeau
Jr
(OpenLink
Software),
Virginia
Fournier
(Apple),
Wendy
Seltzer
(W3C),
Yves
Lafon
(W3C).
The editors are sorry for forgetting any names, and grateful to those who have listened patiently to conversations about this document without feeling a need to add more.
The
following
individuals
contributed
to
the
development
of
earlier
versions
of
the
Process:
Alex
Russell
(Google),
Andreas
Tai
(Institut
fuer
Rundfunktechnik),
Andrew
Betts
(Fastly),
Ann
Bassetti
(The
Boeing
Company),
Anne
van
Kesteren,
Art
Barstow
(Nokia,
unaffiliated),
Bede
McCall
(MITRE),
Ben
Wilson,
Brad
Hill
(Facebook),
Brian
Kardell
(JQuery),
Carine
Bournez
(W3C),
Carl
Cargill
(Netscape,
Sun
Microsystems,
Adobe),
Chris
Lilley
(W3C),
Chris
Wilson
(Google),
Claus
von
Riegen
(SAP
AG),
Coralie
Mercier
(W3C),
Cullen
Jennings
(Cisco),
Dan
Appelquist
(Telefonica,
Samsung),
Dan
Connolly
(W3C),
Daniel
Dardailler
(W3C),
Daniel
Glazman
(Disruptive
Innovations),
David
Baron
(Mozilla),
David
Fallside
(IBM),
David
Singer
(Apple),
David
Singer
(IBM),
Delfí
Ramírez,
Dominique
Hazaël-Massieux
(W3C),
Don
Brutzman
(Web3D),
Don
Deutsch
(Oracle),
Eduardo
Gutentag
(Sun
Microsystems),
Elika
J.
Etemad
aka
fantasai,
Florian
Rivoal,
Fuqiao
Xue
(W3C),
Geoffrey
Creighton
(Microsoft),
Geoffrey
Snedden,
Giri
Mandyam
(Qualcomm),
Gregg
Kellogg,
Hadley
Beeman,
Helene
Workman
(Apple),
Henri
Sivonen
(Mozilla),
Håkon
Wium
Lie
(Opera
Software),
Ian
Hickson
(Google),
Ian
Jacobs
(W3C),
Ivan
Herman
(W3C),
J
Alan
Bird
(W3C),
Jay
Kishigami
岸上順一
(NTT),
Jean-Charles
Verdié
(MStar),
Jean-François
Abramatic
(IBM,
ILOG,
W3C),
Jeff
Jaffe
(W3C),
Jim
Bell
(HP),
Jim
Miller
(W3C),
Joe
Hall
(CDT),
John
Klensin
(MCI),
Josh
Soref
(BlackBerry,
unaffiliated),
Judy
Brewer
(W3C),
Judy
Zhu
朱红儒
(Alibaba),
Kari
Laihonen
(Ericsson),
Karl
Dubost
(Mozilla),
Ken
Laskey
(MITRE),
Kevin
Fleming
(Bloomberg),
Klaus
Birkenbihl
(Fraunhofer
Gesellschaft),
Larry
Masinter
(Adobe
Systems),
Lauren
Wood
(unaffiliated),
Liam
Quin
(W3C),
Léonie
Watson
(The
Paciello
Group),
Marcos
Cáceres
(Mozilla),
Maria
Courtemanche
(IBM),
Mark
Crawford
(SAP),
Mark
Nottingham,
Michael
Champion
(Microsoft),
Michael
Geldblum
(Oracle),
Mike
West
(Google),
Mitch
Stoltz
(EFF),
Natasha
Rooney
(GSMA),
Nigel
Megitt
(BBC),
Olle
Olsson
(SICS),
Ora
Lassila
(Nokia),
Paul
Cotton
(Microsoft),
Paul
Grosso
(Arbortext),
Peter
Linss,
Peter
Patel-Schneider,
Philippe
Le
Hégaret
(W3C),
Qiuling
Pan
(Huawei),
Ralph
Swick
(W3C),
Renato
Iannella
(IPR
Systems),
Rigo
Wenning
(W3C),
Rob
Sanderson
(J
Paul
Getty
Trust),
Robin
Berjon
(W3C),
Sally
Khudairi
(W3C),
Sam
Ruby
(IBM),
Sam
Sneddon,
Sandro
Hawke
(W3C),
Sangwhan
Moon
(Odd
Concepts),
Scott
Peterson
(Google),
Steve
Holbrook
(IBM),
Steve
Zilles
(Adobe
Systems)
Steven
Pemberton
(CWI),
TV
Raman
(Google),
Tantek
Çelik
(Mozilla),
Terence
Eden
(Her
Majesty’s
Government),
Thomas
Reardon
(Microsoft),
Tim
Berners-Lee
(W3C),
Tim
Krauskopf
(Spyglass),
Travis
Leithead
(Microsoft),
Virginia
Fournier
(Apple),
Virginie
Galindo
(Gemalto),
Wayne
Carr
(Intel),
Wendy
Fong
(Hewlett-Packard),
Wendy
Seltzer
(W3C),
Yves
Lafon
(W3C).
13. Changes
This section is non-normative.
Changes
since
the
3
2
November
2023
2021
Process
This
document
is
based
on
the
3
2
November
2023
2021
Process
.
A
list
of
issues
addressed
,
a
diff
from
Process
2023
2021
to
this
latest
version
,
as
well
as
a
detailed
log
of
all
changes
since
then
are
available.
In
addition
to
a
number
of
editorial
adjustments
and
minor
teaks,
the
The
following
is
a
summary
of
the
main
differences:
- Changes related to the role of the Director
-
-
Council dismissal vote counts must be reported. (See Issue 748The CEO) Exclude TAG/AB from voting on their own decisions/proposals. (See Issue 749rather than the Director)is charged with negotiating MoUs . -
Add a requirement to make progress on external issues for update requests (See Issue 781The CEO)rather than the Director is charged with disciplinary questions . -
EnableThe Teamto replace defunct registry custodians when no-one else can. (See Issue 699) Stop citingrather than thesuperseded TAG charter. (See Issue 794Director)is charged with handling Member Submission requests. -
Rename “registry sections” to embedded registriesThe Teamto avoid confusion over whether they can be split across multiple sectionsrather than the Director is charged with handling various participation-related judgement calls (see § 2.1.2.1 Membership Consortia , § 3.1.1.2 Conflict of Interest Policy , § 3.1.1.3 Individuals Representing aRecommendation . (See Issue 800Member Organization , § 3.4.1 Requirements for All Chartered Groups , and § 3.4.3.3 Invited Expert in a Working Group)). -
Put constraints onThe Team rather than thetiming of making Formal Objections public. (See Issue 735Director) Rename "Draft Note" into "Note Draft", and "Draft Registry" into "Registry Draft" to be consistentis charged withother statusesverification thatusestheword "Draft",various expectations of the Process have been fulfilled for Transition Requests andto make that word stand out more. (See Issue 779Update Requests) -
ClarifyThe Team rather than thedefition of a Registry (see Issue 800Director) and of Recommendation Track Documents (see Pull Request 831is charged with appointing).the 3 non-elected TAG members, subject to ratification by the TAG . -
Clarify howThere is no longer an ex-officio seat for theoutcome of certain ballots are determined. (See Issue 836Director on the TAG ,Issue 838 )but Tim Berners-Lee personally does continue to hold one.
-
- Other miscellaneous changes
-
Reorganize and rephrase § 4.3 Charter Review and ApprovalAllow Recommendationsfor readability and ease of understanding. This change, while moderate in size, is purely editorial. (See Pull Request 850to transition directly to Working Draft)without having to go through Candidate RecommendationRetire “ Streamlined Publication Approvalwhen making substantive changes . -
Stop
excluding
comments
from
AC
Reps
from
those
that
have
to
be
addressed
while
transitioning
to
Proposed
Recommendation
”. This was meant; just because there will be an opportunity toenable REC track publication with fewer/faster approval steps when some stricter than usual criteriaaddress them later doesn’t mean they shouldn’t be handled at the first opportunity. -
Various
bits
of
information
that
were
fulfilled. However, regular REC track publication have improved enoughso far required to be included in announcements of charter extensions are covered in the group’s homepage, making it sufficient to point to thatthis became unnecessary, and nobody was using it. (See Issue 856page rather than having to inline everything in the announcement. -
The
TAG
)now picks its own chair(s). - Appointed TAG seats now have consecutive term limits.
-
Changes since earlier versions
Changes since earlier versions of the Process are detailed in the changes section of the previous version of the Process.
Conformance
Document conventions
Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.
All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]
Examples
in
this
specification
are
introduced
with
the
words
“for
example”
or
are
set
apart
from
the
normative
text
with
class="example"
,
like
this:
Informative
notes
begin
with
the
word
“Note”
and
are
set
apart
from
the
normative
text
with
class="note"
,
like
this:
Note, this is an informative note.
Conformant Algorithms
Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.
Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant. Implementers are encouraged to optimize.