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 the 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
standardizes
a
Web
technology.
In
many
cases,
the
goal
initiates
standardization
of
this
work
is
a
W3C
Recommendation
—
a
Web
standard.
technology:
-
People
generate
interest
in
a
particular
topic.
For
instance,
Members
express
interest
by
developing
proposals
in
Community
Groups
or
proposing
ideas
in
the form ofMember Submissions, and. Also, the Team monitors work inside and outside of W3C for signs ofinterest. Also, W3C is likely tointerest, and helps organizeaWorkshopWorkshops to bring people together to discuss topics that interest the W3C community. -
When
there
is
enough
interest
in a topic (e.g., after a successful Workshop and/or discussion onand anAdvisory Committee mailing list ),engaged community, theDirector announcesTeam works with thedevelopment of a proposal for one or more newMembership to draft proposed Interest Group or Working Group charters, depending on the breadth of the topic of interest.. W3C Members review the proposedcharters. Whencharters, and when there is support within W3C for investing resources in the topic of interest, theDirectorW3C 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 .
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
Further
sections
of
the
this
Process
Document:
set
forth
policies
for
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
Document
deal
with
topics
including
liaisons
(
§ 9
Liaisons
(as
represented
by
the
W3C
Advisory
Committee
),
confidentiality
(
§ 7
Dissemination
Policies
),
the
Team,
and
the
general
public.
The
W3C
also
operates
Community
formal
decisions
and
Business
Groups,
which
are
separately
described
in
their
own
process
document
appeals
(
§ 5
Decisions
[BG-CG]
.
).
2.
Members,
Advisory
Committee,
Team,
Advisory
Board,
Technical
Architecture
Group
Members
and
the
Team
W3C’s mission is to lead the Web to its full potential. W3C Member organizations provide resources to this end, and the W3C Team provides the technical leadership and organization to coordinate the effort.
2.1. Members
W3C
Members
are
organizations
subscribed
according
to
the
Membership
Agreement
[MEMBER-AGREEMENT]
.
They
are
primarily
represented
in
W3C
processes
as
follows:
-
The Advisory Committee is composed of oneOne representativefrom eachper Member organization(refer toparticiaptes in theMember-only list of current Advisory Committee representatives . [CURRENT-AC] ) The Advisory Committee: reviews plans for W3C at eachAdvisory Committeemeeting ; reviews formal proposals from the W3C Director: Charter Proposals , Proposed Recommendations , and Proposed Process Documents . elects the Advisory Boardparticipants other thanwhich oversees theAdvisory Board Chair. elects a majority (6)work of theparticipants on the Technical Architecture Group . Advisory Committee representatives may initiate an Advisory Committee Appeal in some cases described in this document.W3C. -
Representatives
of
Member
organizations
participate
in
Working
Groups
and
Interest
Groups
and, where they author and review technical reports .
W3C
membership
is
open
to
all
entities,
as
described
in
“
How
to
Join
W3C
”
[JOIN]
;
(refer
to
the
public
list
of
current
W3C
Members
[MEMBER-LIST]
).
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.
The
vast
majority
of
W3C
Members
faithfully
follow
the
spirit
as
well
as
the
letter
of
these
processes.
When
serious
and/or
repeated
violations
do
occur,
and
repeated
attempts
to
address
these
violations
have
not
resolved
the
situation,
the
Director
may
take
disciplinary
action.
Arbitration
Disciplinary
action
for
anyone
participating
in
the
case
of
further
disagreement
W3C
activities
is
governed
by
paragraph
19
of
the
Membership
Agreement
[MEMBER-AGREEMENT]
described
in
§ 3.1.1.1
Expectations
and
Discipline
.
Refer
to
the
Guidelines
Additional
information
for
Disciplinary
Action
Members
is
available
at
the
Member
Web
site
[DISCIPLINARY-GL]
[MEMBER-HP]
.
2.1.2. Member Consortia and Related Members
2.1.2.1. Membership Consortia
A “ Member Consortium ” means a consortium, user society, or association of two or more individuals, companies, organizations or governments, or any combination of these entities which has the purpose of participating in a common activity or pooling resources to achieve a common goal other than participation in, or achieving certain goals in, W3C. A joint-stock corporation or similar entity is not a Member Consortium merely because it has shareholders or stockholders. If it is not clear whether a prospective Member qualifies as a Member Consortium , the Director may reasonably make the determination. For a Member Consortium , the rights and privileges of W3C Membership described in the W3C Process Document extend to the Member Consortium 's paid staff and Advisory Committee representative.
Member Consortia may also designate up to four (or more at the Team’s discretion) individuals who, though not employed by the organization, may exercise the rights of Member representatives .
For Member Consortia that have individual people as members, these individuals must disclose their employment affiliation when participating in W3C work. Provisions for related Members apply. Furthermore, these individuals must represent the broad interests of the W3C Member organization and not the particular interests of their employers.
For Member 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 Consortium, IPR commitments are made on behalf of the Member Consortium, unless a further IPR commitment is made by the individuals' employers.
2.1.2.2. Related Members
In the interest of ensuring the integrity of the consensus process, Member involvement in some of the processes in this document is affected by related Member status. As used herein, two Members are related if:
- Either Member is a subsidiary of the other, or
- Both Members are subsidiaries of a common entity, or
- The Members have an employment contract or consulting contract that affects W3C participation.
A subsidiary is an organization of which effective control and/or majority ownership rests with another, single organization.
Related Members must disclose these relationships according to the mechanisms described in the New Member Orientation [INTRO] .
2.1.3.
2.2.
The
W3C
Team
The Team consists of the Director, CEO , W3C paid staff, unpaid interns, and W3C Fellows. W3C Fellows are Member employees working as part of the Team; see the W3C Fellows Program [FELLOWS] . The Team provides technical leadership about Web technologies, organizes and manages W3C activities to reach goals within practical constraints (such as resources available), and communicates with the Members and the public about the Web and W3C technologies.
The Director and CEO may delegate responsibility (generally to other individuals in the Team) for any of their roles described in this document, except participation in the TAG .
Team Decisions derive from the Director and CEO 's authority, even when they are carried out by other members of the Team .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 .
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. Groups and Participation
For the purposes of this Process, a W3C Group is one of W3C’s Working Groups , Interest Groups , Advisory Committee , Advisory Board , or TAG , and a participant is a member of such a group.
3.1. Policies for Participation in W3C Groups
3.1.1. Individual Participation Criteria
3.1.1.1. Expectations and Discipline
There are three qualities an individual is expected to demonstrate in order to participate in W3C:
- Technical competence in one’s role;
- The ability to act fairly;
- Social competence in one’s role.
Advisory Committee representatives who nominate individuals from their organization for participation in W3C activities are responsible for assessing and attesting to the qualities of those nominees.
Participants in any W3C activity must abide by the terms and spirit of the W3C Code of Ethics and Professional Conduct [CEPC] and the participation requirements described in “Disclosure” in the W3C Patent Policy [PATENT-POLICY] .
The Director may take disciplinary action, including suspending or removing for cause a participant in any group (including the AB and TAG ) if serious and/or repeated violations, such as failure to meet the requirements on individual behavior of (a) this process and in particular the CEPC, or (b) the membership agreement, or (c) applicable laws, occur. Refer to the Guidelines to suspend or remove participants from groups .
3.1.1.2. Conflict of Interest Policy
Individuals participating materially in W3C work must disclose significant relationships when those relationships might reasonably be perceived as creating a conflict of interest with the individual’s role at W3C. These disclosures must be kept up-to-date as the individual’s affiliations change and W3C membership evolves (since, for example, the individual might have a relationship with an organization that joins or leaves W3C). Each section in this document that describes a W3C group provides more detail about the disclosure mechanisms for that group.
The ability of an individual to fulfill a role within a group without risking a conflict of interest depends on the individual’s affiliations. When these affiliations change, the individual’s assignment to the role must be evaluated. The role may be reassigned according to the appropriate process. For instance, the 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.1.3. Individuals Representing a Member Organization
Generally, individuals representing a Member in an official capacity within W3C are employees of the Member organization. However, an Advisory Committee representative may designate a non-employee to represent the Member. Non-employee Member representatives must disclose relevant affiliations to the Team and to any group in which the individual participates.
In exceptional circumstances (e.g., situations that might jeopardize the progress of a group or create a conflict of interest ), the 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.1.2. Meetings
The requirements in this section apply to the official meetings of any W3C group .
W3C distinguishes two types of meetings:
- A face-to-face meeting is one where most of the attendees are expected to participate in the same physical location.
- A distributed meeting is one where most of the attendees are expected to participate from remote locations (e.g., by telephone, video conferencing, or IRC ).
A Chair may invite an individual with a particular expertise to attend a meeting on an exceptional basis. This person is a meeting guest, not a group participant . Meeting guests do not have voting rights . It is the responsibility of the Chair to ensure that all meeting guests respect the chartered level of confidentiality and other group requirements.
3.1.2.1. Meeting Scheduling and Announcements
Meeting announcements should be sent to all appropriate group mailing lists, i.e. those most relevant to the anticipated meeting participants.
The following table lists recommendations for organizing a meeting:
Face-to-face meetings | Distributed meetings | |
---|---|---|
Meeting announcement (before) | eight weeks * | one week * |
Agenda available (before) | two weeks | 24 hours (or longer if a meeting is scheduled after a weekend or holiday) |
Participation confirmed (before) | three days | 24 hours |
Action items available (after) | three days | 24 hours |
Minutes available (after) | two weeks | 48 hours |
* To allow proper planning (e.g., travel arrangements), the Chair is responsible for giving sufficient advance notice about the date and location of a meeting. Shorter notice for a meeting is allowed provided that there are no objections from group participants.
3.1.2.2. Meeting Minutes
Groups should take and retain minutes of their meetings, and must record any official group decisions made during the meeting discussions. Details of the discussion leading to such decisions are not required, provided that the rationale for the group decision is nonetheless clear.
3.1.2.3. Meeting Recordings and Transcripts
No-one may take an audio or video recording of a meeting, or retain an automated transcript, unless the intent is announced at the start of the meeting, and no-one participating in the recorded portion of the meeting withholds consent. If consent is withheld by anyone, recording/retention must not occur. The announcement must cover: (a) who will have access to the recording or transcript and (b) the purpose/use of it and (c) how it will be retained (e.g. privately, in a cloud service) and for how long.
3.1.3. Tooling for Discussions and Publications
For W3C Groups operating under this Process, a core operating principle is to allow access across disabilities, across country borders, and across time. Thus in order to allow all would-be participants to effectively participate, to allow future participants and observers to understand the rationale and origins of current decisions, and to guarantee long-lived access to its publications, W3C requires that:
- All reports, publications, or other deliverables produced by the group for public consumption (i.e. intended for use or reference outside its own membership) should be published and promoted at a W3C-controlled URL, and backed up by W3C systems such that if the underlying service is discontinued, W3C can continue to serve such content without breaking incoming links or other key functionality.
- All reports, publications, or other deliverables produced by the group for public consumption should follow best practices for internationalization and for accessibility to people with disabilities. Network access to W3C-controlled domains may be assumed.
-
Official
meeting
minutes
and
other
records
of
decisions
made
must
be
archived
by
W3C
for
future
reference;
and
other
persistent
text-based
discussions
sponsored
by
the
group,
pertaining
to
their
work
and
intended
to
be
referenceable
by
all
group
members
should
be.
This
includes
discussions
conducted
over
email
lists
or
in
issue-tracking
services
or
any
equivalent
fora.
Note: The lack, or loss, of such archives does not by itself invalidate an otherwise-valid decision.
-
Any
tooling
used
by
the
group
for
producing
its
documentation
and
deliverables
or
for
official
group
discussions
should
be
usable
(without
additional
cost)
by
all
who
wish
to
participate,
including
people
with
disabilities,
to
allow
their
effective
participation.
Note: If a new participant joins who cannot use the tool, this can require the Working Group to change its tooling or operate some workaround.
- All tools and archives used by the group for its discussions and recordkeeping should be documented such that new participants and observers can easily find the group’s tools and records.
The Team is responsible for ensuring adherence to these rules and for bringing any group not in compliance into compliance.
3.1.4. Resignation from a Group
A W3C Member or Invited Expert may resign from a group. On written notification from an Advisory Committee representative or Invited Expert to the team, the Member and their representatives or the Invited Expert will be deemed to have resigned from the relevant group. The team must record the notification. See “Exclusion and Resignation from the Working Group” in the W3C Patent Policy [PATENT-POLICY] for information about obligations remaining after resignation from certain groups.
3.2. The Advisory Committee (AC)
3.2.1. Role of the Advisory Committee
The Advisory Committee represents the Members of the W3C at large. It is responsible for:
- reviewing plans for W3C at each Advisory Committee meeting .
- reviewing formal proposals of the W3C: Charter Proposals , Proposed Recommendations , and Proposed Process Documents .
- electing the Advisory Board participants other than the Advisory Board Chair.
- electing a majority (6) of the participants on the Technical Architecture Group .
Advisory Committee representatives may initiate an Advisory Committee Appeal of a W3C decision or Director 's decision.
See also the additional roles of Advisory Committee representatives described in the W3C Patent Policy [PATENT-POLICY] .
3.2.2. Participation in the Advisory Committee
The Advisory Committee is composed of one representative from each Member organization (refer to the Member-only list of current Advisory Committee representatives . [CURRENT-AC] )
When
an
organization
joins
W3C
(see
“
How
to
Join
W3C
”
[JOIN]
),
it
must
name
its
Advisory
Committee
representative
as
part
of
the
Membership
Agreement.
The
New
Member
Orientation
[INTRO]
explains
how
to
subscribe
or
unsubscribe
to
Advisory
Committee
mailing
lists,
provides
information
about
Advisory
Committee
Meetings
,
explains
how
to
name
a
new
Advisory
Committee
representative
,
and
more.
Advisory
Committee
representatives
must
follow
the
conflict
of
interest
policy
by
disclosing
information
according
to
the
mechanisms
described
in
the
New
Member
Orientation.
See
also
the
additional
roles
of
Advisory
Committee
representatives
described
in
the
W3C
Patent
Policy
[PATENT-POLICY]
.
Additional
information
for
Members
is
available
at
The
AC
representative
may
delegate
any
of
their
rights
and
responsibilities
to
an
alternate
(except
the
Member
Web
site
[MEMBER-HP]
.
ability
to
designate
an
alternate).
2.1.3.1.
3.2.3.
Advisory
Committee
Mailing
Lists
The Team must provide two mailing lists for use by the Advisory Committee :
- One for official announcements (e.g., those required by this document) from the Team to the Advisory Committee . This list is read-only for Advisory Committee representatives.
- One for discussion among Advisory Committee representatives . Though this list is primarily for Advisory Committee representatives, the Team must monitor discussion and should participate in discussion when appropriate. Ongoing detailed discussions should be moved to other appropriate lists (new or existing, such as a mailing list created for a Workshop ).
An Advisory Committee representative may request that additional individuals from their organization be subscribed to these lists. Failure to contain distribution internally may result in suspension of additional email addresses, at the discretion of the Team.
2.1.3.2.
3.2.4.
Advisory
Committee
Meetings
The Team organizes a face-to-face meeting for the Advisory Committee twice a year . The Team appoints the Chair of these meetings (generally the CEO). At each Advisory Committee meeting, the Team should provide an update to the Advisory Committee about:
- Resources
-
- The number of W3C Members at each level.
- An overview of the financial status of W3C.
- Allocations
-
- The allocation of the annual budget, including size of the Team and their approximate deployment.
- A list of all activities (including but not limited to Working and Interest Groups) and brief status statement about each, in particular those started or terminated since the previous Advisory Committee meeting.
- The allocation of resources to pursuing liaisons with other organizations.
Each Member organization should send one representative to each Advisory Committee Meeting. In exceptional circumstances (e.g., during a period of transition between representatives from an organization), the meeting Chair may allow a Member organization to send two representatives to a meeting.
The Team must announce the date and location of each Advisory Committee meeting no later than at the end of the previous meeting; one year’s notice is preferred. The Team must announce the region of each Advisory Committee meeting at least one year in advance.
More information about Advisory Committee meetings [AC-MEETING] is available at the Member Web site.
2.2.
3.3.
Elected
Groups:
The
W3C
Team
AB
and
the
TAG
The
Team
consists
of
the
Director,
CEO,
W3C
paid
staff,
unpaid
interns,
and
W3C
Fellows.
W3C
Fellows
are
Member
employees
working
as
part
Process
defines
two
types
of
the
Team;
see
the
W3C
Fellows
Program
[FELLOWS]
.
The
Team
provides
technical
leadership
about
Web
technologies,
organizes
and
manages
W3C
activities
to
reach
goals
within
practical
constraints
(such
as
resources
available),
and
communicates
with
the
Members
and
the
public
about
the
Web
and
W3C
technologies.
The
Director
elected
groups
and
CEO
may
delegate
responsibility
(generally
to
other
individuals
in
the
Team)
for
any
of
their
roles
described
in
this
document,
except
participation
in
the
TAG
.
The
Director
is
:
the
lead
technical
architect
at
W3C,
whose
responsibilities
are
identified
throughout
this
document
in
relevant
places.
Some
key
ones
include:
assessing
consensus
Advisory
Board
within
W3C
for
architectural
choices,
publication
of
technical
reports
,
and
chartering
new
Groups;
appointing
group
Chairs
,
adjudicating
as
"tie-breaker"
for
Group
decision
appeals
,
(AB)
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
Technical
Architecture
Group
(TAG),
both
elected
by
the
Host
institutions
Advisory
Committee
.
Note:
3.3.1.
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
Advisory
Board
(AB)
themselves
are
not
W3C
Members.
2.3.
3.3.1.1.
Role
of
the
Advisory
Board
(AB)
Created
in
March
1998,
the
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
.
The
Advisory
Board
hears
a
Submission
Appeal
when
a
Member
Submission
is
rejected
for
reasons
unrelated
to
Web
architecture;
see
also
the
TAG
.
The Advisory Board is not a board of directors and has no decision-making authority within W3C; its role is strictly advisory.
The
Team
must
make
available
a
mailing
list,
confidential
to
the
Advisory
Board
and
Team,
for
the
Advisory
Board
to
use
for
its
communication.
The
Advisory
Board
should
send
a
summary
of
each
of
its
meetings
to
the
Advisory
Committee
and
other
group
Chairs.
The
Advisory
Board
should
also
report
on
its
activities
at
each
Advisory
Committee
meeting
.
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]
.
2.3.1.
3.3.1.2.
Composition
of
the
Advisory
Board
Participation
The
Advisory
Board
consists
of
nine
to
eleven
elected
participants
and
a
Chair.
The
one
Chair
(who
may
be
one
of
the
elected
participants).
With
the
input
of
the
AB
,
the
Team
appoints
the
Chair
Chair,
who
should
choose
a
co-chair
among
the
elected
participants.
The
Chair(s)
are
subject
to
ratification
by
secret
ballot
by
two
thirds
of
the
Advisory
Board
,
who
is
generally
AB
upon
appointment
and
at
the
CEO.
start
of
each
AB
term.
The
team
also
appoints
a
Team
Contact
for
the
AB
,
as
described
in
§ 5.1
§ 3.4.1
Requirements
for
All
Working
and
Interest
Chartered
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
.
With
the
exception
of
the
Chair,
the
The
terms
of
all
elected
Advisory
Board
participants
are
for
two
years
.
Terms
are
staggered
so
that
each
year,
either
five
or
six
terms
expire.
If
an
individual
is
elected
to
fill
an
incomplete
term,
that
individual’s
term
ends
at
the
normal
expiration
date
of
that
term.
Regular
Advisory
Board
terms
begin
on
1
July
and
end
on
30
June.
2.4.
3.3.1.3.
Communications
of
the
Advisory
Board
The Team must make available a mailing list, confidential to the Advisory Board and Team, for the Advisory Board to use for its communication.
The Advisory Board should send a summary of each of its meetings to the Advisory Committee and other group Chairs. The Advisory Board should also report on its activities at each Advisory Committee meeting .
3.3.2.
Technical
Architecture
Group
(TAG)
Created
in
February
2001,
3.3.2.1. Role of the Technical Architecture Group
The mission of the TAG is stewardship of the Web architecture. There are three aspects to this mission:
- to document and build consensus around principles of Web architecture and to interpret and clarify these principles when necessary;
- to resolve issues involving general Web architecture brought to the TAG;
- to help coordinate cross-technology architecture developments inside and outside W3C.
The TAG hears a Submission Appeal 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.
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] .
2.4.1.
3.3.2.2.
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 Director ;
- Six participants elected by the Advisory Committee following the AB/TAG nomination and election process .
The
Team
appoints
the
Chair
of
the
TAG,
who
must
be
one
of
the
participants.
The
team
also
appoints
a
Team
Contact
[TEAM-CONTACT]
for
the
TAG,
as
described
in
§ 5.1
§ 3.4.1
Requirements
for
All
Working
and
Interest
Chartered
Groups
.
The terms of elected and Director-appointed TAG participants are for two years . Terms are staggered so that each year three elected terms, and either one or two appointed terms expire. If an individual is appointed or elected to fill an incomplete term, that individual’s term ends at the normal expiration date of that term. Regular TAG terms begin on 1 February and end on 31 January.
The Director may announce the appointed participants after the results for the Advisory Committee election of participants have been announced.
2.5.
3.3.2.3.
Advisory
Board
and
Communications
of
the
Technical
Architecture
Group
The Team must make available two mailing lists for the TAG:
- a public discussion (not just input) list for issues of Web architecture. The TAG will conduct its public business on this list.
- a Member-only list for discussions within the TAG and for requests to the TAG that, for whatever reason, cannot be made on the public list.
The TAG may also request the creation of additional topic-specific, public mailing lists. For some TAG discussions (e.g., a Submission Appeal ), the TAG may use a list that will be Member-only .
The TAG should send a summary of each of its meetings to the Advisory Committee and other group Chairs. The TAG should also report on its activities at each Advisory Committee meeting .
3.3.3. Participation in Elected Groups
3.3.3.1. Expectations for Elected Groups Participants
Advisory Board and TAG participants have a special role within W3C: they are elected by the Membership and appointed by the 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.
2.5.1.
3.3.3.2.
Advisory
Board
and
Technical
Architecture
Group
Elected
Groups
Participation
Constraints
Given the few seats available on the Advisory Board and the TAG , and in order to ensure that the diversity of W3C Members is represented:
-
Two
participants
with
the
same
primary
affiliation
per
§ 2.5.2§ 3.3.3.3 Advisory Board and Technical Architecture Group Elections must not both occupy elected seats on the TAG except when this is caused by a change of affiliation of an existing participant. At the completion of the next regularly scheduled election for the TAG, the organization must have returned to having at most one seat. -
Two
participants
with
the
same
primary
affiliation
per
§ 2.5.2§ 3.3.3.3 Advisory Board and Technical Architecture Group Elections must not both occupy elected seats on the AB. If, for whatever reason, these constraints are not satisfied (e.g., because an AB participant changes jobs), one participant must cease AB participation until the situation has been resolved. If after 30 days the situation has not been resolved, the Chair will apply the verifiable random selection procedure described below to choose one person for continued participation and declare the other seat(s) vacant. - An individual must not participate on both the TAG and the AB.
2.5.2.
3.3.3.3.
Advisory
Board
and
Technical
Architecture
Group
Elections
The
Advisory
Board
and
a
portion
of
the
Technical
Architecture
Group
are
elected
by
the
Advisory
Committee
,
using
a
Single
Transferable
Vote
system.
An
election
begins
when
the
Team
sends
a
Call
for
Nominations
to
the
Advisory
Committee.
Any
Call
for
Nominations
specifies
the
minimum
and
maximum
number
of
available
seats,
the
deadline
for
nominations,
details
about
the
specific
vote
tabulation
system
selected
by
the
Team
for
the
election,
and
operational
information
such
as
how
to
nominate
a
candidate.
The
Team
may
modify
the
tabulation
system
after
the
Call
for
Nominations
but
must
stabilize
it
no
later
than
the
Call
for
Votes.
The
Director
Team
should
announce
appointments
no
later
than
the
start
of
a
nomination
period
as
part
of
the
Call
for
Nominations.
In the case of regularly scheduled elections of the TAG , the minimum and maximum number of available seats are the same: the 3 seats of the terms expiring that year, plus the number of other seats that are vacant or will be vacant by the time the newly elected members take their seats.
In the case of regularly scheduled elections of the AB , the minimum and maximum number of available seats differ: The maximum number is the 5 or 6 seats of the terms expiring that year, plus the number of other seats that are vacant or will be vacant by the time the newly elected members take their seats; the minimum number is such that when added to the occupied seats from the prior year, the minimum size of the AB (9) is reached.
Each Member (or group of related Members ) may nominate one individual. A nomination must be made with the consent of the nominee. In order for an individual to be nominated as a Member representative, the individual must qualify for Member representation and the Member’s Advisory Committee representative must include in the nomination the (same) information required for a Member representative in a Working Group . In order for an individual to be nominated as an Invited Expert, the individual must provide the (same) information required for an Invited Expert in a Working Group and the nominating Advisory Committee representative must include that information in the nomination. In order for an individual to be nominated as a Team representative, the nominating Advisory Committee representative must first secure approval from Team management. A nominee is not required to be an employee of a Member organization, and may be a W3C Fellow . The nomination form must ask for the nominee’s primary affiliation , and this will be reported on the ballot. For most nominees, the primary affiliation is their employer and will match their affiliation in the W3C database. For contractors and invited experts, this will normally be their contracting company or their invited expert status; in some cases (e.g. where a consultant is consulting for only one organization) this may be the organization for whom the nominee is consulting. A change of affiliation is defined such that this field would carry a different answer if the nominee were to be re-nominated (therefore, terminating employment, or accepting new employment, are changes of affiliation). (Other formal relationships such as other contracts should be disclosed as potential conflicts of interest.) Each nomination should include a few informative paragraphs about the nominee.
If, after the deadline for nominations, the number of nominees is:
-
Greater
than
or
equal
to
the
minimum
number
of
available
seats
and
less
than
or
equal
to
the
maximum
number
of
available
seats,
those
nominees
are
thereby
elected.
This
situation
constitutes
a
tie
for
the
purpose
of
assigning
shortincomplete terms . Furthermore, if the number is less than the maximum number of available seats, the longest terms are filled first. - Less than the minimum number of available seats, Calls for Nominations are issued until a sufficient number of people have been nominated. Those already nominated do not need to be renominated after a renewed call.
- Greater than the maximum number of available seats, the Team issues a Call for Votes that includes the names of all candidates, the (maximum) number of available seats, the deadline for votes, details about the vote tabulation system selected by the Team for the election, and operational information.
When there is a vote, each Member (or group of related Members ) may submit one ballot that ranks candidates in the Member’s preferred order. Once the deadline for votes has passed, the Team announces the results to the Advisory Committee . In case of a tie the verifiable random selection procedure described below will be used to fill the available seats.
The
shortest
incomplete
term
is
assigned
to
the
elected
candidate
ranked
lowest
by
the
tabulation
of
votes,
the
next
shortest
term
to
the
next-lowest
ranked
elected
candidate,
and
so
on.
In
the
case
of
a
tie
among
those
eligible
for
a
short
incomplete
term,
the
verifiable
random
selection
procedure
described
below
will
be
used
to
assign
the
short
incomplete
term.
Refer to How to Organize an Advisory Board or TAG election [ELECTION-HOWTO] for more details.
2.5.2.1.
3.3.3.4.
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
short
incomplete
term),
W3C
uses
the
random
and
verifiable
procedure
defined
in
RFC
3797
[RFC3797]
.
The
procedure
orders
an
input
list
of
names
(listed
in
alphabetical
order
by
family
name
unless
otherwise
specified)
into
a
“result
order”.
W3C applies this procedure as follows:
- When N people have tied for M (less than N) seats. In this case, only the names of the N individuals who tied are provided as input to the procedure. The M seats are assigned in result order.
-
After
all
elected
individuals
have
been
identified,
when
N
people
are
eligible
for
M
(less
than
N)
shortincomplete terms. In this case, only the names of those N individuals are provided as input to the procedure. Theshortincomplete terms are assigned in result order.
2.5.3.
3.3.3.5.
Advisory
Board
and
Technical
Architecture
Group
Elected
Groups
Vacated
Seats
An Advisory Board or TAG participant’s seat is vacated when:
- the participant resigns, or
- an Advisory Board or TAG participant changes affiliations such that the Advisory Board and TAG participation constraints are no longer met, or
-
the
Director
dismisses
the
participant
for
failing
to
meet
the
criteria
in
section
§ 3.1§ 3.1.1 Individual Participation Criteria , or - their term ends.
If a participant changes affiliation, but the participation constraints are met, that participant’s seat becomes vacant at the next regularly scheduled election for that group.
Vacated seats are filled according to this schedule:
- When an appointed TAG seat is vacated, the 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 seats is such that when added to the number of continuing participants, the minimum total number of elected seats is met (6 for the TAG , 9 for the AB ); and the maximum number corresponds to all unoccupied seats. Except for the number of available seats and the length of the terms, the usual rules for Advisory Board and Technical Architecture Group Elections apply.
3.
3.4.
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
,
Chartered
Groups:
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
This
document
defines
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:
:
-
Consensus : 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 consensusWorking Groupswhere all individuals in the set support the decision (i.e., no individual in the set abstains).Dissent :. -
At 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. Note: Chairs have substantial flexibility in how they obtain and assess consensus among their groups. Unless otherwise constrained by charter, they may 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; or they may 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. 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 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.Working Groupsshould 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 decisiontypically produce deliverables (e.g.,in response to arequest to advance a technical report). Note: In this document, the term “Formal Objection” is used to emphasize this process implication: Formal Objections receive Director consideration. The word “objection” used alone has ordinary English connotations. An individual who registers a Formal Objection 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 by the Director. A record of each Formal Objection must be publicly available . A Call for Review (of a document) to the Advisory Committee must identify any Formal Objections . 3.3.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). 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 throughRecommendation Track technicaldiscussion and compromise have failed,reports , software, test suites, andthat 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 groupreviews ofrelated 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 informtheChair in writing who is acting as proxy, with written instructions on the usedeliverables ofthe 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 forotherpurposes 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 madegroups) asthe result of a vote ). As detaileddefined inother parts of this document, the Chair of a Working Group or Interest Group has the prerogative to make certain decisions based on their own judgment. Such decisions are called Chair Decisions . In contrast, decisions taken by the Chair of a Working Group or Interest Group on the basis of having assessed the consensus of the group or following a vote (see § 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 maketheirrequests known to the Team Contactcharter .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 GroupA 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 theWorkingGroup”Groups have additional participation requirements described 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,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 (onsee particularly theW3C Web site, in W3C meetings, etc.): public, Member-only, and Team-only. While much information made available by W3C is public,“Member-only ” information is available to authorized parties only, including representatives of Member organizations, Invited Experts , the Advisory Board, the TAG, and the Team. For example, the charterLicensing Obligations ofsomeWorkingGroups may specify a Member-onlyGroup Participantsconfidentiality level for group proceedings. “ Team-only”information is available to the Team and other authorized parties. Those authorized to access Member-only and Team-only information: must treat the information as confidential within W3C, must use reasonable efforts to 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 employeesandofficial representatives oftheorganization to ensure that Member-only news announcements are distributed for internal use only within their organization. Information about Member mailing lists is availablepatent claim exclusion process inthe New Member Orientation [INTRO] . 4.1.1. Changing Confidentiality Level As a benefit of membership, W3C provides some Team-only and Member-only channels for certain types of communication. For example, Advisory Committee representatives can send reviews to a Team-only channel. However, for“ Exclusion From W3Cprocesses 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 TeamRF Licensing Requirementsand 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 andInterest GroupsThis 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 ;
see information aboutbut can publishmaturity levels for Interest Groupstechnical reports on the Note Track .
5.1.
3.4.1.
Requirements
for
All
Working
and
Interest
Chartered
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 Director appoints (and re-appoints) Chairs for all groups. The Chair is a Member representative , a Team representative , or an Invited Expert , (invited by the Director). The requirements of this document that apply to those types of participants apply to Chairs as well. The role of the Chair [CHAIR] is described in the Art of Consensus [GUIDE] .
Each group must have a Team Contact , who acts as the interface between the Chair , group participants, and the rest of the Team. The role of the Team Contact [TEAM-CONTACT] is described in the Art of Consensus [GUIDE] . The Chair and the Team Contact of a group should not be the same individual.
Each
group
must
have
an
archived
mailing
list
for
formal
group
communication
(e.g.,
for
meeting
announcements
and
minutes,
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.
5.2.1.
3.4.2.
Working
Group
and
Interest
Group
Participation
Requirements
in
Chartered
Groups
There are three types of individual participants in a Working Group : Member representatives , Invited Experts , and Team representatives (including the Team Contact ).
There are four types of individual participants in an Interest Group : the same three types as for Working Groups plus, for an Interest Group where the only participation requirement is mailing list subscription , public participants .
Except where noted in this document or in a group charter, all participants share the same rights and responsibilities in a group; see also the individual participation criteria .
A participant may represent more than one organization in a Working Group or Interest Group . Those organizations must all be members of the group.
An individual may become a Working or Interest Group participant at any time during the group’s existence. See also relevant requirements in “Joining an Already Established Working Group” in the W3C Patent Policy [PATENT-POLICY] .
On an exceptional basis, a Working or Interest Group participant may designate a substitute to attend a meeting and should inform the Chair . The substitute may act on behalf of the participant, including for votes . For the substitute to vote, the participant must inform the Chair in writing in advance. As a courtesy to the group, if the substitute is not well-versed in the group’s discussions, the regular participant should authorize another participant to act as proxy for votes.
To allow rapid progress, Working Groups are intended to be small (typically fewer than 15 people) and composed of experts in the area defined by the charter. In principle, Interest Groups have no limit on the number of participants. When a Working Group grows too large to be effective, W3C may split it into an Interest Group (a discussion forum) and a much smaller Working Group (a core group of highly dedicated participants).
3.4.3.
Types
of
Participants
in
the
Patent
Policy.
Chartered
Groups
5.2.1.1.
3.4.3.1.
Member
Representative
in
a
Working
Group
An individual is a Member representative in a Working Group if all of the following conditions are satisfied:
- the Advisory Committee representative of the Member in question has designated the individual as a Working Group participant, and
- the individual qualifies for Member representation .
To designate an individual as a Member representative in a Working Group , an Advisory Committee representative must provide the Chair and Team Contact with all of the following information , in addition to any other information required by the Call for Participation and charter (including the participation requirements of the W3C Patent Policy [PATENT-POLICY] ):
- The name of the W3C Member the individual represents and whether the individual is an employee of that Member organization;
- A statement that the individual accepts the participation terms set forth in the charter (with an indication of charter date or version);
- A statement that the Member will provide the necessary financial support for participation (e.g., for travel, telephone calls, and conferences).
A Member participates in a Working Group from the moment the first Member representative joins the group until either of the following occurs:
- the group closes, or
- the Member resigns from the Working Group; this is done through the Member’s Advisory Committee representative.
5.2.1.2.
3.4.3.2.
Member
Representative
in
an
Interest
Group
When the participation requirements exceed Interest Group mailing list subscription , an individual is a Member representative in an Interest Group if all of the following conditions are satisfied:
- the Advisory Committee representative of the Member in question has designated the individual as an Interest Group participant, and
- the individual qualifies for Member representation .
To designate an individual as a Member representative in an Interest Group , the Advisory Committee representative must follow the instructions in the Call for Participation and charter.
Member participation in an Interest Group ceases under the same conditions as for a Working Group.
5.2.1.3.
3.4.3.3.
Invited
Expert
in
a
Working
Group
The Chair may invite an individual with a particular expertise to participate in a Working Group. This individual may represent an organization in the group (e.g., if acting as a liaison with another organization).
An individual is an Invited Expert in a Working Group if all of the following conditions are satisfied:
- the Chair has designated the individual as a group participant,
- the Team Contact has agreed with the Chair’s choice, and
- the individual has provided the information required of an Invited Expert to the Chair and Team Contact.
To designate an individual as an Invited Expert in a Working Group, the Chair must inform the Team Contact and provide rationale for the choice. When the Chair and the Team Contact disagree about a designation, the 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 Director withdraws the invitation to participate, or
- the individual resigns .
5.2.1.4.
3.4.3.4.
Invited
Expert
in
an
Interest
Group
When the participation requirements exceed Interest Group mailing list subscription , the participation requirements for an Invited Expert in an Interest Group are the same as those for an Invited Expert in a Working Group .
5.2.1.5.
3.4.3.5.
Team
Representative
in
a
Working
Group
An individual is a Team representative in a Working Group when so designated by W3C management. Team representatives both contribute to the technical work and help ensure the group’s proper integration with the rest of W3C.
A Team representative participates in a Working Group from the moment the individual joins the group until any of the following occurs:
- the group closes, or
- W3C management changes Team representation by sending email to the Chair, copying the group mailing list.
The
Team
participates
in
a
Working
Group
from
the
moment
the
Director
announces
the
creation
of
the
group
is
announced
until
the
group
closes.
5.2.1.6.
3.4.3.6.
Team
Representative
in
an
Interest
Group
When the participation requirements exceed Interest Group mailing list subscription , an individual is a Team representative in an Interest Group when so designated by W3C management.
5.2.2.
4.
Working
Group
and
Interest
Group
Lifecycle
of
Chartered
Groups
4.1. Initiating Charter Development
W3C
creates
a
charter
charters
for
chartered
groups
based
on
interest
from
the
Members
and
Team.
The
Team
must
notify
the
Advisory
Committee
when
a
charter
for
a
new
Working
Group
or
Interest
Group
is
in
development.
This
is
intended
to
raise
awareness,
even
if
no
formal
proposal
is
yet
available.
Advisory
Committee
representatives
may
provide
feedback
on
the
Advisory
Committee
discussion
list
.
or
via
other
designated
channels.
W3C may begin work on a Working Group or Interest Group charter at any time.
5.2.4.
4.2.
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)
Content
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). -
Expected
milestone
dates
where
available.
Note: A charter is not required to include schedules for review of other group’s
deliverables;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
§ 3.4 Votes ;§ 5.2.3 Deciding by Vote . -
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 published under any other Charter (including a predecessor group of the same name), for which there is at least an existing First Public Working Draft the description of that deliverable in the proposed charter of the adopting Working Group must provide the following information:
- The title, stable URL, and publication date of the Working Draft or other Recommendation-track document that will serve as the basis for work on the deliverable (labeled “ Adopted Draft ”);
- The title, stable URL, and publication date of the document that was used as the basis for its most recent Exclusion Opportunity as per the W3C Patent Policy [PATENT-POLICY] . (labeled “ Exclusion Draft ”); and
-
The
stable
URL
of
the
Working
Group
charter
under
which
the
Exclusion
Draft
was
published
(labeled
the
“
OtherExclusion Draft Charter ”).
All of the above data must be identified in the adopting Working Group’s charter using the labels indicated.
The Adopted Draft and the Exclusion Draft must each be adopted in their entirety and without any modification. The proposed charter must state the dates on which the Exclusion Opportunity that arose on publishing the Exclusion Draft began and ended. As per “Joining an Already Established Working Group” in the W3C Patent Policy [PATENT-POLICY] , this potentially means that exclusions can only be made immediately on joining a Working Group.
An Interest Group charter may include provisions regarding participation, including specifying that the only requirement for participation (by anyone) in the Interest Group is subscription to the Interest Group mailing list . This type of Interest Group may have public participants .
A charter may include provisions other than those required by this document. The charter should highlight whether additional provisions impose constraints beyond those of the W3C Process Document (e.g., limits on the number of individuals in a Working Group who represent the same Member organization or group of related Members ).
5.2.7.
4.3.
Advisory
Committee
Review
of
a
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 Interest Group , and a rationale must be provided.
The Call for Review of a substantively modified charter must highlight important changes (e.g., regarding deliverables or resource allocation) and include rationale for the changes.
As part of the Advisory Committee review of any new or substantively modified Working Group charter, any Advisory Committee representative may request an extended review period.
Such a request must be submitted with a Member’s comments in response to the Call for Review. Upon receipt of any such request, the 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.
4.4. Call for Participation in a Chartered 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 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). When a group is re-chartered, individuals participating in the Working Group or Interest Group before the new Call for Participation may attend any meetings held within forty-five (45) days of the Call for Participation even if they have not yet formally rejoined the group (i.e., committed to the terms of the charter and patent policy).
Advisory Committee representatives may initiate an Advisory Committee Appeal against the decision to create or substantially modify a Working Group or Interest Group charter.
4.5. Charter Extension
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.
4.6. Chartered Group Closure
A Working Group or Interest Group charter specifies a duration for the group. The Director may decide to close a group prior to the date specified in the charter in any of the following circumstances:
- There are insufficient resources to produce chartered deliverables or to maintain the group, according to priorities established within W3C.
- The group produces chartered deliverables ahead of schedule.
The Director closes a Working Group or Interest Group by announcement to the Advisory Committee . Advisory Committee representatives may initiate an Advisory Committee Appeal .
Closing a Working Group has implications with respect to the W3C Patent Policy [PATENT-POLICY] .
5. Decisions
W3C attempts to resolve issues through dialog. Individuals who disagree strongly with a decision should register with the Chair any Formal Objections .
5.1. Types of Decisions
The Chair of a Working Group or Interest Group has the prerogative to make certain decisions based on their own judgment. Such decisions are called chair decisions .
In contrast, decisions taken by the Chair of a Working Group or Interest Group on the basis of having assessed the consensus of the group or following a vote (see § 5.2.3 Deciding by Vote ) are called group decisions (also known as group “resolutions”).
A W3C decision is one where the Director decides, after exercising the role of assessing 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 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:
- Consensus :
- 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 :
- At 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.
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 (i.e., there is at least one Formal Objection ) so that the group can make progress (for example, to produce a deliverable in a timely manner). Dissenters cannot stop a group’s work simply by saying that they cannot live with a decision. When the Chair believes that the Group has duly considered the legitimate concerns of dissenters as far as is possible and reasonable, the group should move on.
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.
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. Chair Decision and Group Decision Appeals
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.
5.6. 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 request to advance a technical report).
Note: In this document, the term “Formal Objection” is used to emphasize this process implication: Formal Objections receive Director consideration. The word “objection” used alone has ordinary English connotations.
An individual who registers a Formal Objection 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.
A record of each Formal Objection must be publicly available . A Call for Review (of a document) to the Advisory Committee must identify any Formal Objections .
5.7. Advisory Committee Reviews
Advisory Committee review is the process by which the Advisory Committee formally confers its approval on charters , technical reports , and other matters.
5.7.1. Start of a Review Period
Each Advisory Committee review period begins with a Call for Review from the Team to the Advisory Committee . The Call for Review describes the proposal, raises attention to deadlines, estimates when the decision will be available, and includes other practical information. Each Member organization may send one review, which must be returned by its Advisory Committee representative .
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. After the Review Period
After the review period, the Director must announce to the Advisory Committee the level of support for the proposal ( consensus or dissent ). The Director must also indicate whether there were any Formal Objections , with attention to changing confidentiality level . This W3C decision is generally one of the following:
- The proposal is approved, possibly with editorial changes integrated.
- The proposal is approved, possibly with substantive changes integrated. In this case the announcement must include rationale for the decision to advance the document despite the proposal for a substantive change.
- The proposal is returned for additional work, with a request to the initiator to formally address certain issues.
- The proposal is rejected.
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 Director should provide the Advisory Committee with an update.
5.8. Advisory Committee Votes
The Advisory Committee votes in elections for seats on the TAG or Advisory Board , and in the event of an Advisory Committee Appeal achieving the required support to trigger an appeal vote. Whenever the Advisory Committee votes, each Member or group of related Members has one vote.
5.9. Appeal by Advisory Committee Representatives
Advisory Committee representatives may appeal certain decisions, though appeals are only expected to occur in extraordinary circumstances.
When a W3C decision is made following an Advisory Committee review , Advisory Committee representatives may initiate an Advisory Committee Appeal . These W3C decisions include those related to group creation and modification, and transitions to new maturity levels for Recommendation Track documents and the Process document.
Advisory Committee representatives may also initiate an appeal for certain Director 's decisions that do not involve an Advisory Committee review . These cases are identified in the sections which describe the requirements for the Director 's decision and include additional (non-reviewed) maturity levels of Recommendation Track documents, group charter extensions and closures, and Memoranda of Understanding .
In all cases, an appeal must be initiated within three weeks of the decision.
An Advisory Committee representative initiates an appeal by sending a request to the Team . The request should say “I appeal this Director’s Decision” and identify the decision. Within one week the Team must announce the appeal process to the Advisory Committee and provide a mechanism for Advisory Committee representatives to respond with a statement of positive support for this appeal. The archive of these statements must be member-only . If, within one week of the Team’s announcement, 5% or more of the Advisory Committee support the appeal request, the Team must organize an appeal vote asking the Advisory Committee “Do you approve of the Director’s Decision?” together with links to the Director 's decision and the appeal support.
The ballot must allow for three possible responses: “Approve”, “Reject”, and “Abstain”, together with Comments.
If the number of votes to reject exceeds the number of votes to approve, the decision is overturned. In that case, there are the following possible next steps:
- The proposal is rejected.
- The proposal is returned for additional work, after which the applicable decision process is re-initiated.
6.
W3C
Technical
Report
Development
Process
Reports
The W3C technical report development process is the set of steps and requirements followed by W3C Working Groups to standardize Web technology. The W3C technical report development process is designed to:
- support multiple specification development methodologies
- maximize consensus about the content of stable technical reports
- ensure high technical and editorial quality
- promote consistency among specifications
- facilitate royalty-free, interoperable implementations of Web Standards, and
- earn endorsement by W3C and the broader community.
See also “licensing goals for W3C Specifications” in the W3C Patent Policy [PATENT-POLICY] .
6.1.
W3C
Types
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
page
https://www.w3.org/TR
[TR]
.
This
chapter
describes
the
formal
requirements
for
publishing
and
maintaining
a
W3C
Recommendation
or
,
Note
,
or
Registry
Report
.
- Recommendations
-
Working
Groups
develop
technical
reports
on
the
W3C
Recommendation
Track
in
order
to
produce
normative
specifications
or
guidelines
as
standards
for
the
Web.
The
Recommendation
Track
process
incorporates
requirements
for
wide
review
,
adequate
implementation
experience
,
and
consensus
-building,
and
is
subject
to
the
W3C
Patent
Policy
[PATENT-POLICY]
,
under
which
grantsparticipants commit to Royalty-Free IPR licensestofor implementations. See§ 6.2§ 6.3 The W3C Recommendation Track for details. - Notes
-
Groups
can
also
publish
documents
as
W3C
Notes
and
W3C
Statements
,
typically
either
to
document
information
other
than
technical
specifications,
such
as
use
cases
motivating
a
specification
and
best
practices
for
its
use, or to clarify the status of work that is abandoned.use. See§ 6.3§ 6.4 The Note Track (Notes and Statements) for details. - Registries
-
Working
GroupGroups can also publish registries in order to document collections of values or other data. These are typically published in a separate registry report , although they can also be directly embedded in Recommendation Track documents as a registry section . Defining a registry requires wide review andInterestconsensus , but once set up, changes to registry entries are lightweight and can even be done without a Working GroupNotes. See § 6.5 The Registry Track for details.
Individual Working Groups and Interest Groups should adopt additional processes for developing publications, so long as they do not conflict with the requirements in this chapter.
6.1.1.
6.2.
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 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
§ 5.2.1
Working
Group
and
Interest
Group
§ 3.4.2
Participation
Requirements
in
Chartered
Groups
in
the
Group
responsible
for
the
document(s)
they
are
editing.
The Team is not required to publish a Technical Report that does not conform to the Team’s Publication Rules [PUBRULES] (e.g., for naming , status information, style, and copyright requirements ). These rules are subject to change by the Team from time to time. The Team must inform group Chairs and the Advisory Committee of any changes to these rules.
The primary language for W3C Technical Reports is English. W3C encourages the translation of its Technical Reports . Information about translations of W3C technical reports [TRANSLATION] is available at the W3C Web site.
6.1.2.
6.2.2.
Reviews
and
Review
Responsibilities
A document is available for review from the moment it is first published . Working Groups should formally address any substantive review comment about a technical report in a timely manner.
Reviewers should send substantive technical reviews as early as possible. Working Groups are often reluctant to make substantive changes to a mature document, particularly if this would cause significant compatibility problems due to existing implementation. Working Groups should record substantive or interesting proposals raised by reviews but not incorporated into a current specification.
6.1.2.1.
6.2.2.1.
Wide
Review
The requirements for wide review are not precisely defined by the W3C Process. The objective is to ensure that the entire set of stakeholders of the Web community, including the general public, have had adequate notice of the progress of the Working Group (for example through notices posted to public-review-announce@w3.org ) and were able to actually perform reviews of and provide comments on the specification. A second objective is to encourage groups to request reviews early enough that comments and suggested changes can still be reasonably incorporated in response to the review. Before approving transitions, the 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.1.3.
6.2.3.
Classes
of
Changes
This
document
distinguishes
the
following
4
5
classes
of
changes
to
a
specification.
The
first
two
classes
of
change
are
considered
editorial
changes
,
the
latter
next
two
substantive
changes
,
and
the
last
one
registry
changes
.
-
-
No changes to text content
-
- These changes include fixing broken links, style sheets or invalid markup.
-
-
Corrections that do not affect conformance
-
-
Changes
that
reasonable
implementers
would
not
interpret
as
changing
architectural
or
interoperability
requirements
or
their
implementation.
Changes
which
resolve
ambiguities
in
the
specification
are
considered
to
change
(by
clarification)
the
implementation
requirements
and
do
not
fall
into
this
class.
- Examples of changes in this class include correcting non-normative code examples where the code clearly conflicts with normative requirements, clarifying informative use cases or other non-normative text, fixing typos or grammatical errors where the change does not change implementation requirements. If there is any doubt or disagreement as to whether requirements are changed, such changes do not fall into this class.
-
-
Corrections that do not add new features
-
-
These
changes
may
affect
conformance
to
the
specification.
A
change
that
affects
conformance
is
one
that:
- makes conforming data, processors, or other conforming agents become non-conforming according to the new version, or
- makes non-conforming data, processors, or other agents become conforming, or
- clears up an ambiguity or under-specified part of the specification in such a way that data, a processor, or an agent whose conformance was once unclear becomes clearly either conforming or non-conforming.
-
-
New features
-
- Changes that add a new functionality, element, etc.
-
-
Changes to the contents of a registry table
-
- Changes that add, remove, or alter registry entries in a registry table .
6.1.4.
6.2.4.
Errata
Management
Tracking
errors
is
an
important
part
of
a
Working
Group
's
ongoing
care
of
a
technical
report
;
for
this
reason,
the
scope
of
a
Working
Group
charter
generally
allows
time
for
work
after
publication
of
a
Recommendation
.
In
this
Process
Document,
the
term
“
erratum
”
(plural
“errata”)
refers
to
any
error
that
can
be
resolved
by
one
or
more
changes
in
classes
1-3
of
section
§ 6.1.3
§ 6.2.3
Classes
of
Changes
.
Working Groups must keep a public record of errors that are reported by readers and implementers for Recommendations . Such error reports should be compiled no less frequently than quarterly.
Working Groups decide how to document errata. Such documentation must identify the affected technical report text and describe the error; it may also describe some possible solution(s). Readers of the technical report should be able easily to find and see the errata that apply to that specific technical report with their associated tests. Errata may be documented in a separate errata page or tracking system. They may , in addition or alternatively, be annotated inline alongside the affected technical report text or at the start or end of the most relevant section(s).
6.1.5.
6.2.5.
Candidate
Changes
Amendments
An
erratum
may
be
accompanied
by
an
informative,
candidate
correction
approved
by
the
consensus
of
the
Working
Group
.
When
annotated
inline,
errata—
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
changes
amendments
have
not
yet
received
sufficient
review
or
implementation
experience
to
be
normatively
incorporated
into
the
specification
proper.
A candidate addition is similar to a candidate correction , except that it proposes a new feature rather than an error correction.
If there is no group chartered to maintain a technical report , the Team may maintain its errata and associated candidate corrections . Such corrections must be marked as Team correction , and do not constitute a normative portion of the Recommendation, as defined in the Patent Policy [PATENT-POLICY] (i.e. they are not covered by the Patent Policy). The Team must solicit wide review on Team corrections that it produces.
Candidate
corrections
and
candidate
additions
are
collectively
known
as
candidate
changes
amendments
.
In
addition
to
their
actual
maturity
level
,
published
REC
Track
documents
with
candidate
changes
amendments
are
also
considered,
for
the
purpose
of
the
W3C
Patent
Policy
[PATENT-POLICY]
,
to
be
Working
Drafts
with
those
candidate
changes
amendments
treated
as
normative.
6.1.6.
6.2.6.
License
Grants
from
Non-Participants
When
a
party
who
is
not
already
obligated
under
the
Patent
Policy
offers
a
change
in
class
3
or
4
(as
described
in
§ 6.1.3
§ 6.2.3
Classes
of
Changes
)
to
a
technical
report
under
this
process
the
Team
must
request
a
recorded
royalty-free
patent
commitment;
for
a
change
in
class
4,
the
Team
must
secure
such
commitment.
Such
commitment
should
cover,
at
a
minimum,
all
the
party’s
Essential
Claims
both
in
the
contribution,
and
that
become
Essential
Claims
as
a
result
of
incorporating
the
contribution
into
the
draft
that
existed
at
the
time
of
the
contribution,
on
the
terms
specified
in
the
“W3C
Royalty-Free
(RF)
Licensing
Requirements”
section
of
the
W3C
Patent
Policy
[PATENT-POLICY]
.
6.2.
6.3.
The
W3C
Recommendation
Track
When
advancing
a
technical
report
to
Recommendation,
typically
a
series
of
Working
Drafts
Groups
are
published
,
each
of
which
refines
a
document
under
development
create
specifications
and
guidelines
to
complete
the
scope
of
work
envisioned
by
a
Working
Group
's
charter
.
For
a
These
technical
specification,
once
reports
undergo
cycles
of
revision
and
review
as
they
advance
towards
W3C
Recommendation
status.
Once
review
suggests
the
Working
Group
has
met
their
requirements
satisfactorily
for
a
new
standard,
there
is
including
wide
review
,
a
Candidate
Recommendation
phase.
This
phase
allows
the
entire
W3C
membership
to
provide
feedback
on
the
specification,
while
the
Working
Group
to
formally
collects
collect
implementation
experience
to
demonstrate
that
the
specification
works
in
practice.
The
next
phase
is
a
Proposed
Recommendation
,
to
finalize
At
the
review
end
of
W3C
Members.
If
the
Director
determines
that
W3C
Member
review
supports
a
specification
becoming
a
standard,
process,
the
Advisory
Committee
reviews
the
mature
technical
report,
and
if
there
is
support
from
its
Membership,
W3C
publishes
it
as
a
Recommendation
.
In summary, the W3C Recommendation Track consists of:
- Publication of the First Public Working Draft .
- Publication of zero or more revised Working Drafts .
- Publication of one or more Candidate Recommendations .
- Publication of a Proposed Recommendation .
-
Publication
as
a
W3C
Recommendation
.
Possibly, publication as an Amended Recommendation .
This
Process
defines
certain
Recommendation
Track
publications
as
Patent
Review
Drafts
.
Under
the
2004
(updated
in
2017)
Patent
Policy,
Policy
(and
its
2017
update)
[PATENT-POLICY-2004]
,
these
correspond
to
“Last
Call
Working
Draft”
in
the
Patent
Policy
[PATENT-POLICY-2017]
;
Under
Policy;
Starting
from
the
2020
Patent
Policy,
Policy
[PATENT-POLICY-2020]
,
these
correspond
to
“Patent
Review
Draft”
in
the
Patent
Policy
[PATENT-POLICY]
.
W3C may end work on a technical report at any time.
The
Director
may
decline
a
request
to
advance
in
maturity
level,
requiring
a
Working
Group
to
conduct
further
work,
and
may
require
the
specification
to
return
to
a
lower
maturity
level
.
The
Director
Team
must
inform
the
Advisory
Committee
and
Working
Group
Chairs
when
a
Working
Group
's
request
for
a
specification
to
advance
in
maturity
level
is
declined
and
the
specification
is
returned
to
a
Working
Group
for
further
work.
6.2.1.
6.3.1.
Maturity
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; additional features in a later 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
-
A
Candidate
Recommendation
Snapshot
corresponds
to
a
Patent
Review
Draft
as
used
in
the
W3C
Patent
Policy
[PATENT-POLICY]
.
Publishing
a
Patent
Review
Draft
triggers
a
Call
for
Exclusions,
per
“Exclusion
From
W3C
RF
Licensing
Requirements”
in
the
W3C
Patent
Policy.
Publication as a Candidate Recommendation Snapshot requires approval of either a Transition Request (for the first Candidate Recommendation publication from another maturity level) or an Update Request (for subsequent Candidate Recommendation Snapshots ).
- Candidate Recommendation Draft
-
A
Candidate
Recommendation
Draft
is
published
on
the
W3C’s
Technical
Reports
page
[TR]
to
integrate
changes
from
the
previous
Candidate
Recommendation
Snapshot
that
the
Working
Group
intends
to
include
in
a
subsequent
Candidate
Recommendation
Snapshot
.
This
allows
for
wider
review
of
the
changes
and
for
ease
of
reference
to
the
integrated
specification.
Any changes published directly into a Candidate Recommendation Draft should be at the same level of quality as a Candidate Recommendation Snapshot . However, the process requirements are minimized so that the Working Group can easily keep the specification up to date.
A Candidate Recommendation Draft does not provide an exclusion
opportunityopportunity; instead, it is considered a Working Draft for the purpose of the W3C Patent Policy [PATENT-POLICY] .
A Rescinded Candidate Recommendation is a Candidate Recommendation in which significant problems have been discovered such that W3C cannot endorse it or continue work on it, for example due to burdensome patent claims that affect implementers and cannot be resolved (see the W3C Patent Policy [PATENT-POLICY] and in particular “PAG Conclusion”). There is no path to restoration for a Rescinded Candidate Recommendation . See “W3C Royalty-Free (RF) Licensing Requirements” in the W3C Patent Policy [PATENT-POLICY] for implication on patent licensing obligations.
- Proposed Recommendation ( PR )
-
A
Proposed
Recommendation
is
a
document
that
has
been
accepted
by
theW3C as of sufficient quality to become a W3C Recommendation . This phase triggers formal review by the Advisory Committee , who may recommend that the document be published as a W3C Recommendation , returned to the Working Group for further work, or abandoned. Substantive changes must not be made to a Proposed Recommendation except by publishing a new Working Draft or Candidate Recommendation . - W3C Recommendation ( REC )
-
A
W3C
Recommendation
is
a
specification
or
set
of
guidelines
or
requirements
that,
after
extensive
consensus
-building,
has
received
the
endorsement
of
theW3C 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 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
theW3C recommends for new adoption. An Obsolete or Superseded specification has the same status as a W3C Recommendation with regards to W3C Royalty-Free IPR Licenses granted under the Patent Policy.Note: When a Technical Report which had previously been published as a Recommendation is again published as a Recommendation after following the necessary steps to revise it, the latest version replaces the previous one, without the need to invoke the steps of
§ 6.2.12.3§ 6.3.12.3 Abandoning a W3C Recommendation : it is the same document, updated. Explicitly declaring a documented superseded, using the process documented in§ 6.2.12.3§ 6.3.12.3 Abandoning a W3C Recommendation , is intended for cases where a Recommendation is superseded by a separate Technical Report (or by a document managed outside of W3C). - An Obsolete Recommendation
-
An
Obsolete
Recommendation
is
a
specification
that
theW3C 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,theW3C may decide to restore it to Recommendation status. - Rescinded Recommendation
- A Rescinded Recommendation is an entire Recommendation that W3C no longer endorses, and believes is unlikely to ever be restored to Recommendation status. See also “W3C Royalty-Free (RF) Licensing Requirements” in the W3C Patent Policy [PATENT-POLICY] .
-
- Discontinued Draft
- A technical report representing the state of a Recommendation-track document at the point at which work on it was discontinued. See § 6.3.12.1 Abandoning an Unfinished Recommendation .
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.2.2.
6.3.2.
Implementation
Experience
Implementation experience is required to show that a specification is sufficiently clear, complete, and relevant to market needs, to ensure that independent interoperable implementations of each feature of the specification will be realized. While no exhaustive list of requirements is provided here, when assessing that there is adequate implementation experience the 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.2.3.
6.3.3.
Advancement
on
the
Recommendation
Track
For
all
requests
to
advance
a
specification
to
a
new
maturity
level
other
than
Note
(called
Transition
Requests
),
the
Working
Group:
- must record the group’s decision to request advancement.
- must obtain Director 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 have been made, and may document the details of such changes.
- must formally address all issues raised about the document since the previous maturity level .
- 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
level”,
so
many
requirements
do
not
apply,
and
approval
is
normally
fairly
automatic.
For
later
stages,
especially
transition
to
Candidate
or
Proposed
Recommendation
,
there
is
usually
a
formal
review
meeting
to
ensure
the
requirements
have
been
met
before
Director
's
approval
is
given.
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.2.4.
6.3.4.
Updating
Mature
Publications
on
the
Recommendation
Track
Certain requests to re-publish a specification within its current maturity level (called Update Requests ) require 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
Director
approval,
or
fulfill
the
criteria
for
§ 6.2.4.1§ 6.3.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 ensure the requirements have been met before Director 's approval is given.
Note: Update request approval is expected to be fairly simple compared to getting approval for a transition request .
The
Director
Team
must
announce
the
publication
of
the
revised
specification
to
other
W3C
groups
and
the
Public.
6.2.4.1.
6.3.4.1.
Streamlined
Publication
Approval
Note: These criteria are intentionally stricter than the general requirements for an update request . This is in order to minimize ambiguities and the need for expert judgment, and to make self-evaluation practical.
In order to streamline the publication process in non-controversial cases, 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 substantive changes or with new features :
- Changes to the document are limited to proposed corrections that were included in a Last Call for Review of Proposed Corrections possibly combined with class 1 or 2 changes , and/or (in the case of a Recommendation that allows new features ) proposed additions that were included in a Last Call for Review of Proposed Additions .
-
The
Working
Group
must
show
that
all
changes
have
been
implemented
in
at
least
2
distinct
products
by
2
different
implementers,
as
evidenced
by
passing
tests
of
a
test
suite
providing
extensive
coverage
of
the
changes,
or
an
alternative
streamlined
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.
6.3.5.
Publishing
a
First
Public
Working
Draft
To publish the First Public Working Draft of a document, a Working Group must meet the applicable requirements for advancement .
The
Director
Team
must
announce
the
publication
of
a
First
Public
Working
Draft
to
other
W3C
groups
and
to
the
public.
6.2.6.
6.3.6.
Revising
a
Working
Draft
A Working Group should publish a Working Draft to the W3C Technical Reports page when there have been significant changes to the previous published document that would benefit from review beyond the Working Group.
If 6 months elapse without significant changes to a specification, a Working Group should publish a revised Working Draft , whose status section should indicate reasons for the lack of change.
To publish a revision of a Working draft, a Working Group:
- must record the group’s decision to request publication. Consensus is not required, as this is a procedural step,
- must provide public documentation of substantive changes to the technical report since the previous Working Draft ,
- should provide public documentation of significant editorial changes to the technical report since the previous step,
- should report which, if any, of the Working Group’s requirements for this document have changed since the previous step,
- should report any changes in dependencies with other groups,
Possible next steps for any Working Draft:
- Revised Working Draft
- Candidate Recommendation
-
Working Group NoteDiscontinued Draft
6.2.7.
6.3.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, 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
approval
of
a
Transition
Request
is
always
a
Candidate
Recommendation
Snapshot
.
The
Director
Team
must
announce
the
publication
of
the
Candidate
Recommendation
Snapshot
to
other
W3C
groups
and
to
the
public.
Possible next steps after a Candidate Recommendation Snapshot :
- Return to Working Draft
- A revised Candidate Recommendation Snapshot
- A revised Candidate Recommendation Draft
- Proposed Recommendation
-
Working Group NoteDiscontinued Draft
Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to advance the technical report.
6.2.8.
6.3.8.
Revising
a
Candidate
Recommendation
6.2.8.1.
6.3.8.1.
Publishing
a
Candidate
Recommendation
Snapshot
If there are any substantive changes made to a Candidate Recommendation since the previous Candidate Recommendation Snapshot other than to remove features explicitly identified as at risk , the Working Group must meet the requirements of an update request in order to republish.
In addition the Working Group:
- must specify the deadline for further comments, which must be at least 28 days after publication, and should be longer for complex documents,
- may identify features in the document as at risk . These features may be removed before advancement to Proposed Recommendation without a requirement to publish a new Candidate Recommendation .
The
Director
Team
must
announce
the
publication
of
a
revised
Candidate
Recommendation
Snapshot
to
other
W3C
groups
and
to
the
public.
To provide timely updates and patent protection, a Candidate Recommendation Snapshot should be published within 24 months of the Working Group accepting any proposal for a substantive change (and preferably sooner). To make scheduling reviews easier, a Candidate Recommendation Snapshot should not be published more often than approximately once every 6 months.
Note: Substantive changes trigger a new Exclusion Opportunity per “Exclusion From W3C RF Licensing Requirements” in the W3C Patent Policy [PATENT-POLICY] .
6.2.8.2.
6.3.8.2.
Publishing
a
Candidate
Recommendation
Draft
A Working Group should publish an Update Draft to the W3C Technical Reports page when there have been significant changes to the previous published document that would benefit from review beyond the Working Group.
To publish a revision of a Candidate Recommendation Draft , a Working Group:
- must record the group’s decision to request publication,
- must provide public documentation of substantive changes to the technical report since the previous Candidate Recommendation Snapshot ,
- should provide public documentation of significant editorial changes to the technical report since the previous Candidate Recommendation Snapshot ,
- should document outstanding issues, and parts of the document on which the Working Group does not have consensus,
- should report which, if any, of the Working Group’s requirements for this document have changed since the previous step,
- should report any changes in dependencies with other groups.
Note: A Working Group does not need to meet the requirements of a Candidate Recommendation Snapshot update request in order to publish a Candidate Recommendation Draft .
Possible next steps after a Candidate Recommendation Draft :
- Return to Working Draft
- A revised Candidate Recommendation Snapshot
- A revised Candidate Recommendation Draft
- Proposed Recommendation , if there are no substantive change other than dropping at risk features
-
Working Group NoteDiscontinued Draft
6.2.9.
6.3.9.
Transitioning
to
Proposed
Recommendation
In addition to meeting the requirements for advancement ,
- The status information must specify the deadline for Advisory Committee review , which must be at least 28 days after the publication of the Proposed Recommendation and should be at least 10 days after the end of the last Exclusion Opportunity per ”Exclusion From W3C RF Licensing Requirements” in the W3C Patent Policy [PATENT-POLICY] .
A
Working
Group,
or
for
a
proposed
Amended
Recommendation
,
the
W3C:
Group:
- must show adequate implementation experience except where an exception is approved by the 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 period,
- must not have made any substantive changes to the document since the most recent Candidate Recommendation Snapshot , other than dropping features identified at risk .
- may have removed features identified in the Candidate Recommendation Snapshot document as at risk without republishing the specification as a Candidate Recommendation Snapshot .
The 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 Director should explain the reasons for that 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 .
A
Proposed
Recommendation
may
identify
itself
as
intending
to
allow
new
features
(
class
4
changes
)
after
its
initial
publication
as
a
Recommendation
,
as
described
in
§ 6.2.11.4
§ 6.3.11.4
Revising
a
Recommendation:
New
Features
.
Such
an
allowance
cannot
be
added
to
a
technical
report
previously
published
as
a
Recommendation
that
did
not
allow
such
changes.
Possible Next Steps:
- Return to Working Draft
- Return to Candidate Recommendation
-
Recommendation
status
,
including Amended Recommendation(the expected next step). -
Working Group NoteDiscontinued Draft
Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to advance the technical report.
6.2.10.
6.3.10.
Transitioning
to
W3C
Recommendation
The decision to advance a document to Recommendation is a W3C Decision .
In addition to meeting the requirements for advancement ,
- A Recommendation must identify where errata are tracked, and
- A Recommendation must not include any substantive changes from the Proposed Recommendation on which it is based.
- If there was any dissent in Advisory Committee reviews, the Director 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
DirectorTeam must announce the publication of a W3C Recommendation to Advisory Committee , other W3C groups and to the public.
Possible next steps: A W3C Recommendation normally retains its status indefinitely. However it may be:
-
republished
as
a
revised
Recommendation
or Amended Recommendation, or -
republished
as
a
Candidate
Recommendation
to
be
developed
towards
a
revised
Recommendation or AmendedRecommendation , or - declared superseded or obsolete , or
- rescinded .
6.2.11.
6.3.11.
Revising
a
W3C
Recommendation
This section details the process for making changes to a Recommendation .
6.2.11.1.
6.3.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
.)
If there is no Working Group chartered to maintain a Recommendation , the Team may republish the Recommendation with such changes incorporated.
6.2.11.2.
6.3.11.2.
Revising
a
Recommendation:
Editorial
Changes
Editorial
changes
to
a
Recommendation
require
no
technical
review
of
the
intended
changes.
A
Working
Group
,
provided
there
are
no
votes
against
the
resolution
decision
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
levels.
(See
class
2
changes
.)
If there is no Working Group chartered to maintain a Recommendation , the Team may republish the Recommendation with such changes incorporated, including errata and Team corrections .
6.2.11.3.
6.3.11.3.
Revising
a
Recommendation:
Substantive
Changes
A
candidate
correction
can
be
made
normative
and
be
folded
into
the
main
text
of
the
Recommendation
,
once
it
has
satisfied
all
the
same
criteria
as
the
rest
of
the
Recommendation
,
including
review
by
the
community
to
ensure
the
technical
and
editorial
soundness
of
the
candidate
change
amendments
.
To
validate
this,
the
Working
Group
must
request
a
Last
Call
for
Review
of
Proposed
Changes
Amendments
,
followed
by
an
update
request
.
See
§ 6.2.11.5
§ 6.3.11.5
Incorporating
Candidate
Changes
Amendments
.
Alternatively,
a
Working
Group
may
incorporate
the
changes
and
publish
as
a
Candidate
Recommendation
,
or
if
and
advance
the
specification
from
that
state.
(See
class
3
changes
.)
Note:
If
there
is
no
Working
Group
is
chartered
to
maintain
a
Recommendation
W3C
may
publish
a
candidate
Amended
Recommendation
,
and
advance
the
specification
from
that
state.
If
the
publication
was
requested
by
the
W3C
team
Team
in
the
absence
of
a
Working
Group
,
cannot
make
substantive
changes
and
republish
the
resulting
Recommendation
will
be
called
an
Amended
Recommendation
.
(See
class
3
It
can,
however,
informatively
highlight
problems
and
desirable
changes
.)
using
errata
and
candidate
corrections
and
republish
as
described
in
the
previous
section
.
6.2.11.4.
6.3.11.4.
Revising
a
Recommendation:
New
Features
New
features
(see
class
4
changes
)
may
be
incorporated
into
a
Recommendation
explicitly
identified
as
allowing
new
features
using
candidate
additions
.
A
candidate
addition
can
be
made
normative
and
be
folded
into
the
main
text
of
the
Recommendation
,
once
it
has
satisfied
all
using
the
same
criteria
process
as
the
rest
of
the
Recommendation
,
including
review
by
the
community
to
ensure
the
technical
and
editorial
soundness
of
the
candidate
change
.
To
validate
this,
the
Working
Group
must
request
a
Last
Call
for
Review
of
Proposed
Changes
candidate
amendments
,
followed
by
an
update
request
.
See
§ 6.2.11.5
Incorporating
Candidate
as
detailed
in
§ 6.3.11.3
Revising
a
Recommendation:
Substantive
Changes
.
Note: This prohibition against new features unless explicitly allowed enables third parties to depend on Recommendations having a stable feature-set, as they have prior to the 2020 revision of this Process.
To make changes which introduce a new feature to a Recommendation that was not approved for accepting new features, W3C must create a new technical report , following the full process of advancing a technical report to Recommendation beginning with a new First Public Working Draft .
6.2.11.5.
6.3.11.5.
Incorporating
Candidate
Changes
Amendments
A
Last
Call
for
Review
of
Proposed
Changes
Amendments
verifies
acceptance
by
the
W3C
community
of
candidate
changes
amendments
by
combining
an
AC
Review
with
a
patent
exclusion
opportunity.
The
Last
Call
for
Review
of
Proposed
Changes
Amendments
must
be
announced
to
other
W3C
groups,
the
public,
and
the
Advisory
Committee
.
The
announcement
must
:
- Identify whether this is a Last Call for Review of Proposed Corrections , Last Call for Review of Proposed Additions , or Last Call for Review of Proposed Corrections and Additions .
-
Identify
the
specific
candidate
changesamendments under review as proposedchangesamendments ( proposed corrections / proposedadditionadditions ). - Specify the deadline for review comments, which must not be any sooner than 60 days from the Call for Review.
- Solicit review and, if it does not already have it, implementation experience.
The
combination
of
the
existing
Recommendation
with
the
proposed
changes
amendments
included
in
the
Last
Call
for
Review
of
Proposed
Changes
Amendments
is
considered
a
Patent
Review
Draft
for
the
purposes
of
the
Patent
Policy
[PATENT-POLICY]
.
Also,
the
review
initiated
by
the
Last
Call
for
Review
of
Proposed
Additions
Amendments
is
an
Advisory
Committee
Review
.
Note: Last Call for Review of Proposed Additions and Last Call for Review of Proposed Corrections and Additions can only be issued for Recommendations that allow new features .
A
Working
Group
may
batch
multiple
proposed
changes
amendments
into
a
single
Last
Call
for
Review
of
Proposed
Changes
Amendments
.
To
facilitate
review,
a
Last
Call
for
Review
of
Proposed
Changes
Amendments
on
a
given
specification
should
not
be
issued
more
frequently
than
approximately
once
every
6
months.
At
the
end
of
the
Last
Call
for
Review
of
Proposed
Changes
Amendments
,
the
W3C
Decision
may
either
be
to
reject
the
proposed
change
amendment
,
or
to
clear
the
proposed
change
amendment
for
advancement
as
is,
or
to
return
the
proposal
to
the
Working
Group
with
a
request
to
formally
address
comments
made
on
the
changes
under
review.
If
the
Working
Group
needs
to
amend
a
proposed
change
amendment
in
response
to
review
feedback
it
must
issue
another
Last
Call
for
Review
of
Proposed
Change
Amendments
on
the
revised
change
before
it
can
be
incorporated
into
the
main
text.
Once
all
comments
on
a
proposed
change
amendment
have
been
formally
addressed
,
and
after
the
Working
Group
can
show
adequate
implementation
experience
and
the
fulfillment
of
all
other
requirements
of
Recommendation
text,
it
may
incorporate
the
proposed
change
amendment
into
the
normative
Recommendation
by
issuing
an
update
request
for
publication
of
the
updated
Recommendation
.
To
ensure
adequate
review
of
proposed
change
amendment
combinations,
only
proposed
changes
amendments
included
in
the
most
recent
Last
Call
for
Review
of
Proposed
Changes
Amendments
can
be
incorporated
into
the
normative
Recommendation
text.
(Thus
if
incorporation
of
a
proposed
change
amendment
is
postponed,
it
may
need
to
be
included
in
multiple
Last
Calls
for
Review
of
Proposed
Changes.)
Amendments.)
6.2.12.
6.3.12.
Retiring
Recommendation
Track
Documents
Work on a technical report may cease at any time. Work should cease if W3C or a Working Group determines that it cannot productively carry the work any further.
6.2.12.1.
6.3.12.1.
Abandoning
an
Unfinished
Technical
Report
Recommendation
Any
Recommendation-track
technical
report
no
longer
intended
to
advance
or
to
be
maintained,
and
that
is
not
being
rescinded,
should
be
published
as
a
Working
Group
Note
.
Discontinued
Draft
,
with
no
substantive
change
compared
to
the
previous
publication.
This
can
happen
if
the
Working
Group
decided
to
abandon
work
on
the
report,
or
the
Director
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
Notes
may
resume
work
on
such
a
technical
report
within
the
scope
of
its
charter
at
any
time,
by
re-
publishing
it
as
a
Working
Draft
.
6.2.12.2.
6.3.12.2.
Rescinding
a
Candidate
Recommendation
The process for rescinding a Candidate Recommendation is the same as for rescinding a Recommendation .
6.2.12.3.
6.3.12.3.
Abandoning
a
W3C
Recommendation
It is possible that W3C decides that implementing a particular Recommendation is no longer recommended. There are three designations for such specifications, chosen depending on the advice W3C wishes to give about further use of the specification.
W3C may obsolete a Recommendation , for example if the W3C Community decides that the Recommendation no longer represents best practices, or is not adopted and is not apparently likely to be adopted. An Obsolete Recommendation may be restored to normal Recommendation , for example because despite marking it Obsolete the specification is later more broadly adopted.
W3C
may
declare
a
Recommendation
Superseded
if
a
newer
version
exists
which
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” and “PAG Conclusion”.
W3C only rescinds, supersedes, or obsoletes entire Recommendations. A Recommendation can be both superseded and obsolete. To rescind, supersede, or obsolete some part of a Recommendation, W3C follows the process for modifying a Recommendation .
Note: For the purposes of the W3C Patent Policy [PATENT-POLICY] an Obsolete or Superseded Recommendation has the status of an active Recommendation , although it is not recommended for future implementation; a Rescinded Recommendation ceases to be in effect and no new licenses are granted under the Patent Policy.
6.2.12.4.
6.3.12.4.
Process
for
Rescinding,
Obsoleting,
Superseding,
Restoring
a
Recommendation
The process of rescinding, obsoleting, superseding, or restoring a Recommendation can be initiated either by a request from the 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
Director
Team
must
then
submit
the
request
to
the
Advisory
Committee
for
review.
For
any
Advisory
Committee
review
of
a
proposal
to
rescind,
obsolete,
supersede,
or
restore
a
Recommendation
the
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 'sannouncement
and should
- identify known implementations.
If there was any dissent in the Advisory Committee review , the 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 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.3.
6.4.
Working
Group
The
Note
Track
(Notes
and
Interest
Statements)
6.4.1. 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,
or
to
document
work
that
was
abandoned
without
producing
a
Recommendation
.
standard.
Working
Groups
and
,
Interest
Groups
,
the
TAG
and
the
AB
may
publish
work
as
W3C
Notes
.
Examples
include:
-
supporting
documentation
for
a
specification,
such
as
explanations
of
design
principles
or
use
cases
and
requirements,requirements -
non-normative
guides
to
good
practices, specifications where work has been stopped and there is no longer consensus for making them a new standard.practices
Some
W3C
Notes
are
developed
through
successive
Working
Drafts
,
with
an
expectation
that
they
will
become
Draft
Notes
before
publication
as
a
full
Notes
,
while
others
are
simply
published
directly
as
a
Note
.
There
are
few
formal
requirements
to
publish
a
document
as
a
W3C
Note
or
Draft
Note
,
and
they
have
no
standing
as
a
recommendation
of
W3C
but
are
simply
documents
preserved
for
historical
reference.
Note: The W3C Patent Policy [PATENT-POLICY] does not apply any licensing requirements or commitments for Notes or Draft Notes .
6.4.2. Publishing Notes
In
order
to
publish
a
Note
,
a
Working
Group
or
Interest
Group
:
Draft
Note
,
the
group:
-
may publish a Note with or without its prior publication as a Working Draft .must recordthe group’stheir decision to request publication as a Note or Draft Note , and - should publish documentation of significant changes to the technical report since any previous publication.
Possible
next
steps:
End
state:
Both
Notes
and
Draft
Notes
can
be
updated
by
republishing
as
a
Note
or
Draft
Note
.
A
technical
report
may
remain
a
Working
or
Interest
Group
Note
indefinitely
A
Working
Group
indefinitely.
If
a
Note
may
resume
work
on
produced
by
a
technical
report
within
the
chartered
group
is
no
longer
in
scope
of
its
charter
at
for
any
time,
at
group,
the
maturity
level
Team
may
republish
the
specification
had
before
publication
as
a
Note
Note:
The
W3C
Patent
Policy
[PATENT-POLICY]
with
class
1
does
not
specify
any
licensing
requirements
or
commitments
for
Working
Group
Notes.
changes
incorporated,
as
well
as
with
errata
and
Team
corrections
annotated.
6.4.
6.4.3.
Further
reading
Elevating
Group
Notes
to
W3C
Statement
status
Refer
to
"How
A
W3C
Statement
is
a
Note
that
has
been
endorsed
by
W3C
as
a
whole.
In
order
to
Organize
elevate
a
Recommendation
Track
Transition"
Note
[TRANSITION]
to
W3C
Statement
in
status,
A
group
must
:
-
show
that
the
Artdocument has received wide review . - record the group’s decision to request publication as a W3C Statement .
- show that all issues raised against the document since its first publication as a Note have been formally addressed .
-
provide
public
documentation
of
Consensusany Formal Objections .
A
Note
[GUIDE]
specifying
implementable
technology
should
not
be
elevated
to
W3C
Statement
for
practical
information
about
preparing
for
status;
if
it
does,
the
reviews
request
to
publish
as
a
Statement
must
include
rationale
for
why
it
should
be
elevated,
and
announcements
of
why
it
is
not
on
the
various
steps,
and
tips
Recommendation
track
.
Once
these
conditions
are
fulfilled,
the
Team
must
then
begin
an
Advisory
Committee
Review
on
getting
the
question
of
whether
the
document
is
appropriate
to
Recommendation
faster
publish
as
a
W3C
Statement
.
During
this
review
period,
the
Note
[REC-TIPS]
must
not
be
updated.
The
decision
to
advance
a
document
to
W3C
Statement
is
a
W3C
Decision
.
Please
see
also
Advisory
Committee
representatives
may
initiate
an
Advisory
Committee
Appeal
of
the
Requirements
for
modification
decision.
The
Team
must
announce
the
publication
of
a
W3C
Technical
Reports
Statement
[REPUBLISHING]
.
to
the
Advisory
Committee
,
other
W3C
groups,
and
the
public.
7.
6.4.4.
Advisory
Committee
Reviews,
Appeals,
and
Votes
Revising
W3C
Statements
This
section
describes
how
Given
a
recorded
group
decision
to
do
so,
groups
can
request
publication
of
a
W3C
Statement
with
editorial
changes
—
A
candidate
amendment
can
be
folded
into
the
main
text
of
the
W3C
Statement
,
once
it
has
satisfied
all
the
same
criteria
as
the
rest
of
the
Statement
,
including
review
by
the
community
to
ensure
the
substantive
and
editorial
soundness
of
the
candidate
amendments
.
To
validate
this,
the
group
must
request
an
Advisory
Committee
review
reviews
proposals
from
of
the
Director
changes
it
wishes
to
incorporate.
The
specific
candidate
amendments
and
how
under
review
must
be
identified
as
proposed
amendments
just
as
in
a
Last
Call
for
Review
of
Proposed
Corrections
.
The decision to incorporate proposed amendments into W3C Statement is a W3C Decision . Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision.
6.5. The Registry Track
A
registry
documents
a
W3C
decision
data
set
consisting
of
one
or
more
associated
registry
tables
,
each
table
representing
an
updatable
collection
of
logically
independent,
consistently-structured
registry
entries
.
A
registry
has
three
associated
components:
- the registry definition , defining how the registry tables are structured and maintained
-
one
or
Directormore registry tables , holding the data set represented by the registry's decision. A W3C decision(the registry datais) -
one
whereor more referencing specifications, which make use of theDirectorregistrydecides, after exercising
The purposes of maintaining a registry can include:
- non-collision
-
Avoiding
the
roleproblem ofassessingtwo entities using the same value with different semantics. - non-duplication
- Avoiding the problem of having two or more different values in use with the same semantics.
- information
- Providing a central index where anyone can find out what a value means and what its formal definition is (and where it is).
- submission
- Ease of adding new terms, including by stakeholders external to the custodian organization.
- consensus
- Promoting a clear consensus of the community on the terms.
This
section
of
the
W3C
Community
after
an
Advisory
Committee
review
Process
provides
a
specialized
process
facilitating
the
publication
and
maintenance
of
such
registry
tables
,
particularly
those
required
by
or
closely
related
to
W3C
Recommendations
.
Note: Not every table in a specification is a potential registry. If the intent or effect is that the table enumerates all the possibilities the authors of the specification expect or envisage, then the table by itself is enough. Similarly, if the table is managed by the Working Group and only updated as part of specification update, then the complexities of registry management are not needed.
7.1.
6.5.1.
Advisory
Committee
Reviews
Registry
Definitions
The
Advisory
Committee
reviews:
A
registry
definition
defines
what
each
registry
table
is
and
how
it
is
maintained.
It
must
:
-
newDefine the scope andmodified Workingpurpose of each registry table . -
Define
the
fields
of
each
registry
table
and
Interest Groups ,their constraints (e.g. values must be drawn from a defined set, or be unique, or only reference publicly available resources, etc.) -
Proposed Recommendations , ProposalsDefine the policy for changes toObsolete, Rescind, Supersede,existing entries, such as-
whether
entries
can
be
deleted
or
Restore Recommendations ,deprecated - whether entries can be changed after being published, and what kinds of changes are allowed
-
Proposedwhether previously-deleted unique identifiers can be re-used, or are reserved indefinitely
-
whether
entries
can
be
deleted
or
- Define the method and criteria by which changes are proposed, approved, and incorporated. (For example, a registry could define that changes to registry entries can be proposed using a particular web form or email address, that they must be accompanied by certain background information, or that they do or do not need to be approved by any member of a particular Working Group.)
-
Identify
the
W3C processcustodian of the registry table : the entity to which requests for registry changes must be sent, and which is responsible for evaluating whether such requests satisfy the criteria defined in the registry definition .The custodian may be the Working Group , the Team , or a delegated entity. The custodian for all registry tables in a single registry should generally be the same entity.
7.1.1.
6.5.2.
Start
of
a
Review
Period
Publishing
Registries
Each
Advisory
Committee
review
period
begins
with
Registries
can
be
published
either
as
a
Call
for
Review
from
the
Team
stand-alone
technical
report
to
the
Advisory
Committee
.
The
Call
for
Review
describes
on
the
proposal,
raises
attention
Registry
Track
called
a
registry
report
,
or
incorporated
as
part
of
a
Recommendation
as
a
registry
section
.
A
registry
report
or
registry
section
is
purely
documentational,
is
not
subject
to
deadlines,
estimates
when
the
decision
will
be
available,
W3C
Patent
Policy,
and
includes
other
practical
information.
Each
Member
organization
may
send
one
review,
which
must
not
be
returned
by
its
Advisory
Committee
representative
.
contain
any
requirements
on
implementations.
For
the
purposes
of
the
Patent
Policy
[PATENT-POLICY]
,
any
registry
section
in
a
Recommendation
track
document
is
not
a
normative
portion
of
that
specification.
The
Team
registry
report
or
registry
section
must
provide
two
channels
for
Advisory
Committee
review
comments:
:
-
an archived Team-onlyClearly label the registry reportchannel;/ section , its tables , and its registry definitions as such, including a link to § 6.5 The Registry Track in this Process. -
an archived Member-onlyInclude the registry definitionchannel.for each of its registry tables . -
Provide
the
registry
data
by
either:
- Including the entire contents of each registry table , either inline in the report (e.g. formatted as a table, or list, or other appropriate representation), or in a machine-readable file published as part of the technical report , or (preferably) both.
- Linking to one or more standalone Registry Data Reports containing the registry tables in human-readable form, machine-readable form, or (preferably) both.
- Include, if the registry table is provided in a machine-readable file, a definition of the format of that file.
The
Call
for
Review
Team
must
specify
which
channel
is
the
default
make
available
a
means
for
review
comments
interested
parties
to
be
notified
of
any
updates
to
a
registry
table
.
Note:
Since
the
Process
does
not
impose
requirements
on
changes
to
the
contents
of
a
registry
table
other
than
those
imposed
by
the
registry
definition
,
acceptance
of
proposed
registry
changes
on
behalf
of
the
custodian
and
publication
of
an
updated
registry
report
that
Call.
contains
only
registry
changes
since
the
previous
publication
can
be
automated
if
satisfaction
of
those
rules
can
be
automatically
verified.
Reviewers
may
send
information
Rules
for
publication
and
advancement
on
the
Registry
Track
are
identical
to
either
or
both
channels.
They
may
also
share
that
of
the
Recommendation
Track
with
the
following
exceptions:
-
Registry
reports
are
not
subject
to
the
[PATENT-POLICY]
,
and
therefore
none
of
their
reviewspublications correspond, to First Public Working Draft , Working Draft , or Patent Review Draft for the purposes of the [PATENT-POLICY] . - For the same reason, there is no equivalent to Rescinded Recommendation nor to Rescinded Candidate Recommendation for Registries .
- The equivalent of Working Draft is called Draft Registry .
-
The
equivalent
of
Candidate
Recommendation
is
called
Candidate
Registry
,
with
other Members onCandidate Recommendation Snapshot and Candidate Recommendation Draft corresponding to Candidate Registry Snapshot and Candidate Registry Draft . - The equivalent of W3C Recommendation is called W3C Registry ; Obsolete Recommendation and Superseded Recommendation correspond to Obsolete Registry and Superseded Registry .
-
There
is
no
equivalent
to
the
Proposed
Recommendation
phase.
Instead,
an
Advisory
Committee
discussion listReview is started upon publication of each Candidate Registry Snapshot .A Member organization may modify its review during a review period (e.g., -
Changes
that
add
new
features
(i.e.
class
4
changes
)
are
allowed
in
light of comments from other Members).all W3C Registries , without needing the to explicitly indicate that this is allowed.
7.1.2.
6.5.3.
After
the
Review
Period
Updating
Registry
Tables
After
Changes
to
the
review
period,
contents
of
a
registry
table
that
are
in
accordance
with
the
Director
registry
definition
,
(i.e.
Class
5
changes
must
announce
to
)
can
be
made
by
re-publishing
the
Advisory
Committee
technical
report
that
contains
the
level
of
support
affected
table,
without
needing
to
satisfy
any
other
requirements
for
the
proposal
(
consensus
or
dissent
publication
(not
even
Working
Group
consensus,
unless
this
is
required
by
the
registry
definition
).
The
Director
Such
registry
changes
must
also
indicate
whether
there
were
any
Formal
Objections
do
not
trigger
new
Advisory
Committee
Reviews
,
with
attention
to
changing
confidentiality
level
.
This
W3C
decision
nor
Exclusion
Opportunities,
and
do
not
require
approval
via
an
update
request
,
even
for
technical
reports
is
generally
one
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
following:
registry
when
the
custodian
is
another
entity.
Note:
The
proposal
custodian
is
approved,
possibly
with
editorial
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
defintion.
If
other
changes
are
desired,
they
must
be
requested
of
the
responsible
Working
Group—
Changes
to
the
registry
tables
integrated.
The
proposal
is
approved,
possibly
made
in
accordance
with
substantive
changes
candidate
integrated.
In
this
case
or
proposed
amendments
to
the
Director’s
announcement
registry
definition
which
would
not
be
allowed
by
the
unamended
registry
definition
must
include
rationale
for
the
decision
to
advance
the
document
despite
be
identified
as
such.
6.5.4. Registry Data Reports
When
the
proposal
for
registry
data
is
published
in
a
substantive
change.
The
proposal
separate
technical
report
from
its
registry
definition
,
that
report
is
returned
for
additional
work,
with
called
a
request
Registry
Data
Report
.
This
technical
report
:
-
Must
link
to
the
initiator to formally addressregistry definitioncertain issues.establishing the registry tables that it contain. -
The proposal is rejected.May contain informative introductory text, examples, and notes about the registry tables and entries that it contains. (Changes to these parts are deemed to be editorial changes ).
This
document
does
Registry
Data
Reports
do
not
specify
time
intervals
between
have
maturity
levels
in
and
of
themselves;
The
maturity
level
of
the
end
registry
whose
data
they
record
is
that
of
an
Advisory
Committee
review
the
technical
report
period
and
holding
the
W3C
decision
registry
definition
.
This
Anytime
a
change
is
made
to
ensure
that
a
registry
definition
,
the
Members
Working
Group
must
update
and
Team
republish
any
document
holding
the
corresponding
registry
tables
have
sufficient
time
to
consider
comments
gathered
during
make
it
consistent
with
these
changes.
Given
a
recorded
group
decision
to
do
so,
the
review.
The
Advisory
Committee
Working
Group
should
not
may
expect
an
announcement
sooner
than
two
weeks
after
the
end
of
a
review
period.
If,
after
three
weeks
,
the
Director
has
not
announced
republish
the
outcome,
Registry
Data
Report
to
incorporate
editorial
changes
.
If
there
is
no
Working
Group
chartered
to
maintain
this
registry,
the
Director
Team
should
may
provide
the
Advisory
Committee
with
an
update.
do
so
instead.
7.2.
6.5.5.
Appeal
by
Advisory
Committee
Representatives
Specifications
that
Reference
Registries
Advisory
Committee
representatives
Registries
document
values,
they
do
not
define
any
architectural
or
interoperability
requirements
related
to
those
values.
All
architectural
and
interoperability
requirements
pertaining
to
registry
entries
may
must
appeal
certain
decisions,
though
appeals
be
contained
in
the
specifications
that
reference
the
registry,
and
are
only
expected
therefore
subject
to
occur
the
processes
(including
approval
and
intellectual
property
provisions)
applicable
to
those
referencing
specifications.
If
there
are
entries
that
must
be
implemented,
or
any
other
such
restrictions,
they
must
be
defined
or
documented
in
extraordinary
circumstances.
the
referencing
specification
without
dependency
on
the
registry.
Basic-Method
as
defined
in
the
registry”
is
not
acceptable;
a
change
to
the
definition
of
the
Basic-Method
in
the
registry
would
then
affect
conformance.
Instead,
the
requirement
must
be
complete
in
the
specification,
directly
or
by
reference
to
another
specification.
For
example
“All
implementations
must
recognize
the
name
Basic-Method
,
and
implement
it
as
defined
by
section
yy
of
IETF
RFC
xxxx”.
(The
Registry
should
nonetheless
contain
Basic-Method
as
an
entry.)
6.6. Switching Tracks
When
Given
a
W3C
Group
decision
to
do
so,
Working
Groups
can
republish
a
technical
report
on
a
different
track
than
the
one
it
is
made
on,
under
the
following
an
Advisory
Committee
review
,
Advisory
Committee
representatives
restrictions:
-
A
technical
report
may initiate an Advisory Committee Appeal . Thesethat is or was a W3CdecisionsRecommendation , W3C Statement , or Patent Review Draftinclude those related to group creation and modification, and transitions to new maturity levels forcannot switch tracks. -
A
technical
report
should
not
switch
away
from
the
Recommendation
Track
documentswithout due consideration of the Patent Policy implications and approval of theProcess document.W3C’s legal counsel if the Working Group envisions a likelihood of returning to it later.
Advisory
Committee
representatives
may
also
initiate
an
appeal
for
certain
Director
Technical
reports
's
decisions
that
do
not
involve
an
Advisory
Committee
review
.
These
cases
are
identified
switch
tracks
start
at
their
new
track’s
initial
maturity
level,
while
retaining
any
established
identity
(url,
shortname,
etc.).
6.7. Further reading
Refer
to
"How
to
Organize
a
Recommendation
Track
Transition"
[TRANSITION]
in
the
sections
which
describe
the
requirements
Art
of
Consensus
[GUIDE]
for
practical
information
about
preparing
for
the
Director
's
decision
reviews
and
include
additional
(non-reviewed)
maturity
levels
announcements
of
the
various
steps,
and
tips
on
getting
to
Recommendation
Track
documents,
group
charter
extensions
faster
and
closures,
and
Memoranda
[REC-TIPS]
.
Please
see
also
the
Requirements
for
modification
of
Understanding
W3C
Technical
Reports
[REPUBLISHING]
.
7. Dissemination Policies
7.1. Public Communication
In
all
cases,
an
appeal
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
must
should
be
initiated
within
three
weeks
of
solicit
review
by
the
decision.
Team
prior
to
issuing
press
releases
about
their
work
within
W3C.
An
Advisory
Committee
representative
initiates
an
appeal
The
Team
by
sending
a
request
makes
every
effort
to
ensure
the
Team
.
The
request
should
say
“I
appeal
this
Director’s
Decision”
persistence
and
identify
the
decision.
Within
one
week
availability
of
the
Team
following
public
information:
-
W3C
technical
reports
must announcewhose publication has been approved. Per theappeal processMembership Agreement, W3C technical reports (and software) are available free of charge to theAdvisory Committeegeneral public; (refer to the W3C Document License [DOC-LICENSE] ). -
A
mission
statement
[MISSION]
that
explains
the
purpose
and
provide a mechanismmission of W3C, the key benefits forAdvisory Committee representativesMembers, and the organizational structure of W3C. -
Legal
documents,
including
the
Membership
Agreement
to respond[MEMBER-AGREEMENT] and documentation of any legal commitments W3C has with other entities. - The Process Document.
- Public results of W3C activities and Workshops .
To
keep
the
Members
abreast
of
W3C
meetings,
Workshops
,
and
review
deadlines,
the
Team
provides
them
with
a
statement
regular
(e.g.,
weekly)
news
service
and
maintains
a
calendar
[CALENDAR]
of
positive
support
official
W3C
events.
Members
are
encouraged
to
send
schedule
and
event
information
to
the
Team
for
inclusion
on
this
appeal.
The
archive
of
these
statements
must
be
member-only
.
If,
within
one
week
calendar.
7.2. Confidentiality Levels
There
are
three
principal
levels
of
access
to
W3C
information
(on
the
Team’s
announcement,
5%
or
more
W3C
Web
site,
in
W3C
meetings,
etc.):
public,
Member-only,
and
Team-only.
While
much
information
made
available
by
W3C
is
public,
“
Member-only
”
information
is
available
to
authorized
parties
only,
including
representatives
of
Member
organizations,
Invited
Experts
,
the
Advisory
Committee
support
Board,
the
appeal
request,
TAG,
and
the
Team
Team.
For
example,
the
charter
of
some
Working
Groups
must
may
organize
an
appeal
vote
asking
specify
a
Member-only
confidentiality
level
for
group
proceedings.
“
Team-only
”
information
is
available
to
the
Advisory
Committee
Team
and
other
authorized
parties.
Those
authorized
to
access
Member-only
“Do
you
approve
of
and
Team-only
information:
-
must
treat
the
Director’s Decision?” together with linksinformation as confidential within W3C, -
must
use
reasonable
efforts
to
maintain
the
Director 's decisionproper level of confidentiality, and -
must
not
release
this
information
to
the
appeal support.general public or press.
The
ballot
Team
must
allow
for
three
possible
responses:
“Approve”,
“Reject”,
and
“Abstain”,
together
with
Comments.
If
provide
mechanisms
to
protect
the
number
confidentiality
of
votes
Member-only
information
and
ensure
that
authorized
parties
have
proper
access
to
reject
exceeds
this
information.
Documents
should
clearly
indicate
whether
they
require
Member-only
confidentiality.
Individuals
uncertain
of
the
number
confidentiality
level
of
votes
a
piece
of
information
should
contact
the
Team.
Advisory
Committee
representatives
may
authorize
Member-only
access
to
approve,
Member
representatives
and
other
individuals
employed
by
the
decision
Member
who
are
considered
appropriate
recipients.
For
instance,
it
is
overturned.
In
the
responsibility
of
the
Advisory
Committee
representative
and
other
employees
and
official
representatives
of
the
organization
to
ensure
that
case,
there
Member-only
news
announcements
are
the
following
possible
next
steps:
The
proposal
is
rejected.
The
proposal
is
returned
distributed
for
additional
work,
after
which
the
applicable
decision
process
internal
use
only
within
their
organization.
Information
about
Member
mailing
lists
is
re-initiated.
available
in
the
New
Member
Orientation
[INTRO]
.
7.3.
Advisory
Committee
Votes
Changing
Confidentiality
Level
The
As
a
benefit
of
membership,
W3C
provides
some
Team-only
and
Member-only
channels
for
certain
types
of
communication.
For
example,
Advisory
Committee
representatives
votes
in
elections
can
send
reviews
to
a
Team-only
channel.
However,
for
seats
on
W3C
processes
with
a
significant
public
component,
such
as
the
TAG
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
Advisory
Board
,
and
in
the
event
of
an
Advisory
Committee
Appeal
public.
Similarly,
a
Working
Group
whose
proceedings
are
Member-only
achieving
must
make
public
information
pertinent
to
the
required
support
technical
report
development
process.
This
document
clearly
indicates
which
information
must
be
available
to
trigger
an
appeal
vote.
Whenever
Members
or
the
Advisory
Committee
public,
even
though
that
information
was
initially
communicated
on
Team-only
votes,
each
Member
or
group
Member-only
channels.
Only
the
Team
and
parties
authorized
by
the
Team
may
change
the
level
of
related
Members
confidentiality
of
this
information.
When
doing
so:
-
The
Team
has one vote.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, thecaseTeam 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
Advisory Boardconfidentiality, andTAG elections , “one vote” means “one vote per available seat”.without attribution to the original author.
8. Workshops and Symposia
The Team organizes Workshops and Symposia to promote early involvement in the development of W3C activities from Members and the public.
The goal of a Workshop is usually either to convene experts and other interested parties for an exchange of ideas about a technology or policy, or to address the pressing concerns of W3C Members. Organizers of the first type of Workshop may solicit position papers for the Workshop program and may use those papers to choose attendees and/or presenters.
The goal of a Symposium is usually to educate interested parties about a particular subject.
The
Call
for
Participation
in
a
Workshop
or
Symposium
may
indicate
participation
requirements
or
limits,
and
expected
deliverables
(e.g.,
reports
and
minutes).
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 a Memorandum of Understanding with another organization. For the purposes of the W3C Process a Memorandum of Understanding ( MoU ) is a formal agreement or similar contractual framework between W3C and another party or parties, other than agreements between the Hosts or between Hosts and W3C members for the purposes of membership and agreements related to the ordinary provision of services for the purposes of running W3C, that specifies rights and obligations of each party toward the others. These rights and obligations may include joint deliverables, an agreed share of technical responsibilities with due coordination, and/or considerations for confidentiality and specific IPR. The agreement may be called something other than a “Memorandum of Understanding”, and something called a “Memorandum of Understanding” may not be an MoU for the purposes of the Process.
Before signing the MoU, the Team must inform the Advisory Committee of the intent to sign and make the MoU available for Advisory Committee review ; Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to sign the MoU . Unless an appeal rejects the proposal to sign an MoU, the Director may sign the MoU on behalf of W3C. A signed Memorandum of Understanding should be made public.
Information about W3C liaisons with other organizations [LIAISON] and the guidelines W3C follows when creating a liaison is available on the Web.
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 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
Director
must
either
acknowledge
or
reject
the
Submission
request.
- If acknowledged , the Team must make the Member Submission available at the public W3C Web site, in addition to Team comments about the Member Submission .
- If rejected , the Submitter (s) may initiate a Submission Appeal to either the TAG or the Advisory Board .
- Documents in a Member Submission are developed outside of the W3C technical report development process (and therefore are not included in the index of W3C technical reports [TR] ).
- The Submission process is not a means by which Members ask for “ratification” of these documents as W3C Recommendations .
- There is no requirement or guarantee that technology which is part of an acknowledged Submission request will receive further consideration by W3C (e.g., by a W3C Working Group ).
Making
a
Member
Submission
available
at
the
W3C
website
Web
site
does
not
imply
endorsement
by
W3C,
including
the
W3C
Team
or
Members.
The
acknowledgment
of
a
Submission
request
does
not
imply
that
any
action
will
be
taken
by
W3C.
It
merely
records
publicly
that
the
Submission
request
has
been
made
by
the
Submitter.
A
Member
Submission
made
available
by
W3C
must
not
be
referred
to
as
“work
in
progress”
of
the
W3C.
The list of acknowledged Member Submissions [SUBMISSION-LIST] is available at the W3C Web site.
10.1. Submitter Rights and Obligations
When more than one Member jointly participates in a Submission request, only one Member formally sends in the request. That Member must copy each of the Advisory Committee representatives of the other participating Members, and each of those Advisory Committee representatives must confirm (by email to the Team) their participation in the Submission request.
At any time prior to acknowledgment, any Submitter may withdraw support for a Submission request (described in " How to send a Submission request " [SUBMISSION-REQ] ). A Submission request is “withdrawn” when no Submitter(s) support it. The Team must not make statements about withdrawn Submission requests.
Prior to acknowledgment, the Submitter (s) must not , under any circumstances , refer to a document as “submitted to the World Wide Web Consortium” or “under consideration by W3C” or any similar phrase either in public or Member communication. The Submitter (s) must not imply in public or Member communication that W3C is working (with the Submitter (s)) on the material in the Member Submission . The Submitter (s) may release the documents in the Member Submission to the public prior to acknowledgment (without reference to the Submission request).
After acknowledgment, the Submitter (s) must not , under any circumstances , imply W3C investment in the Member Submission until, and unless, the material has been adopted as a deliverable of a W3C Working Group .
10.1.1. Scope of Member Submissions
When a technology overlaps in scope with the work of a chartered Working Group, Members should participate in the Working Group and contribute the technology to the group’s process rather than seek publication through the Member Submission process. The Working Group may incorporate the contributed technology into its deliverables. If the Working Group does not incorporate the technology, it should not publish the contributed documents as Working Group Notes since Working Group Notes represent group output, not input to the group.
On the other hand, while W3C is in the early stages of developing a charter, Members should use the Submission process to build consensus around concrete proposals for new work.
Members should not submit materials covering topics well outside the scope of W3C’s mission [MISSION] .
10.1.2. Information Required in a Submission Request
The Submitter (s) and any other authors of the submitted material must agree that, if the request is acknowledged, the documents in the Member Submission will be subject to the W3C Document License [DOC-LICENSE] and will include a reference to it. The Submitter (s) may hold the copyright for the documents in a Member Submission.
The request must satisfy the Member Submission licensing commitments in “Licensing Commitments in W3C Submissions” in the W3C Patent Policy [PATENT-POLICY] .
The Submitter (s) must include the following information:
- The list of all submitting Members.
- Position statements from all submitting Members (gathered by the Submitter). All position statements must appear in a separate document.
- Complete electronic copies of any documents submitted for consideration (e.g., a technical specification, a position paper, etc.) If the Submission request is acknowledged, these documents will be made available by W3C and therefore must satisfy the Team’s Publication Rules [PUBRULES] . Submitters may hold the copyright for the material contained in these documents, but when made available by W3C, these documents must be subject to the provisions of the W3C Document License [DOC-LICENSE] .
The request must also answer the following questions.
- What proprietary technology is required to implement the areas addressed by the request, and what terms are associated with its use? Again, many answers are possible, but the specific answer will affect the Team’s decision.
-
What
resources,
if
any,
does
the
Submitter
intend
to
make
available
if
theW3C 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 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
Director
Team
acknowledges
a
Submission
request
by
sending
an
announcement
to
the
Advisory
Committee
.
Though
the
announcement
may
be
made
at
any
time,
the
Submitter
(s)
can
expect
an
announcement
between
four
to
six
weeks
after
the
validation
notice
.
The
Team
must
keep
the
Submitter
(s)
informed
of
when
an
announcement
is
likely
to
be
made.
Once a Submission request has been acknowledged, the Team must :
-
Make
the
Member
Submission
available
at
the
W3C
website.Web site. -
Make
the
Team
comments
about
the
Submission
request
available
at
the
W3C
website.Web site.
If the Submitter (s) wishes to modify a document made available as the result of acknowledgment, the Submitter(s) must start the Submission process from the beginning, even just to correct editorial changes .
10.4. Rejection of a Submission Request, and Submission Appeals
The 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 of the Team’s Decision to the TAG if the reasons are related to Web architecture, or to the Advisory Board if the request is rejected for other reasons. In this case the Team should make available its rationale for the rejection to the appropriate body. The Team will establish a process for such appeals that ensures the appropriate level of confidentiality .
11. Process Evolution
Revision
of
the
W3C
Process
and
related
documents
(see
below)
undergoes
similar
consensus
-building
processes
as
for
technical
reports
,
with
the
Advisory
Board
—
The documents covered by this section are:
-
the W3C Process (this document)
-
the W3C Patent Policy [PATENT-POLICY]
-
the W3C Code of Ethics and Professional Conduct [CEPC]
-
The W3C Document License [DOC-LICENSE]
The Advisory Board initiates review as follows:
- The Team sends a Call for Review to the Advisory Committee and other W3C groups.
- After comments have been formally addressed and the document possibly modified, the Team seeks endorsement from the Members by initiating an Advisory Committee review . The review period must last at least 28 days .
-
After
the
Advisory
Committee
review
,
following
a
W3C
decision
to
adopt
the
document(s),
the
Team
does
so
and
sends
an
announcement
to
the
Advisory
Committee
.
Advisory
Committee
representatives
may
initiate
an
Advisory
Committee
Appeal
to
theW3C.
Note: As of June 2020, the Patent Policy is developed in the Patents and Standards Interest Group , the Code of Ethics and Professional Conduct in the Positive Work Environment Community Group , and the Process in the W3C Process Community Group .
12. Acknowledgments
This section is non-normative.
The editors are grateful to the following people, who as interested individuals and/or with the affiliation(s) listed, have contributed to this proposal for a revised Process: Brian Kardell, Carine Bournez (W3C), Charles McCathie Nevile (ConsenSys), Chris Wilson (Google), David Singer (Apple), Delfí Ramírez, Dominique Hazaël-Massieux (W3C), Elika J. Etemad aka fantasai, Fuqiao Xue (W3C), Jeff Jaffe (W3C), Kevin Fleming (Bloomberg), Léonie Watson (The Paciello Group), Michael Champion (Microsoft), Nigel Megitt (BBC), Philippe Le Hégaret (W3C), Ralph Swick (W3C), Samuel Weiler (W3C), Sandro Hawke (W3C), Shawn Lawton Henry, Tantek Çelik (Mozilla), Virginia Fournier (Apple), Wendy Seltzer (W3C), Yves Lafon (W3C).
The editors are sorry for forgetting any names, and grateful to those who have listened patiently to conversations about this document without feeling a need to add more.
The following individuals contributed to the development of earlier versions of the Process: Alex Russell (Google), Andreas Tai (Institut fuer Rundfunktechnik), Andrew Betts (Fastly), Ann Bassetti (The Boeing Company), Anne van Kesteren, Art Barstow (Nokia, unaffiliated), Bede McCall (MITRE), Ben Wilson, Brad Hill (Facebook), Brian Kardell (JQuery), Carine Bournez (W3C), Carl Cargill (Netscape, Sun Microsystems, Adobe), Chris Lilley (W3C), Chris Wilson (Google), Claus von Riegen (SAP AG), Coralie Mercier (W3C), Cullen Jennings (Cisco), Dan Appelquist (Telefonica, Samsung), Dan Connolly (W3C), Daniel Dardailler (W3C), Daniel Glazman (Disruptive Innovations), David Baron (Mozilla), David Fallside (IBM), David Singer (Apple), David Singer (IBM), Delfí Ramírez, Dominique Hazaël-Massieux (W3C), Don Brutzman (Web3D), Don Deutsch (Oracle), Eduardo Gutentag (Sun Microsystems), Elika J. Etemad aka fantasai, Florian Rivoal, Fuqiao Xue (W3C), Geoffrey Creighton (Microsoft), Geoffrey Snedden, Giri Mandyam (Qualcomm), Gregg Kellogg, Hadley Beeman, Helene Workman (Apple), Henri Sivonen (Mozilla), Håkon Wium Lie (Opera Software), Ian Hickson (Google), Ian Jacobs (W3C), Ivan Herman (W3C), J Alan Bird (W3C), Jay Kishigami 岸上順一 (NTT), Jean-Charles Verdié (MStar), Jean-François Abramatic (IBM, ILOG, W3C), Jeff Jaffe (W3C), Jim Bell (HP), Jim Miller (W3C), Joe Hall (CDT), John Klensin (MCI), Josh Soref (BlackBerry, unaffiliated), Judy Brewer (W3C), Judy Zhu 朱红儒 (Alibaba), Kari Laihonen (Ericsson), Karl Dubost (Mozilla), Ken Laskey (MITRE), Kevin Fleming (Bloomberg), Klaus Birkenbihl (Fraunhofer Gesellschaft), Larry Masinter (Adobe Systems), Lauren Wood (unaffiliated), Liam Quin (W3C), Léonie Watson (The Paciello Group), Marcos Cáceres (Mozilla), Maria Courtemanche (IBM), Mark Crawford (SAP), Mark Nottingham, Michael Champion (Microsoft), Michael Geldblum (Oracle), Mike West (Google), Mitch Stoltz (EFF), Natasha Rooney (GSMA), Nigel Megitt (BBC), Olle Olsson (SICS), Ora Lassila (Nokia), Paul Cotton (Microsoft), Paul Grosso (Arbortext), Peter Linss, Peter Patel-Schneider, Philippe Le Hégaret (W3C), Qiuling Pan (Huawei), Ralph Swick (W3C), Renato Iannella (IPR Systems), Rigo Wenning (W3C), Rob Sanderson (J Paul Getty Trust), Robin Berjon (W3C), Sally Khudairi (W3C), Sam Ruby (IBM), Sandro Hawke (W3C), Sangwhan Moon (Odd Concepts), Scott Peterson (Google), Steve Holbrook (IBM), Steve Zilles (Adobe Systems) Steven Pemberton (CWI), TV Raman (Google), Tantek Çelik (Mozilla), Terence Eden (Her Majesty’s Government), Thomas Reardon (Microsoft), Tim Berners-Lee (W3C), Tim Krauskopf (Spyglass), Travis Leithead (Microsoft), Virginia Fournier (Apple), Virginie Galindo (Gemalto), Wayne Carr (Intel), Wendy Fong (Hewlett-Packard), Wendy Seltzer (W3C), Yves Lafon (W3C).
13. Changes
This section is non-normative.
Changes
since
the
1
March
2019
15
September
2020
Process
This
document
is
based
on
the
1
March
2019
15
September
2020
Process
.
A
Disposition
list
of
Comments
issues
addressed
,
as
well
as
a
detailed
log
of
all
changes
since
then
are
available.
See
below
for
diffs
.
A
diff
comparing
it
to
the
2019
edition
The
following
is
a
summary
of
the
Process
is
available.
Note
that
due
to
overlapping
changes,
this
diff
may
be
somewhat
difficult
to
review.
In
order
to
make
review
easier,
several
partial
diffs,
grouping
related
changes,
are
available
as
well,
as
detailed
below.
main
differences:
-
Major Update to the RecommendationRegistries TrackSignificant additions and modifications were made to the Recommendation Track. While the meaning -
Introduced
a
new
class
of
the various maturities and associated transition criteria are unchanged, important additionstechnical reports called registries , for documents that describe collections of values or other data that havebeen made to what can be done during CRno normative implementation requirements, yet need specific andREC phases. These aim to facilitate maintenance of specifications,enforceable rules about how they are updated. - Recommendation Track
-
Made
a
small
clarifications
and
minor
simplifications
to
provide a Living Standards capability as a native capability oftheW3CRecommendationTrack.Track:-
Work-in-progress updates to CRs can be published on TR as Candidate Recommendation Drafts . This allowsRetired Amended RECs: this process, which had never been used, allowed theWorking GroupTeam topublishdo update a REC with normative changes in thelatest stateabsence oftheir work anda Working Group, in order toget wide review onmaintain theofficial copy, without having to direct readers to an unofficial Editor’s Draft.document. This ability is now provided through candidate amendments . -
An
simultaneous updateincorrect use ofthe Patent Policy is planned and the Process“Proposed Additions” has beenadjusted to tie into it. Together, they provide patent protection from the CR stage, as opposed to havingcorrected towait fortheRecommendation as needed today.intended “Proposed Changes”. -
Errata and related changes can be informatively annotated inlineSome text in section § 6.3.11.4 Revising aRecommendation, and republished without W3C approval. This too allows the Working Group to publish the latest state of their work and to get wide review on the official copy, without having to direct readers to an unofficial Editor’s Draft, or separate errata documents. Once some of these candidate changesRecommendation: New Featureshave reached sufficient maturity to be part of the Recommendation, and once ithassecured the usual approvals (Director review, AC Review), the Working Group can fold them into the Recommendation asbeen rewritten to reduce redundancy with other sections, with no normativetext, republish the Recommendation directly, without intermediate publication as CR or PR.change. -
Both the addition of new candidate changesCandidate andthe normative incorporation of matureproposedchanges“changes” have been renamed intothe Recommendation can be done incrementally, allowing complex specifications to be gradually improved without having to fix everything before anything can be republished. Similarly to candidate corrections which correct errors,candidateadditionsand proposed amendments . -
Added
an
editorial
clarification
to
a Recommendation can be annotated inline, then made normative when sufficiently mature. Thiswhat islimitedsupposed toRecommendations explicitly identifying themselves as allowing new features, so ashappen toavoid breaking expectationthe status section offeature-set stability on Recommendationsunfinished technical reports thathave already been published without this note. When certain objective criteria are met, bothget abandoned .
-
- Note Track
-
Disentangled
the
CR-to-REC transition andNote Track from theREC-to-REC update can be automatically approvedRecommendation Track, andskip the usual “transition call”. Further developments in tooling may later reduce friction on this “fast-path”. Some minor simplifications have also been made:added a few capabilities:-
DropCreated dedicated status ( Discontinued Draft ) for discontinued REC Track documents, instead of using Notes for that purpose. -
Made
Draft
Note
into
its
own
status,
instead
of
using
REC
Track
Working
Draft
(which,
unlike
Notes,
is
covered
by
the
distinction between RecommendationPatent Policy, andEdited Recommendation.cannot be published by Interest Groups ) for that purpose. -
Don’t require documenting editorial changes since the previous CR. A diff comparing the state before/after these changesAllowed TAGis available. Other Substantive ChangesandClarificationsABA diff comparing the state before/after these changesto publish Notesis available. Retire the “Team Submissions” ( not “Member Submissions”) mechanism, as it is unused, does not provide(for theTeam with abilities it doesn’tTAG, this was alreadyhave, nor provides meaningful governancean allowed practice, inconsistent with the letter of theTeam’s communications.Process). -
Define that the process to revise the CEPC and Patent PolicyCreated W3C Statements , which are Notes endorsed by thesameW3C asfor revising the Processa whole, through an AC Review . -
Avoid usingDefined how technical reports can switch tracks (other than by copy & paste). -
Enabled
the
specialized term “ publish ”Team tomean anything other than putting documentsdo limited maintenance onTR.orphaned Notes.
-
- Governance and Operations
-
Avoid using the specialized term “ dissentAllowed AC representatives to designate an alternate . - Defined requirements for recording of meetings , minutes , and resolutions .
-
Defined
guidelines
for
any
tooling
”used for publication and collaboration insituations that do not involve Formal Objections.order to ensure long-lived access to W3C publications, and to enable access and effective participation by anyone. -
Phrasing clarificationsChanged how the AB selects its chair , andremovalmade sure the CEO is invited to AB meetings even if they are not the chair. -
Acknowledged
existence
of
unnecessary textpublic channels for charter comments in§ 2.5.1 Advisory Board§ 4.1 Initiating Charter Development andTechnical Architecture Group Participation Constraints§ 4.3 Advisory Committee Review of a Charter . -
Integrated
language
from
the
Patent
Policy
FAQ
allowing
prior
participants
of
a
group
that
was
just
rechartered
and
§ 7.1.2 Afterwho have not yet formally rejoined to continue to attend meetings held within a 45-day window of theReview Periodcall for participation . -
ClarifyMake sure thatappeal statementsnormative references of the Process with requirements on members aremeanteither made through (dated) references tobe member-only. Clarifydocuments thatWorking Draftscannot change or must go through formal member approval for updates .
-
- Miscellaneous editorial tweaks, clarifications, and simplifications
-
A
few
typos
and
grammatical
oddities
have
some, even if limited, standing. Resolve minor wording conflict asbeen addressed, and some parts have been rephrased or adjusted in an attempt towhether charters "should"simplify or"may" include formal voting procedures.clarify. Notably:-
Delete references to non existingThe various parts of thePatent policy, previously invoked in the TAG participation section. Remove a spurious linkdocument thatmade it look like AC-Reps were involved when participants in the TAG or AB resign.talked about discipline have been consolidated into a single section, § 3.1.1.1 Expectations and Discipline . -
Add some sub-section headingsReferences toimprove readability“short terms” andcross-section linking Clarify the rule“incomplete terms” for serving onvacant seats in § 2.5.2 Advisory Board and Technical Architecture Group Electionselected bodies have been unified to “incomplete terms”. -
Eliminate the useMentions of theundefined “minor changes” term Define and differentiate between Group Decisions and Chair Decisions. Add note clarifying when it is appropriate to useDirector which had no material effects on thesuperseding process, and when not.Process have been removed. -
Add Note aboutReplaced theflexibility of Consensus. Notable Editorial Changesvague “Other Charter” term with “ Exclusion Draft Charter ”. -
Converted the source code of the process toRemoved a stray sentence about theBikeshedold voting system. -
The
introduction
document format, improvingto theease of maintenance,document, which had been neglected for some time, has been updated andgainingreorganized to bettercross linking capabilities as wellfulfill its role as anIndex in the process. Note that while this makes no changeintroduction. - A reference to an external document detailing how to work with Horizontal Review groups has been added to § 6.2.2.1 Wide Review .
-
- Major editorial reorganization
-
In
addition
to
the
text of the process, it isindividual changes detailed above, this update includes a largechange of the source code, and source level diffs are unlikely to beeditorial reorganization ofhelp to comparethebefore and after state. A diff comparing the state before/after this change is available. Section § 6 W3C Technical Report Development Process has been reorganized, to disentangle definitionsstructure of the document. It rearranges variousmaturities fromparts of thesteps neededexisting text in order topublishcreate a more easily understandable andto transition formnavigable table of contents than the onematurity to another.we had ended up with through many years of gradual accretion of content.A diff comparingAnyone interested in thestate before/after this change is available. Note thatdetails of this reorganizationwas done prioris invited to consult the corresponding pull request in GitHub , which outlines themajorchanges at a high level in addition tothe Recommendation track mentioned earlier. Final adjustements Based onproviding acycle of reviewsource diff.
The
editorial
reorganization
was
merged
by
the
Advisory
Committee
and
Process
CG
as
the
broader
community
of
last
change
in
the
changes
described
above,
a
few
cycle,
prior
to
final
adjustments
were
made:
Clarify
review
by
the
definition
of
W3C
Decision,
to
make
it
clear
that
broader
community.
Although
this
resulting
document
is
the
Director
actually
has
decision
power,
preferred
one
to
read
and
does
take
the
input
review
in
general,
moving
significant
amounts
of
text
around
means
that
the
whole
community
into
account.
Adjust
the
wording
of
section
§ 11
full
diff
from
Process
Evolution
to
clarify
responsibilities.
Define
the
published
candidate
changes
2020
to
be
treated
as
Working
Drafts
for
the
purpose
of
the
Patent
Policy.
Remove
statement
from
introductory
text
on
the
REC
track
about
this
latest
version
is
largely
unusable.
Therefore
the
kind
last
state
of
feedback
the
AC
is
expected
Process
2021
Draft
prior
to
provide
during
the
CR
phase.
Rename
"proposed
changes"
to
"candidate
changes",
reorganization
,
as
well
as
a
diff
between
Process
2020
and
use
the
term
"proposed
changes"
to
refer
to
the
subset
which
is
under
AC
review.
Adjust
a
section
title
for
easier
referencing.
Adjust
grammar
in
a
list
pre-reorg
state
of
requirements
so
that
all
entries
have
the
same
subject.
Use
consistent
terminology
to
refer
document
are
also
available,
to
Candidate
Recommednation
Snapshotsa.
Fix
a
typo
and
use
more
appropriate
vocabulary
("previous"
rather
than
"old")
A
diff
comparing
enable
detailed
review
of
the
state
before/after
these
changes
is
available.
aside
from
the
reorganization.
Changes since earlier versions
Changes
since
earlier
version
versions
of
the
Process
are
detailed
in
the
changes
section
of
the
previous
version
of
the
Process.
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
2020Patent Policy . URL:https://www.w3.org/Consortium/Patent-Policy-20200915/https://www.w3.org/Consortium/Patent-Policy/[PATENT-POLICY-2017] - [PATENT-POLICY-2004]
- The W3C 2004 Patent Policy, Updated 2017 . URL: https://www.w3.org/Consortium/Patent-Policy-20170801/
- [PATENT-POLICY-2020]
- The W3C 2020 Patent Policy . URL: https://www.w3.org/Consortium/Patent-Policy-20200915/
- [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/rfc2119https://datatracker.ietf.org/doc/html/rfc2119 - [RFC3797]
-
D.
Eastlake
3rd.
Publicly
Verifiable
Nominations
Committee
(NomCom)
Random
Selection
.
June
2004.
Informational.
URL:
https://tools.ietf.org/html/rfc3797https://www.rfc-editor.org/rfc/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
.
URL:
https://www.w3.org/community/about/agreements/https://www.w3.org/community/about/process/ - [CALENDAR]
- Calendar of all scheduled official W3C events . URL: https://www.w3.org/participate/eventscal
- [CHAIR]
- W3C 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]
- How 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/Groupshttps://www.w3.org/groups/ - [GUIDE]
- The Art of Consensus, a guidebook for W3C Working Group Chairs and other collaborators . 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 list of current W3C Members . URL: https://www.w3.org/Consortium/Member/List
- [MEMBER-SUB]
- How to 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 Getting to Recommendation Faster . URL: https://www.w3.org/2002/05/rec-tips
- [REPUBLISHING]
- In-place modification of W3C Technical Reports . URL: https://www.w3.org/2003/01/republishing/
- [SUBMISSION-LIST]
- The list of acknowledged Member Submissions . URL: https://www.w3.org/Submission/
- [SUBMISSION-REQ]
- Make or 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/
- [TEAM-CONTACT]
- Role of the 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
§2.3§3.3.1.1 - AB Note , in §6.4.1
-
AC
,
in
§2.1§3.2.1 -
AC
Appeal
,
in
§7.2§5.9 -
AC
representative
,
in
§2.1§3.2.2 -
AC
Review
,
in
§7.1.1§5.7 -
adequate
implementation
experience
,
in
§6.2.2§6.3.2 -
Adopted
Draft
,
in
§5.2.6§4.2 -
Advisory
Board
,
in
§2.3§3.3.1.1 -
Advisory
Committee
,
in
§2.1§3.2.1 -
Advisory
Committee
Appeal
,
in
§7.2§5.9 -
Advisory
Committee
representative
,
in
§2.1§3.2.2 -
Advisory
Committee
review
,
in
§7.1.1§5.7 -
allow
new
features
,
in
§6.2.9§6.3.9 -
Amended Recommendationalt AC rep , in§6.2.1§3.2.2 - alternate AC representative , in §3.2.2
- alternate Advisory Committee representative , in §3.2.2
-
Appeal
,
in
§7.2§5.9 -
at
risk
,
in
§6.2.7§6.3.7 -
Call
for
Review
,
in
§7.1.1§5.7.1 -
candidate
addition
,
in
§6.1.5§6.2.5 -
candidate
changeamendment , in§6.1.5§6.2.5 -
candidate
correction
,
in
§6.1.5§6.2.5 -
Candidate
Recommendation
,
in
§6.2.1§6.3.1 -
Candidate
Recommendation
Draft
,
in
§6.2.1§6.3.1 -
Candidate
Recommendation
Snapshot
,
in
§6.2.1§6.3.1 - Candidate Registry , in §6.5.2
- Candidate Registry Draft , in §6.5.2
- Candidate Registry Snapshot , in §6.5.2
- CEO , in §2.2
-
Chair
,
in
§5.1§3.4.1 -
Chair
Decision
Appeal
,
in
§3.5§5.5 -
Chair Decisionschair decisions , in§3.5§5.1 -
charter
,
in
§5.2.6§4.2 - chartered groups , in §3.4
-
charter
extension
,
in
§5.2.5§4.5 -
Consensus
,
in
§3.3§5.2.1 -
CR
,
in
§6.2.1§6.3.1 - custodian , in §6.5.1
- Director , in §2.2
- Discontinued Draft , in §6.3.1
-
Dissent
,
in
§3.3§5.2.1 -
distributed
meeting
,
in
§3.2§3.1.2 - Draft Note , in §6.4.1
- Draft Registry , in §6.5.2
-
ED
,
in
§6.2.1§6.3.1 -
Editor
Draft
,
in
§6.2.1§6.3.1 -
editorial
changeschange , in§6.1.3§6.2.3 -
Editor’s
Draft
,
in
§6.2.1§6.3.1 - elected groups , in §3.3
-
errata
,
in
§6.1.4§6.2.4 -
erratum
,
in
§6.1.4§6.2.4 -
Exclusion
Draft
,
in
§5.2.6§4.2 - Exclusion Draft Charter , in §4.2
-
face-to-face
meeting
,
in
§3.2§3.1.2 -
First
Public
Working
Draft
,
in
§6.2.1§6.3.1 -
formally
addressed
,
in
§3.3.3§5.3 -
Formal
Objection
,
in
§3.3.2§5.6 - group , in §3
- group decision , in §5.1
-
Group
Decision
Appeal
,
in
§3.5§5.5 -
Group
DecisionsNote , in§3.5§6.4.1 - Host institutions , in §2.2
- Hosts , in §2.2
-
IG Note , in §6.3Interest Group Note , in§6.3§6.4.1 -
Interest
Groups
,
in
§5.2§3.4 -
Invited
Expert
in
an
Interest
Group
,
in
§5.2.1.4§3.4.3.4 -
Invited
Expert
in
a
Working
Group
,
in
§5.2.1.3§3.4.3.3 -
Last
Call
for
Review
of
Proposed
Additions
,
in
§6.2.11.5§6.3.11.5 -
Last
Call
for
Review
of
Proposed
ChangesAmendments , in§6.2.11.5§6.3.11.5 -
Last
Call
for
Review
of
Proposed
Corrections
,
in
§6.2.11.5§6.3.11.5 -
Last
Call
for
Review
of
Proposed
Corrections
and
Additions
,
in
§6.2.11.5§6.3.11.5 - liaison , in §9
- Member , in §2.1
- Member Consortia , in §2.1.2.1
- Member Consortium , in §2.1.2.1
-
Member-Only
,
in
§4.1§7.2 -
Member
representative
in
an
Interest
Group
,
in
§5.2.1.2§3.4.3.2 -
Member
representative
in
a
Working
Group
,
in
§5.2.1.1§3.4.3.1 - Member Submission , in §10
- Memoranda of Understanding , in §9
- Memorandum of Understanding , in §9
- minutes , in §3.1.2.2
- MoU , in §9
-
Note
,
in
§6.3§6.4.1 - not required , in §Unnumbered section
-
Obsolete
Recommendation
,
in
§6.2.1§6.3.1 -
Other CharterObsolete Registry , in§5.2.6§6.5.2 - participant , in §3
-
participants
in
an
Interest
Group
,
in
§5.2.1§3.4.2 -
participants
in
a
Working
Group
,
in
§5.2.1§3.4.2 -
participate
in
a
Working
Group
as
an
Invited
Expert
,
in
§5.2.1.3§3.4.3.3 -
Patent
Review
Drafts
,
in
§6.2§6.3 -
PR
,
in
§6.2.1§6.3.1 -
primary
affiliation
,
in
§2.5.2§3.3.3.3 -
proposed
additionadditions , in§6.2.11.5§6.3.11.5 -
proposed
changesamendments , in§6.2.11.5§6.3.11.5 -
proposed
corrections
,
in
§6.2.11.5§6.3.11.5 -
Proposed
Recommendation
,
in
§6.2.1§6.3.1 -
proxy
,
in
§3.4§5.2.3 -
public
participants
,
in
§5.2.1§3.4.2 -
publish
,
in
§6.1§6.2.1 -
REC
,
in
§6.2.1§6.3.1 -
Recommendation
,
in
§6.2.1§6.3.1 -
Recommendation
Track
,
in
§6.2§6.3 - Recommendation-track , in §6.3
-
REC
Track
,
in
§6.2§6.3 - registry , in §6.5
- registry change , in §6.2.3
- registry data , in §6.5
- Registry Data Report , in §6.5.4
- registry definition , in §6.5.1
- registry entry , in §6.5
- registry report , in §6.5.2
- registry section , in §6.5.2
- registry table , in §6.5
- Registry Track , in §6.5.2
- Related Member , in §2.1.2.2
-
Rescinded
Candidate
Recommendation
,
in
§6.2.1§6.3.1 -
Rescinded
Recommendation
,
in
§6.2.1§6.3.1 - resolution , in §5.1
- Statement , in §6.4.3
- submitter , in §10
- subsidiary , in §2.1.2.2
-
substantive
changeschange , in§6.1.3§6.2.3 -
substitute
,
in
§5.2.1§3.4.2 -
Superseded
Recommendation
,
in
§6.2.1§6.3.1 - Superseded Registry , in §6.5.2
- Symposia , in §8
- Symposium , in §8
-
TAG
,
in
§2.4§3.3.2.1 - TAG Note , in §6.4.1
- Team , in §2.2
-
Team
Contact
,
in
§5.1§3.4.1 - Team correction , in §6.2.5
- Team Decision , in §2.2
-
Team-Only
,
in
§4.1§7.2 -
Team
representative
in
an
Interest
Group
,
in
§5.2.1.6§3.4.3.6 -
Team
representative
in
a
Working
Group
,
in
§5.2.1.5§3.4.3.5 - Team’s Decision , in §2.2
-
Technical
Architecture
Group
,
in
§2.4§3.3.2.1 -
Technical
Report
,
in
§6.1§6.2.1 -
Transition
Requests
,
in
§6.2.3§6.3.3 -
Unanimity
,
in
§3.3§5.2.1 -
Update
Requests
,
in
§6.2.4§6.3.4 - validation notice , in §10.2
-
W3C
Candidate
Recommendation
,
in
§6.2.1§6.3.1 -
W3C
decision
,
in
§7§5.1 - W3C Director , in §2.2
- W3C Fellows , in §2.2
- W3C Group , in §3
- W3C Member , in §2.1
-
W3C
Note
,
in
§6.3§6.4.1 -
W3C
Proposed
Recommendation
,
in
§6.2.1§6.3.1 -
W3C
Recommendation
,
in
§6.2.1§6.3.1 -
W3C
Recommendation
Track
,
in
§6.2§6.3 -
W3C
TeamRegistry , in§2.2§6.5.2 -
W3C
Working DraftStatement , in§6.2.1§6.4.3 - W3C Team , in §2.2
-
WDW3C Working Draft , in§6.2.1§6.3.1 -
WG NoteWD , in§6.3§6.3.1 -
wide
review
,
in
§6.1.2.1§6.2.2.1 -
Working
Draft
,
in
§6.2.1§6.3.1 -
Working
Group
Note
,
in
§6.3§6.4.1 -
Working
Groups
,
in
§5.2§3.4 - Workshops , in §8