1. Introduction
Most W3C work revolves around the standardization of Web technologies. To accomplish this work, W3C follows processes that promote the development of high-quality standards based on 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
standardizes
a
Web
technology.
In
many
cases,
the
goal
of
this
work
is
a
W3C
Recommendation
—
technology:
standard.
-
People
generate
interest
in
a
particular
topic.
For
instance,
Members
express
interest
by developing proposals in Community Groups or proposing ideasin the form of Member Submissions. Also,, and the Team monitors work inside and outside of W3C for signs ofinterest, and helpsinterest. Also, W3C is likely to organize aWorkshopsWorkshop to bring people together to discuss topics that interest the W3C community. -
When
there
is
enough
interest
andin a topic (e.g., after a successful Workshop and/or discussion on anengaged community, the TeamAdvisory Committee mailing listworks with), theMembership to draft proposedDirector announces the development of a proposal for one or more new Interest Group or Working Group charters., depending on the breadth of the topic of interest. W3C Members review the proposedcharters, and whencharters. When there is support within W3C for investing resources in the topic of interest,W3Cthe Director approves thegroup(s),group(s) and they begin their work. - There are three types of Working Group participants: Member representatives , Invited Experts , and Team representatives . Team representatives both contribute to the technical work and help ensure the group’s proper integration with the rest of W3C. The Working Group charter sets expectations about each group’s deliverables (e.g., technical reports , test suites, and tutorials).
- Working Groups generally create specifications and guidelines that undergo cycles of revision and review as they advance to W3C Recommendation status. The W3C process for producing these technical reports includes significant review by the Members and public, and requirements that the Working Group be able to show implementation and interoperability experience. At the end of the process, the Advisory Committee reviews the mature technical report, and if there is support, W3C publishes it as a Recommendation .
Further
The
Process
Document
promotes
the
goals
of
quality
and
fairness
in
technical
decisions
by
encouraging
consensus
,
requiring
reviews
(by
both
Members
and
public)
as
part
of
the
technical
report
development
process
,
and
through
an
Advisory
Committee
Appeal
process
.
The
other
sections
of
this
the
Process
Document
deal
with
topics
including
liaisons
(
§ 9
Liaisons
Document:
-
set
forth
policies
), confidentiality ( § 7 Dissemination Policiesfor participation in W3C groups, - establish two permanent groups within W3C: the Technical Architecture Group (TAG) , to help resolve Consortium-wide technical issues; and the Advisory Board (AB) , to help resolve Consortium-wide non-technical issues, and to manage the evolution of the W3C process , and
-
describe
other
interactions
between
the
Members
(as
represented
by
the
W3C
Advisory
Committee
),
the
Team,
and
formal decisionsthe general public.
The
W3C
also
operates
Community
and
appeals
(
§ 5
Decisions
Business
Groups,
which
are
separately
described
in
their
own
process
document
).
[BG-CG]
.
2.
Members
and
the
Team
Members,
Advisory
Committee,
Team,
Advisory
Board,
Technical
Architecture
Group
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
primarily
represented
in
W3C
processes
as
follows:
-
OneThe Advisory Committee is composed of one representativeperfrom each Member organizationparticipates in(refer to the Member-only list of current Advisory Committee representatives . [CURRENT-AC]which oversees) The Advisory Committee:- reviews plans for W3C at each Advisory Committee meeting ;
-
reviews
formal
proposals
from
the
workW3C Director: Charter Proposals , Proposed Recommendations , and Proposed Process Documents . - elects the Advisory Board participants other than the Advisory Board Chair.
-
elects
a
majority
(6)
of
W3C.the participants on the Technical Architecture Group .
Advisory Committee representatives may initiate an Advisory Committee Appeal in some cases described in this document.
-
Representatives
of
Member
organizations
participate
in
Working
Groups
and
Interest
Groups
, where theyand 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] ). Organizations subscribe according to the Membership Agreement [MEMBER-AGREEMENT] . The Team must ensure that Member participation agreements remain Team-only and that no Member receives preferential treatment within W3C.
While W3C does not have a class of membership tailored to individuals, individuals may join W3C. Restrictions pertaining to related Members apply when the individual also represents another W3C Member.
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
The
vast
majority
of
W3C
activities
is
described
in
§ 3.1.1.1
Expectations
and
Discipline
.
Additional
information
for
Members
faithfully
follow
the
spirit
as
well
as
the
letter
of
these
processes.
When
serious
and/or
repeated
violations
do
occur,
and
repeated
attempts
to
address
these
violations
have
not
resolved
the
situation,
the
Director
may
take
disciplinary
action.
Arbitration
in
the
case
of
further
disagreement
is
available
at
governed
by
paragraph
19
of
the
Member
website
Membership
Agreement
[MEMBER-AGREEMENT]
.
Refer
to
the
Guidelines
for
Disciplinary
Action
[MEMBER-HP]
[DISCIPLINARY-GL]
.
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
Director
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] .
3.2.
2.1.3.
The
Advisory
Committee
(AC)
3.2.1.
Role
of
the
Advisory
Committee
When an organization joins W3C (see “ How to Join W3C ” [JOIN] ), it must name its Advisory Committee representative as part of the Membership Agreement. The New Member Orientation [INTRO] explains how to subscribe or unsubscribe to Advisory Committee mailing lists, provides information about Advisory Committee Meetings , explains how to name a new Advisory Committee representative , and more. Advisory Committee representatives must follow the conflict of interest policy by disclosing information according to the mechanisms described in the New Member Orientation. See also the additional roles of Advisory Committee representatives described in the W3C Patent Policy [PATENT-POLICY] .
The
AC
representative
may
delegate
any
of
their
rights
and
responsibilities
to
an
alternate
(except
Additional
information
for
Members
is
available
at
the
ability
to
designate
an
alternate).
Member
Web
site
[MEMBER-HP]
.
3.2.3.
2.1.3.1.
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.
2.1.3.2.
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.
2.2.
Elected
Groups:
The
AB
and
the
TAG
W3C
Team
The
Team
consists
of
the
Director,
CEO,
W3C
Process
defines
two
types
paid
staff,
unpaid
interns,
and
W3C
Fellows.
W3C
Fellows
are
Member
employees
working
as
part
of
elected
groups
:
the
Advisory
Board
Team;
see
the
W3C
Fellows
Program
(AB)
[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
Technical
Architecture
Group
Members
and
the
public
about
the
Web
and
W3C
technologies.
The
Director
(TAG),
both
elected
by
and
CEO
may
delegate
responsibility
(generally
to
other
individuals
in
the
Advisory
Committee
Team)
for
any
of
their
roles
described
in
this
document,
except
participation
in
the
TAG
.
3.3.1.
The Director is the lead technical architect at W3C, whose responsibilities are identified throughout this document in relevant places. Some key ones include: assessing consensus within W3C for architectural choices, publication of technical reports , and chartering new Groups; appointing group Chairs , adjudicating as "tie-breaker" for Group decision appeals , and deciding on the outcome of formal objections; the Director is generally Chair of the TAG .
Team administrative information such as Team salaries, detailed budgeting, and other business decisions are Team-only , subject to oversight by the Host institutions .
Advisory
Board
(AB)
Note:
W3C
is
not
currently
incorporated.
For
legal
contracts,
W3C
is
represented
by
four
“Host”
institutions
:
Beihang
University,
the
European
Research
Consortium
for
Informatics
and
Mathematics
(
ERCIM
),
Keio
University,
and
the
Massachusetts
Institute
of
Technology
(
MIT
).
Within
W3C,
the
Host
institutions
are
governed
by
hosting
agreements;
the
Hosts
themselves
are
not
W3C
Members.
3.3.1.1.
2.3.
Role
of
the
Advisory
Board
(AB)
The
Created
in
March
1998,
the
Advisory
Board
provides
ongoing
guidance
to
the
Team
on
issues
of
strategy,
management,
legal
matters,
process,
and
conflict
resolution.
The
Advisory
Board
also
serves
the
Members
by
tracking
issues
raised
between
Advisory
Committee
meetings,
soliciting
Member
comments
on
such
issues,
and
proposing
actions
to
resolve
these
issues.
The
Advisory
Board
manages
the
evolution
of
the
Process
Document
.
As
part
of
a
W3C
Council
,
members
of
the
The
Advisory
Board
hear
and
adjudicate
on
hears
a
Submission
Appeals
Appeal
and
Formal
Objections
when
a
Member
Submission
is
rejected
for
reasons
unrelated
to
Web
architecture;
see
also
the
TAG
.
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.
The
Team
as
such
does
not
have
decision-making
authority,
must
make
available
a
mailing
list,
confidential
to
the
Advisory
Board
and
Team,
for
the
Advisory
Board
to
use
for
its
members
do
when
sitting
as
part
of
communication.
The
Advisory
Board
should
send
a
W3C
Council
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
.
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.
2.3.1.
Composition
of
the
Advisory
Board
Participation
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
a
Chair.
The
Team
appoints
the
Chair,
who
should
choose
a
co-chair
among
the
elected
participants.
Upon
appointment,
the
Chair(s)
are
subject
to
ratification
by
secret
ballot,
requiring
approval
by
two
thirds
of
the
elected
participants.
Chair
selection
must
be
run
at
least
at
the
start
of
each
regular
term,
as
well
as
when
a
majority
of
the
participants
request
it;
and
may
be
run
at
other
times
when
initiated
by
the
current
chairs
or
the
Team,
for
example
if
a
chair
steps
down
or
if
a
minority
of
Advisory
Board
,
who
is
generally
the
participants
make
such
a
request.
CEO.
The
team
also
appoints
a
Team
Contact
for
the
AB
,
as
described
in
§ 3.4.1
§ 5.1
Requirements
for
All
Chartered
Working
and
Interest
Groups
.
The
CEO
and
Team
Contact
have
a
standing
invitation
to
all
regular
Advisory
Board
sessions.
The remaining nine to eleven Advisory Board participants are elected by the W3C Advisory Committee following the AB/TAG nomination and election process .
The
With
the
exception
of
the
Chair,
the
terms
of
elected
all
Advisory
Board
participants
are
for
two
years
.
Terms
are
staggered
so
that
each
year,
either
five
or
six
terms
expire.
If
an
individual
is
elected
to
fill
an
incomplete
term,
that
individual’s
term
ends
at
the
normal
expiration
date
of
that
term.
Regular
Advisory
Board
terms
begin
on
1
July
and
end
on
30
June.
3.3.2.
2.4.
Technical
Architecture
Group
(TAG)
3.3.2.1.
Role
of
the
Technical
Architecture
Group
The
Created
in
February
2001,
the
mission
of
the
TAG
is
stewardship
of
the
Web
architecture.
There
are
three
aspects
to
this
mission:
- to document and build consensus around principles of Web architecture and to interpret and clarify these principles when necessary;
- to resolve issues involving general Web architecture brought to the TAG;
- to help coordinate cross-technology architecture developments inside and outside W3C.
As
part
of
a
W3C
Council
,
the
members
of
the
The
TAG
hear
and
adjudicate
on
hears
a
Submission
Appeals
Appeal
and
Formal
Objections
when
a
Member
Submission
is
rejected
for
reasons
related
to
Web
architecture;
see
also
the
Advisory
Board
.
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
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 .
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.
2.4.1.
Composition
of
the
Technical
Architecture
Group
Participation
The TAG consists of:
- Tim Berners-Lee, who is a life member;
- The Director , sitting ex officio ;
-
Three
participants
appointed
by
the
TeamDirector ; -
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
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
TAG,
who
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
one
of
the
participants
make
such
a
request.
participants.
The
Team
team
also
appoints
a
Team
Contact
[TEAM-CONTACT]
for
the
TAG,
as
described
in
§ 3.4.1
§ 5.1
Requirements
for
All
Chartered
Working
and
Interest
Groups
.
The
terms
of
elected
and
Director-appointed
TAG
participants
last
are
for
two
years
.
Terms
are
staggered
so
that
four
each
year
three
elected
terms
terms,
and
either
one
or
two
appointed
terms
expire
each
year.
expire.
If
an
individual
is
appointed
or
elected
to
fill
an
incomplete
term,
that
individual’s
term
ends
at
the
normal
expiration
date
of
that
term.
Regular
TAG
terms
begin
on
1
February
and
end
on
31
January.
The
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
Director
may
also
request
announce
the
creation
of
additional
topic-specific,
public
mailing
lists.
For
some
TAG
discussions
(e.g.,
a
Submission
Appeal
),
appointed
participants
after
the
TAG
may
use
a
list
that
will
be
Member-only
.
The
TAG
should
send
a
summary
of
each
of
its
meetings
to
results
for
the
Advisory
Committee
and
other
group
Chairs.
The
TAG
should
also
report
on
its
activities
at
each
Advisory
Committee
meeting
.
election
of
participants
have
been
announced.
3.3.3.
2.5.
Advisory
Board
and
Technical
Architecture
Group
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
Director
with
the
expectation
that
they
will
use
their
best
judgment
to
find
the
best
solutions
for
the
Web,
not
just
for
any
particular
network,
technology,
vendor,
or
user.
Advisory
Board
and
TAG
participants
are
expected
to
participate
regularly
and
fully.
Advisory
Board
and
TAG
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.
2.5.1.
Elected
Groups
Advisory
Board
and
Technical
Architecture
Group
Participation
Constraints
Given the few seats available on the Advisory Board and the TAG , and in order to ensure that the diversity of W3C Members is represented:
-
Two
participants
with
the
same
primary
affiliation
per
§ 3.3.3.3§ 2.5.2 Advisory Board and Technical Architecture Group Elections must not both occupy elected seats on the TAG except when this is caused by a change of affiliation of an existing participant. At the completion of the next regularly scheduled election for the TAG, the organization must have returned to having at most one seat. -
Two
participants
with
the
same
primary
affiliation
per
§ 3.3.3.3§ 2.5.2 Advisory Board and Technical Architecture Group Elections must not both occupy elected seats on the AB. If, for whatever reason, these constraints are not satisfied (e.g., because an AB participant changes jobs), one participant must cease AB participation until the situation has been resolved. If after 30 days the situation has not been resolved, the Chair will apply the verifiable random selection procedure described below to choose one person for continued participation and declare the other seat(s) vacant. - An individual must not participate on both the TAG and the AB.
3.3.3.3.
2.5.2.
Advisory
Board
and
Technical
Architecture
Group
Elections
The
Advisory
Board
and
a
portion
of
the
Technical
Architecture
Group
are
elected
by
the
Advisory
Committee
,
using
a
Single
Transferable
Vote
system.
An
election
begins
when
the
Team
sends
a
Call
for
Nominations
to
the
Advisory
Committee.
Any
Call
for
Nominations
specifies
the
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
Director
announces
should
announce
appointments
after
the
results
of
the
election
are
known,
and
before
no
later
than
the
start
of
the
term,
a
nomination
period
as
described
in
§ 3.3.3.4
Technical
Architecture
Group
Appointments
.
part
of
the
Call
for
Nominations.
In
the
case
of
regularly
scheduled
elections
of
the
TAG
,
the
minimum
and
maximum
number
of
available
avaiable
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
avaiable
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
incompleteshort 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)(maxiumum) number of available seats, the deadline for votes, details about the vote tabulation system selected by the Team for the election, and operational information.
When there is a vote, each Member (or group of related Members ) may submit one ballot that ranks candidates in the Member’s preferred order. Once the deadline for votes has passed, the Team announces the results to the Advisory Committee . In case of a tie the verifiable random selection procedure described below will be used to fill the available seats.
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
short
term,
the
verifiable
random
selection
procedure
described
below
will
be
used
to
assign
the
incomplete
short
term.
Refer to How to Organize an Advisory Board or TAG election [ELECTION-HOWTO] for more details.
3.3.3.5.
2.5.2.1.
Verifiable
Random
Selection
Procedure
When
it
is
necessary
to
use
a
verifiable
random
selection
process
(e.g.,
in
an
AB
or
TAG
election,
to
“draw
straws”
in
case
of
a
tie
or
to
fill
a
incomplete
short
term),
W3C
uses
the
random
and
verifiable
procedure
defined
in
RFC
3797
[RFC3797]
.
The
procedure
orders
an
input
list
of
names
(listed
in
alphabetical
order
by
family
name
unless
otherwise
specified)
into
a
“result
order”.
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)
incompleteshort terms. In this case, only the names of those N individuals are provided as input to the procedure. Theincompleteshort terms are assigned in result order.
3.3.3.6.
2.5.3.
Elected
Groups
Advisory
Board
and
Technical
Architecture
Group
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
CEODirector dismisses the participant for failing to meet the criteria in section§ 3.1.1§ 3.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.Director may re-appoint someone immediately, but no later than the next regularly scheduled election. -
When
an
elected
seat
on
either
the
AB
or
TAG
is
vacated,
the
seat
is
filled
at
the
next
regularly
scheduled
election
for
the
group
unless
the
group
Chair
requests
that
W3C
hold
an
election
before
then
(for
instance,
due
to
the
group’s
workload).
- The group 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
seatsseat 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.
3.
Chartered
Groups:
General
Policies
for
W3C
Groups
This section describes general policies for W3C groups regarding participation, meeting requirements, and decision-making. These policies apply to participants in the following groups: Advisory Committee , Advisory Board , TAG , Working Groups , and Interest Groups .
3.1. Individual Participation Criteria
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 [CEPC] and the participation requirements described in “Disclosure” in the W3C Patent Policy [PATENT-POLICY] .
The Director may suspend or remove for cause a participant in any group (including the AB and TAG ), where cause includes failure to meet the requirements of this process, the membership agreement, or applicable laws.
3.1.1. 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 Director may appoint a new group Chair when the current Chair changes affiliations (e.g., if there is a risk of conflict of interest, or if there is risk that the Chair’s new employer will be over-represented within a W3C activity).
The following are some scenarios where disclosure is appropriate:
- Paid consulting for an organization whose activity is relevant to W3C, or any consulting compensated with equity (shares of stock, stock options, or other forms of corporate equity).
- A decision-making role/responsibility (such as participating on the Board) in other organizations relevant to W3C.
- A position on a publicly visible advisory body, even if no decision making authority is involved.
Individuals seeking assistance on these matters should contact the Team .
Team members are subject to the W3C Team conflict of interest policy [CONFLICT-POLICY] .
3.1.2. Individuals Representing a Member Organization
Generally, individuals representing a Member in an official capacity within W3C are employees of the Member organization. However, an Advisory Committee 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 Director 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.2. Meetings
W3C groups (including the Advisory Committee , Advisory Board , TAG , and Working Groups ) should observe the meeting requirements in this section.
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.
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 requirements 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.3. Consensus
Consensus
is
a
core
value
of
W3C.
To
promote
consensus,
the
W3C
process
requires
Chairs
to
ensure
that
groups
:
consider
all
legitimate
views
and
objections,
and
endeavor
to
resolve
them,
whether
these
views
and
objections
are
expressed
by
the
active
participants
of
the
group
or
by
others
(e.g.,
another
W3C
group,
a
group
in
another
organization,
or
the
general
public).
Decisions
may
be
made
during
meetings
(
face-to-face
or
distributed
)
as
well
as
through
email.
Note: The Director, CEO, and COO have the role of assessing consensus within the Advisory Committee.
The following terms are used in this document to describe the level of support for a decision among a set of eligible individuals:
-
Working GroupsConsensus : - A substantial number of individuals in the set support the decision and nobody in the set registers a Formal Objection . Individuals in the set may abstain. Abstention is either an explicit expression of no opinion or silence by an individual in the set.
- Unanimity :
- The particular case of consensus where all individuals in the set support the decision (i.e., no individual in the set abstains).
-
.Dissent : -
Working Groups typicallyAt least one individual in the set registers a Formal Objection .
By default, the set of individuals eligible to participate in a decision is the set of group participants. The Process Document does not require a quorum for decisions (i.e., the minimal number of eligible participants required to be present before the Chair can call a question). A 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.
3.3.1. Managing Dissent
In
some
cases,
even
after
careful
consideration
of
all
points
of
view,
a
group
might
find
itself
unable
to
reach
consensus.
The
Chair
may
record
a
decision
where
there
is
dissent
(i.e.,
there
is
at
least
one
Formal
Objection
)
so
that
the
group
can
make
progress
(for
example,
to
produce
deliverables
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.
3.3.2. Recording and Reporting Formal Objections
In
the
W3C
process,
an
individual
may
register
a
Formal
Objection
to
a
decision.
A
Formal
Objection
to
a
group
decision
is
one
that
the
reviewer
requests
that
the
Director
consider
as
part
of
evaluating
the
related
decision
(e.g.,
in
response
to
a
Recommendation
Track
request
to
advance
a
technical
reports
,
software,
test
suites,
report).
Note: In this document, the term “Formal Objection” is used to emphasize this process implication: Formal Objections receive Director consideration. The word “objection” used alone has ordinary English connotations.
An
individual
who
registers
a
Formal
Objection
should
cite
technical
arguments
and
reviews
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
by
the
Director.
A
record
of
each
Formal
Objection
must
be
publicly
available
.
A
Call
for
Review
(of
a
document)
to
the
deliverables
Advisory
Committee
must
identify
any
Formal
Objections
.
3.3.3. Formally Addressing an Issue
In
the
context
of
other
groups)
as
defined
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
charter
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).
3.3.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.
3.4. Votes
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
Groups
have
additional
participation
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.
Procedures for Advisory Committee votes are described separately.
3.5. Appeal of Chair Decisions and Group Decisions
Groups resolve issues through dialog. Individuals who disagree strongly with a decision should register with the Chair any Formal Objections (e.g., to a decision made as the result of a vote ).
As detailed in other parts of this document, the Chair of a Working Group or Interest Group has the prerogative to make certain decisions based on their own judgement. 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 § 3.4 Votes ) are called Group Decisions .
When group participants believe that their concerns are not being duly considered by the group or the Chair , they may ask the Director (for representatives of a Member organization, via their Advisory Committee representative) to confirm or deny the decision. This is a Group Decision Appeal or a Chair Decision Appeal . The participants should also make their requests known to the Team Contact . The Team Contact must inform the Director when a group participant has raised concerns about due process.
Any requests to the Director to confirm a decision must include a summary of the issue (whether technical or procedural), decision, and rationale for the objection. All counter-arguments, rationales, and decisions must be recorded.
Procedures for Advisory Committee appeals are described separately.
3.6. Resignation from a Group
A W3C Member or Invited Expert may resign from a group. On written notification from an Advisory Committee representative or Invited Expert to the team, the Member and their representatives or the Invited Expert will be deemed to have resigned from the relevant group. The team must record the notification. See “Exclusion and Resignation from the Working Group” in the W3C Patent Policy [PATENT-POLICY] for information about obligations remaining after resignation from certain groups.
4. Dissemination Policies
The Team is responsible for managing communication within W3C and with the general public (e.g., news services, press releases, managing the 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 by the Director. Per the Membership Agreement, W3C technical reports (and software) are available free of charge to the general public; (refer to the W3C Document License [DOC-LICENSE] ).
- A mission statement [MISSION] that explains the purpose and mission of W3C, the key benefits for Members, and the organizational structure of W3C.
- Legal documents, including the Membership Agreement [MEMBER-AGREEMENT] and documentation of any legal commitments W3C has with other entities.
- The Process Document.
- Public results of W3C activities and Workshops .
To
keep
the
Members
abreast
of
W3C
meetings,
Workshops
,
see
particularly
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.
4.1. Confidentiality Levels
There are three principal levels of access to W3C information (on the W3C Web site, in W3C meetings, etc.): public, Member-only, and Team-only.
While
much
information
made
available
by
W3C
is
public,
“
Licensing
Obligations
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
Group
Participants
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
patent claim exclusion processinformation as confidential within W3C, - must use reasonable efforts to maintain the proper level of confidentiality, and
- must not release this information to the general public or 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
“
Exclusion
From
the
New
Member
Orientation
[INTRO]
.
4.1.1. Changing Confidentiality Level
As
a
benefit
of
membership,
W3C
RF
Licensing
Requirements
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.
5.
Working
Groups
and
Interest
Groups
.
This document defines two types of 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). There are additional participation requirements described in the W3C Patent Policy [PATENT-POLICY] .
- 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
see
information
about
technical
reports
on
the
Note
Track
maturity
levels
for
Interest
Groups
.
3.4.1.
5.1.
Requirements
for
All
Chartered
Working
and
Interest
Groups
Each
group
must
have
a
charter
.
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
Director
appoints
(and
re-appoints)
Chairs
for
all
groups.
The
Chair
is
a
Member
representative
,
a
Team
representative
,
or
an
Invited
Expert
,
(invited
by
the
Team
).
Director).
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
Member
guide
[GUIDE]
.
The
Chair
and
the
Team
Contact
of
a
group
should
not
be
the
same
individual.
Each
group
must
have
an
archived
mailing
list
for
formal
group
communication
(e.g.,
for
meeting
announcements
and
minutes
,
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.
5.2.
Participation
in
Chartered
Working
Groups
and
Interest
Groups
Although Working Groups and Interest Groups have different purposes, they share some characteristics, and so are defined together in the following sections.
5.2.1. Working Group and Interest Group Participation Requirements
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).
See
also
the
licensing
obligations
on
Working
Group
participants
in
Chartered
Groups
“Licensing
Obligations”
in
the
W3C
Patent
Policy
[PATENT-POLICY]
,
and
the
patent
claim
exclusion
process
in
“Exclusion
From
W3C
RF
Licensing
Requirements”
in
the
Patent
Policy.
3.4.3.1.
5.2.1.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.
5.2.1.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.
5.2.1.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
Director
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
CEODirector withdraws the invitation to participate, or - the individual resigns .
3.4.3.4.
5.2.1.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.
5.2.1.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
Director
announces
the
creation
of
the
group
is
announced
until
the
group
closes.
3.4.3.6.
5.2.1.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.1.
5.2.2.
Initiating
Working
Group
and
Interest
Group
Charter
Development
W3C
creates
charters
for
chartered
groups
a
charter
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.
5.2.3.
Content
Advisory
Committee
Review
of
a
Working
Group
or
Interest
Group
Charter
The Director must solicit Advisory Committee review of every new or substantively modified Working Group or Interest Group charter, except for either:
a charter extension
substantive changes to a charter that do not affect the way the group functions in any significant way.
The review period must be at least 28 days. The following are examples of substantive changes that would not require an Advisory Committee Review : the addition of an in-scope deliverable, a change of Team Contact , or a change of Chair . Such changes must nonetheless be announced to the Advisory Committee and to participants in the Working or in the Intrest Group , and a rationale must be provided.
The Director’s Call for Review of a substantively modified charter must highlight important changes (e.g., regarding deliverables or resource allocation) and include rationale for the changes.
As part of the Advisory Committee review of any new or substantively modified Working Group charter, any Advisory Committee representative may request an extended review period.
Such a request must be submitted with a Member’s comments in response to the Call for Review. Upon receipt of any such request, the Director must ensure that the Call for Participation for the Working Group occurs at least 60 days after the Call for Review of the charter.
5.2.4. Call for Participation in a Working Group or Interest Group
After Advisory Committee review of a Working Group or Interest Group charter , the Director may issue a Call for Participation to the Advisory Committee. Charters may be amended based on review comments before the Director issues a Call for Participation.
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).
Advisory Committee representatives may initiate an Advisory Committee Appeal against a Director’s decision to create or substantially modify a Working Group or Interest Group charter.
5.2.5. Working Group and Interest Group Charter Extension
To extend a Working Group or Interest Group charter with no other substantive modifications, the Director announces the extension to the Advisory Committee. The announcement must indicate the new duration. The announcement must also include rationale for the extension, a reference to the charter , the name(s) of the group’s Chair (s), the name of the Team Contact , and instructions for joining the group.
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 Director’s decision regarding the extension of a Working Group or Interest Group charter.
5.2.6. Working Group and Interest Group Charters
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).groups); -
The
scope
of
the
group’s
work
and
criteria
for
success.success; -
The
duration
of
the
group
(typically
from
six
months
to
two
years).years); -
The
nature
of
any
deliverables
(technical
reports,
reviews
of
the
deliverables
of
other
groups,
or
software).software); -
For
each
technical
report,
a
designation
whether
it
may,
when
sufficiently
mature,
be
published
as
a
Expandable
Recommendation
,
as
an
ordinary
Recommendation
,
or
as
either
at
the
discretion
of
the
Working
Group
.
If
this
information
is
left
out,
only
publishing
as
an
ordinary
Recommendation
is
allowed.
Note: Revising the Recommendation using proposed additions (see § 6.2.11.4 Revising a Recommendation: New Features ) is only allowed for Expandable Recommendations .
-
Expected
milestone
dates
where
available.
Note: A charter
doesis notneedrequired to include schedules for review of other group’sdeliverables.deliverables; -
The
process
for
the
group
to
approve
the
release
of
deliverables
(including
intermediate
results).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.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.deliverables; -
Meeting
mechanisms
and
expected
frequency.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.public; -
Any
voting
procedures
or
requirements
other
than
those
specified
in
§ 5.2.3 Deciding by Vote .§ 3.4 Votes ; -
An
estimate
of
the
expected
time
commitment
from
participants.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
a
Working
Draft
(WD)
published
under
any
other
Charter
(including
a
predecessor
group
of
the
same
name),
for
which
there
is
at
least
an
existing
First
Public
Working
Patent
Review
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 itsmost recent Patent Review Draft that triggered an 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 DraftOther 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.5.
5.2.7.
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.
The
Team
,
the
TAG
,
or
the
AB
Director
may
propose
decide
to
close
a
group
prior
to
the
date
specified
in
the
charter
in
any
of
the
following
circumstances:
-
There
are
insufficient
memberresources to produce chartered deliverables or to maintain the group, according to priorities established within W3C.A Patent Advisory Group concluded that the work should be terminated. The TAG or AB determined that continuing operation of the chartered group or its work would be detrimental to W3C or its mission. -
The
group
produced allproduces chartered deliverables ahead of schedule.
Such
a
proposal
to
close
a
group
must
be
accompanied
by
rationale,
and
the
proposal
must
be
confirmed
by
an
AC
Review
as
a
W3C
Decision
.
Closing
a
Working
Group
has
implications
with
respect
to
the
W3C
Patent
Policy
[PATENT-POLICY]
.
5.
Decisions
W3C
attempts
to
resolve
issues
through
dialog.
Individuals
who
disagree
strongly
with
a
decision
should
register
with
the
Chair
any
Formal
Objections
.
5.1.
Types
of
Decisions
The
Chair
of
a
Working
Group
or
Interest
Group
has
the
prerogative
to
make
certain
decisions
based
on
their
own
judgment.
Such
decisions
are
called
chair
decisions
.
In
contrast,
decisions
taken
by
the
Chair
Director
of
closes
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
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,
but
isn’t
necessary
to
express
it
(except
in
the
context
of
formal
AC
Reviews
).
Disagreement
with
a
proposed
decision,
however,
does
not
always
rise
to
the
level
of
sustained
objection,
as
individuals
could
be
willing
to
accept
a
decision
while
expressing
disagreement.
By
default,
the
set
of
individuals
eligible
to
participate
in
a
decision
is
the
set
of
group
participants.
The
Process
Document
does
not
require
a
quorum
for
decisions
(i.e.,
the
minimal
number
of
eligible
participants
required
to
be
present
before
the
Chair
can
call
a
question).
A
charter
may
include
a
quorum
requirement
for
consensus
decisions.
Where
unanimity
is
not
possible,
a
group
should
strive
to
make
consensus
decisions
where
there
is
significant
support
and
few
abstentions.
The
Process
Document
does
not
require
a
particular
percentage
of
eligible
participants
to
agree
to
a
motion
in
order
for
a
decision
to
be
made.
To
avoid
decisions
where
there
is
widespread
apathy,
(i.e.,
little
support
and
many
abstentions),
groups
should
set
minimum
thresholds
of
active
support
before
a
decision
can
be
recorded.
The
appropriate
percentage
may
vary
depending
on
the
size
of
the
group
and
the
nature
of
the
decision.
A
charter
may
include
threshold
requirements
for
consensus
decisions.
For
instance,
a
charter
might
require
a
supermajority
of
eligible
participants
(i.e.,
some
established
percentage
above
50%)
to
support
certain
types
of
consensus
decisions.
Note:
Chairs
have
substantial
flexibility
in
how
they
obtain
and
assess
consensus
among
their
groups.
Unless
otherwise
constrained
by
charter,
they
can
use
modes
including
but
not
limited
to
explicit
calls
for
consensus,
polls
of
participants,
“lazy
consensus”
in
which
lack
of
objection
after
sufficient
notice
is
taken
as
assent;
they
can
also
delegate
and
empower
a
document
editor
to
assess
consensus
on
their
behalf,
whether
in
general
or
for
specific
pre-determined
circumstances
(e.g.
in
non-controversial
situations,
for
specific
types
of
issues,
etc.).
If
questions
or
disagreements
arise,
the
final
determination
of
consensus
remains
with
the
chair.
5.2.2.
Managing
Dissent
In
some
cases,
even
after
careful
consideration
of
all
points
of
view,
a
group
might
find
itself
unable
to
reach
consensus.
The
Chair
may
record
a
decision
where
there
is
dissent
so
that
the
group
can
make
progress
(for
example,
to
produce
a
deliverable
in
a
timely
manner).
Dissenters
cannot
stop
a
group’s
work
simply
by
saying
that
they
cannot
live
with
a
decision.
When
the
Chair
believes
that
the
Group
has
duly
considered
the
legitimate
concerns
of
dissenters
as
far
as
is
possible
and
reasonable,
the
group
should
move
on.
Groups
should
favor
proposals
that
create
the
weakest
objections.
This
is
preferred
over
proposals
that
are
supported
by
a
large
majority
but
that
cause
strong
objections
from
a
few
people.
As
part
of
making
a
decision
where
there
is
dissent
,
the
Chair
is
expected
to
be
aware
of
which
participants
work
for
the
same
(or
related
)
Member
organizations
and
weigh
their
input
accordingly.
Note:
Dissenters
can
escalate
their
sustained
objection
to
a
decision
by
registering
a
Formal
Objection
.
5.2.3.
Deciding
by
Vote
A
group
should
only
conduct
a
vote
to
resolve
a
substantive
issue
after
the
Chair
has
determined
that
all
available
means
of
reaching
consensus
through
technical
discussion
and
compromise
have
failed,
and
that
a
vote
is
necessary
to
break
a
deadlock.
In
this
case
the
Chair
must
record
(e.g.,
in
the
minutes
of
the
meeting
or
in
an
archived
email
message):
an
explanation
of
the
issue
being
voted
on;
the
decision
to
conduct
a
vote
(e.g.,
a
simple
majority
vote)
to
resolve
the
issue;
the
outcome
of
the
vote;
any
Formal
Objections.
In
order
to
vote
to
resolve
a
substantive
issue,
an
individual
must
be
a
group
participant
.
Each
organization
represented
in
the
group
must
have
at
most
one
vote,
even
when
the
organization
is
represented
by
several
participants
in
the
group
(including
Invited
Experts).
For
the
purposes
of
voting:
A
Member
or
group
of
related
Members
is
considered
a
single
organization.
The
Team
is
considered
an
organization.
Unless
the
charter
states
otherwise,
Invited
Experts
may
vote.
If
a
participant
is
unable
to
attend
a
vote,
that
individual
may
authorize
anyone
at
the
meeting
to
act
as
a
proxy
.
The
absent
participant
must
inform
the
Chair
in
writing
who
is
acting
as
proxy,
with
written
instructions
on
the
use
of
the
proxy.
For
a
Working
Group
or
Interest
Group,
see
the
related
requirements
regarding
an
individual
who
attends
a
meeting
as
a
substitute
for
a
participant.
A
group
may
vote
for
other
purposes
than
to
resolve
a
substantive
issue.
For
instance,
the
Chair
often
conducts
a
“straw
poll”
vote
as
a
means
of
determining
whether
there
is
consensus
about
a
potential
decision.
A
group
may
also
vote
to
make
a
process
decision.
For
example,
it
is
appropriate
to
decide
by
simple
majority
whether
to
hold
a
meeting
in
San
Francisco
or
San
Jose
(there’s
not
much
difference
geographically).
When
simple
majority
votes
are
used
to
decide
minor
issues,
voters
are
not
required
to
state
the
reasons
for
votes,
and
the
group
is
not
required
to
record
individual
votes.
A
group
charter
may
include
formal
voting
procedures
(e.g.,
quorum
or
threshold
requirements)
for
making
decisions
about
substantive
issues.
5.3.
Formally
Addressing
an
Issue
In
the
context
of
this
document,
a
group
has
formally
addressed
an
issue
when
it
has
sent
a
public,
substantive
response
to
the
reviewer
who
raised
the
issue.
A
substantive
response
is
expected
to
include
rationale
for
decisions
(e.g.,
a
technical
explanation,
a
pointer
to
charter
scope,
or
a
pointer
to
a
requirements
document).
The
adequacy
of
a
response
is
measured
against
what
a
W3C
reviewer
would
generally
consider
to
be
technically
sound.
If
a
group
believes
that
a
reviewer’s
comments
result
from
a
misunderstanding,
the
group
should
seek
clarification
before
reaching
a
decision.
As
a
courtesy,
both
Chairs
and
reviewers
should
set
expectations
for
the
schedule
of
responses
and
acknowledgments.
The
group
should
reply
to
a
reviewer’s
initial
comments
in
a
timely
manner.
The
group
should
set
a
time
limit
for
acknowledgment
by
a
reviewer
of
the
group’s
substantive
response;
a
reviewer
cannot
block
a
group’s
progress.
It
is
common
for
a
reviewer
to
require
a
week
or
more
to
acknowledge
and
comment
on
a
substantive
response.
The
group’s
responsibility
to
respond
to
reviewers
does
not
end
once
a
reasonable
amount
of
time
has
elapsed.
However,
reviewers
should
realize
that
their
comments
will
carry
less
weight
if
not
sent
to
the
group
in
a
timely
manner.
Substantive
responses
should
be
recorded.
The
group
should
maintain
an
accurate
summary
of
all
substantive
issues
and
responses
to
them
(e.g.,
in
the
form
of
an
issues
list
with
links
to
mailing
list
archives).
5.4.
Reopening
a
Decision
When
Presented
With
New
Information
The
Chair
may
reopen
a
decision
when
presented
with
new
information,
including:
additional
technical
information,
comments
by
email
from
participants
who
were
unable
to
attend
a
scheduled
meeting,
comments
by
email
from
meeting
attendees
who
chose
not
to
speak
out
during
a
meeting
(e.g.,
so
they
could
confer
later
with
colleagues
or
for
cultural
reasons).
The
Chair
should
record
that
a
decision
has
been
reopened,
and
must
do
so
upon
request
from
a
group
participant.
5.5.
Registering
Formal
Objections
Any
individual
(regardless
of
whether
they
are
associated
with
a
Member)
may
appeal
any
decision
made
in
connection
with
this
Process
(except
those
having
a
different
appeal
process)
by
registering
a
Formal
Objection
with
the
Team
.
Group
participants
should
inform
their
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
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
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.
Registering
a
Formal
Objection
initiates
the
process
of
addressing
the
Formal
Objection
.
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
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.
W3C
Council
A
W3C
Council
is
the
body
convened
to
resolve
Formal
Objections
by
combining
the
capabilities
and
perspectives
of
the
AB
,
the
TAG
,
and
the
Team
,
and
is
tasked
with
doing
so
in
the
best
interests
of
the
Web
and
W3C.
5.6.2.1.
Council
Composition
Each
W3C
Council
is
composed
of
the
following
members
(excepting
any
renounced
or
dismissed
):
the
CEO
or
their
chosen
Team
delegate
the
members
of
the
Advisory
Board
the
members
of
the
Technical
Architecture
Group
Participation
in
a
W3C
Council
must
not
require
attendance
of
face-to-face
meetings
.
A
distinct
instance
of
the
W3C
Council
is
convened
for
each
decision
being
appealed
or
objected
to.
Membership
of
each
Council
instance
is
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.
5.6.2.2.
Extraordinary
Delegation
In
extraordinary
cases,
if
they
feel
a
Council
would
not
be
the
appropriate
deciding
body,
a
member
of
the
Team
(particularly
the
Legal
Counsel)
or
any
potential
Council
member
may
suggest
that
the
decision
for
that
specific
Formal
Objection
be
delegated
to
the
W3C
Board
of
Directors,
to
an
officer
of
its
corporation
(such
as
the
Legal
Counsel),
or
to
one
or
more
specific
individuals
from
the
Team
.
The
potential
Council
members
then
may
confidentially
discuss
and
must
vote
whether
to
delegate
the
decision
for
that
specific
Formal
Objection
.
A
decision
announcement
to
delegate
must
be
supported
by
a
two-thirds
supermajority
vote
(i.e.,
at
least
twice
as
many
votes
in
favor
as
against).
Delegation
in
such
cases
cannot
be
later
revoked.
The
Team
must
inform
the
Advisory
Committee
when
a
Formal
Objection
has
been
delegated,
and
to
whom
it
has
been
delegated.
5.6.2.3.
Council
Participation,
Dismissal,
and
Renunciation
A
potential
Council
member
may
be
dismissed
from
the
Council.
In
order
to
apply
consistent
criteria,
the
potential
Council
members
decide
collectively
which
reasons
against
service
rise
to
a
sufficient
level
for
a
potential
member
to
be
dismissed
.
No-one
is
automatically
dismissed,
and
individual
recusal
is
not
used
in
the
Council.
Dismissal
applies
to
an
individual
person
in
the
context
of
a
specific
Council,
and
should
be
used
rarely
in
order
to
preserve
the
greatest
diversity
on
the
Council.
Note:
A
W3C
Council
is
a
deliberative
body
whose
purpose
is
to
find
the
best
way
forward
for
the
Web
and
for
W3C.
It
is
not
a
judicial
body
tasked
with
determining
right
or
wrong.
The
Team
must
draft
a
list
of
potential
Council
members,
with
annotations
of
possible
reasons
for
dismissal
against
each
one.
The
W3C
community,
including
members
and
team,
and
potential
council
members,
must
be
given
an
opportunity
to
contribute
possible
reasons
to
this
list.
Affected
members
must
be
given
an
opportunity
to
respond
to
such
comments
about
themselves.
The
Team
may
report
comments
verbatim
or
may
paraphrase
them
while
preserving
their
intent;
they
may
also
elide
inappropriate
comments,
such
as
any
that
violate
applicable
laws
or
the
[COC]
.
Before
a
Council
forms,
the
Team
presents
the
entire
list
of
potential
members
and
collected
reasons
and
responses
to
the
potential
Council
members,
who
then
consider
for
each
potential
member
whether
that
individual’s
participation
would
compromise
the
integrity
of
the
Council
decision,
and
vote
whether
to
dismiss
that
potential
member.
No
one
is
allowed
to
vote
on
their
own
dismissal;
each
dismissal
is
enacted
if
there
are
at
least
as
many
ballots
for
as
against.
Note:
Since
dismissal
is
individual,
when
the
decision
being
objected
to
was
made
by
the
TAG
or
AB
acting
as
a
body,
the
entire
TAG
or
AB
is
not
expected
to
be
dismissed.
An
individual
may
also
renounce
their
seat
on
a
Council,
for
strong
reason,
such
as
being
forbidden
by
their
employer
to
serve.
The
individual
chooses
the
extent
to
which
they
explain
their
renunciation.
Renunciation
is
disqualification
from
participation,
not
abstention,
and
should
not
be
used
to
excuse
an
absence
of
participation.
Any
person
who
has
been
dismissed
or
who
renounces
their
seat
does
not
receive
Council
materials,
take
part
in
its
deliberations,
help
in
the
determination
of
consensus,
or
vote.
The
W3C
Council
may
still
solicit
and
hear
their
testimony,
as
they
can
of
anyone
else
in
the
W3C
community.
5.6.2.4.
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.
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
or
overrule
the
objection.
The
W3C
Council
may
overrule
the
Formal
Objection
even
if
it
agrees
with
some
of
the
supportive
arguments.
When
upholding
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
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
W3C
Council
is
unable
to
reach
consensus,
the
W3C
Council
Chair
may
instead
resort
to
voting.
In
that
case,
the
decision
is
adopted
if
there
are
more
ballots
for
than
against;
in
case
of
a
tie,
the
W3C
Council
Chair
determines
the
outcome.
However,
if
the
decision
or
proposal
being
objected
to
originated
with
the
TAG
or
AB,
then
members
of
that
group
at
the
time
the
decision
or
proposal
was
made
must
abstain
in
such
a
vote.
In
case
of
a
vote,
if
two
members
of
a
Council
who
share
the
same
affiliation
cast
an
identical
ballot,
then
their
ballots
count
as
a
one
vote,
not
two.
In
the
case
of
non-unanimous
decisions,
members
of
a
W3C
Council
who
disagree
with
the
decision
may
write
a
Minority
Opinion
explaining
the
reason
for
their
disagreement.
The
deliberations
of
a
W3C
Council
are
confidential
to
that
W3C
Council
and
its
Council
Team
Contact
.
If
a
W3C
Council
is
unable
to
come
to
a
conclusion
within
45
days
of
being
convened
,
the
W3C
Council
Chair
must
inform
the
AC
of
this
delay
and
of
the
status
of
the
discussions.
The
W3C
Council
Chair
may
additionally
make
this
report
public
.
5.6.2.7.
Council
Decision
Report
A
Council
terminates
by
issuing
a
Council
Report
,
which:
must
state
whether
the
Council
upholds
or
overrules
the
objection(s).
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,
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
vote
totals
for
the
Council’s
decision,
if
a
formal
vote
was
held.
must
not
attribute
any
position
to
any
individual
on
the
Council.
The
Team
must
maintain
a
public
page
on
the
W3C
website
indexing
all
completed
Council
Reports
.
If
a
Council
decision
is
later
overturned
by
an
AC
Appeal
,
this
must
also
be
mentioned.
Council
Reports
must
be
no
more
confidential
than
the
decision
or
document
being
objected
to.
The
Council
may
also
issue
a
Supplemental
Confidential
Council
Report
with
a
more
restricted
level
of
confidentiality
than
its
main
report
when
it
believes
that
additional
commentary
on
confidential
aspects
of
the
case
would
be
informative.
However,
the
main
Council
Report
should
be
self-sufficient
and
understandable
without
reference
to
Supplemental
Confidential
Council
Reports.
5.6.2.8.
Appealing
Council
Decisions
Advisory
Committee
representatives
may
initiate
an
Advisory
Committee
Appeal
of
a
Council
decision
issued
in
a
Council
Report
.
5.7.
Advisory
Committee
Reviews
and
W3C
Decisions
The
Advisory
Committee
formally
confers
its
approval
on
charters
,
technical
reports
,
and
other
matters
through
an
Advisory
Committee
review
and
its
resulting
W3C
Decision
.
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
the
W3C
Decision
After
the
review
period,
the
Team
determines
the
appropriate
W3C
Decision
,
which
they
must
announce
to
the
Advisory
Committee
.
The
announcement
must
indicate
the
level
of
support
for
the
proposal
(
consensus
or
dissent
),
and
specifically
whether
there
were
any
Formal
Objections
,
with
attention
to
changing
the
confidentiality
level
of
the
Formal
Objections
.
If
there
were
Formal
Objections
,
at
least
some
of
which
were
upheld
,
or
if
there
is
not
consensus
because
of
insufficient
support,
W3C
Decision
must
be
one
of:
The
proposal
is
returned
for
additional
work,
with
a
request
to
the
initiator
to
improve
the
proposal.
The
proposal
is
rejected.
If
the
proposal
has
consensus
,
or
if
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
Closing
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
Working
Group
consensus
or
implementation
experience),
those
other
conditions
must
also
be
re-fulfilled.
For
example,
to
make
substantive
changes
to
a
Proposed
Recommendations
,
the
technical
report
could
be
returned
to
Candidate
Recommendation
.
Alternatively,
the
desired
changes
can
be
introduced
as
non-substantive
amendments
using
the
process
for
revising
a
Recommendation
.
However,
they
cannot
be
directly
integrated
between
PR
and
REC
,
because
that
would
fail
to
trigger
a
patent
exclusion
opportunity.
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
implications
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
respect
to
new
maturity
stages
for
Recommendation
Track
documents
and
the
Process
document.
Advisory
Committee
representatives
may
also
initiate
an
appeal
for
decisions
of
a
W3C
Council
,
and
for
certain
decisions
that
do
not
involve
an
Advisory
Committee
review
.
These
cases
are
identified
in
the
sections
which
describe
the
requirements
for
the
decision
and
include
additional
(non-reviewed)
maturity
stages
of
Recommendation
Track
documents,
group
charter
extensions
and
closures,
and
technical
agreements
.
In
all
cases,
an
appeal
must
be
initiated
within
three
weeks
of
the
decision.
An
Advisory
Committee
representative
initiates
an
appeal
by
sending
a
request
to
the
Team
,
and
should
also
share
this
request
with
the
Advisory
Committee
.
The
request
should
say
“I
appeal
this
Decision”
and
identify
the
decision,
and
may
also
include
their
rationale
for
appealing
the
decision.
Note:
See
Appealing
a
W3C
Decision
for
a
recommendation
on
how
to
communicate
an
appeal
request
to
the
Team
and
the
AC
.
Within
one
week
the
Team
must
announce
the
appeal
process
to
the
Advisory
Committee
and
provide
a
mechanism
for
Advisory
Committee
representatives
to
respond
with
a
statement
of
positive
support
for
this
appeal.
The
archive
of
these
statements
must
be
member-only
Patent
Policy
[PATENT-POLICY]
.
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:
6.
W3C
Technical
Reports
Report
Development
Process
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
W3C
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 page https://www.w3.org/TR [TR] .
This
chapter
describes
the
formal
requirements
for
publishing
and
maintaining
a
W3C
Recommendation
,
Note
,
or
Registry
Report
Note
.
- 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]
, underwhichparticipants commit togrants Royalty-Free IPR licensesforto implementations. See§ 6.3§ 6.2 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 itsuse. 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 be published either as a distinct registry report ,use, ordirectly within a Recommendation Track document as an embedded registry . Defining a registry requires wide review and consensus , but once set up, changestoregistry entries are lightweight and can even be done without aclarify the status of work that is abandoned. See § 6.3 Working Group. See § 6.5 The Registry Trackand Interest Group Notes 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.
6.1.1.
General
Requirements
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.
The
index
of
W3C
technical
reports
[TR]
is
available
at
the
W3C
Web
site.
W3C
strives
to
make
archival
documents
indefinitely
available
at
their
original
address
in
their
original
form.
Every
document
published
as
part
of
the
technical
report
development
process
must
clearly
indicate
its
maturity
stage
level
,
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
§ 5.2.1
Working
Group
and
Interest
Group
Participation
in
Chartered
Groups
Requirements
in
the
Group
responsible
for
the
document(s)
they
are
editing.
The Team is not required to publish a Technical Report that does not conform to the Team’s Publication Rules [PUBRULES] (e.g., for naming , status information, style, and copyright requirements ). These rules are subject to change by the Team from time to time. The Team must inform group Chairs and the Advisory Committee of any changes to these rules.
The
primary
language
for
W3C
Technical
Reports
is
English.
W3C
encourages
the
translation
of
its
Technical
Reports
.
Information
about
translations
of
W3C
technical
reports
[TRANSLATION]
is
available
at
the
W3C
website.
Web
site.
6.2.2.
6.1.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.
6.1.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
Director
will
consider
who
has
been
explicitly
offered
a
reasonable
opportunity
to
review
the
document,
who
has
provided
comments,
the
record
of
requests
to
and
responses
from
reviewers,
especially
W3C
Horizontal
Groups
[CHARTER]
and
groups
identified
as
dependencies
in
the
charter
or
identified
as
liaisons
[LIAISON]
,
and
seek
evidence
of
clear
communication
to
the
general
public
about
appropriate
times
and
which
content
to
review
and
whether
such
reviews
actually
occurred.
For
example,
inviting
review
of
new
or
significantly
revised
sections
published
in
Working
Drafts,
and
tracking
those
comments
and
the
Working
Group
's
responses,
is
generally
a
good
practice
which
would
often
be
considered
positive
evidence
of
wide
review.
Working
Groups
should
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.
6.1.3.
Classes
of
Changes
This
document
distinguishes
the
following
5
4
classes
of
changes
to
a
document.
specification.
The
first
two
classes
of
change
are
considered
editorial
changes
,
the
next
latter
two
substantive
changes
,
and
the
last
one
registry
changes
.
-
-
No changes to text content
-
-
These
changes
include
fixing
broken
links,
style
sheets,sheets or invalid markup. -
-
ChangesCorrections that do notfunctionallyaffectinterpretation of the documentconformance
-
-
For Recommendation-track technical reports specifically, this constitutes changes that do not affect conformance, i.e. changesChanges that reasonable implementers would not interpret as changing architectural or interoperability requirements or their implementation. Changes which resolve ambiguities in the specification are considered to change (by clarification) the implementation requirements and do not fall into this class.- Examples of changes in this class include correcting non-normative code examples
whichwhere the code clearlyconflictconflicts with normative requirements, clarifying informative use cases or other non-normative text, fixing typos or grammatical errors where the change does not change implementation requirements. If there is any doubt or disagreement as to whethera change functionally affects interpretation, that change doesrequirements are changed, such changes do not fall into this class. - Examples of changes in this class include correcting non-normative code examples
-
-
Other changesCorrections that do not add new features
-
-
For Recommendation-track documents, theseThese 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
a
new
functionality,
such as new elements, new APIs, new rules,element, etc.Changes to the contents of a registry table Changes that add, remove, or alter registry entries in a registry table .
6.2.4.
6.1.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
§ 6.1.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.
6.1.5.
Candidate
Amendments
Proposed
Changes
An
erratum
may
be
accompanied
by
an
informative,
candidate
proposed
correction
approved
by
group
decision
the
consensus
of
the
Working
Group
.
When
annotated
inline,
errata—including
errata—
candidate
proposed
corrections
—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
proposed
changes
have
not
yet
received
sufficient
review
or
implementation
experience
to
be
normatively
incorporated
into
the
specification
proper.
A
candidate
proposed
addition
is
similar
to
a
candidate
proposed
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
Proposed
corrections
and
candidate
proposed
additions
are
collectively
known
as
candidate
amendments
proposed
changes
.
6.2.6.
6.1.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
§ 6.1.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.
6.2.
The
W3C
Recommendation
Track
When
advancing
a
technical
report
to
Recommendation,
typically
a
series
of
Working
Groups
Drafts
create
specifications
and
guidelines
are
published
,
each
of
which
refines
a
document
under
development
to
complete
the
scope
of
work
envisioned
by
a
Working
Group
's
charter
.
These
For
a
technical
reports
undergo
cycles
of
revision
and
review
as
they
advance
towards
W3C
Recommendation
status.
Once
specification,
once
review
suggests
the
Working
Group
has
met
their
requirements
satisfactorily
for
a
new
standard,
including
wide
review
,
there
is
a
Candidate
Recommendation
phase
phase.
This
allows
the
entire
W3C
membership
to
provide
feedback
on
whether
the
specification
is
appropriate
as
a
W3C
Recommendation
,
while
the
Working
Group
to
formally
collect
collects
implementation
experience
to
demonstrate
that
the
specification
works
in
practice.
At
The
next
phase
is
a
Proposed
Recommendation
,
to
finalize
the
end
review
of
W3C
Members.
If
the
process,
the
Advisory
Committee
reviews
the
mature
technical
report,
and
if
there
is
support
from
its
Membership,
Director
determines
that
W3C
Member
review
supports
a
specification
becoming
a
standard,
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
.
A W3C -
Possibly,
publication
as
an
Edited
or
Amended
Recommendation
Track document is any document whose current status is one of the five in the numbered list above..
This
Process
defines
certain
Recommendation
Track
publications
as
Patent
Review
Drafts
.
Under
the
2004
Patent
Policy
(and
its
2017
update)
[PATENT-POLICY-2004]
,
these
These
correspond
to
the
“Last
Call
Working
Draft”
in
the
Patent
Policy;
Starting
from
the
2020
Patent
Policy
[PATENT-POLICY-2020]
,
these
correspond
to
“Patent
Review
Draft”
in
of
the
Patent
Policy
[PATENT-POLICY]
.
W3C may end work on a technical report at any time.
As
described
The
Director
may
decline
a
request
to
advance
in
§ 6.3.3
Advancement
on
maturity
level,
requiring
a
Working
Group
to
conduct
further
work,
and
may
require
the
Recommendation
Track
,
specification
to
return
to
a
lower
maturity
level
.
The
Director
must
inform
the
Team
Advisory
Committee
will
decline
and
Working
Group
Chairs
when
a
Working
Group
's
request
for
a
specification
to
advance
in
maturity
stage
level
is
declined
and
return
the
specification
is
returned
to
a
Working
Group
for
further
work
if
it
determines
that
the
requirements
for
advancement
have
not
been
met.
work.
6.3.1.
6.2.1.
Maturity
Stages
Levels
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,
or
makes
substantive
corrections
to
a
Recommendation
that
is
not
maintained
by
a
Working
Group
,
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 RecommendationReview 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” insection 5.5 of the W3C Patent Policy.Publication as a Candidate Recommendation Snapshot requires
verificationapproval of either a Transition Request (for the first Candidate Recommendation publication from another maturitystage)level) or an Update Request (for subsequent Candidate RecommendationSnapshots ).Snapshots). -
Candidate
Recommendation
Draft
( CRD ) -
AAn 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 RecommendationSnapshot .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 .Reveiw 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;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 section 5.5.5.4 of 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” insection 2.8.3 of 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
the
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
.
When the intended next step is a Expandable Recommendation , the Proposed Recommendation is deemed to be a Proposed Expandable Recommendation , and must identify itself as such. In all other respects, Proposed Recommendations and Proposed Expandable Recommendations are identical.
- 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
the
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:
- An Edited Recommendation
- A Working Group may make editorial to a Recommendation , and produce a new version which W3C publishes as a revised edition of the Recommendation .
- An Amended Recommendation
- An Amended Recommendation is a Recommendation that is amended to include substantive changes that do not add new features , and is produced by the W3C at a time when the Recommendation does not fit within the charter of any active Working Group. Since the W3C team rather than a Working Group moves it through the Process, there are implications regarding the scope of Royalty-Free IPR licenses granted under the W3C Patent Policy [PATENT-POLICY] .
- A Superseded Recommendation
-
A
Superseded
Recommendation
is
a
specification
that
has
been
replaced
by
a
newer
version
that
the
W3C
recommends
for
new
adoption.
An
Obsolete
or
Superseded
specification
has
the
same
status
as
a
W3C
Recommendation
with
regards
to
W3C
Royalty-Free
IPR
Licenses
granted
under
the
Patent
Policy.
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
previousold one, without the need to invoke the the steps of§ 6.3.13.3§ 6.2.12.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§ 6.2.12.3 Abandoning a W3C Recommendation , is intended for cases where a Recommendation is superseded by a separate Technical Report (or a by a document managed outside of W3C). - An Obsolete Recommendation
- An Obsolete Recommendation is a specification that the W3C has determined lacks sufficient market relevance to continue recommending it for implementation, but which does not have fundamental problems that would require it to be Rescinded . If an Obsolete specification gains sufficient market relevance, the W3C may decide to restore it to Recommendation status.
- 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” insection 2.8.3 of the W3C Patent Policy [PATENT-POLICY] .
-
Discontinued DraftW3C Expandable Recommendation ( Extensible REC ) -
A
technical reportExpandable Recommendation is identical to a Recommendationrepresentingin most respects. All statements about Recommendations in this document apply to Expandable Recommendations as well. For instance, thestate ofcriteria for advancement are the same, the steps to declare aRecommendation-track document atW3C Recommendation Rescinded, Obsolete or Superseded are thepoint atsame, a Expandable Recommendation is a Recommendation for the purpose of the Patent Policy [PATENT-POLICY] , etc.However, new features (i.e. class 4 changes ) can be incrementally added to a Expandable Recommendation , which
work on it was discontinued. See § 6.3.13.1 Abandoningis not possible for anUnfinishedordinary Recommendation . This is enabled by the mechanism described in § 6.2.11.4 Revising a Recommendation: New Features . Publishing a technical report as a Expandable Recommendation is only possible when explicitly allowed in the Working Group 's Charter .
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.
6.2.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
Director
will
consider
(though
not
be
limited
to):
- is each feature of the current specification implemented, and how is this demonstrated?
- are there independent interoperable implementations of the current specification?
- are there implementations created by people other than the authors of the specification?
- are implementations publicly deployed?
- is there implementation experience at all levels of the specification’s ecosystem (authoring, consuming, publishing…)?
- are there reports of difficulties or problems with implementation?
Planning and accomplishing a demonstration of (interoperable) implementations can be very time consuming. Groups are often able to work more effectively if they plan how they will demonstrate interoperable implementations early in the development process; for example, developing tests in concert with implementation efforts.
6.3.3.
6.2.3.
Advancement
on
the
Recommendation
Track
For
all
requests
to
advance
a
specification
to
a
new
maturity
stage
level
other
than
Note
(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 upheld by a Council but not yet fully addressed ), or if the document does not adequately reflect all relevant decisions of the W3C Council (or its delegates). If the Team rejects a Transition Request it must indicate its rationale to the Advisory CommitteeDirectorand the Working Group .approval. - 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 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
stagelevel . - 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”,
level”,
so
many
requirements
do
not
apply,
and
verification
approval
is
normally
fairly
straightforward.
automatic.
For
later
stages,
especially
transition
to
Candidate
or
Proposed
Recommendation
,
there
is
usually
a
formal
review
meeting
to
verify
that
ensure
the
requirements
have
been
met.
met
before
Director
's
approval
is
given.
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 Director 's decision on an Advisory Committee Review .
6.3.4.
6.2.4.
Updating
Mature
Publications
on
the
Recommendation
Track
Certain
requests
to
re-publish
a
specification
within
its
current
maturity
stage
level
(called
Update
Requests
)
require
extra
verification.
Director
approval.
For
such
update
requests
,
the
Working
Group:
- must record the group’s decision to request the update.
- must show that the changes have received wide review .
-
must
obtain
Team verification. Team verification (a Team decision ): should be withheld if any Process requirements are not met, may be withheld in consideration of unresolved Formal Objections (including any upheld by a Council but not yet fully addressed ), may be withheld if the document does not adequately reflect all relevant decisions of a W3C Council (or its delegates), may be withheld if the Team believes the Group is not making reasonable progress on addressing issues raised by individuals external to the Group. If the TeamDirectorrejects an Update Request , it must indicate its rationale to the Working Group . If it waives any Process requirements, it must indicate its rationale toapproval, or fulfill theACcriteria for § 6.2.4.1 Streamlined Publication Approval . - 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
ensure
the
requirements
have
been
met.
met
before
Director
's
approval
is
given.
Note:
Update
request
verification
approval
is
expected
to
be
fairly
simple
compared
to
verification
of
getting
approval
for
a
transition
request
.
The
Team
Director
must
announce
the
publication
of
the
revised
specification
to
other
W3C
groups
and
the
Public.
6.3.5.
6.2.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 judgement, and to make self-evaluation practical.
In order to streamline the publication process in non-controversial cases, approval to 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 substative 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 an Expandable Recommendation ) 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
approval
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.2.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
Director
must
announce
the
publication
of
a
First
Public
Working
Draft
to
other
W3C
groups
and
to
the
public.
6.3.6.
6.2.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:
- Revised Working Draft
- Candidate Recommendation
-
Discontinued DraftWorking Group Note
6.3.7.
6.2.7.
Transitioning
to
Candidate
Recommendation
To
publish
a
Candidate
Recommendation
,
in
addition
to
meeting
the
requirements
for
advancement
a
Working
Group
:
,
or
in
the
case
of
a
candidate
Amended
Recommendation
(a
document
intended
to
become
an
Amended
Recommendation
),
the
W3C:
- 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
approval
of
having
met
the
requirements
for
a
Transition
Request
is
always
a
Candidate
Recommendation
Snapshot
.
The
Team
Director
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 DraftWorking Group Note
Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to advance the technical report.
6.3.8.
6.2.8.
Revising
a
Candidate
Recommendation
6.3.8.1.
6.2.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
Director
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
section
5.5
of
the
W3C
Patent
Policy
[PATENT-POLICY]
.
6.3.8.2.
6.2.8.2.
Publishing
a
Candidate
Recommendation
Draft
A
Working
Group
should
publish
an
a
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 DraftWorking Group Note
6.3.9.
6.2.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” insection 5.5 of the W3C Patent Policy [PATENT-POLICY] .
A
Working
Group:
Group,
or
for
a
proposed
Amended
Recommendation
,
the
W3C:
-
must
show
adequate
implementation
experience
except
where
an
exception
is
approved
by
a Team Decisionthe Director , - must show that the document has received wide review ,
- must show that all issues raised during the Candidate Recommendation review period other than by Advisory Committee representatives acting in their formal AC representative role have been formally addressed ,
-
must
identify
any
substantive
issues
raised
since
the
close
of
the
Candidate
Recommendation
review
periodperiod, - must indicate whether the intended next step is Expandable Recommendation , in which case the Proposed Recommendation must be identified as a Proposed Expandable Recommendation . This is only possible when the Charter allows it for that Technical Report.
-
must
not
have
madeany substantive changesto the documentsince 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
:
Director:
- 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
TeamDirectormustshould explain the reasons for thatdecision, and that information must be included in the Call for Review proposing advancement to W3C Recommendation .decision.
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 .
Possible Next Steps:
- Return to Working Draft
- Return to Candidate Recommendation
-
Recommendation
status
,
(theincluding Edited or Amended Recommendation (The expected next step). -
Discontinued DraftWorking Group Note
Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to advance the technical report.
6.3.10.
6.2.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
TeamDirector 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
TeamDirector 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
aanrevisedEdited or Amended Recommendation , or -
republished
as
a
Candidate
Recommendation
to
be
developed
towards a revisedas an Edited or Amended Recommendation , or - declared superseded or obsolete , or
- rescinded .
6.3.11.
6.2.11.
Revising
a
W3C
Recommendation
This section details the process for making changes to a Recommendation .
6.3.11.1.
6.2.11.1.
Revising
a
Recommendation:
Markup
Changes
A Working group may request republication of a Recommendation , or if there is no Working Group chartered to maintain a Recommendation W3C may republish the Recommendation , to make corrections that do not result in any changes to the text of the specification. (See class 1 changes .)
6.3.11.2.
6.2.11.2.
Revising
a
Recommendation:
Editorial
Changes
Editorial
changes
to
a
Recommendation
require
no
technical
review
of
the
intended
proposed
changes.
A
Working
Group
,
provided
there
are
no
votes
against
the
decision
resolution
to
publish,
may
request
publication
of
a
Recommendation
or
W3C
may
publish
a
Recommendation
to
make
this
class
of
change
without
passing
through
earlier
maturity
stages.
levels.
Such
publications
are
called
Edited
Recommendations
.
(See
class
2
changes
.)
6.3.11.3.
6.2.11.3.
Revising
a
Recommendation:
Substantive
Changes
A
candidate
proposed
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
.
proposed
change.
To
validate
this,
the
Working
Group
must
request
a
Last
Call
for
Review
of
Proposed
Amendments
Changes
,
followed
by
an
update
request
.
See
§ 6.3.11.5
§ 6.2.11.5
Incorporating
Candidate
Amendments
.
Proposed
Changes
Alternatively,
a
Working
Group
may
incorporate
the
changes
and
publish
as
a
Working
Draft
—or,
if
the
relevant
criteria
are
fulfilled,
publish
as
a
Candidate
Recommendation
—and
advance
the
specification
from
that
state.
(See
class
3
changes
.)
Note:
If
there
is
,
or
if
no
Working
Group
is
chartered
to
maintain
a
Recommendation
the
Team
cannot
make
substantive
changes
and
republish
the
W3C
may
publish
a
candidate
Amended
Recommendation
.
It
can,
however,
informatively
highlight
problems
and
desirable
changes
using
errata
,
and
candidate
corrections
advance
the
specification
from
that
state.
If
the
publication
was
requested
by
the
W3C
team
and
republish
as
described
in
the
previous
section
absence
of
a
Working
Group
,
the
resulting
Recommendation
will
be
called
an
Amended
Recommendation
.
(See
class
3
changes
.)
6.3.11.4.
6.2.11.4.
Revising
a
Recommendation:
New
Features
New
To
make
changes
which
introduce
a
new
feature
or
features
(see
class
4
changes
)
may
be
incorporated
into
to
a
Recommendation
explicitly
identified
as
allowing
which
is
not
a
Expandable
Recommendation
,
W3C
must
follow
the
full
process
of
advancing
a
technical
report
to
Recommendation
beginning
with
a
new
First
Public
Working
Draft
.
However,
new
features
can
also
be
added
to
a
Expandable
Recommendation
using
candidate
proposed
additions
.
A
candidate
proposed
addition
can
be
made
normative
and
be
folded
into
the
main
text
of
the
an
Expandable
Recommendation
using
,
once
it
has
satisfied
all
the
same
process
criteria
as
for
candidate
amendments
the
rest
of
the
Recommendation
,
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
including
review
by
the
community
to
ensure
the
2020
revision
technical
and
editorial
soundness
of
this
Process.
the
proposed
change.
To
make
changes
which
introduce
a
new
feature
to
a
Recommendation
validate
this,
the
Working
Group
that
does
not
allow
new
features
,
W3C
must
create
request
a
new
technical
report
,
following
the
full
process
Last
Call
for
Review
of
advancing
a
technical
report
to
Recommendation
beginning
with
a
new
First
Public
Working
Draft
Proposed
Changes
,
followed
by
an
update
request
.
See
§ 6.2.11.5
Incorporating
Proposed
Changes
6.3.11.5.
6.2.11.5.
Incorporating
Candidate
Amendments
Proposed
Changes
A
Last
Call
for
Review
of
Proposed
Amendments
Changes
verifies
acceptance
by
the
W3C
community
of
candidate
amendments
proposed
changes
by
combining
an
AC
Review
with
a
patent
exclusion
opportunity.
The
combination
of
the
existing
Recommendation
with
the
proposed
changes
included
in
the
Last
Call
for
Review
of
Proposed
Amendments
Changes
is
considered
a
Patent
Review
Draft
of
the
proposed
changes
for
the
purposes
of
the
Patent
Policy
[PATENT-POLICY]
.
Also,
the
review
initiated
by
the
Last
Call
for
Review
of
Proposed
Additions
is
an
Advisory
Committee
Review
.
The Last Call for Review of Proposed Changes 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 (proposedcorrections / proposed additions ).changes under review. - 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.
Note:
Last
Call
for
Review
of
Proposed
Additions
and
Last
Call
for
Review
of
Proposed
Corrections
and
Additions
can
only
be
issued
for
Expandable
Recommendations
that
allow
new
features
.
A
Working
Group
may
batch
multiple
proposed
amendments
changes
into
a
single
Last
Call
for
Review
of
Proposed
Amendments
Changes
.
To
facilitate
review,
a
Last
Call
for
Review
of
Proposed
Amendments
Changes
on
a
given
specification
should
not
be
issued
more
frequently
than
approximately
once
every
6
six
months.
At
the
end
of
the
Last
Call
for
Review
of
Proposed
Amendments
Changes
,
the
W3C
Decision
may
either
be
to
reject
the
proposed
amendment
Proposed
Change
,
or
to
clear
the
proposed
amendment
Proposed
Change
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
Proposed
Change
in
response
to
review
feedback
it
must
issue
another
Last
Call
for
Review
of
Proposed
Amendments
Change
on
the
revised
change
before
it
can
be
incorporated
into
the
main
text.
Once
all
comments
on
a
proposed
amendment
Proposed
Change
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
Proposed
Change
into
the
normative
Recommendation
by
issuing
an
update
request
for
publication
of
the
updated
Recommendation
.
To
ensure
adequate
review
of
proposed
amendment
Proposed
Change
combinations,
only
proposed
amendments
Proposed
Changes
included
in
the
most
recent
Last
Call
for
Review
of
Proposed
Amendments
Changes
can
be
incorporated
into
the
normative
Recommendation
text.
(Thus
if
incorporation
of
a
proposed
amendment
Proposed
Change
is
postponed,
it
may
need
to
be
included
in
multiple
Last
Calls
for
Review
of
Proposed
Amendments.)
Changes.)
6.3.12.
6.2.11.6.
Regression
on
the
Transitoning
between
Expandable
Recommendation
and
Recommendation
Track
A
If
the
Working
Group
may
republish
's
Charter
allows
a
Recommendation-track
Technical
Report
to
be
published
either
as
a
Recommendation
technical
report
or
as
a
Expandable
Recommendation
,
it
is
possible
to
republish
a
Recommendation
at
as
a
lower
maturity
stage
Expandable
Recommendation
:
There
must
be
a
Working
Group
by
fulfilling
the
requirements
to
transition
decision
to
that
maturity
stage,
as
described
above.
Additionally,
with
do
so,
after
which
the
approvals
(by
group
decision
Team
must
solicit
an
Advisory
Committee
Review
)
of
each
the
proposed
change
of
status.
The
review
period
must
last
at
least
28
days
.
If
the
TAG
and
proposal
is
approved,
the
AB
Recommendation
the
Team
is
republished
as
a
Expandable
Recommendation
.
Republishing
a
Expandable
Recommendation
may
return
as
a
Recommendation
,
if
allowed
by
the
technical
report
relevant
Working
Group
's
charter,
follows
the
same
process.
Note:
An
AC
Review
is
necessary
to
a
lower
maturity
stage
make
sure
the
change
from
Recommendation
in
response
to
wide
review
Expandable
Recommendation
or
is
not
made
lightly,
as
there
may
be
stakeholders
who
rely
on
a
formal
objection
.
Recommendation
having
a
fixed
scope.
6.3.13.
6.2.12.
Retiring
Recommendation
Track
Documents
Work on a technical report may cease at any time. Work should cease if W3C or a Working Group determines that it cannot productively carry the work any further.
6.3.13.1.
6.2.12.1.
Abandoning
an
Unfinished
Recommendation
Technical
Report
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.
Working
Group
Note
.
This
can
happen
if
the
Working
Group
decided
to
abandon
work
on
the
report,
or
as
the
result
of
an
AC
Review
Director
requiring
required
the
Working
Group
to
discontinue
work
on
the
technical
report
before
completion.
If
the
Director
closes
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
Notes
.
6.3.13.2.
6.2.12.2.
Rescinding
a
Candidate
Recommendation
The process for rescinding a Candidate Recommendation is the same as for rescinding a Recommendation .
6.3.13.3.
6.2.12.3.
Abandoning
a
W3C
Recommendation
It is possible that W3C decides that implementing a particular Recommendation is no longer recommended. There are three designations for such specifications, chosen depending on the advice W3C wishes to give about further use of the specification.
W3C may obsolete a Recommendation , for example if the W3C Community decides that the Recommendation no longer represents best practices, or is not adopted and is not apparently likely to be adopted. An Obsolete Recommendation may be restored to normal Recommendation , for example because despite marking it Obsolete the specification is later more broadly adopted.
W3C may declare a Recommendation Superseded if a newer version exists which the W3C recommends for new adoption. The process for declaring a Recommendation Superseded is the same as for declaring it Obsolete, below; only the name and explanation change.
W3C
may
rescind
a
Recommendation
if
W3C
believes
there
is
no
reasonable
prospect
of
it
being
restored
for
example
due
to
burdensome
patent
claims
that
affect
implementers
and
cannot
be
resolved;
see
the
W3C
Patent
Policy
[PATENT-POLICY]
and
in
particular
“W3C
Royalty-Free
(RF)
Licensing
Requirements”
section
2.8.3
and
“PAG
Conclusion”.
section
5.5.5.4
.
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.
6.2.12.4.
Process
for
Rescinding,
Obsoleting,
Superseding,
Restoring
Superseding
a
Recommendation
The
process
of
rescinding,
obsoleting,
rescinding,
superseding,
or
restoring
a
Recommendation
can
be
initiated
either
by
a
request
from
the
Team
Director
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
Director
must
then
submit
the
request
to
the
Advisory
Committee
for
review.
For
any
Advisory
Committee
review
of
a
proposal
to
rescind,
obsolete,
rescind,
supersede,
or
restore
a
Recommendation
the
Team
Director
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 Director 's announcement
and should
- identify known implementations.
If
there
was
any
dissent
in
the
Advisory
Committee
review
,
the
Team
Director
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
Director
'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.
6.3.
The
Note
Track
(Notes
Working
Group
and
Statements)
6.4.1.
Interest
Group
Notes
A
Working
Group
Note
or
Interest
Group
Note
(
NOTE
)
is
published
by
a
chartered
Working
Group
or
Interest
Group
to
provide
a
stable
reference
for
a
useful
document
that
is
not
intended
to
be
a
formal
standard.
standard,
or
to
document
work
that
was
abandoned
without
producing
a
Recommendation
.
Working
Groups
,
Interest
Groups
,
the
TAG
and
the
AB
Interest
Groups
may
publish
work
as
W3C
Notes
.
Examples
include:
-
supporting
documentation
for
a
specification,
such
as
explanations
of
design
principles
or
use
cases
and
requirementsrequirements, -
non-normative
guides
to
good
practicespractices, - specifications where work has been stopped and there is no longer consensus for making them a new standard.
Some
W3C
Notes
are
developed
through
successive
Note
Working
Drafts
before
publication
as
a
full
,
with
an
expectation
that
they
will
become
Notes
,
while
others
are
simply
published
directly
as
a
Note
.
There
are
few
formal
requirements
to
publish
a
document
as
a
Note
or
W3C
Note
Draft
,
and
they
have
no
standing
as
a
recommendation
of
W3C
but
are
simply
documents
preserved
for
historical
reference.
In
order
to
publish
a
Note
,
a
Working
Group
or
Note
Draft
,
the
group:
Interest
Group
:
- may publish a Note with or without its prior publication as a Working Draft .
-
must
record
theirthe group’s decision to request publication as aNote orNoteDraft, and - should publish documentation of significant changes to the technical report since any previous publication.
Both
Notes
and
Note
Drafts
can
be
updated
by
republishing
as
a
Note
or
Note
Draft
.
Possible
next
steps:
-
End
state:
A
technical
report
may
remain
a
Working
or
Interest
Group
Note
indefinitely. If a Noteindefinitely -
A
Working
Group
produced bymay resume work on achartered group is no longer intechnical report within the scopeforof its charter at anygroup,time, at theTeam may republishmaturity level theNote with class 1 changes incorporated, as wellspecification had before publication aswith errataa Noteand Team corrections
Note:
The
W3C
Patent
Policy
[PATENT-POLICY]
annotated.
does
not
specify
any
licensing
requirements
or
commitments
for
Working
Group
Notes.
6.4.3.
6.4.
Elevating
Group
Notes
to
W3C
Statement
status
Further
reading
A
W3C
Statement
is
a
Note
that
has
been
endorsed
by
W3C
as
a
whole.
In
order
to
elevate
a
Note
Refer
to
W3C
Statement
status,
A
group
must
:
show
that
the
document
has
received
wide
review
.
record
the
group’s
decision
"How
to
request
publication
as
a
W3C
Statement
.
show
that
all
issues
raised
against
the
document
since
its
first
publication
as
Organize
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
Recommendation
Track
Transition"
status;
if
it
does,
the
request
to
publish
as
a
Statement
[TRANSITION]
must
include
rationale
for
why
it
should
be
elevated,
and
why
it
is
not
on
the
Recommendation
track
.
Once
these
conditions
are
fulfilled,
in
the
Team
Member
guide
must
then
begin
an
Advisory
Committee
Review
[GUIDE]
on
for
practical
information
about
preparing
for
the
question
reviews
and
announcements
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
various
steps,
and
tips
on
getting
to
W3C
Statement
Recommendation
faster
is
a
W3C
Decision
[REC-TIPS]
.
Advisory
Committee
representatives
may
initiate
an
Advisory
Committee
Appeal
of
the
decision.
The
Team
must
announce
Please
see
also
the
publication
Requirements
for
modification
of
a
W3C
Statement
Technical
Reports
to
the
Advisory
Committee
,
other
W3C
groups,
and
the
public.
[REPUBLISHING]
.
6.4.4.
7.
Revising
W3C
Statements
Advisory
Committee
Reviews,
Appeals,
and
Votes
Given
a
recorded
group
decision
to
do
so,
groups
can
request
publication
of
a
W3C
Statement
with
editorial
changes
—including
candidate
amendment
—without
any
additional
process.
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,
This
section
describes
how
the
group
must
request
an
Advisory
Committee
review
of
reviews
proposals
from
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
Director
is
a
W3C
Decision
.
and
how
Advisory
Committee
representatives
may
initiate
an
Advisory
Committee
Appeal
of
the
a
W3C
decision
or
Director
's
decision.
A
W3C
decision
is
one
where
the
Director
(or
the
Director’s
delegate)
has
exercised
the
role
of
assessing
consensus
after
an
Advisory
Committee
review
.
6.5.
7.1.
The
Registry
Track
Advisory
Committee
Reviews
A
registry
documents
a
data
set
consisting
of
one
or
more
registry
tables
,
each
table
representing
an
updatable
collection
of
logically
independent,
consistently-structured
registry
entries
.
A
registry
consists
of:
The
Advisory
Committee
reviews:
-
the registry definition , defining how the registry tables are structurednew andmaintainedmodified Working and Interest Groups , -
one or more registry tablesProposed Recommendations ,holding the data set represented by the registry (the registry data ) The purposes of maintaining a registry can include: non-collision Avoiding the problem of two entities using the same value with different semantics. non-duplication Avoiding the problem of having twoProposals to Obsolete, Rescind, Supersede, ormore different values in use with the same semantics. information Providing a central index where anyone can find out what a value meansRestore Recommendations , andwhat its formal definition is (and where it is). submission Ease of adding new terms, including by stakeholders external -
Proposed
changes
to
the
custodian organization. consensus Promoting a clear consensus of the community on the terms. This section of theW3CProcess provides a specializedprocessfacilitating the publication and maintenance of such registry tables , particularly those required by or closely related to W3C Recommendations.Note: Not every table in -
Conversion
from
a
specification isRecommendation to apotential 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 GroupExpandable Recommendation , andonly updated as part of specification update, then the complexities of registry management are not needed.vice versa.
6.5.1.
7.1.1.
Registry
Definitions
Start
of
a
Review
Period
A
registry
definition
Each
Advisory
Committee
review
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
period
begins
with
a
defined
set,
or
be
unique,
or
only
reference
publicly
available
resources,
etc.)
Define
the
policy
Call
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
Review
from
the
method
and
criteria
by
which
changes
are
proposed,
approved,
and
incorporated.
(For
example,
a
registry
could
define
that
changes
to
registry
entries
Team
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
Advisory
Committee
.
The
Call
for
Review
of
the
registry
table
:
describes
the
entity
proposal,
raises
attention
to
which
requests
for
registry
changes
must
deadlines,
estimates
when
the
decision
will
be
sent,
available,
and
includes
other
practical
information.
Each
Member
organization
may
send
one
review,
which
is
responsible
for
evaluating
whether
such
requests
satisfy
the
criteria
defined
in
the
registry
definition
must
be
returned
by
its
Advisory
Committee
representative
.
The
custodian
may
be
the
Working
Group
,
the
Team
,
or
a
delegated
entity.
The
custodian
must
provide
two
channels
for
all
registry
tables
Advisory
Committee
review
comments:
-
an
archived
Team-only
in a single registrychannel; - an archived Member-only channel.
The
Call
for
Review
should
must
generally
be
specify
which
channel
is
the
same
entity.
default
for
review
comments
on
that
Call.
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
Reviewers
may
send
information
to
make
contact),
and
the
Working
Group
that
owns
the
registry
definition
is
itself
closed
either
or
unresponsive,
the
Team
both
channels.
They
should
may
propose
replacing
also
share
their
reviews
with
other
Members
on
the
custodian
,
which
Advisory
Committee
discussion
list
.
A
Member
organization
must
may
be
confirmed
by
an
AC
Review
as
modify
its
review
during
a
W3C
Decision
.
review
period
(e.g.,
in
light
of
comments
from
other
Members).
6.5.2.
7.1.2.
Publishing
Registries
After
the
Review
Period
Registries
can
be
published
either
as
a
stand-alone
technical
report
on
After
the
Registry
Track
called
a
registry
report
,
or
incorporated
as
part
of
a
Recommendation
as
an
embedded
registry
.
The
registry
report
or
embedded
registry
review
period,
the
Director
must
:
Clearly
label
the
registry
report
or
embedded
registry
,
its
tables
,
and
its
registry
definitions
as
such,
including
a
link
announce
to
§ 6.5
The
Registry
Track
in
this
Process.
Include
the
registry
definition
for
each
of
its
registry
tables
.
Provide
the
registry
data
Advisory
Committee
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
level
of
support
for
the
technical
report
,
or
(preferably)
both.
Linking
to
one
or
more
standalone
Registry
Data
Reports
containing
the
registry
tables
proposal
(
consensus
in
human-readable
form,
machine-readable
form,
or
(preferably)
both.
Include,
if
the
registry
table
dissent
is
provided
in
a
machine-readable
file,
a
definition
of
the
format
of
that
file.
).
The
Team
Director
must
make
available
a
means
for
interested
parties
to
be
notified
of
also
indicate
whether
there
were
any
updates
Formal
Objections
,
with
attention
to
a
registry
table
changing
confidentiality
level
.
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
This
W3C
decision
and
publication
is
generally
one
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.
following:
-
The
proposal
is
approved,
possibly
with
the following exceptions:editorial changes integrated. -
Registry reportsThe proposal is approved, possibly with substantive changesare not subject tointegrated. In this case the[PATENT-POLICY] , and therefore none of their publications correspond, to First Public Working Draft , Working Draft , or Patent Review DraftDirector’s announcement must include rationale for thepurposes ofdecision to advance the[PATENT-POLICY] . Fordocument despite thesame reason, there is no equivalent to Rescinded Recommendation nor to Rescinded Candidate Recommendationproposal forRegistries . The equivalent of Working Draft is called Registry Draft .a substantive change. -
The
equivalent of Candidate Recommendationproposal iscalled Candidate Registry ,returned for additional work, withCandidate Recommendation Snapshot and Candidate Recommendation Draft correspondinga request toCandidate Registry Snapshot and Candidate Registry Draft . The equivalent of W3C Recommendation is called W3C Registry ; Obsolete Recommendation and Superseded Recommendation correspondthe initiator toObsolete Registry and Superseded Registry .formally address certain issues. -
ThereThe proposal isno equivalent torejected.
This
document
does
not
specify
time
intervals
between
the
Proposed
Recommendation
phase.
Instead,
end
of
an
Advisory
Committee
Review
is
started
upon
publication
of
each
Candidate
Registry
Snapshot
.
Changes
that
add
new
features
(i.e.
class
4
changes
review
)
are
allowed
in
all
W3C
Registries
,
without
needing
period
and
the
to
explicitly
indicate
that
this
W3C
decision
.
This
is
allowed.
6.5.3.
Updating
Registry
Tables
Changes
to
the
contents
of
a
registry
table
ensure
that
are
in
accordance
with
the
registry
definition
,
(i.e.
Class
5
changes
)
can
be
made
by
re-publishing
the
technical
report
Members
and
Team
that
contains
the
affected
table,
without
needing
have
sufficient
time
to
satisfy
any
other
requirements
for
the
publication
(not
even
Working
Group
consensus,
unless
this
is
required
by
consider
comments
gathered
during
the
registry
definition
).
Such
registry
changes
do
not
trigger
new
review.
The
Advisory
Committee
Reviews
,
nor
Exclusion
Opportunities,
and
do
should
not
require
verification
via
expect
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:
announcement
sooner
than
two
weeks
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.
If
other
changes
are
desired,
they
need
to
be
requested
of
the
responsible
Working
Group—or
in
after
the
absence
end
of
a
Working
Group,
of
the
Team.
Changes
to
the
registry
tables
made
in
accordance
with
candidate
or
proposed
amendments
to
review
period.
If,
after
three
weeks
,
the
registry
definition
which
would
Director
has
not
be
allowed
by
announced
the
unamended
registry
definition
outcome,
the
Director
must
should
be
identified
as
such.
provide
the
Advisory
Committee
with
an
update.
6.5.4.
7.2.
Registry
Data
Reports
Appeal
by
Advisory
Committee
Representatives
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
Advisory
Committee
representatives
that
it
contain.
May
may
contain
informative
introductory
text,
examples,
and
notes
about
the
registry
tables
and
entries
that
it
contains.
(Changes
to
these
parts
appeal
certain
decisions,
though
appeals
are
deemed
only
expected
to
be
editorial
changes
).
Registry
Data
Reports
do
not
have
maturity
stages
occur
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.
extraordinary
circumstances.
Given
When
a
recorded
group
W3C
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
made
following
an
Advisory
Committee
review
,
Advisory
Committee
representatives
may
do
so
instead.
6.5.5.
Specifications
that
Reference
Registries
initiate
an
Advisory
Committee
Appeal
.
These
W3C
decisions
Registries
document
values,
they
do
not
define
any
architectural
or
interoperability
requirements
include
those
related
to
those
values.
All
architectural
group
creation
and
interoperability
requirements
pertaining
to
registry
entries
must
be
contained
in
the
specifications
that
reference
the
registry,
modification,
and
are
therefore
subject
transitions
to
the
processes
(including
approval
new
maturity
levels
for
Recommendation
Track
documents
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.
Process
document.
A
registry
report
or
embedded
registry
Advisory
Committee
representatives
is
not
subject
to
the
W3C
Patent
Policy,
and
must
not
may
define
any
requirements
on
implementations.
For
the
purposes
of
the
Patent
Policy
[PATENT-POLICY]
(only),
any
embedded
registry
in
a
Recommendation
track
also
initiate
an
appeal
for
certain
Director
document
is
not
a
normative
portion
of
's
decisions
that
specification.
6.6.
Switching
Tracks
Given
a
Group
decision
to
do
so,
Working
Groups
can
republish
a
technical
report
on
a
different
track
than
the
one
it
is
on,
under
the
following
restrictions:
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
involve
an
Advisory
Committee
review
.
These
cases
are
identified
in
the
Recommendation
Track
without
due
consideration
of
sections
which
describe
the
Patent
Policy
implications
and
approval
of
W3C’s
legal
counsel
if
requirements
for
the
Working
Group
envisions
a
likelihood
of
returning
to
it
later.
Technical
reports
Director
that
switch
tracks
start
at
their
new
track’s
initial
's
decision
and
include
additional
(non-reviewed)
maturity
stage,
while
retaining
any
established
identity
(url,
shortname,
etc.).
6.7.
Further
reading
Refer
to
"How
to
Organize
a
levels
of
Recommendation
Track
Transition"
[TRANSITION]
in
the
Art
of
Consensus
[GUIDE]
documents,
group
charter
extensions
for
practical
information
about
preparing
for
the
reviews
and
announcements
of
the
various
steps,
closures,
and
tips
on
getting
to
Recommendation
faster
[REC-TIPS]
.
Please
see
also
the
Requirements
for
modification
Memoranda
of
W3C
Technical
Reports
[REPUBLISHING]
Understanding
.
The
Team
In
all
cases,
an
appeal
is
responsible
for
managing
communication
within
W3C
and
with
the
general
public
(e.g.,
news
services,
press
releases,
managing
the
website
and
access
privileges,
and
managing
calendars).
Members
should
must
solicit
review
by
the
Team
prior
to
issuing
press
releases
about
their
work
be
initiated
within
W3C.
three
weeks
of
the
decision.
The
Team
An
Advisory
Committee
representative
makes
every
effort
initiates
an
appeal
by
sending
a
request
to
ensure
the
persistence
Team
.
The
request
should
say
“I
appeal
this
Director’s
Decision”
and
availability
of
identify
the
following
public
information:
W3C
technical
reports
decision.
Within
one
week
the
Team
whose
publication
has
been
approved.
Per
W3C
IPR
Policies
,
W3C
technical
reports
(and
software)
are
available
free
of
charge
must
announce
the
appeal
process
to
the
general
public.
A
mission
statement
[MISSION]
Advisory
Committee
that
explains
the
purpose
and
mission
of
W3C,
the
key
benefits
provide
a
mechanism
for
Members,
and
the
organizational
structure
of
W3C.
Legal
documents,
including
the
Membership
Agreement
[MEMBER-AGREEMENT]
Advisory
Committee
representatives
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
to
respond
with
a
regular
(e.g.,
weekly)
news
service
and
maintains
a
calendar
[CALENDAR]
statement
of
official
W3C
events.
Members
are
encouraged
to
send
schedule
and
event
information
to
the
Team
positive
support
for
inclusion
on
this
calendar.
7.2.
Confidentiality
Levels
appeal.
The
archive
of
these
statements
must
be
member-only
.
If,
within
one
week
There
are
three
principal
levels
of
access
to
W3C
information
(on
the
W3C
website,
in
W3C
meetings,
etc.):
public,
Member-only,
and
Team-only.
While
much
information
made
available
by
W3C
is
public,
“
Member-only
”
information
is
available
to
authorized
parties
only,
including
representatives
Team’s
announcement,
5%
or
more
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
Committee
confidentiality
level
for
group
proceedings.
“
Team-only
”
information
is
available
to
support
the
Team
and
other
authorized
parties.
Those
authorized
to
access
Member-only
and
Team-only
information:
must
treat
appeal
request,
the
information
as
confidential
within
W3C,
must
use
reasonable
efforts
to
preserve
that
confidentiality,
and
Team
must
not
release
this
information
to
the
general
public
or
press,
nor
beyond
organize
an
appeal
vote
asking
the
proper
level
of
access.
The
Team
Advisory
Committee
must
provide
mechanisms
“Do
you
approve
of
the
Director’s
Decision?”
together
with
links
to
protect
the
confidentiality
of
Member-only
Director
information
's
decision
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.
appeal
support.
Advisory
Committee
representatives
The
ballot
may
must
authorize
Member-only
access
to
Member
representatives
allow
for
three
possible
responses:
“Approve”,
“Reject”,
and
other
individuals
employed
by
the
Member
who
are
considered
appropriate
recipients.
For
instance,
it
is
“Abstain”,
together
with
Comments.
If
the
responsibility
number
of
votes
to
reject
exceeds
the
Advisory
Committee
representative
and
other
employees
and
official
representatives
number
of
the
organization
votes
to
ensure
approve,
the
decision
is
overturned.
In
that
Member-only
news
announcements
case,
there
are
distributed
for
internal
use
only
within
their
organization.
Information
about
Member
mailing
lists
is
available
in
the
New
Member
Orientation
[INTRO]
.
following
possible
next
steps:
- The proposal is rejected.
- The proposal is returned for additional work, after which the applicable decision process is re-initiated.
7.3.
Changing
Confidentiality
Level
Advisory
Committee
Votes
As
a
benefit
of
membership,
W3C
provides
some
Team-only
and
Member-only
channels
for
certain
types
of
communication.
For
example,
The
Advisory
Committee
representatives
can
send
reviews
to
a
Team-only
channel.
However,
votes
in
elections
for
W3C
processes
with
a
significant
public
component,
such
as
seats
on
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
TAG
or
Advisory
Board
,
and
in
the
public.
Similarly,
a
Working
Group
whose
proceedings
are
Member-only
event
of
an
Advisory
Committee
Appeal
must
make
public
information
pertinent
to
achieving
the
technical
report
development
process.
This
document
clearly
indicates
which
information
must
be
available
required
support
to
Members
or
trigger
an
appeal
vote.
Whenever
the
public,
even
though
that
information
was
initially
communicated
on
Team-only
Advisory
Committee
votes,
each
Member
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
group
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
related
Members
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
one
vote.
In
the
original
level
case
of
confidentiality,
Advisory
Board
and
without
attribution
to
the
original
author.
TAG
elections
,
“one
vote”
means
“one
vote
per
available
seat”.
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
).
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.
The
W3C
Director
may
negotiate
technical
agreements
a
Memorandum
of
Understanding
with
another
organization.
For
the
purposes
of
the
W3C
Process,
a
technical
agreement
is
a
formal
contract,
or
Process
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
agreements
between
the
Hosts
or
between
Hosts
and
W3C
members
for
the
purposes
of
membership
and
agreements
related
to
the
technical
activity
ordinary
provision
of
services
for
the
Consortium
(e.g.,
its
publications,
groups,
or
liaisons).
It
purposes
of
running
W3C,
that
specifies
rights
and
obligations
of
each
party
toward
the
others.
These
rights
and
obligations
may
include
joint
deliverables,
an
agreed
share
of
technical
responsibilities
with
due
coordination,
and/or
considerations
for
confidentiality
and
specific
IPR.
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”
may
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
(i.e.,
before
Before
signing
the
decision
whether
to
sign
is
made),
MoU,
the
Team
should
must
provide
inform
the
Advisory
Committee
with
a
draft
of
the
proposed
agreement
,
along
with
an
explanation
of
how
W3C
would
benefit
from
signing
this
agreement
,
for
their
review
and
discussion.
After
addressing
any
comments,
and
subject
to
any
management
or
governance
procedures
that
apply
(e.g.,
formal
review
of
proposed
contracts
by
legal
counsel
or
by
the
Board
),
if
the
Team
decides
to
proceed
with
signing
the
agreement
,
the
Team
must
announce
the
intent
to
sign,
sign
and
provide
the
final
text
of
the
agreement
,
with
an
explanation
of
signing
rationale,
to
make
the
MoU
available
for
Advisory
Committee
.
review
;
Advisory
Committee
representatives
may
initiate
an
Advisory
Committee
Appeal
of
the
decision
to
sign
the
agreement
MoU
.
If
Unless
an
appeal
rejects
the
proposal
is
rejected
on
appeal
,
to
sign
an
MoU,
the
Team
Director
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
Team
review,
the
TeamDirector 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 does not imply endorsement by W3C, including the W3C Team or Members. The acknowledgment of a Submission request does not imply that any action will be taken by W3C. It merely records publicly that the Submission request has been made by the Submitter. A Member Submission made available by W3C must not be referred to as “work in progress” of the W3C.
The
list
of
acknowledged
Member
Submissions
[SUBMISSION-LIST]
is
available
at
the
W3C
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 Communication Team’s Publication Rules [PUBRULES] . Submitters may hold the copyright for the material contained in these documents, but when made available by W3C, these documents must be subject to the provisions of the W3C Document License [DOC-LICENSE] .
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 .decision. - What resources, if any, does the Submitter intend to make available if the W3C acknowledges the Submission request and takes action on it?
- What action would the Submitter like W3C to take if the Submission request is acknowledged?
- What mechanisms are there to make changes to the specification being submitted? This includes, but is not limited to, stating where change control will reside if the request is acknowledged.
For other administrative requirements related to Submission requests, see “ How to send a Submission request ” [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
Director
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.
- Make the Team comments about the Submission request available at the W3C website.
If the Submitter (s) wishes to modify a document made available as the result of acknowledgment, the Submitter(s) must start the Submission process from the beginning, even just to correct editorial changes .
10.4. Rejection of a Submission Request, and Submission Appeals
The
Team
Director
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
of
the
same
as
for
Formal
Objections
,
except
that
an
AC
Appeal
Team’s
Decision
to
the
TAG
is
not
possible
and
both
if
the
Formal
Objection
and
reasons
are
related
to
Web
architecture,
or
to
the
Council
Report
Advisory
Board
are
confidential
if
the
request
is
rejected
for
other
reasons.
In
this
case
the
Team
should
make
available
its
rationale
for
the
rejection
to
the
appropriate
body.
The
Team
,
TAG
,
and
AB
will
establish
a
process
for
such
appeals
that
ensures
the
appropriate
level
of
confidentiality
.
11.
Process
Evolution
of
the
Governing
Documents
Revision
of
The
W3C
Governing
Documents
comprise:
the W3C Process (this document)
the W3C Patent Policy [PATENT-POLICY]
the W3C Code of Ethics and
related documents (see below)Professional Conduct [CEPC]
Revision
of
a
W3C
Governing
Document
undergoes
similar
consensus
-building
processes
as
for
technical
reports
,
with
the
Advisory
Board
—acting
—
The
documents
may
be
developed
by
To
help
assure
fitness
for
purpose,
the
AB
or
by
another
group
to
whom
the
AB
has
delegated
development.
Review
includes
soliciting
should
solicit
input
from
the
W3C
community,
and
in
particular
the
Team.
The
documents
covered
by
this
section
are:
the
W3C
Process
(this
document)
the
W3C
Patent
Policy
[PATENT-POLICY]
the
W3C
Code
of
Conduct
[COC]
The
W3C
Document
License
[DOC-LICENSE]
The
Advisory
Board
initiates
review
of
a
W3C
Governing
Document
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 aif there is consensus , the Team enacts the new process officially by announcing the W3C decision toadopt the document(s), the Team does so and sends an announcement tothe Advisory Committee . Advisory Committee representatives may initiate an Advisory Committee Appeal to the W3C.
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
November
2023
1
March
2019
Process
:
This
document
is
based
on
the
3
November
2023
1
March
2019
Process
.
A
list
Disposition
of
issues
addressed
,
a
diff
from
Process
2023
to
this
latest
version
Comments
,
as
well
as
a
detailed
Detailed
log
of
all
changes
since
then
are
available.
The
following
is
a
summary:
-
Converted
the
source
code
of
the
process
to
a numberthe Bikeshed document format, improving the ease ofeditorial adjustmentsmaintenance, andminor teaks,gaining better cross linking capabilities as well as an Index in thefollowingprocess. Note that while this makes no change to the text of the process, it is asummarylarge change of themain differences: Council dismissal vote counts mustsource code, and source level diffs are unlikely to bereported. (See Issue 748of help to compare the before and after state. -
Phrasing
clarifications
and
removal
of
unnecessary
text
in
§ 2.5.1
Advisory
Board
and
Technical
Architecture
Group
Participation
Constraints
)and § 7.1.2 After the Review Period . -
Exclude TAG/AB from votingAvoid using the specialized term “ publish ” to mean anything other than putting documents ontheir own decisions/proposals. (See Issue 749TR. -
Avoid
using
the
specialized
term
“
dissent
)” in situations that do not involve Formal Objections. -
AddRetire the “Team Submissions” ( not “Member Submissions”) mechanism, as it is unused, does not provide the Team with abilities it doesn’t already have, nor provides meaningful governance of the Team’s communications. - Clarify that appeal statements are meant to be member-only.
- Clarify that Working Drafts have some, even if limited, standing.
- Resolve minor wording conflict as to whether charters "should" or "may" include formal voting procedures.
- Delete references to non existing parts of the Patent policy, previously invoked in the TAG participation section.
-
Remove
a
requirementspurious link that made it look like AC-Reps were involved when participants in the TAG or AB resign. -
Add
some
sub-section
headings
to
make progressimprove readability and cross-section linking -
Clarify
the
rule
on
external issues for update requests (See Issue 781vacant seats in § 2.5.2 Advisory Board and Technical Architecture Group Elections) -
Enable TeamEliminate the use of the undefined “minor changes” term - Define and differentiate between Group Decisions and Chair Decisions.
-
Define
that
the
process
to
replace defunct registry custodiansrevise the CEPC and Patent Policy are the same as for revising the Process -
Add
note
clarifying
when
no-one else can. (See Issue 699it is appropriate to use the superseding process, and when not. - Dont require documenting editorial changes since the previous CR.
- Add Note about the flexibility of Consensus.
Changes
since
the
1
February
2018
Process
:
)
This document is based on the 1 February 2018 Process . A Detailed log of all changes since then is available. The following is a summary:
-
Stop citingMention thesupersededexistence of Community Groups and Business Groups in § 1 Introduction . - Change the size of the Advisory Board from a fixed 9 to a range of 9 to 11 elected members in § 2.3.1 Advisory Board Participation , and adjust the election mechanics accordingly in § 2.5.2 Advisory Board and Technical Architecture Group Elections and § 2.5.3 Advisory Board and Technical Architecture Group Vacated Seats .
-
Clarify
that
AB
and
TAG
charter. (See Issue 794members act in their personal capacity in § 2.5 Advisory Board and Technical Architecture Group Participation . -
Improve
phrasing
in
§ 2.5.1
Advisory
Board
and
Technical
Architecture
Group
Participation
Constraints
)to avoid suggesting that while member organizations were limited to one seat, non member organizations could have several. -
Rename “registry sections”Clarify what constitutes “affiliation” for the purposes of the “change of affiliation” provisions for TAG and AB members in § 2.5.2 Advisory Board and Technical Architecture Group Elections . - In case of resignation from a group, require that the team records the resignation notification, in § 3.6 Resignation from a Group .
-
Allow
one
person
to
embedded registriesrepresent (with disclosure) multiple organizations in a Working Group in § 5.2.1 Working Group and Interest Group Participation Requirements . - Various phrasing clarifications to § 6.2.1 Maturity Levels on the Recommendation Track , and § 6.2.3 Advancement on the Recommendation Track , and § 6.2.5 Publishing a First Public Working Draft .
-
Added
new
§ 6.1.6
License
Grants
from
Non-Participants
to
avoid confusion over whether theydefine the requirements for contributions made by non-WG members. -
Clarify
in
§ 6.2.12.3
Abandoning
a
W3C
Recommendation
that
a
Recommendation
can
be
split across multiple sectionsboth superseded and obsolete. -
Add
an
informative
diagram
about
the
process
of
obsoleting,
rescinding,
or
restoring
a
Recommendation
in
§ 6.2.12.3
Abandoning
a
W3C
Recommendation
.
(See Issue 800 ) -
Put constraints onClarify in § 6.2.12.3 Abandoning a W3C Recommendation that thetimingprocess to obsolete, rescind, or restore a Recommendation does not have to be initiated by the Director. -
Rephrase
part
of
making Formal Objections public. (See Issue 735§ 10 Member Submission Process) Rename "Draft Note" into "Note Draft", and "Draft Registry" into "Registry Draft"tobe consistent with other statusesavoid statement about Member Submissions thatusesappeared to negate theword "Draft",possibility of having work originate in Community Groups. - Remove meaningless claim from § 11 Evolution of the Governing Documents that an alternative way to update the Process was to follow the REC track process.
Changes between the 1 March 2017 Process and the 1 February 2018 Process :
A
log
of
all
changes
from
March
2017
to
make
that
word
stand
out
more.
(See
Issue
779
the
1
February
2018
Processs
)
is
available,
as
is
an
earlier
log
of
changes
in
previous
versions,
from
2005-2014
.
The
following
is
a
summary:
- § 2.3.1 Advisory Board Participation
- The AB has a team contact
- § 2.4.1 Technical Architecture Group Participation
-
Tim
Berners-Lee
is
a
Life
Member
of
the
defitionTAG.- The TAG chair must be one of the participants
- The TAG has 6 AC-elected members instead of 5
- The TAG has a
Registry (see Issue 800team contact - The TAG chair must be one of the participants
-
§ 2.5
Advisory
Board
and
Technical
Architecture
Group
Participation
) - Seats on the AB or TAG cannot be delegated to a proxy
-
§ 2.5.3
Advisory
Board
and
of Recommendation Track Documents (see Pull Request 831Technical Architecture Group Vacated Seats). Clarify how -
AB
and
TAG
seats
are
vacated
if
the
outcomeDirector removes a participant, instead ofcertain ballots are determined. (See Issue 836 , Issue 838if the chair asks them to resign- Clarify that a special election can begin if a candidate resigns as of some future date, rather than waiting for that resignation to take effect.
-
§ 3.1
Individual
Participation
Criteria
) Reorganize -
Participants
in
W3C
activity
are
explicitly
required
to
abide
by
the
terms
and
rephrasespirit of the CEPC- The Director can suspend or remove a participant from any Group or activity for failure to meet participation criteria.
-
§ 4.3§ 5.2.3 Advisory Committee Review of a Working Group or Interest Group Charter -
An
AC
member
may
request
at
least
60
days
to
review
any
new
or
substantively
modified
working
group
charter,
with
such
review
period
occurring
between
the
Call
for
Review
and
Approvalthe Call forreadabilityParticipation. -
§ 5.2.6
Working
Group
and
easeInterest Group Charters -
Charters
must
include
documentation
of
understanding. This change, while moderateany voting procedures additional to those defined insize, is purely editorial. (See Pull Request 850 )§ 3.4 Votes . -
§ 6.2.11
Revising
a
W3C
Recommendation
Retire “ Streamlined Publication Approval -
W3C
can
produce
an
Amended
Recommendation
”. This was meanttoenable REC track publication with fewer/faster approval steps when some stricter than usual criteria were fulfilled. However, regular REC track publication have improved enoughupdate a Recommendation, without adding new features, similar to the way a Working Group produces an Edited Recommendation. - § 6.2.12.3 Abandoning a W3C Recommendation
- A Recommendation can be declared Superseded.
- § 7.2 Appeal by Advisory Committee Representatives
-
Clarify
that
this became unnecessary, and nobody was using it. (See Issue 856in the event of an Advisory Committee appeal, a Director’s decision can be overtuned by more votes for than against -
§ 9
Liaisons
) - Definition of MoU and conditions for approval.
Changes
since
earlier
versions
References
Normative References
- [CEPC]
- W3C Code of Ethics and Professional Conduct . URL: https://www.w3.org/Consortium/cepc/
- [COLLABORATORS-AGREEMENT]
- Invited expert and collaborators agreement . URL: https://www.w3.org/Consortium/Legal/collaborators-agreement
- [CONFLICT-POLICY]
- Conflict of Interest Policy for W3C Team Members Engaged in Outside Professional Activities . URL: https://www.w3.org/2000/09/06-conflictpolicy
- [DOC-LICENSE]
- W3C Document License . URL: https://www.w3.org/Consortium/Legal/copyright-documents
- [PATENT-POLICY]
- The W3C Patent Policy . URL: https://www.w3.org/Consortium/Patent-Policy/
- [PUBRULES]
- Publication Rules . URL: https://www.w3.org/pubrules/
- [RFC2119]
- S. Bradner. Key words for use in RFCs to Indicate Requirement Levels . March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
- [RFC3797]
- D. Eastlake 3rd. Publicly Verifiable Nominations Committee (NomCom) Random Selection . June 2004. Informational. URL: https://datatracker.ietf.org/doc/html/rfc3797
Informative References
- [AB-HP]
- The Advisory Board home page . URL: https://www.w3.org/2002/ab/
- [AC-MEETING]
- Advisory Committee meetings (Member-only access) . URL: https://www.w3.org/Member/Meeting/
- [BG-CG]
-
Community
and
Business
Group
Process
are detailed in the changes section of the previous version. URL: https://www.w3.org/community/about/agreements/ - [CALENDAR]
-
Calendar
of
the Process.all scheduled official W3C events . URL: https://www.w3.org/participate/eventscal - [CHAIR]
-
ConformanceW3C Working/Interest Group Chair . URL: https://www.w3.org/Guide/chair/role.html - [CHARTER]
- How to Create a Working Group or Interest Group . URL: https://www.w3.org/Guide/process/charter.html
- [CURRENT-AC]
- Current Advisory Committee representatives (Member-only access) . URL: https://www.w3.org/Member/ACList
- [DISCIPLINARY-GL]
- Guidelines for Disciplinary Action . URL: https://www.w3.org/2002/09/discipline
- [ELECTION-HOWTO]
-
Document conventionsHow to Organize an Advisory Board or TAG election . URL: https://www.w3.org/2002/10/election-howto - [FELLOWS]
- W3C Fellows Program . URL: https://www.w3.org/Consortium/Recruitment/Fellows
- [GROUP-MAIL]
- Group mailing lists (Member-only access) . URL: https://www.w3.org/Member/Groups
- [GUIDE]
-
Conformance requirements are expressed with a combinationThe Art ofdescriptive assertions and RFC 2119 terminology.Consensus . URL: https://www.w3.org/Guide/ - [INTRO]
- Process, Patent Policy, Finances, Specs management, Strategic vision (Member-only access) . URL: https://www.w3.org/Member/Intro
- [JOIN]
- How to Join W3C . URL: https://www.w3.org/Consortium/join
- [LIAISON]
- W3C liaisons with other organizations . URL: https://www.w3.org/2001/11/StdLiaison
- [MEMBER-AGREEMENT]
- W3C Membership Agreement . URL: https://www.w3.org/Consortium/Agreement/Member-Agreement
- [MEMBER-HP]
- Member Web site (Member-only access) . URL: https://www.w3.org/Member/
- [MEMBER-LIST]
-
The
key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative partslist ofthis document arecurrent W3C Members . URL: https://www.w3.org/Consortium/Member/List - [MEMBER-SUB]
-
How
to
be interpreted as described in RFC 2119. However,send a Submission request . URL: https://www.w3.org/2000/09/submission - [MISSION]
- The W3C Mission statement . URL: https://www.w3.org/Consortium/mission
- [OBS-RESC]
- Obsoleting and Rescinding W3C Specifications . URL: https://www.w3.org/2016/11/obsoleting-rescinding/
- [REC-TIPS]
-
Tips
for
readability, these words do not appear in all uppercase letters in this specification. AllGetting to Recommendation Faster . URL: https://www.w3.org/2002/05/rec-tips - [REPUBLISHING]
-
In-place
modification
of
the textW3C Technical Reports . URL: https://www.w3.org/2003/01/republishing/ - [SUBMISSION-LIST]
-
The
list
of
this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]acknowledged Member Submissions . URL: https://www.w3.org/Submission/Examples in this specification are introduced with the words “for example” - [SUBMISSION-REQ]
-
Make
or
are set apart from the normative text with class="example" , like this:Withdraw a Member Submission Request (Member-only access) . URL: https://www.w3.org/2000/09/submission - [TAG-CHARTER]
- Technical Architecture Group (TAG) Charter . URL: https://www.w3.org/2004/10/27-tag-charter.html
- [TAG-HP]
-
The
TAG
home
page
.
URL:
https://www.w3.org/2001/tag/
This is an example - [TEAM-CONTACT]
-
Role
of
an informative example. Informative notes begin withtheword “Note” and are set apart from the normative text with class="note" , like this: Note, this is an informative note.Team Contact . URL: https://www.w3.org/Guide/teamcontact/role.html - [TR]
- The W3C technical reports index . URL: https://www.w3.org/TR/
- [TRANSITION]
- Organize a Technical Report Transition . URL: https://www.w3.org/Guide/transitions
- [TRANSLATION]
- Translations of W3C technical reports . URL: https://www.w3.org/Consortium/Translation/
Index
Terms defined by this specification
-
AB
,
in
§ 3.3.1.1 AB Note , in § 6.4.1§2.3 -
AC
,
in
§ 3.2.1§2.1 -
AC
Appeal
,
in
§ 5.9§7.2 -
AC
representative
,
in
§ 3.2.2§2.1 -
AC
Review
,
in
§ 5.7§7.1.1 -
adequate
implementation
experience
,
in
§ 6.3.2§6.2.2 -
Adopted
Draft
,
in
§ 4.2§5.2.6 -
Advisory
Board
,
in
§ 3.3.1.1§2.3 -
Advisory
Committee
,
in
§ 3.2.1§2.1 -
Advisory
Committee
Appeal
,
in
§ 5.9§7.2 -
Advisory
Committee
representative
,
in
§ 3.2.2§2.1 -
Advisory
Committee
review
,
in
§ 5.7 agreement , in § 9 allow new features , in § 6.3.9 alt AC rep , in § 3.2.2 alternate AC representative , in § 3.2.2§7.1.1 -
alternate Advisory Committee representativeAmended Recommendation , in§ 3.2.2§6.2.1 -
Appeal
,
in
§ 5.9§7.2 -
at
risk
,
in
§ 6.3.7 Board , in § 2.2 Board of Directors , in § 2.2 BoD , in § 2.2§6.2.7 -
Call
for
Review
,
in
§ 5.7.1 candidate addition , in § 6.2.5 candidate amendment , in § 6.2.5 candidate correction , in § 6.2.5§7.1.1 -
Candidate
Recommendation
,
in
§ 6.3.1§6.2.1 -
Candidate
Recommendation
Draft
,
in
§ 6.3.1 Candidate Recommendation review period , in § 6.3.7§6.2.1 -
Candidate
Recommendation
Snapshot
,
in
§ 6.3.1 Candidate Registry , in § 6.5.2 Candidate Registry Draft , in § 6.5.2 Candidate Registry Snapshot , in § 6.5.2§6.2.1 -
CEOChair , in§ 2.2§5.1 -
Chair
Decision
Appeal
,
in
§ 3.4.1§3.5 -
chair decisionsChair Decisions , in§ 5.1§3.5 -
charter
,
in
§ 4.2 chartered groups , in § 3.4§5.2.6 -
charter
extension
,
in
§ 4.5§5.2.5 -
Consensus
,
in
§ 5.2.1 Council , in § 5.6.2 Council Report , in § 5.6.2.7 Council Team Contact , in § 5.6.2.1§3.3 -
CR
,
in
§ 6.3.1 CRD , in § 6.3.1 CRS , in § 6.3.1 custodian , in § 6.5.1 Discontinued Draft , in § 6.3.1 dismiss , in § 5.6.2.3 dismissal , in § 5.6.2.3§6.2.1 -
dismissedDirector , in§ 5.6.2.3§2.2 -
Dissent
,
in
§ 5.2.1§3.3 -
distributed
meeting
,
in
§ 3.1.2§3.2 -
ED
,
in
§ 6.3.1 Editor Draft , in § 6.3.1§6.2.1 -
editorial changeEdited Recommendation , in§ 6.2.3§6.2.1 -
Editor'sEditor Draft , in§ 6.3.1§6.2.1 -
elected groupseditorial changes , in§ 3.3§6.1.3 -
embedded registryEditor’s Draft , in§ 6.5.2§6.2.1 -
errata
,
in
§ 6.2.4§6.1.4 -
erratum
,
in
§ 6.2.4§6.1.4 -
Exclusion
Draft
,
in
§ 4.2§5.2.6 -
Exclusion Draft CharterExpandable Recommendation , in§ 4.2§6.2.1 - Extensible REC , in §6.2.1
-
face-to-face
meeting
,
in
§ 3.1.2§3.2 -
First
Public
Working
Draft
,
in
§ 6.3.1§6.2.1 -
formally
addressed
,
in
§ 5.3§3.3.3 -
Formal
Objection
,
in
§ 5.5§3.3.2 -
fully addressedGroup Decision Appeal , in§ 5.6.2.6§3.5 -
groupGroup Decisions , in§ 3§3.5 -
group decisionHost institutions , in§ 5.1§2.2 - Hosts , in §2.2
-
GroupIG Note , in§ 6.4.1§6.3 -
Interest
Group
Note
,
in
§ 6.4.1§6.3 -
Interest
Groups
,
in
§ 3.4§5.2 -
Invited
Expert
in
an
Interest
Group
,
in
§ 3.4.3.4§5.2.1.4 -
Invited
Expert
in
a
Working
Group
,
in
§ 3.4.3.3§5.2.1.3 -
Last
Call
for
Review
of
Proposed
Additions
,
in
§ 6.3.11.5§6.2.11.5 -
Last
Call
for
Review
of
Proposed
AmendmentsChanges , in§ 6.3.11.5§6.2.11.5 -
Last
Call
for
Review
of
Proposed
Corrections
,
in
§ 6.3.11.5§6.2.11.5 -
Last
Call
for
Review
of
Proposed
Corrections
and
Additions
,
in
§ 6.3.11.5§6.2.11.5 -
liaison
,
in
§ 9 Member , in § 2.1§9 -
Member
AssociationConsortia , in§ 2.1.2.1§2.1.2.1 -
Member
AssociationsConsortium , in§ 2.1.2.1§2.1.2.1 -
Member-Only
,
in
§ 7.2§4.1 -
Member
representative
in
an
Interest
Group
,
in
§ 3.4.3.2§5.2.1.2 -
Member
representative
in
a
Working
Group
,
in
§ 3.4.3.1§5.2.1.1 -
Member
Submission
,
in
§ 10§10 -
Minority OpinionMemoranda of Understanding , in§ 5.6.2.6§9 -
minutesMemorandum of Understanding , in§ 3.1.2.2§9 -
NoteMoU , in§ 6.4.1§9 -
Note
Draft, in§ 6.4.1§6.3 -
not
required
,
in
§ Unnumbered§Unnumbered section -
Obsolete
Recommendation
,
in
§ 6.3.1 Obsolete Registry , in § 6.5.2 overrule , in § 5.6.2.6§6.2.1 -
participantOther Charter , in§ 3§5.2.6 -
participants
in
an
Interest
Group
,
in
§ 3.4.2§5.2.1 -
participants
in
a
Working
Group
,
in
§ 3.4.2§5.2.1 -
participate
in
a
Working
Group
as
an
Invited
Expert
,
in
§ 3.4.3.3§5.2.1.3 -
Patent
Review
Drafts
,
in
§ 6.3§6.2 -
PR
,
in
§ 6.3.1§6.2.1 -
primary
affiliation
,
in
§ 3.3.3.3§2.5.2 -
proposed
additionsaddition , in§ 6.3.11.5§6.1.5 -
proposed
amendmentschange , in§ 6.3.11.5§6.1.5 -
proposed
correctionscorrection , in§ 6.3.11.5§6.1.5 - Proposed Expandable Recommendation , in §6.2.1
-
Proposed
Recommendation
,
in
§ 6.3.1§6.2.1 -
proxy
,
in
§ 5.2.3§3.4 -
public
participants
,
in
§ 3.4.2§5.2.1 -
publish
,
in
§ 6.2.1§6.1 -
REC
,
in
§ 6.3.1§6.2.1 -
Recommendation
,
in
§ 6.3.1§6.2.1 -
Recommendation
Track
,
in
§ 6.3§6.2 -
Recommendation-track , in § 6.3 RecommendationREC Trackdocument, in§ 6.3§6.2 -
Recommendation-track documentRelated Member , in§ 6.3§2.1.2.2 -
REC TrackRescinded Candidate Recommendation , in§ 6.3§6.2.1 -
REC Track documentRescinded Recommendation , in§ 6.3§6.2.1 -
registrysubmitter , in§ 6.5§10 -
registry changesubsidiary , in§ 6.2.3§2.1.2.2 -
registry datasubstantive changes , in§ 6.5§6.1.3 -
Registry Data Reportsubstitute , in§ 6.5.4§5.2.1 -
registry definitionSuperseded Recommendation , in§ 6.5.1§6.2.1 -
Registry DraftSymposia , in§ 6.5.2§8 -
registry entrySymposium , in§ 6.5§8 -
registry reportTAG , in§ 6.5.2§2.4 -
registry tableTeam , in§ 6.5§2.2 -
Registry TrackTeam Contact , in§ 6.5.2§5.1 -
Related MemberTeam-Only , in§ 2.1.2.2§4.1 -
renounceTeam representative in an Interest Group , in§ 5.6.2.3§5.2.1.6 -
renunciationTeam representative in a Working Group , in§ 5.6.2.3§5.2.1.5 -
Rescinded Candidate RecommendationTechnical Architecture Group , in§ 6.3.1§2.4 -
Rescinded RecommendationTechnical Report , in§ 6.3.1§6.1 -
resolutionTransition Requests , in§ 5.1§6.2.3 -
StatementUnanimity , in§ 6.4.3§3.3 -
Submission AppealsUpdate Requests , in§ 10.4§6.2.4 -
submittervalidation notice , in§ 10§10.2 -
subsidiaryW3C Candidate Recommendation , in§ 2.1.2.2§6.2.1 -
substantive changeW3C decision , in§ 6.2.3§7 -
substituteW3C Director , in§ 3.4.2§2.2 -
SupersededW3C Expandable Recommendation , in§ 6.3.1§6.2.1 -
Superseded RegistryW3C Fellows , in§ 6.5.2§2.2 -
Supplemental Confidential Council ReportW3C Governing Documents , in§ 5.6.2.7§11 -
SymposiaW3C Note , in§ 8§6.3 -
SymposiumW3C Proposed Recommendation , in§ 8§6.2.1 -
TAGW3C Recommendation , in§ 3.3.2.1§6.2.1 -
TAG NoteW3C Recommendation Track , in§ 6.4.1§6.2 -
W3C
Team
,
in
§ 2.2§2.2 -
Team ContactW3C Working Draft , in§ 3.4.1§6.2.1 -
Team correctionWD , in§ 6.2.5§6.2.1 -
Team DecisionWG Note , in§ 5.1§6.3 -
Team-Onlywide review , in§ 7.2§6.1.2.1 -
Team representative in an Interest GroupWorking Draft , in§ 3.4.3.6§6.2.1 -
Team representative in aWorking Group Note , in§ 3.4.3.5§6.3 -
Team's DecisionWorking Groups , in§ 5.1§5.2 -
technical agreementWorkshops , in§ 9§8