World Wide Web Consortium Process Document

World Wide Web Consortium Process Document
World Wide Web Consortium Process Document
1 September 2015
Superseded; see the
current W3C Process Document
This version - permanent URI:
Latest Editor's version:
Latest operative version:
Previous operative version:
1 August 2014 Process
Editor:
Charles McCathie Nevile,
andex
ндекс
Previous editor:
Ian Jacobs,
W3C
W3C
MIT
ERCIM
Keio
Beihang
), All Rights Reserved. W3C
liability
trademark
document
use
and
software licensing
rules apply. Your interactions
with this site are in accordance with our
W3C privacy statements
Abstract
The mission of the World Wide Web Consortium (
W3C
) is to lead the World Wide Web to its full potential by developing
common protocols that promote its evolution and ensure its interoperability. The W3C Process Document describes the organizational
structure of the W3C and the processes related to the responsibilities and functions they exercise to enable W3C to accomplish its
mission. This document does not describe the internal workings of the Team or W3C's public communication mechanisms.
For more information about the W3C mission and the history of W3C, please refer to
About W3C
PUB15
].
Status of this Document
This is the 1 September 2015 W3C Process Document. This
document was developed between the
W3C
Advisory Board
and
the
Revising W3C
Process Community Group
and reviewed by the W3C
Membership.
W3C, including all existing chartered groups, follows
the
most recent
operative Process Document
announced to the Membership.
Please send comments about this document to the
Revising W3C
Process Community Group
mailing
list archive
, publicly available) or to process-issues@w3.org
Member-only
list archive
The terms
must
must not
should
should not
required
, and
may
are
used in accordance with
RFC
2119
RFC2119
]. The term
not
required
is equivalent to the term
may
as defined in RFC 2119.
Some terms have been capitalized in this document (and in other W3C
materials) to indicate that they are entities with special relevance to
the W3C Process. These terms are defined herein, and readers should be
aware that the ordinary (English) definitions are incomplete for purposes
of understanding this document.
Relation of Process Document to Patent Policy
W3C Members' attention is called to the fact that provisions of the Process Document are binding on Members per the
Membership
Agreement
PUB6
]. The Patent Policy
W3C
Patent Policy
PUB33
] is incorporated by normative reference as a part of the Process Document,
and is thus equally binding.
The Patent Policy places additional obligations on Members, Team, and other participants in W3C. The Process Document does not
restate those requirements but includes references to them. The Process Document and Patent Policy have been designed so that they may
evolve independently.
In the Process Document, the term "participant" refers to an individual, not an organization.
Table of Contents
1 Introduction
2 Members, Advisory Committee, Team, Advisory Board, Technical
Architecture Group
3 General Policies for W3C Groups
4 Dissemination Policies
5 Working Groups and Interest Groups
6 W3C Technical Report Development Process
7 Advisory Committee Reviews, Appeals, and Votes
8 Workshops and Symposia
9 Liaisons
10 Member Submission Process
11 Process Evolution
12 References
13 Acknowledgments
14 Changes
Expanded table of contents
1 Introduction
2 Members, Advisory Committee, Team, Advisory Board, Technical Architecture Group
2.1 Members
2.1.1 Rights of Members
2.1.2 Related Members
2.1.3 Advisory Committee (AC)
2.2 The W3C Team
2.2.1 Team Submissions
2.3 Advisory Board (AB)
2.3.1 Advisory Board Participation
2.4 Technical Architecture Group (TAG)
2.4.1 Technical Architecture Group Participation
2.5 Advisory Board and Technical Architecture Group Participation
2.5.1 Advisory Board and Technical Architecture Group Participation
Constraints
2.5.2 Advisory Board and Technical Architecture Group Elections
2.5.3 Advisory Board and Technical Architecture Group Vacated Seats
3 General Policies for W3C Groups
3.1 Individual Participation Criteria
3.1.1 Conflict of Interest Policy
3.1.2 Individuals Representing a Member Organization
3.2 Meetings
3.3 Consensus
3.3.1 Managing Dissent
3.3.2 Recording and Reporting Formal Objections
3.3.3 Formally Addressing an Issue
3.3.4 Reopening a Decision When Presented With New Information
3.4 Votes
3.5 Appeal of a Chair's Decision
3.6 Resignation from a Group
4 Dissemination Policies
4.1 Confidentiality Levels
4.1.1 Changing Confidentiality Level
5 Working Groups and Interest Groups
5.1 Requirements for All Working and Interest Groups
5.2 Working Groups and Interest Groups
5.2.1 Working Group and Interest Group Participation Requirements
5.2.2 Working Group and Interest Group Charter Development
5.2.3 Advisory Committee Review of a Working Group or Interest Group Charter
5.2.4 Call for Participation in a Working Group or Interest Group
5.2.5 Working Group and Interest Group Charter Extension
5.2.6 Working Group and Interest Group Charters
5.2.8 Working Group and Interest Group Closure
6 W3C Technical Report Development Process
6.1 W3C Technical Reports
6.1.1 Recommendations and Notes
6.1.2 Maturity Levels
6.2 General requirements and definitions
6.2.1 General requirements for Technical Reports
6.2.2 Advancement on the Recommendation Track
6.2.2.1 Substantive Change
6.2.3 Reviews and Review Responsibilities
6.2.3.1 Wide Review
6.2.4 Implementation Experience
6.2.5 Classes of Changes to a Recommendation
6.3 Working Draft
6.3.1 First Public Working Draft
6.3.2 Revising Public Working Drafts
6.3.3 Stopping work on a specification
6.4 Candidate Recommendation
6.4.1 Revising a Candidate Recommendation
6.5 Proposed Recommendation
6.6 W3C Recommendation
6.7 Modifying a W3C Recommendation
6.7.1 Errata Management
6.7.2 Revising a Recommendation
6.8 Publishing a Working Group or Interest Group Note
6.9 Rescinding a W3C Recommendation
Further reading
7 Advisory Committee Reviews, Appeals, and Votes
7.1 Advisory Committee Reviews
7.1.1 Start of a Review Period
7.1.2 After the Review Period
7.2 Appeal by Advisory Committee Representatives
7.3 Advisory Committee Votes
8 Workshops and Symposia
9 Liaisons
10 Member Submission Process
10.1 Submitter Rights and Obligations
10.1.1 Scope of Member Submissions
10.1.2 Information Required in a Submission Request
10.2 Team Rights and Obligations
10.3 Acknowledgment of a Submission Request
10.4 Rejection of a Submission Request
11 Process Evolution
12 References
12.1 Public Resources
12.2 Member-only Resources
12.3 Other References
13 Acknowledgments
14 Changes
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.
Here is a general overview of how W3C standardizes a Web technology. In many cases, the goal of this work is a
W3C
Recommendation
, the W3C equivalent of a Web standard.
People generate interest in a particular topic (e.g., Web services). For instance, Members express interest in the form of
Member
Submissions
, and the
Team
monitors work inside and outside of W3C for signs of interest. Also, W3C is
likely to organize a
Workshop
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 on an
Advisory
Committee mailing list
), the Director announces the development of a proposal for one or more new
Interest
Group or Working Group charters
, depending on the breadth of the topic of interest. W3C Members
review
the proposed charters. When there is support within W3C for investing resources in the topic of interest, the Director approves
the 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
appeal process
for the Advisory Committee.
The other sections of the 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
(as represented by the
W3C Advisory
Committee
), the Team, and the general public.
2 Members, Advisory Committee, Team, Advisory Board, Technical Architecture Group
W3C's mission is to lead the Web to its full potential. W3C
Member
organizations provide resources to this
end, and the W3C
Team
provides the technical leadership and organization to coordinate the effort.
2.1 Members
W3C Members are primarily represented in W3C processes as follows:
The
Advisory Committee
is composed of one representative from each Member organization (refer to the
Member-only
list of
current Advisory Committee representatives
MEM1
]).
The Advisory Committee:
reviews plans for W3C at each
Advisory Committee meeting
reviews formal proposals from the W3C Director:
Charter Proposals
Proposed
Recommendations
, and
Proposed Process Documents
elects the
Advisory Board
participants other than the Advisory Board Chair.
elects 5 of the 9 participants on the
Technical Architecture Group
Advisory Committee representatives have
appeal
powers for some processes described in this document.
Representatives of Member organizations participate in
Working Groups and Interest Groups
and author
and review
technical reports
W3C membership is open to all entities, as described in "
How to
Join W3C
" [
PUB5
]; (refer to the public list of
current
W3C Members
PUB8
]). Organizations subscribe according to the
Membership
Agreement
PUB6
]. The
Team
must
ensure that
Member participation agreements remain
Team-only
and that no Member receives preferential treatment within
W3C.
W3C does not have a class of membership tailored to, or priced for individuals. However, an individual
may
join W3C as an Affiliate Member. In this case the same 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
MEM4
].
Furthermore, 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
In the case (described in paragraph 5g of the
Membership
Agreement
), where a Member organization is itself a consortium, user society, or otherwise has members or sponsors, the
organization's paid staff and Advisory Committee representative exercise all the rights and privileges of W3C membership. In
addition, the Advisory Committee representative
may
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
. These individuals
must
disclose their employment affiliation when participating in
W3C work. Provisions for
related Members
apply. Furthermore, these individuals are expected to
represent the broad interests of the W3C Member organization and not the parochial interests of their employers.
The rights and benefits of W3C membership 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 in the case of further disagreement is governed by paragraph 19 of the Membership Agreement.
Refer to the
Guidelines for Disciplinary Action
MEM14
].
2.1.2 Related Members
In the interest of ensuring the integrity of the consensus process, Member involvement in some of the processes in this document is
affected by related Member status. As used herein, two Members are related if:
Either Member is a subsidiary of the other, or
Both Members are subsidiaries of a common entity, or
The Members have an employment contract or consulting contract that affects W3C participation.
subsidiary
is an organization of which effective control and/or majority ownership rests with another, single
organization.
Related Members
must
disclose these relationships according to the mechanisms described in the
New
Member Orientation
MEM4
].
2.1.3 Advisory Committee (AC)
When an organization joins W3C (see "
How to Join W3C
" [
PUB5
]),
it
must
name its Advisory Committee representative as part of the Membership Agreement. The
New
Member Orientation
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
PUB33
].
Additional information for Members is available at the
Member Web site
MEM6
].
2.1.3.1 Advisory Committee Mailing Lists
The Team
must
provide two mailing lists for use by the Advisory Committee:
One for official announcements (e.g., those required by this document) from the Team to the Advisory Committee. This list is
read-only for Advisory Committee representatives.
One for discussion among Advisory Committee representatives. Though this list is primarily for Advisory Committee
representatives, the Team
must
monitor discussion and
should
participate in
discussion when appropriate. Ongoing detailed discussions
should
be moved to other appropriate lists
(new or existing, such as a mailing list created for a
Workshop
).
An Advisory Committee representative
may
request that additional individuals from their organization be
subscribed to these lists. Failure to contain distribution internally
may
result in suspension of
additional email addresses, at the discretion of the Team.
2.1.3.2 Advisory Committee Meetings
The Team organizes a
face-to-face meeting
for the Advisory Committee
twice
a year
. The Team appoints the Chair of these meetings (generally the CEO). At each Advisory
Committee meeting, the Team
should
provide an update to the Advisory Committee about:
Resources
The number of Full and Affiliate W3C Members.
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
MEM5
is available at the Member Web site.
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
PUB32
]. 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.
The
Director
is the lead technical architect at W3C. His 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
; "tie-breaker" for
appeal of a Working Group decision
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.
2.2.1 Team Submissions
Team members
may
request that the Director publish information at the W3C Web site. At the Director's
discretion, these documents are published as "Team Submissions". These documents are analogous to
Member
Submissions
(e.g., in
expected scope
). However, there is no additional Team comment. The
document
status section
of a Team Submission indicates the level of Team consensus about the published material.
Team Submissions are
not
part of the
technical report development process
The list of
published Team Submissions
PUB16
is available at the W3C Web site.
2.3 Advisory Board (AB)
Created in March 1998, the Advisory Board provides ongoing guidance to the Team on issues of strategy, management, legal matters,
process, and conflict resolution. The Advisory Board also serves the Members by tracking issues raised between Advisory Committee
meetings, soliciting Member comments on such issues, and proposing actions to resolve these issues. The Advisory Board manages the
evolution of the Process Document
. The Advisory Board hears appeals of
Member
Submission requests
that are 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 for the Advisory Board to use for its communication,
confidential to the Advisory Board and Team.
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
PUB30
].
2.3.1 Advisory Board Participation
The Advisory Board consists of nine elected participants and a Chair. The Team appoints the Chair of the
Advisory
Board
, who is generally the CEO.
The remaining nine 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 terms of all Advisory Board participants are for
two years
Terms are staggered so that each year, either four or five 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 Technical Architecture Group (TAG)
Created in February 2001, the mission of the TAG is stewardship of the Web architecture. There are three aspects to this mission:
to document and build consensus around principles of Web architecture and to interpret and clarify these principles when
necessary;
to resolve issues involving general Web architecture brought to the TAG;
to help coordinate cross-technology architecture developments inside and outside W3C.
The TAG hears appeals of
Member Submission requests
that are 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
PUB25
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.
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., an appeal of a
rejected Member Submission request
), 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
PUB25
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
PUB26
].
2.4.1 Technical Architecture Group Participation
The TAG consists of eight elected or appointed participants and a Chair. The Team appoints the Chair of the TAG, who is generally
the
Director
Three TAG participants are appointed by the Director. Appointees are
not required
to be on the W3C Team.
The Director
may
appoint
W3C Fellows
to the TAG.
The remaining five TAG participants are elected by the W3C Advisory Committee following the
AB/TAG
nomination and election process
With the exception of the Chair, the terms of all TAG participants are for
two years
. Terms are
staggered so that each year, either two or 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.
2.5 Advisory Board and Technical Architecture Group Participation
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
An individual participates on the Advisory Board or TAG from the moment the individual's term begins until the term ends or the
seat is
vacated
. 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
). See also the licensing obligations on TAG participants in
section
of the
W3C Patent Policy
PUB33
],
and the claim exclusion process of
section 4
2.5.1 Advisory Board and Technical Architecture Group Participation Constraints
Given the few seats available on the Advisory Board and the TAG, and in order to ensure that the diversity of W3C Members is
represented:
A Member organization is permitted at most one participant on the TAG except when having more than one participant is caused by
a change of affiliation of an existing participant. At the completion of the next regularly scheduled election for the TAG, the
Member organization
must
have returned to having at most one participant.
A Member organization is permitted at most one participant on the AB.
An individual
must not
participate on both the TAG and 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 declare one participant's seat to be vacant. When more than one individual is involved, the
verifiable
random selection procedure
described below will be used to choose one person for continued participation.
2.5.2 Advisory Board and Technical Architecture Group Elections
The Advisory Board and a portion of the Technical Architecture Group are elected by the Advisory Committee. An election begins when
the Team sends a Call for Nominations to the Advisory Committee. Any Call for Nominations specifies the number of available seats,
the deadline for nominations, and the address where nominations are sent. The Director
should
announce
appointments no later than the start of a nomination period, and generally as part of the Call for Nominations.
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
Each nomination
should
include a few informative paragraphs about the nominee.
If, after the deadline for nominations, the number of nominees is:
Equal to the number of available seats, those nominees are thereby elected. This situation constitutes a tie for the purposes of
assigning
short terms
Less than the 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 number of available seats, the Team issues a Call for Votes that includes the names of all candidates, the
number of available seats, the deadline for votes, and the address where votes are sent.
When there is a vote, each Member (or group of
related Members
may
vote
for as many candidates as there are available seats; see the section on
Advisory Committee votes
. Once the
deadline for votes has passed, the Team announces the results to the Advisory Committee. The candidates with the most votes are
elected to the available seats. In case of a tie where there are more apparent winners than available seats (e.g., three candidates
receive 10 votes each for two seats), the
verifiable random selection procedure
described below will be used
to fill the available seats.
The shortest term is assigned to the elected individual who received the fewest votes, the next shortest to the
elected individual who received the next fewest, and so on. In the case of a tie among those eligible for a short term, the
verifiable
random selection procedure
described below will be used to assign the short term.
Refer to
How to Organize an Advisory Board or TAG election
MEM15
for more details.
2.5.2.1 Verifiable Random Selection Procedure
When it is necessary to use a verifiable random selection process (e.g., in an AB or TAG election, to "draw straws" in case of a
tie or to fill a short term), W3C uses the random and verifiable procedure defined in
RFC
2777
RFC2777
]. 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) short terms. In this case,
only the names of those N individuals are provided as input to the procedure. The short terms are assigned in result order.
2.5.3 Advisory Board and Technical Architecture Group Vacated Seats
An Advisory Board or TAG participant's seat is vacated when either of the following occurs:
the participant
resigns
, or
the Chair asks the participant to
resign
When an Advisory Board or TAG participant changes affiliations, as long as
Advisory Board and TAG
participation constraints
are respected, the individual
may
continue to participate until the next
regularly scheduled election for that group. Otherwise, the seat is vacated.
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 an exceptional election if the next regularly scheduled election is fewer than
three months away.
3 General Policies for W3C Groups
This section describes general policies for W3C groups regarding participation, meeting requirements, and decision-making. These
policies apply to
participants
in the following groups:
Advisory Committee
Advisory
Board
TAG
Working Groups
, and
Interest
Groups
3.1 Individual Participation Criteria
There are three qualities an individual is expected to demonstrate in order to participate in W3C:
Technical competence in one's role
The ability to act fairly
Social competence in one's role
Advisory Committee representatives who nominate individuals from their organization for participation in W3C activities are
responsible for assessing and attesting to the qualities of those nominees.
See also the participation requirements described in
section 6
of the
W3C Patent Policy
PUB33
].
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 is clearly a function of 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
PUB23
].
3.1.2 Individuals Representing a Member Organization
Generally, individuals representing a Member in an official capacity within W3C are employees of the Member organization. However,
an Advisory Committee representative
may
designate a non-employee to represent the Member. Non-employee
Member representatives
must
disclose relevant affiliations to the Team and to any group in which the
individual participates.
In exceptional circumstances (e.g., situations that might jeopardize the progress of a group or create a
conflict
of interest
), the
Director
may
decline to allow an individual
designated by an Advisory Committee representative to participate in a group.
A group charter
may
limit the number of individuals representing a W3C Member (or group of
related
Members
).
3.2 Meetings
W3C groups (including the
Advisory Committee
Advisory Board
TAG
and
Working Groups
should
observe the meeting requirements in this section.
W3C distinguishes two types of meetings:
face-to-face meeting
is one where most of the attendees are expected to participate in the same
physical location.
distributed meeting
is one where most of the attendees are expected to participate from
remote locations (e.g., by telephone, video conferencing, or
IRC
).
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
is 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.
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 may 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.
3.3.2 Recording and Reporting Formal Objections
In the W3C process, an individual may register a Formal Objection to a decision. A
Formal Objection
to a group decision is one that the reviewer requests that the Director consider as part of evaluating the related decision (e.g.,
in response to a
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 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
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, the minority are
not required
to state the reasons for their
dissent, and the group is
not required
to record individual votes.
A group charter
should
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 a Chair's Decision
Groups resolve issues through dialog. Individuals who disagree strongly with a decision
should
with the Chair any
Formal Objections
(e.g., to a decision made as the result of a
vote
).
When group participants believe that their concerns are not being duly considered by the group, they
may
ask the
Director
(for representatives of a Member organization, via their Advisory Committee
representative) to confirm or deny the decision. The participants
should
also make their requests known to
the
Team Contact
. The Team Contact
must
inform the Director when a group
participant has raised concerns about due process.
Any requests to the Director to confirm a decision
must
include a summary of the issue (whether technical
or procedural), decision, and rationale for the objection. All counter-arguments, rationales, and decisions
must
be recorded.
Procedures for
Advisory Committee appeals
are described separately.
3.6 Resignation from a Group
A W3C Member or Invited Expert
may
resign from a group. On written notification from an Advisory
Committee representative or Invited Expert to the team, the Member and their representatives or the Invited Expert will be deemed to
have resigned from the relevant group. See section 4.2. of the
W3C Patent
Policy
PUB33
] 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
PUB18
]).
mission statement
PUB15
] 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
PUB6
]) 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
MEM3
of official W3C events. Members are encouraged to send schedule and event information to the Team for inclusion on this calendar.
4.1 Confidentiality Levels
There are three principal levels of access to W3C information (on the W3C Web site, in W3C meetings, etc.): public, Member-only,
and Team-only.
While much information made available by W3C is public,
"Member-only" information
is available to
authorized parties only, including representatives of Member organizations,
Invited Experts
, the
Advisory Board, the TAG, and the Team. For example, the
charter
of some Working Groups may specify a
Member-only confidentiality level for group proceedings.
"Team-only" information is available to the Team and other authorized parties.
Those authorized to access Member-only and Team-only information:
must
treat the information as confidential within W3C,
must
use reasonable efforts to maintain the proper level confidentiality, and
must not
release this information to the general public or press.
The Team
must
provide mechanisms to protect the confidentiality of Member-only information and ensure
that authorized parties have proper access to this information. Documents
should
clearly indicate
whether they require Member-only confidentiality. Individuals uncertain of the confidentiality level of a piece of information
should
contact the Team.
Advisory Committee representatives
may
authorize Member-only access to
Member
representatives
and other individuals employed by the Member who are considered appropriate recipients. For instance, it is
the responsibility of the Advisory Committee representative and other employees and official representatives of the organization
to ensure that Member-only news announcements are distributed for internal use only within their organization. Information about
Member mailing lists is available in the
New Member Orientation
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 W3C processes
with a significant public component, such as the technical report development process, it is also important for information that
affects decision-making to be publicly available. The Team
may
need to communicate Team-only information
to a Working Group or the public. Similarly, a Working Group whose proceedings are Member-only
must
make
public information pertinent to the technical report development process.
This document clearly indicates which information
must
be available to Members or the public, even
though that information was initially communicated on Team-only or Member-only channels. Only the Team and parties authorized by
the Team change the level of confidentiality of this information. When doing so:
The Team
must
use a version of the information that was expressly provided by the author for the new
confidentiality level. In Calls for Review and other similar messages, the Team
should
remind
recipients to provide such alternatives.
The Team
must not
attribute the version for the new confidentiality level to the author without the
author's consent.
If the author has not conveyed to the Team a version that is suitable for another confidentiality level, the Team
may
make available a version that reasonably communicates what is required, while respecting the original level of confidentiality,
and without attribution to the original author.
5 Working Groups and Interest Groups
This document defines two types of groups:
Working Groups.
Working Groups typically produce deliverables (e.g.,
Recommendation
Track technical reports
, software, test suites, and reviews of the deliverables of other groups). There are additional
participation requirements described in the
W3C Patent Policy
PUB33
].
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 about
maturity
levels for Interest Groups
5.1 Requirements for All Working and Interest Groups
Each group
must
have a charter. Requirements for the charter depend on the group type. All group
charters
must
be public (even if other proceedings of the group are
Member-only
).
Existing charters that are not yet public
must
be made public when next revised or extended (with
attention to
changing confidentiality level
).
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
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 [MEM14]
is described in the
Member guide
MEM9
].
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
is described
in the Member guide. The Chair and the Team Contact of a group
should not
be the same individual.
Each group
must
have an archived mailing list for formal group communication (e.g., for meeting
announcements and minutes, documentation of decisions, and
Formal Objections
to decisions). It is
the responsibility of the Chair and Team Contact to ensure that new participants are subscribed to all relevant mailing lists.
Refer to the list of
group mailing lists
MEM2
].
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
Working Groups
and
Interest Groups
Although Working Groups and Interest Groups have different purposes, they share some characteristics, and so are defined together
in the following sections.
5.2.1
Working Group and Interest Group Participation Requirements
There are three types of individual
participants in a Working Group
Member
representatives
Invited Experts
, and
Team representatives
(including
the
Team Contact
).
There are four types of individual
participants in an Interest Group
: the same three types as for
Working Groups plus, for an Interest Group where the only
participation requirement is mailing list
subscription
public participants
Except where noted in this document or in a group charter, all participants share the same rights and responsibilities in a
group; see also the
individual participation criteria
A participant
must
represent at most one organization in a Working Group or Interest Group.
An individual
may
become a Working or Interest Group participant at any time during the group's
existence. See also relevant requirements in
section 4.3
of the
W3C Patent Policy
PUB33
].
On an exceptional basis, a Working or Interest Group participant
may
designate a
substitute
to attend a
meeting
and
should
inform the Chair. The substitute
may
act on behalf of the participant, including for
votes
. For the substitute to vote, the participant
must
inform the Chair in writing in advance. As a courtesy to the group, if the substitute is not well-versed in the group's
discussions, the regular participant
should
authorize another participant to act as
proxy
for votes.
To allow rapid progress, Working Groups are intended to be small (typically fewer than 15 people) and composed of experts in the
area defined by the charter. In principle, Interest Groups have no limit on the number of participants. When a Working Group grows
too large to be effective, W3C
may
split it into an Interest Group (a discussion forum) and a much
smaller Working Group (a core group of highly dedicated participants).
See also the licensing obligations on Working Group participants in
section
of the
W3C Patent Policy
PUB33
],
and the patent claim exclusion process of
section 4
5.2.1.1
Member Representative
in a Working Group
An individual is a Member representative in a Working Group if all of the following conditions are satisfied:
the Advisory Committee representative of the Member in question has designated the individual as a Working Group participant,
and
the individual qualifies for
Member representation
To designate an individual as a Member representative in a Working Group
, an Advisory Committee
representative
must
provide the Chair and Team Contact with all of the following information, in
addition to any other information required by the
Call for Participation
and charter (including the
participation requirements of the
W3C Patent Policy
PUB33
]):
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
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
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 be able to participate in a Working Group as an Invited Expert
, an individual
must
do all of the following:
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
PUB17
],
accept the participation terms set forth in the charter (including the participation requirements of
section
(especially 3.4) and
section 6
(especially
6.10) of the
W3C Patent Policy
PUB33
]).
Indicate 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
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
Team Representative in a Working Group
An individual is a Team representative in a Working Group when so designated by W3C management.
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, cc'ing the group mailing list.
The Team participates in a Working Group from the moment the Director announces the creation of the group until the group closes.
5.2.1.6
Team Representative in an Interest Group
When the participation requirements exceed
Interest Group mailing list subscription
, an individual
is a Team representative in an Interest Group when so designated by W3C management.
5.2.2
Working Group and Interest Group Charter Development
W3C creates a charter based on interest from the Members and Team. The Team
must
notify the Advisory
Committee when a charter for a new Working Group or Interest Group is in development. This is intended to raise awareness, even if
no formal proposal is yet available. Advisory Committee representatives
may
provide feedback on the
Advisory Committee discussion list
W3C
may
begin work on a Working Group or Interest Group charter at any time.
5.2.3
Advisory Committee Review of a Working Group or Interest Group Charter
The Director
must
solicit
Advisory Committee review
of every new or
substantively modified Working Group or Interest Group charter. The Director is
not required
to solicit
Advisory Committee review prior to a charter extension or for minor changes. The review period
must
be
at least four weeks.
The Director's Call for Review of a substantively modified charter
must
highlight important changes
(e.g., regarding deliverables or resource allocation) and include rationale for the changes.
5.2.4
Call for Participation in a Working Group or Interest Group
After Advisory Committee review of a Working Group or Interest Group charter, the Director
may
issue a
Call for Participation to the Advisory Committee. Charters
may
be amended based on review comments
before the Director issues a Call for Participation.
For a new group, this announcement officially creates the group. The announcement
must
include a
reference to the
charter
, the name(s) of the group's
Chair(s)
, and the
name of the
Team Contact
After a Call for Participation, any
Member representatives
and
Invited
Experts
must
be designated (or re-designated).
Advisory Committee representatives
may
appeal
creation or substantive
modification of 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
appeal
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);
The scope of the group's work and criteria for success;
The duration of the group (typically from six months to two years);
The nature of any deliverables (technical reports, reviews of the deliverables of other groups, or software), expected
milestones, and the process for the group participants to approve the release of these deliverables (including public
intermediate results). A charter is
not required
to include the schedule for a review of another
group's deliverables;
Any dependencies by groups within or outside of W3C on the deliverables of this group. For any dependencies, the charter
must
specify the mechanisms for communication about the deliverables;
Any dependencies of this group on other groups within or outside of W3C. Such dependencies include interactions with
W3C
Horizontal Groups
The
level of confidentiality
of the group's proceedings and deliverables;
Meeting mechanisms and expected frequency;
If known, the date of the first
face-to-face meeting
. The date of the first face-to-face meeting
of a proposed group
must not
be sooner than
eight weeks
after the
date of the proposal.
Communication mechanisms to be employed within the group, between the group and the rest of W3C, and with the general public;
An estimate of the expected time commitment from participants;
The expected time commitment and level of involvement by the Team (e.g., to track developments, write and edit technical
reports, develop code, or organize pilot experiments).
Intellectual property information. What are the intellectual property (including patents and copyright) considerations
affecting the success of the Group? In particular, is there any reason to believe that it will be difficult to meet the
Royalty-Free licensing goals of section 2 of the
W3C Patent Policy
PUB33
]?
See also the charter requirements of
section 2
and
section
of the
W3C Patent Policy
PUB33
].
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 additional voting procedures, but those procedures
must not
conflict with the
voting requirements
of the Process Document.
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.8
Working Group and Interest Group Closure
A Working Group or Interest Group charter specifies a duration for the group. The Director, subject to
appeal
by Advisory Committee representatives,
may
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.
Closing a Working Group has implications with respect to the
W3C Patent
Policy
PUB33
].
6 W3C Technical Report Development Process
The W3C technical report development process is the set of steps and requirements followed by W3C
Working
Groups
to standardize Web technology. The W3C technical report development process is designed to
support multiple specification development methodologies
maximize
consensus
about the content of stable technical reports
ensure high technical and editorial quality
promote consistency among specifications
facilitate royalty-free, interoperable implementations of Web Standards, and
earn endorsement by W3C and the broader community.
See also the licensing goals for W3C Recommendations in
section
of the
W3C Patent Policy
PUB33
].
6.1 W3C Technical Reports
Please note that
publishing
as used in this document refers to producing a version which is listed as a W3C Technical
Report on its
Technical Reports page http://www.w3.org/TR
This chapter describes the formal requirements for publishing and maintaining a W3C Recommendation or Note.
Typically a series of Working Drafts are published, each of which refines a document under development to complete the scope of
work envisioned by a Working Group's charter. For a technical specification, once review suggests the Working Group has met their
requirements satisfactorily for a new standard, there is a Candidate Recommendation phase. This allows the entire W3C membership to
provide feedback on whether the specification is appropriate as a W3C Recommendation, while the Working Group formally collects
implementation experience to demonstrate that the specification works in practice. The next phase is a Proposed Recommendation, to
finalize the review of W3C Members. If the Director determines that W3C member review supports a specification becoming a standard,
W3C publishes it as a Recommendation.
Groups may also publish documents as W3C Notes, 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.
Some W3C Notes are developed through successive Working Drafts, with an expectation that they will become Notes, while others are
simply published. There are few formal requirements to publish a document as a W3C Note, and they have no standing as a
recommendation of W3C but are simply documents preserved for historical reference.
Individual Working Groups and Interest Groups may adopt additional processes for developing publications, so long as they do not
conflict with the requirements in this chapter.
6.1.1 Recommendations and Notes
W3C follows these steps when advancing a technical report to Recommendation.
Publication of the
First Public Working Draft
Publication of zero or more revised
Public Working Drafts
Publication of a
Candidate Recommendation
Publication of a
Proposed Recommendation
Publication as a
W3C Recommendation
Possibly, Publication as an
Edited Recommendation
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
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.1.2 Maturity Levels
Working Draft (WD)
A Working Draft is a document that W3C has published for review by the community, including W3C Members, the public, and other
technical organizations. 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. Any Working Draft not, or no longer, intended to advance to
Recommendation
should
be published as a Working Group Note. Working Drafts do not necessarily represent
a consensus of the Working Group, and do not imply any endorsement by W3C or its members beyond agreement to work on a general
area of technology.
Candidate Recommendation (CR)
A Candidate Recommendation is a document that satisfies the Working Group's technical requirements, 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
begin 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.
Provide an exclusion opportunity as per the
W3C Patent Policy
PUB33
]. A Candidate Recommendation under this process corresponds to the "Last Call Working
Draft" discussed in the Patent Policy.
Note:
Candidate Recommendations are expected to be acceptable as Recommendations. Announcement of a different
next step
should
include the reasons why the change in expectations comes at so late a stage.
Proposed Recommendation
A Proposed Recommendation is a document that has been accepted by the W3C Director as of sufficient quality to become a W3C
Recommendation. This phase establishes a deadline for the Advisory Committee review which begins with Candidate Recommendation.
Substantive changes
must
not be made to a Proposed Recommendation except by publishing a new Working
Draft or Candidate Recommendation.
W3C Recommendation (REC)
A W3C Recommendation is a specification or set of guidelines or requirements that, after extensive consensus-building, has
received the endorsement of W3C Members and the Director. W3C recommends the wide deployment of its Recommendations as standards
for the Web. The W3C Royalty-Free IPR licenses granted under the Patent Policy apply to W3C Recommendations.
Working Group Note, Interest Group Note (NOTE)
A Working Group Note or Interest Group 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.
Rescinded Recommendation
A Rescinded Recommendation is an entire Recommendation that W3C no longer endorses. See also clause 10 of the licensing
requirements for W3C Recommendations in
section 5
of
the
W3C Patent Policy
PUB33
].
Working Groups and Interest Groups
may
make available "Editor's drafts". Editor's drafts 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 General requirements and definitions
Please note that
publishing
as used in this document refers to producing a version which is listed as a W3C Technical
Report on its
Technical Reports page http://www.w3.org/TR
PUB11
].
6.2.1 General requirements for Technical Reports
Every document published as part of the technical report development process
must
be a public
document. The
index of W3C technical reports
PUB11
] 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, as a Member representative,
Team representative, or Invited Expert 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
PUB31
](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
PUB18
] is available at the W3C Web site.
6.2.2 Advancement on the Recommendation Track
For
all
requests to advance a specification to a new maturity level other than Note the Working Group:
must
record the group's decision to request advancement.
must
obtain Director approval.
must
provide public documentation of all
substantive changes
to the
technical report since the previous publication.
must
formally address
all issues raised about the document since the
previous maturity level.
must
provide public documentation of any
Formal Objections
should
provide public documentation of changes that are not substantive.
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 generally a formal
review meeting to ensure the requirements have been met before Director's approval is given.
6.2.3 Reviews and Review Responsibilities
A document is available for review from the moment it is first published. Working Groups
should
formally
address
any
substantive review comment about a technical report in a timely manner.
Reviewers
should
send substantive technical reviews as early as possible. Working Groups are often reluctant
to make
substantive changes
to a mature document, particularly if this would cause significant
compatibility problems due to existing implementation. Working Groups
should
record substantive or
interesting proposals raised by reviews but not incorporated into a current specification.
6.2.3.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 may 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
and groups identified as dependencies in the charter or identified as
liaisons
PUB29
], 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
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 four weeks). 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 may only represent comment from a
small segment of the relevant stakeholder community.
6.2.4 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, they may wish to develop tests in concert with implementation efforts.
6.2.5 Classes of Changes
This document distinguishes the following 4 classes of changes to a specification. The first two classes of change are considered
editorial changes
, the latter two
substantive changes
1. No changes to text content
These changes include fixing broken links, style sheets or invalid markup.
2. 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 are 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 dissent as to whether requirements are changed, such changes
do not belong to this class..
3. 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.
4. New features
Changes that add a new functionality, element, etc.
6.3 Working Draft
A Public Working Draft is published on the
W3C's Technical Reports page
PUB11
for review, and for simple historical reference. For all Public 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.
6.3.1 First Public Working Draft
To publish the First Public Working Draft of a document, a Working Group
must
meet the applicable
general
requirements for advancement
The Director
must
announce the publication of a First Public Working Draft publication to other W3C
groups and to the public.
Publishing the First Public Working Draft triggers a Call for Exclusions, per
section
of the
W3C Patent Policy
PUB33
].
6.3.2 Revising Public Working Drafts
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
Public Working Draft
Candidate recommendation
Working Group Note
6.3.3 Stopping Work on a specification
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. If the Director
closes
a Working Group
W3C
must
publish any unfinished specifications on the Recommendation track as
Working Group Notes
. If a Working group decides, or the Director requires, the Working Group to discontinue work
on a technical report before completion, the Working Group
should
publish the document as a
Working
Group Note
6.4 Candidate Recommendation
To publish a Candidate recommendation, in addition to meeting the
general requirements for advancement
a Working Group:
must
show that the specification has met all Working Group requirements, or explain why the
requirements have changed or been deferred,
must
document changes to dependencies during the development of the specification,
must
document how adequate
implementation experience
will be
demonstrated,
must
specify the deadline for comments, which
must
be
at least
four weeks 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 Director
must
announce the publication of a Candidate Recommendation to other W3C groups and to the
public, and
must
begin an Advisory Committee Review on the question of whether the specification is
appropriate to publish as a W3C Recommendation.
A Candidate Recommendation corresponds to a "Last Call Working Draft" as used in the
W3C
Patent Policy
PUB33
]. Publishing a Candidate Recommendation triggers a Call for Exclusions,
per
section 4
of the
W3C
Patent Policy
PUB33
].
Possible next steps:
Return to
Working Draft
A revised
Candidate Recommendation
Proposed Recommendation
(The expected next step)
Working Group Note
If there was any
dissent
to the Working Group decision to request advancement
Advisory Committee
representatives
may
appeal
the decision to advance the technical report.
6.4.1 Revising a Candidate Recommendation
If there are any
substantive changes
made to a Candidate Recommendation other than to remove
features explicitly identified as "at risk", the Working Group
must
obtain the Director's approval to
publish a revision of a Candidate Recommendation. This is because substantive changes will generally require a new Exclusion
Opportunity per
section 4
of the
W3C
Patent Policy
PUB33
]. Note that approval is
expected
to be fairly simple compared
to getting approval for a transition from Working Draft to Candidate Recommendation.
In addition the Working Group:
must
show that the revised specification meets all Working Group requirements, or explain why the
requirements have changed or been deferred,
must
specify the deadline for further comments, which
must
be
at
least
four weeks after publication, and
should
be longer for complex documents,
must
document the changes since the previous Candidate Recommendation,
must
show that the proposed changes have 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 Director
must
announce the publication of a revised Candidate Recommendation to other W3C groups and
the Public.
6.5 Proposed Recommendation
In addition to meeting the
general 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
section
of the
W3C Patent Policy
PUB33
].
A Working 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 by parties other than Advisory Committee representatives acting in their formal AC representative role,
may
have removed features identified in the Candidate Recommendation document as "at risk" without
republishing the specification as a Candidate Recommendation.
The Director:
must
announce the publication of a Proposed Recommendation to the
Advisory Committee
and
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.
Possible Next Steps:
Return to
Working Draft
Return to
Candidate Recommendation
Recommendation status
(The expected next step)
Working Group Note
6.6 W3C Recommendation
The decision to advance a document to Recommendation is a
W3C Decision
In addition to meeting the
general 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. In this case the
Advisory Committee
may
appeal
the decision,
The Director
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 an
(Edited) Recommendation
, or
may
be
rescinded
6.7 Modifying a W3C Recommendation
This section details the management of errors in, and the process for making changes to a Recommendation. Please see also the
Requirements
for modification of W3C Technical Reports
PUB35
].
6.7.1 Errata Management
Tracking errors is an important part of a Working Group's ongoing care of a Recommendation; 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
7.2.5
Classes of Changes
Working Groups
must
keep a record as errors are reported by readers and implementers. Such error reports
should
be processed no less frequently than quarterly. Readers of the Recommendation
should
be able easily to find and see the errata that apply to that specific Recommendation.
Working groups may decide how to document errata. The best practice is a document that identifies itself as based on the
Recommendation text and clearly identifies the errata and any proposed corrections; other approaches include various forms of an
errata page, possibly auto-generated from a database.
An erratum is resolved by an informative, "proposed" correction generated by the Working Group. A correction becomes part of the
Recommendation by the process for Revising a Recommendation described in the next section.
6.7.2 Revising a Recommendation
A Working group
may
request republication of a Recommendation, or W3C
may
republish a Recommendation, to make corrections that do not result in any changes to the text of the specification.
Editorial changes
to a Recommendation require no technical review of the proposed changes. A
Working Group, provided there are no votes against the resolution to publish
may
request publication of a
Proposed Recommendation
or W3C
may
publish a
Proposed
Recommendation
to make this class of change without passing through earlier maturity levels. Such publications
may
be called a
Proposed Edited Recommendation
To make corrections to a Recommendation that produce
substantive changes
but do not add new
features, or where there were votes against publishing the corrections directly as a
Proposed Recommendation
a Working Group
may
request publication of a
Candidate Recommendation
, without
passing through earlier maturity levels.
In the latter two cases, the resulting Recommendation
may
be called an
Edited
Recommendation
When requesting the publication of an edited Recommendation as described in this section, in addition to meeting the requirements
for the relevant maturity level, a Working Group
must
show that the changes to the document have received
wide review
, and
should
address all recorded errata.
For changes which introduces a new feature or features, W3C
must
follow the full process of
advancing
a technical report to Recommendation
beginning with a new First Public Working Draft.
6.8 Publishing a Working Group or Interest Group Note
Working Groups and Interest Groups publish material that is not a formal specification as Notes. This includes supporting
documentation for a specification such as explanations of design principles or use cases and requirements, non-normative guides to
good practices, as well as specifications where work has been stopped and there is no longer consensus for making them a new
standard.
In order to publish a Note, a Working Group or Interest Group:
may
publish a Note with or without its prior publication as a Working Draft.
must
record the group's decision to request publication as a Note, and
should
publish documentation of significant changes to the technical report since any previous
publication.
Possible next steps:
End state: A technical report
may
remain a Working Group Note indefinitely
A Working Group
may
resume work on technical report within the scope of its charter at any time, at
the maturity level the specification had before publication as a Note
The
W3C Patent Policy
PUB33
] does not
specify any licensing requirements or commitments for Working Group Notes.
6.9 Rescinding a W3C Recommendation
W3C
may
rescind a Recommendation, for example if the Recommendation contains many errors that conflict
with a later version or if W3C discovers burdensome patent claims that affect implementers and cannot be resolved; see the
W3C
Patent Policy
PUB33
] and in particular
section
(bullet 10) and
section 7.5
. A Working Group
may
request the Director to rescind a Recommendation which was a deliverable, or the Director
may
directly propose to rescind a Recommendation.
W3C only rescinds entire specifications. To rescind some
part
of a Recommendation, W3C follows the process for
modifying
a Recommendation
Once W3C has published a Rescinded Recommendation, future W3C technical reports
must not
include
normative references to that technical report.
To propose rescinding a W3C Recommendation, a Working Group or the Director
must
publish rationale for rescinding the Recommendation.
should
document known implementation.
In addition a Working Group requesting to rescind a Recommendation
must
show that the request to rescind has received
wide review
In addition the Director, if proposing to rescind a Recommendation
must
show that the request to rescind is based on public comment
The Director
must
announce the proposal to rescind a W3C Recommendation to other W3C groups, the public,
and the
Advisory Committee
. The announcement
must
indicate that this is a Proposal to Rescind a Recommendation
specify the deadline for review comments, which
must
be at least
four
weeks after announcing
the proposal to rescind.
identify known dependencies and solicit review from all dependent Working Groups;
solicit public review.
If there was any
dissent
in Advisory Committee reviews, the Director
must
publish the substantive content of the dissent to W3C
and
the public
, and
must
formally address
the comment at least 14
days before publication as a Rescinded Recommendation. In this case the
Advisory Committee
may
appeal
the decision.
A Rescinded Recommendation
must
be published with up to date status. The updated version
may
remove the rescinded content (i.e. the main body of the document).
Note:
the original Recommendation document will continue to be available at its
version-specific URL.
Further reading
Refer to
"How to Organize a Recommendation Track Transition"
in the
Member
guide
for practical information about preparing for the reviews and announcements of the various steps, and
tips
on getting to Recommendation faster
PUB27
].
7 Advisory Committee Reviews, Appeals, and Votes
This section describes how the Advisory Committee reviews proposals from the Director and how Advisory Committee representatives
appeal W3C decisions and decisions by the Director. A
W3C decision
is one where the Director (or
the Director's delegate) has exercised the role of assessing consensus after an
Advisory Committee review
of an
Charter Proposal
, after a
Call for Review of a Proposed Recommendation
after a
Call for Review of a Proposed Recommendation
, after a
Proposal
to Rescind a W3C Recommendation
, and after a
Proposed Process Document
review.
7.1 Advisory Committee Reviews
The Advisory Committee reviews:
new and modified Working and Interest Groups
Proposed Recommendations
Proposed Edited Recommendations
Proposal
to Rescind a Recommendation
, and
Proposed changes to the W3C process
7.1.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
review
form
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. They
may
also share
their reviews with other Members on the
Advisory Committee discussion list
A Member organization
may
modify its review during a review period (e.g., in light of comments from other
Members).
7.1.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 minor changes integrated.
The proposal is approved, possibly with
substantive changes
integrated. In this case the
Director's 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 Proposed Recommendation review period. If, after
three weeks
the Director has not announced the outcome, the Director
should
provide the Advisory Committee with an
update.
7.2 Appeal by Advisory Committee Representatives
Advisory Committee representatives
may
appeal certain decisions, though appeals are only expected to
occur in extraordinary circumstances.
When Advisory Committee review immediately precedes a decision, Advisory Committee representatives
may
only appeal when there is
dissent
. These decisions are:
Publication of a Recommendation
or
Publication of a Rescinded
Recommendation
Working or Interest Group creation
, substantive
modification
or
extension
Changes to the
W3C process
Advisory Committee representatives
may
always appeal the following decisions:
Working or Interest Group extension
or
closure
Call for Implementations
Call for Review of a Proposed Recommendation
Call
for Review of an Edited Recommendation
, or
Proposal to Rescind a Recommendation
the Director's intention to sign a
Memorandum of Understanding
with another organization.
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 (explained in detail in the
New
Member Orientation
). The Team
must
announce the appeal process to the Advisory Committee and provide
an address for comments from Advisory Committee representatives. The archive of these comments
must
be
Member-visible. 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
to approve or reject the decision.
7.3 Advisory Committee Votes
The Advisory Committee votes in
elections for seats on the TAG or Advisory Board
, and in the event
of a formal appeal of a
W3C decision
. Whenever the Advisory Committee votes, each Member or group
of
related Members
has one vote. In the case of
Advisory Board and TAG
elections
, "one vote" means "one vote per available seat".
8 Workshops and Symposia
The Team organizes
Workshops
and
Symposia
to promote early involvement in the
development of W3C activities from Members and the public.
The goal of a Workshop is usually either to convene experts and other interested parties for an exchange of ideas about a
technology or policy, or to address the pressing concerns of W3C Members. Organizers of the first type of Workshop
may
solicit position papers for the Workshop program and
may
use those papers to choose attendees and/or
presenters.
The goal of a Symposium is usually to educate interested parties about a particular subject.
The Call for Participation in a Workshop or Symposium
may
indicate participation requirements or limits,
and expected deliverables (e.g., reports and minutes). 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.
Note:
In general, W3C does not organize
conferences
. Currently, W3C presents its work to
the public at the annual World Wide Web Conference, which is coordinated by the
International World
Wide Web Conference Committee
IW3C2
).
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 and sign a
Memorandum of Understanding (
MoU
with another organization. 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; the Advisory Committee
may
appeal
Once approved, a Memorandum of Understanding
should
be made public.
Information about
W3C liaisons with other organizations
and the guidelines W3C
follows when creating a liaison [
PUB28
] 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
publish the material 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 publishes review comments on the Submitted materials for W3C Members, the public, and the media.
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 Submitter(s).
The Submission process consists of the following steps:
One of the Submitter(s) 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
publish the Member Submission at the
public W3C Web site, in addition to Team comments about the Member Submission.
If
rejected
, the Submitter(s)
may
appeal to either the
TAG
or the
Advisory Board
Note:
To avoid confusion about the Member Submission process, please note that:
Documents in a Member Submission are developed outside of W3C. These documents are
not
part of the
technical
report development process
(and therefore are not included in the
index of W3C technical
reports
). Members wishing to have documents developed outside of W3C published by W3C
must
follow
the Member Submission process.
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).
Publication of a Member Submission by W3C 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 published by W3C
must not
be referred to as "work in
progress" of the W3C.
The list of
acknowledged Member Submissions
PUB10
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
"). 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
publish the
documents in the Member Submission 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
PUB15
].
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
PUB18
] 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 of
section
3.3
of the
W3C Patent Policy
PUB33
].
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 published by W3C and therefore
must
satisfy the Communication Team's
Publication Rules
PUB31
].
Submitters may hold the copyright for the material contained in these documents, but when published by W3C, these documents
must
be subject to the provisions of the
W3C Document License
PUB18
].
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 the W3C acknowledges the Submission request and takes
action on it?
What action would the Submitter like W3C to take if the Submission request is acknowledged?
What mechanisms are there to make changes to the specification being submitted? This includes, but is not limited to, stating
where change control will reside if the request is acknowledged.
For other administrative requirements related to Submission requests, see "
How to
send a Submission request
" [
MEM8
].
10.2 Team Rights and Obligations
Although they are not technical reports, the documents in a Member Submission
must
fulfill the
requirements established by the Team, including the Team's
Publication Rules
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
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
Publish the Member Submission.
Publish Team comments about the Submission request.
If the Submitter(s) wishes to modify a document published 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
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
PUB33
],
Document
License
PUB18
], or other IPR policies.
The ideas expressed in the request are poor, might harm the Web, or run counter to
W3C's
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
appeal the rejection 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
The
W3C Process Document
undergoes similar consensus-building processes as technical reports, with
the
Advisory Board
acting as the sponsoring Working Group.
The Advisory Board initiates review of a Process Document as follows:
The Team sends a Call for Review to the Advisory Committee and other W3C groups.
After comments have been
formally addressed
and the document possibly modified, the Team seeks
endorsement from the Members by initiating an
Advisory Committee review
of a Proposed Process Document.
The review period
must
last at least
four weeks
After the Advisory Committee review
, if there is consensus, the Team enacts the new process
officially by announcing the
W3C decision
to the Advisory Committee. If there was
dissent
Advisory Committee representatives
may
appeal
the decision.
W3C
may
also modify a Process Document by following the processes for
modifying a
Recommendation
Reviews of the Process Document are not public reviews.
12 References
12.1 Public Resources
The following public information is available at the
W3C Web site
[PUB5]
How to Join W3C
[PUB6]
Membership Agreement
[PUB8]
The list of current W3C Members
[PUB9]
The list of W3C Activities
[PUB10]
The list of acknowledged Member Submissions
[PUB11]
The W3C technical reports index
[PUB13]
Submission request overview
[PUB14]
The W3C Team
[PUB15]
About the World Wide Web Consortium
[PUB16]
The list of published Team Submissions
[PUB17]
Invited expert and collaborators agreement
[PUB18]
W3C Document License
[PUB19]
W3C Software Notice and License
[PUB20]
Translations of W3C technical reports
[PUB21]
Public W3C mailing lists
[PUB23]
Conflict of Interest Policy for W3C Team Members Engaged in Outside
Professional Activities
[PUB25]
Technical Architecture Group (TAG) Charter
[PUB26]
The TAG home page
[PUB27]
Tips for Getting to Recommendation Faster
[PUB28]
W3C liaisons with other organizations
[PUB30]
The Advisory Board home page
[PUB31]
Publication Rules
[PUB32]
W3C Fellows Program
[PUB33]
5 Feb 2004 version of the W3C Patent Policy
. The
latest version of the W3C Patent Policy
is available at
[PUB35]
In-place modification of W3C Technical Reports
12.2
Member-only Resources
The following
Member-only
information is available at the
W3C Web site
[MEM1]
Current Advisory Committee representatives
[MEM2]
Group mailing lists
[MEM3]
The
calendar of all scheduled official W3C events
[MEM4]
The
New Member Orientation
, which includes an introduction to W3C
processes from a practical standpoint, including relevant email addresses.
[MEM5]
Advisory Committee meetings
[MEM6]
Member Web site
[MEM8]
How to send a Submission request
[MEM9]
The Art of Consensus
, a guidebook for W3C Working Group Chairs and other
collaborators
[MEM14]
Guidelines for Disciplinary Action
[MEM15]
How to Organize an Advisory Board or TAG election
12.3 Other References
[RFC2119]
"Key words for use in RFCs to Indicate Requirement Levels"
, S.
Bradner, March 1997.
[RFC2777]
"Publicly Verifiable Nomcom Random Selection"
, D. Eastlake 3rd,
February 2000.
13 Acknowledgments
The following individuals have contributed to this proposal for a revised Process: Daniel Appelquist (Telefonica), Art Barstow
(Nokia, unaffiliated), Robin Berjon (W3C), Judy Brewer (W3C), Marcos Cáceres (Mozilla), Wayne Carr (Intel), Michael Champion (W3C),
Mark Crawford (SAP), Karl Dubost (Mozilla), Fantasai (unaffiliated), Virginie Galindo (Gemalto), Daniel Glazman (Disruptive
Innovations), Eduardo Gutentag (unaffiiliated), Brad Hill (Facebook), Jeff Jaffe (W3C), Cullen Jennings (Cisco), Brain Kardell
(JQuery), Peter Linss (HP), Nigel Megitt (BBC), Olle Olsson (SICS), Natasha Rooney (GSMA), Sam Ruby (IBM), David Singer (Apple),
Henri Sivonen (Mozilla), Josh Soref (BlackBerry), Anne van Kesteren (Mozilla), Léonie Watson (The Paciello Group), Mike West
(Google), Chris Wilson (Google), Steve Zilles (Adobe).
The following individuals contributed to the development of earlier versions of the Process: Jean-François Abramatic (IBM, and
previously ILOG and W3C), Dan Appelquist (Telefonica), Art Barstow (Nokia), Ann Bassetti (The Boeing Company), Jim Bell (HP), Robin
Berjon (W3C), Tim Berners-Lee (W3C), Klaus Birkenbihl (Fraunhofer Gesellschaft), Don Brutzman (Web3D), Carl Cargill (Netscape, Sun
Microsystems), Wayne Carr (Intel), Marcos Cáceres (Mozilla), Michael Champion (Microsoft), Paul Cotton (Microsoft), Mark Crawford
(SAP), Tantek Çelik (Mozilla), Don Deutsch (Oracle), David Fallside (IBM), Fantasai (Mozilla), Wendy Fong (Hewlett-Packard),
Virginie Galindo (Gemalto), Daniel Glazman (Disruptive Innovations), Paul Grosso (Arbortext), Eduardo Gutentag (Sun Microsystems),
Joe Hall (CDT), Ivan Herman (W3C), Ian Hickson (Google), Steve Holbrook (IBM), Renato Iannella (IPR Systems), Ian Jacobs (W3C), Jeff
Jaffe (W3C), Cullen Jennings (Cisco), Sally Khudairi (W3C), John Klensin (MCI), Tim Krauskopf (Spyglass), Kari Laihonen (Ericsson),
Ken Laskey (MITRE), Ora Lassila (Nokia), Håkon Wium Lie (Opera Software), Chris Lilley (W3C), Bede McCall (MITRE), Giri Mandyam
(Qualcomm), Larry Masinter (Adobe Systems), Qiuling Pan (Huawei), TV Raman (Google), Thomas Reardon (Microsoft), Claus von Riegen
(SAP AG), David Singer (Apple), David Singer (IBM), Ralph Swick (W3C), Anne van Kesteren, Jean-Charles Verdié (MStar), Chris Wilson
(Google), Lauren Wood (unaffiliated), and Steve Zilles (Adobe Systems).
14 Changes
This version of the process removes
Activities and
Coordination
Groups, removes
Good Standing, and
incorporates editorial cleanups primarily to
Chapter 7
Detailed change logs
are available.
Other notable changes from the
1 August 2014 Process Document
include:
A working group can propose non-substantive editorial corrections directly as a Proposed Recommendation (
ISSUE-152
Sections above 5 have been renumbered (reduced by one since chapter 5 was removed)
More explicit mention of W3C Horizontal Groups has been made in regards to wide review and dependencies
The default channel for
AC review
has been removed in favor of a requirement for each review to specify
a default (
ISSUE-154
A procedure for
resignation
from Working and Interest Groups has been provided (
ISSUE-151
Loosen constraints on multiple employees of a single member being on the TAG
Editorial cleanups to
7.2.3.1 Wide Review
Editorial Changes to
7.7.1 Errata Management
ISSUE-141
Replace "
W3C Chair" with "CEO" throughout
Editorial tweaks to what is requested in
7.2.3.1 Wide
Review
Remove section
6.2.7 "Heartbeat" publishing requirement, redundant with the first requirement of
section 6.3.2
Various minimal editorial cleanups