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].
This is the 14 October 2005 version of the W3C Process Document. This
document has been produced by the W3C Advisory
Board and reviewed by the W3C Members
and Team.
The list of changes to the
public Process Document is available on the Web.
W3C, including all existing chartered groups, follows the most recent
operative Process Document announced to the Membership.
Please send comments about this document to process-issues@w3.org (Member-only
archive).
Additional Member-only information about the Process Document (e.g., issues
lists, Member-only drafts, and changes to Member-only drafts) is available from
the Process Plan page. General
information about W3C is available on the Web,
including information about becoming a W3C
Member.
The terms MUST, MUST NOT, SHOULD, SHOULD NOT, REQUIRED, and MAY when
highlighted (through style sheets, and in uppercase in the source) are used in
accordance with RFC 2119
[RFC2119]. The term NOT REQUIRED (not defined in RFC
2119) indicates exemption.
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.
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.
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. This was the case, for example, with Web
services.
- 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 a new Activity or
Working Group charter, depending on the
breadth of the topic of interest. An Activity
Proposal describes the scope, duration, and other characteristics of the
intended work, and includes the charters of one or more Working Groups, Interest Groups, and possibly Coordination
Groups to carry out the work. W3C Members review each Activity Proposal and the associated
Working Group charters. When there is support within W3C for investing
resources in the topic of interest, the Director approves the new Activity and
groups get down to work. For the Web Services Activity, the initial Activity
Proposal called for one Working Group to work on Web Services Architecture and
one to work on a language for Web Services Description. The Activity Proposal
also incorporated an existing Working Group (from another Activity) working on
XML Protocols.
- 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.
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.
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:
Advisory Committee representatives have appeal powers
for some processes described in this document.
- Representatives of Member organizations participate in Working Groups, Interest Groups, and Coordination 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.
Each Member organization enjoys the following rights and benefits:
Furthermore, representatives of Member organizations participate in W3C as
follows:
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].
In the interest of ensuring the integrity of the consensus process, Member
involvement in some of the processes in this document is affected by related
Member status. As used herein, two Members are related if:
- Either Member is a subsidiary of the other, or
- Both Members are subsidiaries of a common entity, or
- The Members have an employment contract or consulting contract that affects
W3C participation.
A subsidiary is an organization of which effective control and/or
majority ownership rests with another, single organization.
Related Members MUST disclose these
relationships according to the mechanisms described in the New Member Orientation [MEM4].
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].
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.
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 W3C
Chair or Chief
Operating Officer). 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 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.
The Team consists of the 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 Team is led by the Director, W3C Chair, and Chief Operating Officer.
These individuals 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 and as such, is responsible for
assessing consensus within W3C for architectural choices,
publication of technical reports, and new Activities. The Director appoints group Chairs and has the role of "tie-breaker" for questions of
Good Standing in a Working Group or appeal of a Working Group decision. The Director is generally
Chair of the TAG.
The W3C Chair
leads Member relations, and liaisons with other
organizations, governments, and the public.
The Chief Operating
Officer (COO) leads the operation of W3C as an
organization: a collection of people, Host institutions,
and processes.
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 three "Host"
institutions: 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 joint sponsorship contracts; the Hosts themselves
are not W3C Members.
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.
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].
The Advisory Board consists of nine elected participants and a Chair. The
Team appoints the Chair of the Advisory Board, who is
generally the W3C Chair.
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.
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.
- a Member-only list for discussions within the
TAG and for requests to the TAG that, for whatever reason, cannot be made on
the public list.
The TAG MAY also request the creation of
additional topic-specific, public mailing lists. For some TAG discussions
(e.g., 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].
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.
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.
Good Standing rules as defined for Working Group
participants also apply to Advisory Board and TAG participants. 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
3 of the W3C Patent
Policy [PUB33], and the claim exclusion
process of section 4.
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.
- 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
a TAG or AB participant changes jobs), one participant MUST cease TAG or 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.
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.
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.
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, for
example because the participant has failed to remain in Good Standing.
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.
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, Interest
Groups, and Coordination Groups.
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].
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].
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).
W3C groups (including the Advisory Committee,
Advisory Board, TAG, and Working Groups) SHOULD observe the
meeting requirements in this section.
W3C distinguishes two types of meetings:
- A face-to-face meeting is one
where most of the attendees are expected to participate in the same physical
location.
- A distributed
meeting is one where most of the attendees are expected to participate from
remote locations (e.g., by telephone, video conferencing, or IRC).
A Chair MAY invite an individual with a
particular expertise to attend a meeting on an exceptional basis. This person
is a meeting guest, not a group participant. Meeting
guests do not have voting rights. It is the responsibility
of the Chair to ensure that all meeting guests respect the chartered level of confidentiality and other group
requirements.
Meeting announcements SHOULD be sent to all
appropriate group mailing lists, i.e., those most relevant to the anticipated
meeting participants.
The following table lists requirements for organizing a meeting:
|
Face-to-face meetings |
Distributed meetings |
| Meeting announcement (before) |
eight weeks* |
one week* |
| Agenda available (before) |
two weeks |
24 hours (or longer if a meeting is
scheduled after a weekend or holiday) |
| Participation confirmed (before) |
three days |
24 hours |
| Action items available (after) |
three days |
24 hours |
| Minutes available (after) |
two weeks |
48 hours |
* To allow proper planning (e.g., travel arrangements), the Chair
is responsible for giving sufficient advance notice about the date and location
of a meeting. Shorter notice for a meeting is allowed provided that there are
no objections from group participants.
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, W3C Chair, 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 in Good Standing.
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.
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.
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.
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).
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.
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 in
Good Standing. 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.
Groups resolve issues through dialog. Individuals who disagree strongly with
a decision SHOULD register with the Chair any
Formal Objections (e.g., to a decision made as
the result of a vote).
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.
A W3C Member or Invited Expert MAY resign from
a group. The Team will establish administrative procedures for resignation. See
section 4.2. of the W3C
Patent Policy [PUB33] for information about
obligations remaining after resignation from certain groups.
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]).
- A 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.
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.
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.
This section describes the mechanisms for establishing consensus within the
areas of Web development the Consortium chooses to pursue. An Activity organizes the
work necessary for the development or evolution of a Web technology.
W3C starts an Activity based on interest from the Members and Team. W3C
Members build interest around new work through discussions among Advisory
Committee representatives, Chairs, and Team, and through the Submission process. The Team tracks Web developments inside
and outside W3C, manages liaisons, and organizes
Workshops.
Based on input from the Team and Members about the structure and scope of an
Activity, the Team sends an Activity Proposal
to the Advisory Committee. This is a proposal to dedicate Team and Member
resources to a particular area of Web technology or policy, and when there is
consensus about the motivation, scope, and structure of the proposed work, W3C
starts a new Activity.
Each Activity has its own structure that generally includes Working Groups,
Interest Groups, and Coordination Groups. Within the framework of an Activity,
these groups produce technical reports, review the work of other groups, and
develop sample code or test suites.
The progress of each Activity is documented in an Activity Statement. Activity
Statements describe the goals of the Activity, completed and unfinished
deliverables, changing perspectives based on experience, and future plans. At
least before each Advisory Committee meeting, the
Team SHOULD revise the Activity Statement for each
Activity that has not been closed.
Refer to the list of W3C
Activities [PUB9]. Note:
This list MAY include some Activities that began
prior to the formalization in 1997 of the Activity creation process.
The Team MUST notify the Advisory Committee
when a proposal for a new or modified Activity is in development. This is
intended to raise awareness, even if no formal proposal is yet available.
Advisory Committee representatives MAY express
their general support on the Advisory Committee
discussion list. The Team MAY incorporate
discussion points into an Activity Proposal. Refer to additional tips on getting to Recommendation
faster [PUB27].
The Director MUST solicit Advisory Committee review of every proposal to create,
substantively modify, or extend an Activity.
After a Call for Review from the Director, the Advisory Committee reviews and comments on the proposal. The review period
MUST be at least four
weeks.
The Director announces to the Advisory Committee whether there is consensus
within W3C to create or modify the Activity (possibly with changes suggested
during the review). For a new Activity, this announcement officially creates
the Activity. This announcement MAY include a
Call for Participation in any groups created as part of the
Activity.
If there was dissent, Advisory
Committee representatives MAY appeal a decision to create, modify, or extend the Activity.
Note: There is no appeal of a decision not to create
an Activity; in general, drafting a new Activity Proposal will be simpler than
following the appeal process.
Activities are intended to be flexible. W3C expects participants to be able
to adapt in the face of new ideas (e.g., Member Submission requests) and
increased understanding of goals and context, while remaining true to the
intent of the original Activity Proposal. If it becomes necessary to make
substantive changes to an Activity (e.g., because significant additional
resources are necessary or because the Activity's scope has clearly changed
from the original proposal), then the Director MUST solicit Advisory Committee
review of a complete Activity Proposal, including
rationale for the changes.
When the Director solicits Advisory Committee
review of a proposal to extend the duration of an Activity with no other
substantive modifications to the composition of the Activity, the proposal
MUST indicate the new duration and include
rationale for the extension. The Director is NOT
REQUIRED to submit a complete Activity
Proposal.
An Activity Proposal specifies a duration for the Activity. The Director,
subject to appeal by Advisory Committee
representatives, MAY close an Activity prior to
the date specified in the proposal in any of the following circumstances:
- Groups in the Activity fail to produce chartered deliverables.
- Groups in the Activity produce chartered deliverables ahead of
schedule.
- There are insufficient resources to maintain the Activity, according to
priorities established within W3C.
The Director closes an Activity by announcement to the Advisory
Committee.
An Activity Proposal defines the initial scope and structure of an Activity.
The proposal MUST include or reference the
following information:
- An Activity summary. What is the nature of the Activity (e.g., to track
developments, create technical reports, develop code, organize pilot
experiments, or for education)? Who or what group wants this (providers or
users)?
- Context information. Why is this Activity being proposed now? What is the
situation in the world (e.g., with respect to the Web community, market,
research, or society)? within the scope of the proposal? Who or what currently
exists that is pertinent to this Activity? Is the community
mature/growing/developing a niche? What competing technologies exist? What
competing organizations exist?
- A description of the Activity's scope. How might a potential Recommendation
interact and overlap with existing international standards and Recommendations?
What organizations are likely to be affected by potential overlap (see the
section on liaisons with other organizations)? What
should be changed if the Activity is approved?
- A description of the Activity's initial deployment, including:
- The duration of the Activity.
- What groups will be created as part of this
Activity and how those groups will be coordinated. For each group, the proposal
MUST include a provisional charter. Groups
MAY be scheduled to run concurrently or
sequentially (either because of a dependency or an expected overlap in
membership and the desirability of working on one subject at a time). These
charters MAY be amended based on review comments
before the Director issues a Call for Participation.
- The expected timeline of the Activity, including proposed deliverable dates
and scheduled Workshops and Symposia.
- If known, the date of the first face-to-face
meeting of each proposed group. 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 Activity Proposal.
- A summary of resources (Member, Team, administrative, technical, and
financial) expected to be dedicated to the Activity. The proposal MAY specify the threshold level of effort that Members are
expected to pledge in order for the Activity to be accepted.
- Information about known dependencies within W3C or outside of W3C.
- Intellectual property information. What are the intellectual property
(including patents and copyright) considerations affecting the success of the
Activity? 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]?
- A list of supporters and references. What community is expected to benefit
from this Activity? Are members of this community part of W3C now? Are they
expected to join the effort?
This document defines three 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 Good Standing requirements for
Working Group participation as well as 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.
- Coordination Groups. A Coordination Group manages
dependencies and facilitates communication with other groups, within or outside
of W3C.
Neither Interest Groups nor Coordination Groups publish Recommendation Track technical reports; see information
about maturity levels for Interest Groups and
Coordination 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, a Team
representative, or an Invited Expert
(invited by the Director). The requirements of this document that apply to
those types of participants apply to Chairs as well. The role of the Chair [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.
Although Working Groups and Interest Groups have different purposes, they
share some characteristics, and so are defined together in the following
sections.
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. For the purposes of Good
Standing, the regular representative and the substitute are considered the
same participant.
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 3 of
the W3C Patent Policy
[PUB33], and the patent claim exclusion process
of section
4.
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.
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.
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 3
(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.
6.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.
An individual is a Team representative in a Working Group when so designated
by W3C management.
An 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.
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.
Participation by an individual in a Working Group on an ongoing basis
implies a serious commitment to the charter, including all of the
following:
- attending most meetings of the Working Group.
- providing deliverables or drafts of deliverables in a timely fashion.
- being familiar with the relevant documents of the Working Group, including
minutes of past meetings.
- following discussions on relevant mailing list(s).
At the first Working Group meeting that follows any Call for
Participation, all participants are in Good Standing. If a Member or
Invited Expert joins the Working Group after the end of that meeting, the
Member Representative or Invited Expert does not attain Good Standing until the
start of the second consecutive meeting that individual attends.
When the Chair and the Team Contact agree, the
Chair MAY declare that a participant is no longer
in Good Standing (henceforth called "Bad Standing"). If there is disagreement
between the Chair and the Team Contact about standing, the Director determines
the participant's standing. The Chair MAY declare
a Team participant to be in Bad Standing, but it is clearly preferable for the
Chair, Team participant, and W3C management to resolve issues internally.
A participant MAY be declared in Bad Standing
in any of the following circumstances:
- the individual has missed more than one of the last three distributed meetings.
- the individual has missed more than one of the last three face-to-face meetings.
- the individual has not provided deliverables in a timely fashion twice in
sequence.
- the individual has not followed the conflict of interest
policy by disclosing information to the rest of the group.
Although all participants representing an organization SHOULD attend all meetings, attendance by one representative
of an organization satisfies the meeting attendance requirement for all
representatives of the organization.
The above criteria MAY be relaxed if the Chair
and Team Contact agree that doing so will not set back the Working Group. For
example, the attendance requirement can be relaxed for reasons of expense
(e.g., cost of travel) or scheduling (for example, an exceptional
teleconference is scheduled at 3:00 a.m. local time for the participant). It is
the responsibility of the Chair and Team Contact to apply criteria for Good
Standing consistently.
When a participant risks losing Good Standing, the Chair and Team Contact
are expected to discuss the matter with the participant and the participant's
Advisory Committee representative (or W3C management for the Team) before
declaring the participant in Bad Standing.
The Chair declares a participant in Bad Standing by informing the
participant's Advisory Committee representative and the participant of the
decision. If the Advisory Committee representative and Chair differ in opinion,
the Advisory Committee representative MAY ask the
Director to
confirm or deny the decision. Invited Experts
declared in Bad Standing MAY appeal to the
Director.
The Chair and Team Contact restore Good Standing and SHOULD do so when the individual in Bad Standing satisfies the
above criteria. The Chair MUST inform the
individual's Advisory Committee representative of any change in standing.
When a Member representative permanently replaces another (i.e., is not
simply a temporary substitute), the new
participant inherits the standing of the departing participant.
Changes in an individual's standing in a Working Group have no effect on the
obligations associated with Working Group participation that are described in
the W3C Patent Policy
[PUB33].
Note: In general, the time commitment for participating in
an Interest Group is less than that for a Working Group; see the section on
participation provisions in an Interest
Group charter.
The Team MUST notify the Advisory Committee
when a charter for a new Working Group or Interest Group is in development. The
suggestions for building support around an Activity Proposal apply to charters as well.
W3C MAY begin work on a Working Group or
Interest Group charter at any time. A Working Group or Interest Group
MUST be part of an approved Activity.
6.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 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.
After Advisory Committee review of a Working Group or Interest Group
charter, the Director MAY issue a Call for
Participation to the Advisory Committee. For a new group, this announcement
officially creates the group. The announcement MUST include a reference to the charter, the name(s) of the group's Chair(s), and the name 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.
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, which MUST NOT exceed the duration of
the Activity to which the group belongs. 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.
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.
For example, one group's charter might specify that another group is expected
to review a technical report before it can become a Recommendation. For any
dependencies, the charter MUST specify when
required deliverables are expected from the other groups. The charter
SHOULD set expectations about how coordination
with those groups will take place; see the section on liaisons with other organizations. Finally, the charter
SHOULD specify expected conformance to the
deliverables of the other groups;
- The level of confidentiality of the
group's proceedings and deliverables;
- Meeting mechanisms and expected frequency;
- 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).
See also the charter requirements of section 2 and
section
3 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).
It is important that a Working Group keep the Membership and public informed
of its activity and progress. To this end, each Working Group SHOULD publish in the W3C
technical reports index a new draft of each active technical
report at least once every three months. An active technical report is a
Working Draft, Candidate Recommendation, Proposed Recommendation, or Proposed
Edited Recommendation. Each Working Group MUST
publish a new draft of at least one of its active technical reports on
the W3C technical reports index [PUB11] at least once every three months.
Public progress reports are also important when a Working Group does not
update a technical report within three months (for example, when the delay is
due to a challenging technical issue) or when a Working Group has no active
technical reports (for example, because it is developing a test suite).
In exceptional cases, the Chair MAY ask the
Director to be excused from this publication requirement. However, in this
case, the Working Group MUST issue a public status
report with rationale why a new draft has not been published.
There are several reasons for this Working Group "heartbeat"
requirement:
- To promote public accountability;
- To encourage Working Groups to keep moving forward, and to incorporate
their decisions into readable public documents. People cannot be expected to
read several months of a group's mailing list archive to understand where the
group stands;
- To notify interested parties of updated work in familiar a place such as
the W3C home page and index of technical reports.
As an example, suppose a Working Group has one technical report as a
deliverable, which it publishes as a Proposed Recommendation. Per the heartbeat
requirement, the Working Group is required to publish a new draft of the
Proposed Recommendation at least once every three months, even if it is only to
revise the status of the Proposed Recommendation document (e.g., to provide an
update on the status of the decision to advance). The heartbeat requirement
stops when the document becomes a Recommendation (or a Working Group Note).
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 Activity to which the group belongs terminates.
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].
W3C Activities interact in many ways. There are dependencies between groups
within the same Activity or in different Activities. There are also
dependencies between W3C Activities and the activities of other organizations.
Examples of dependencies include the use by one technology of another being
developed elsewhere, scheduling constraints between groups, and the
synchronization of publicity for the announcement of deliverables. Coordination
Groups are created to manage dependencies so that issues are resolved fairly
and the solutions are consistent with W3C's mission and results.
Where a Coordination Group's scope covers two groups with unresolved
disputes or tensions, it is the first locus of resolution of these
disputes.
There are four types participants
in a Coordination Group: the Chair, the Chair
of each coordinated group (to promote effective communication among the
groups), Invited Experts (e.g., liaisons to groups inside or outside W3C), and
Team representatives (including the Team Contact).
The requirements for Invited Expert participation are the same as for an
Invited Expert in a Working Group.
Coordination Group participants MUST follow the
conflict of interest policy by disclosing information to the
rest of the group.
There are no Good Standing requirements for Coordination Group
participation; regular participation in a relevant Coordination Group is one of
the roles of a group Chair [MEM14].
The Director creates or modifies a Coordination Group by sending the
Coordination Group charter to the Advisory Committee.
A Coordination Group MAY be created as part of an
Activity Proposal (for example to coordinate
other groups in the Activity or to draw up charters of future groups), or
during the life of an Activity when dependencies arise. A Coordination Group
MAY operate as part of several W3C Activities.
A Coordination Group SHOULD close when there is
no longer a perceived need for coordination.
A Coordination Group charter MUST include all
of the following information:
- The group's mission;
- The scope of the group's work, including the names of coordinated groups
and contact information for those groups;
- Any dependencies by groups within or outside of W3C on this group;
- Any dependencies of this group on other groups within or outside of W3C;
see the section on liaisons with other
organizations.
- The level of confidentiality of the
group's proceedings;
- Meeting mechanisms and expected frequency;
- 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 level of involvement by the Team.
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.
The W3C technical report development process is the set of steps and
requirements followed by W3C Working Groups to
standardize Web technology. The processes followed by a Working Group to manage
specifications and guidelines -- called technical reports in this section --
include:
The W3C technical report development process is designed to maximize
consensus about
the content of a technical report, to ensure high technical and editorial
quality, to promote consistency among specifications, and to earn endorsement
by W3C and the broader community. See also the licensing goals for W3C
Recommendations in section 2 of the
W3C Patent Policy
[PUB33].
The following sections describe:
- the steps of the technical report development process (e.g., "Announcement
of Last Call" or "Call for Implementations"),
- the requirements for each step, and
- the maturity level of a technical report at
each step (e.g., "Working Draft" or "Candidate Recommendation"). Please note
that there is not a one-to-one correspondence between steps of the technical
report development process and maturity levels.
Maturity levels are described first, followed by the steps of the technical
report development process and the requirements for each step.
The maturity level of a published technical report indicates its place in
the development process. The maturity levels "Working Draft" and "Working Group
Note" represent the possible initial
states of a technical report in the development process. The maturity
levels "Recommendation," "Working Group Note," and "Rescinded Recommendation"
represent the possible end
states.
- 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.
In addition to Working Drafts that are meant to advance to Recommendation,
the other maturity levels of the Recommendation Track are:
- Candidate Recommendation (CR)
- A Candidate Recommendation is a document that W3C believes has been widely
reviewed and satisfies the Working Group's technical requirements. W3C
publishes a Candidate Recommendation to gather implementation experience.
- Proposed Recommendation (PR)
- A Proposed Recommendation is a mature technical report that, after wide
review for technical soundness and implementability, W3C has sent to the W3C
Advisory Committee for final endorsement.
- W3C Recommendation (REC)
- A W3C Recommendation is a specification or set of guidelines that, after
extensive consensus-building, has received the endorsement of W3C Members and
the Director. W3C recommends the wide deployment of its Recommendations.
Note: W3C Recommendations are similar to the standards
published by other organizations.
- Working Group Note
- A Working Group Note is published by a chartered Working Group to indicate
that work has ended on a particular topic. A Working Group MAY publish a Working Group Note with or without its prior
publication as a Working Draft.
Note: To avoid confusion in the developer community and the
media about which documents represent the output of chartered groups and which
documents are input to W3C Activities (Member
Submissions and Team Submissions), W3C has
stopped using the unqualified maturity level "Note."
- Proposed Edited
Recommendation
- A Proposed Edited Recommendation is a Recommendation published for
community review of changes, some of which
may affect conformance. When there is consensus about the changes, the document
is published as a Recommendation.
- Rescinded Recommendation
- A Rescinded Recommendation is an entire Recommendation that W3C no longer
endorses.
W3C MAY also publish "Interest Group Notes" and
"Coordination Group Notes". Because the label "W3C Working Draft" is so
strongly associated with W3C Working Group deliverables (especially those on
the Recommendation Track), W3C publishes "Interest/Coordination Group Notes"
for both ongoing and completed work by those groups.
In preparation for advancement to Candidate Recommendation or subsequent
maturity levels up to and including publication as a Recommendation, the
Working Group MUST:
- Record the group's decision to request advancement.
- Provide public documentation of all changes (both substantive and minor) to
the technical report since the previous step. A substantive change (whether deletion, inclusion, or
other modification) is one where someone could reasonably expect that making
the change would invalidate an individual's review or implementation
experience. Other changes (e.g., clarifications, bug fixes, editorial repairs,
and minor error corrections) are minor
changes.
- Report which, if any, of the Working Group's requirements for this document
have changed since the previous step.
- Report any changes in dependencies with other groups.
- Show evidence of wide review.
- Formally address all issues raised about the
document since the previous step.
- Report any Formal Objections.
The following information is important to the decision to advance a
technical report and therefore MUST be publicly available:
- Documentation of all changes to the technical report (e.g., by providing
"diffs" in addition to summaries of substantive
changes);
- A statement that all requirements have been fulfilled or a listing of
unfulfilled requirements and the rationale for advancing the document though
some requirements have not been met.
- Evidence of wide review and that dependencies with other groups have been
resolved;
- All responses that formally address issues
raised by reviewers;
- All Formal Objections.
Refer to "How to Organize a Recommendation
Track Transition" in the Member
guide for practical guidance on satisfying these requirements.
Experience shows that the following help build consensus around technical
reports:
- Frequent publication (see the Working Group
"Heartbeat" requirement).
- Early review, to find errors quickly and decrease the chances of diverging
technologies.
- Wide review, including from other groups in and outside of W3C.
A document receives review from the moment it is first published. Starting
with the First Public Working Draft until the start of a Last Call review, a
Working Group SHOULD formally address any substantive review comment
about a technical report and SHOULD do so in a
timely manner.
Starting with a Last Call review up to the transition to Proposed
Recommendation, a Working Group MUST formally address any substantive review comment
about a technical report and SHOULD do so in a
timely manner. When a Working Group requests to advance to Candidate
Recommendation or beyond, the Director expects positive documentation that
issues have been formally addressed (e.g., in an issues list that shows their
disposition).
The Director MUST formally address any
substantive issue raised by Advisory Committee representatives during Proposed
Recommendation, Proposed Edited Recommendation, and Proposed Rescinded
Recommendation review periods. The Working Group MUST communicate to the Director (usually through the Team
Contact) any substantive issues raised during Proposed Recommendation, Proposed
Edited Recommendation, and Proposed Rescinded Recommendation review periods by
parties other than Advisory Committee representatives.
Reviewers SHOULD NOT send substantive technical
reviews late on the Recommendation track. Reviewers SHOULD NOT expect that a Working Group will readily make
substantive changes to a mature document. The
more evidence a Working Group can show of wide review, the less weight
substantive comments will carry when provided late on the Recommendation Track.
Worthy ideas SHOULD BE recorded even when not
incorporated into a mature document.
The Working Group MUST be able to show evidence
of having attempted to respond to and satisfy reviewers. Reviewers MAY register a Formal Objection
any time they are dissatisfied with how a Working Group has handled an
issue.
A Working Group SHOULD negotiate review
schedules with other groups expected to review a document, including relevant
liaisons.
There are two formal review periods with fixed durations when advancing to
Recommendation: after a Last Call announcement and after a Call for Review of a
Proposed Recommendation. Out of consideration for the Working Group, reviewers
SHOULD send their comments early in a review
period. A Working Group SHOULD NOT start a new
review before the scheduled end of an ongoing review (e.g., do not start a new
Last Call review before the scheduled end of an ongoing Last Call review).
Ordinarily, reviewers SHOULD NOT raise
substantive technical issues about a technical report after the end of a Last
Call review period. However, this does occur, and as stated above, a Working
Group's requirement to formally address those issues extends until the start of
a Proposed Recommendation review period. However, to allow the Working Group to
make progress on a technical report, the Working Group MAY decline to make substantive changes to address issues
raised between the end of a Last Call review period and publication of a
Recommendation. A reviewer MAY register a Formal Objection.
Advisory Committee representatives SHOULD NOT
(but MAY) raise new substantive technical issues
during a Proposed Recommendation review period. The Director MAY respond to the reviewer after the close of the Proposed
Recommendation review period. Note: It may be necessary to
change confidentiality level when
conveying issues raised by Advisory Committee representatives to the Working
Group.
During review by the Members, the Working Group SHOULD also formally address
informed and relevant issues raised outside the Advisory Committee (e.g., by
the public or another W3C Working Group), and report them to the Director in a
timely fashion.
When a Working Group receives a substantive issue after the end of Proposed
Recommendation review period, the Working Group MUST respond to the reviewer but MAY decline to formally address
the issue. In this case, the Working Group MAY
consider the issue as part of tracking errata.
W3C follows these steps when advancing a technical report to
Recommendation.
- Publication of the First Public Working Draft.
- Last Call announcement
- Call for Implementations. Note: The
Director MAY permit the Working Group to skip this
step if the entrance criteria for the next step have already been
satisfied.
- Call for Review of a Proposed Recommendation.
- Publication as a Recommendation.
In general, Working Groups embark on this journey with the intent of
publishing one or more Recommendations. However, W3C MAY end work on a technical report at
any time, or MAY require a Working Group to
conduct further work, possibly repeating one or
more steps.
Between publication of the First Public Working Draft and Last Call
announcement, a Working Group publishes revisions that generally include
substantive changes. Between any two steps after a Last Call announcement, the
Working Group MAY publish a new draft of the
technical report at the same maturity level provided there are no substantive changes since the earlier step.
The Team MUST notify the Advisory
Committee and other W3C groups of a revision to a Candidate Recommendation
or Proposed Recommendation.
These steps of the technical report development process can take
considerable time, so participants are encouraged to read the tips on getting to Recommendation
faster [PUB27].
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.
Document maturity level: Working Draft.
Announcement: The Director MUST announce the
first Working Draft publication to other W3C groups and to the public.
Purpose: The publication of the First Public Working Draft is a signal to
the community to begin reviewing the document. See section 4.1 of
the W3C Patent Policy [PUB33] for
information about the policy implications of the First Public Working
Draft.
Entrance criteria: The Chair MUST record the
group's decision to request advancement. Since this is the first time that a
document with this short name appears in the Technical Reports index, Director
approval is REQUIRED for the transition.
Ongoing work: After publication of the First Public Working Draft, the
Working Group generally revises the technical report (see the Working Group "Heartbeat" Requirement) in accordance
with its charter.
In order to make Working Drafts available to a wide audience early in their
development, the requirements for publication of a Working Draft are limited to
an agreement by a chartered Working Group to publish the technical report and
satisfaction of the Team's Publication Rules [PUB31]. Consensus is not a prerequisite for approval to
publish; the Working Group MAY request publication
of a Working Draft even if it is unstable and does not meet all Working Group
requirements.
Working Groups SHOULD encourage early and wide
review of the technical report, within and outside of W3C, especially from
other Working Groups with dependencies on the technical report. Advisory
Committee representatives SHOULD encourage review
within their organizations as early as First Public Working Draft, i.e., before
a Last Call announcement and well before a
Call for Review of a Proposed Recommendation.
The Working Group SHOULD be responsive to and
facilitate ongoing review by addressing issues in a timely manner and clearly
indicating changes between drafts (e.g., by providing "diffs" and summaries of
substantive changes).
Possible next steps:
Document maturity level: Working Draft.
Announcement: The Working Group MUST announce
the Last Call to other W3C groups and to the public. A Last Call announcement
MUST:
- specify the deadline for review comments;
- identify known dependencies and solicit review from all dependent Working
Groups;
- solicit public review.
Purpose: A Working Group's Last Call announcement is a signal that:
- the Working Group believes that it has satisfied its relevant technical
requirements (e.g., of the charter or requirements document) in the Working
Draft;
- the Working Group believes that it has satisfied significant dependencies
with other groups;
- other groups SHOULD review the document to
confirm that these dependencies have been satisfied.
In general, a Last Call announcement is also a signal that the Working Group
is planning to advance the technical report to later maturity levels.
A Working Group SHOULD work with other groups
prior to a Last Call announcement to reduce the risk of surprise at Last
Call.
Ideally, after a Last Call announcement, a Working Group receives only
indications of support for the document, with no proposals for substantive
change. In practice, Last Call announcements generate comments that sometimes
result in substantive changes to a document. A Working Group SHOULD NOT assume that it has finished its work by virtue of
issuing a Last Call announcement.
Entrance criteria: Before announcing a Last Call, the Working Group
MUST do all of the following:
- Record the group's decision to request advancement.
- Fulfill the relevant requirements of the Working Group charter and those of
any accompanying requirements documents, or report which relevant requirements
have not been fulfilled.
- Indicate which dependencies with other groups the Working Group believes it
has satisfied, and report which dependencies have not been satisfied.
Duration of the review: The announcement begins a review period that
SHOULD last at least three weeks but MAY last
longer if the technical report is complex or has significant external
dependencies.
Ongoing work: During the review period, the Working Group solicits and
responds to comments from the Team, the Members, other W3C groups, and the
public.
It is important to ensure the proper integration of a technical report in
the international community. Starting at this step in the Recommendation
process, the technical report SHOULD include a
statement about how the technology relates to existing international standards
and to related work outside of W3C.
Possible next steps:
Document maturity level: Candidate Recommendation.
Announcement: The Director MUST announce the
Call for Implementations to the Advisory Committee.
Purpose: At this step, W3C believes the technical report is stable and
appropriate for implementation. The technical report MAY still change based on implementation experience.
Entrance criteria: The Director calls for implementation when satisfied that
the Working Group has fulfilled the general
requirements for advancement.
The Working Group is NOT REQUIRED to show that
a technical report has two independent and interoperable implementations as
part of a request to the Director to announce a Call for Implementations.
However, the Working Group SHOULD include a report
of present and expected implementations as part of the request.
In the Call for Implementations, the Working Group MAY identify specific features of the technical report as
being "features at risk."
General statements such as "We plan to remove any unimplemented feature" are
not acceptable; the Working Group MUST precisely
identify any features at risk. Thus, in response to a Call for Implementations,
reviewers can indicate whether they would register a Formal Objection to the decision to remove the
identified features.
After gathering implementation experience, the Working Group MAY remove features from the technical report that were
identified as being "at risk" and request that the Director Call
for Review of a Proposed Recommendation. If the Working Group makes other
substantive changes to the technical report,
the Director MUST return it to the Working Group
for further work.
The request to the Director to advance a technical report to Candidate
Recommendation MUST indicate whether the Working
Group expects to satisfy any Proposed Recommendation entrance criteria beyond
the default requirements (described below).
Advisory Committee representatives MAY appeal the decision to advance the technical report.
Duration of the implementation period: The announcement MUST indicate a minimal duration, before which the Working
Group MUST NOT request a Call for
Review of a Proposed Recommendation; this minimal duration is designed to
allow time for comment. The announcement SHOULD
also include the Working Group's estimate of the time expected to gather
sufficient implementation data.
Possible next steps:
Document maturity level: Proposed Recommendation.
Announcement: The Director MUST announce the
Call for Review to the Advisory Committee.
Purpose: At this step, W3C seeks endorsement of the stable technical report.
The outcome of this review is taken as an indication of the organization's
support for the technical report.
Entrance criteria: The Director calls for review when satisfied that the
Working Group has:
- Fulfilled the general requirements for
advancement;
- Shown that each feature of the technical report has been implemented.
Preferably, the Working Group SHOULD be able to
demonstrate two interoperable implementations of each feature. If the Director
believes that immediate Advisory Committee review is critical to the success of
a technical report, the Director MAY accept to
Call for Review of a Proposed Recommendation even without adequate
implementation experience;
- Satisfied any other announced entrance criteria (e.g., any included in the
request to advance to Candidate Recommendation, or announced at Last Call if
the Working Group does not intend to issue a Call for Implementations).
Advisory Committee representatives MAY appeal the decision to advance the technical report.
Duration of the review: The announcement begins a review period that
MUST last at least four weeks.
Ongoing work: During the review period, the Working Group requests
endorsement and support from Members (e.g., testimonials as part of a press
release).
Possible next steps:
Document maturity level: Recommendation.
Announcement: The Director MUST announce the
publication of a W3C Recommendation to the Advisory
Committee.
Purpose: W3C publishes Recommendations when it believes that the ideas in
the technical report are appropriate for widespread deployment and that they
promote W3C's mission.
Entrance criteria: The Director publishes a W3C Recommendation when
satisfied that there is significant support for the technical report from the
Advisory Committee, the Team, W3C Working Groups, and the public. The decision
to advance a document to Recommendation is a W3C
decision.
If there was any dissent during
the Member review, Advisory Committee representatives MAY appeal the decision to publish the
Recommendation.
Possible next steps:
The Director MAY submit a W3C Recommendation to
another standards body for adoption and formal approval by that body.
A technical report is returned to a Working Group for further work in either
of the following situations:
- The Working Group makes substantive
changes to the technical report at any time after a Last Call announcement and prior to Publication as a Recommendation, except
when the changes involve the removal of features at
risk identified in a Call for Implementations. In the
case of substantive changes, the Working Group MUST republish the technical report as a Working Draft.
- The Director requires the Working Group to address important issues raised
during a review or as the result of implementation experience. In this case,
Director MAY request that the Working Group
republish the technical report as a Working Draft, even if the Working Group
has not made substantive changes.
The Director MUST inform the Advisory Committee and group Chairs when a technical report has been
returned to a Working Group for further work.
After republication as a Working Draft, the next forward step available to
the Working Group is a Last Call announcement. The
Last Call announcement MAY occur at the same time
as the publication of the Working Draft.
The Director MAY ask the Working Group to
republish a technical report as a Candidate Recommendation. At the same time as
publication, the Director issues a Call for
Implementations.
Work on a technical report MAY cease at any
time. When a Working Group completes its work on a technical report, it
publishes it either as a Recommendation or a Working Group Note. For example, a
Working Group might publish several Working Drafts of a requirements document,
and then indicate that it no longer plans to work on the requirements document
by publishing a Working Group Note.
Work MAY also cease because W3C determines that
it cannot productively carry the work any further. For instance, the Director
might close a Working Group, the participants
might lose interest in a technical report, or the ideas might be subsumed by
another technical report. If W3C decides to discontinue work on a technical
report before completion, the technical report SHOULD be published as a Working Group Note.
Possible next steps:
- End state: A technical report MAY remain a
Working Group Note indefinitely
- Otherwise: A Working Group MAY resume work on
the technical report as a Working Draft
W3C makes every effort to maintain its Recommendations (e.g., by tracking
errata, providing test-bed applications, and helping to create test suites) and
to encourage widespread implementation. The following sections discuss the
management of errors and the process for making normative changes to a
Recommendation.
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 class of mistake,
from mere editorial to a serious error that may affect the conformance with the
Recommendation by software or content (e.g., content validity).
Note: Before a document becomes a Recommendation, the W3C
Process focuses on substantive changes (those
related to prior reviews). After a document has been published as
Recommendation, the W3C Process focuses on those changes to a technical report
that might affect the conformance of content or deployed software.
Working Groups MUST track errata on an "errata
page." An errata page is a list of enumerated errors, possibly accompanied by
corrections. Each Recommendation links to an errata page; see the Team's
Publication Rules.
A correction is first "proposed" by the Working Group. A correction becomes
normative -- of equal status as the text in the published Recommendation --
through one of the processes described below. An errata page MAY include both proposed and normative corrections. The
Working Group MUST clearly identify which
corrections are proposed and which are normative.
A Working Group SHOULD keep their errata pages
up-to-date, as errors are reported by readers and implementers. A Working Group
MUST report errata page changes to interested
parties, notably when corrections are proposed or become normative, according
to the Team's requirements. For instance, the Team might set up a mailing list
per Recommendation where a Working Group reports changes to an errata page.
This document distinguishes the following classes of changes to a
Recommendation.
- 1. No changes to text content
- These changes include fixing broken links or invalid markup.
- 2. Corrections that do not affect conformance
- Editorial changes or clarifications that do not change the technical
content of the specification.
- 3. Corrections that MAY affect conformance,
but add no new features
- These changes MAY affect conformance to the
Recommendation. A change that affects conformance is one that:
- turns conforming data, processors, or other conforming agents into
non-conforming agents, or
- turns non-conforming agents into conforming ones, or
- clears up an ambiguity or under-specified part of the specification in such
a way that an agent whose conformance was once unclear becomes clearly
conforming or non-conforming.
- 4. New features
The first two classes of change require no technical review of the proposed
changes, although a Working Group MAY issue a Call
for Review. The modified Recommendation is published according to the Team's
requirements, including Publication
Rules [PUB31].
For the third class of change, W3C requires:
- Review by the community to ensure the technical soundness of proposed
corrections.
- Timely publication of the edited Recommendation, with corrections
incorporated.
For the third class of change, the Working Group MUST either:
- Request that the Director issue a Call for Review of
an Edited Recommendation, or
- Issue a Call for Review of Proposed
Corrections that have not been incorporated into an edited draft (e.g.,
those listed on an errata page). After this review, the Director MAY announce that the proposed corrections are normative.
While the second approach is designed so that a Working Group can establish
normative corrections quickly, it does not obviate the need to incorporate
changes into an edited version of the Recommendation. In particular, when
corrections are numerous or complex, integrating them into a single document is
important for interoperability; readers might otherwise interpret the
corrections differently.
For the fourth class of change (new features), W3C MUST follow the full process of advancing a technical report to Recommendation.
Document maturity level: Proposed Edited
Recommendation.
Announcement: The Director MUST announce the
Call for Review to other W3C groups, the public, and the Advisory
Committee. The announcement MUST clearly
indicate that this is a proposal to edit a Recommendation and MUST:
- specify the deadline for review comments;
- identify known dependencies and solicit review from all dependent Working
Groups;
- solicit public review.
Purpose: At this step, W3C seeks confirmation of proposed corrections to a
Recommendation.
Entrance criteria: The Director calls for review when satisfied that, with
respect to changes to the document, the Working Group has fulfilled the same
entrance criteria as for a Call for Review of a Proposed
Recommendation (e.g., the Working Group can show implementation experience
that supports the changes). In the request to advance to this status, the
Working Group MUST report any substantive issues
about the technical report that have not been resolved.
Advisory Committee representatives MAY appeal the decision to advance the technical report.
Duration of the review: The announcement begins a formal Advisory Committee
review period that MUST last at least four weeks.
Ongoing work: During the review period, the Working Group solicits and
responds to comments from the Team, the Members, other W3C groups, and the
public.
Possible next steps:
Document maturity level: A Recommendation, plus a list of proposed
corrections. The Working Group SHOULD also include
a detailed description of how the Working Group plans to change the text of the
Recommendation for each proposed correction.
Announcement: The Working Group MUST announce
the Call for Review to other W3C groups, the public, and the Advisory Committee. This is not a formal Advisory
Committee review. However, the announcement MUST clearly indicate that this is a proposal to make
normative corrections to the Recommendation and MUST:
- specify the deadline for review comments;
- identify known dependencies and solicit review from all dependent Working
Groups;
- solicit public review.
Purpose: At this step, W3C seeks confirmation of proposed corrections to a
Recommendation.
Entrance criteria: The Working Group calls for review when, with respect to
changes to the document, the group has fulfilled the same entrance criteria as
for a Call for Review of a Proposed Recommendation.
Duration of the review: The announcement begins a review period that
MUST last at least four weeks.
Ongoing work: Same as for a Proposed Edited
Recommendation.
If there are no Formal Objections to the
proposed corrections, W3C considers them normative. The Working Group
MUST report Formal Objections to the Director, who
assesses whether there is sufficient consensus to declare the proposed
corrections to be normative.
Possible next steps:
- Forward: Publication of a W3C
Recommendation. In order for the corrections to remain normative, the
Working Group MUST incorporate them into an edited
Recommendation. The Working Group MUST publish the
revised Recommendation within six months
after the end of the review or secure an extension from the Director. Prior to
publication, if the Working Group makes further changes to the technical report
that affect conformance, the Working Group MUST
request a Call for Review of an Edited
Recommendation.
- Otherwise: The Recommendation remains unchanged and two steps are possible:
return to Working Group or end
work
At times, W3C MAY rescind an entire
Recommendation, for instance when W3C learns of significant errors in the
Recommendation, when the Recommendation becomes outdated, or if W3C discovers
burdensome patent claims that affect implementers; see the W3C Patent Policy [PUB33] and in particular section 5
(bullet 10) and section
7.5.
To deprecate 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.
Document maturity level: Recommendation, plus separate rationale for the
proposal to rescind.
Announcement: The Director MUST announce the
Proposal to Rescind a Recommendation to other W3C groups, the public, and the
Advisory Committee. The announcement MUST clearly indicate that this is a Proposal to Rescind a
Recommendation and MUST:
- specify the deadline for review comments;
- identify known dependencies and solicit review from all dependent Working
Groups;
- solicit public review.
Purpose: At this step, W3C seeks confirmation of a Proposal to Rescind a
Recommendation.
Entrance criteria: The Director proposes that W3C rescind a Recommendation
when satisfied that there is sufficient reason.
Advisory Committee representatives MAY appeal the Proposal to Rescind the Recommendation.
Duration of the review: The announcement begins a review period that
MUST last at least four weeks.
Ongoing work: During the review period, the Working Group solicits and
responds to comments from the Team, the Members, other W3C groups, and the
public.
Possible next steps:
Document maturity level: Rescinded
Recommendation.
Announcement: The Director MUST announce the
Publication of a Rescinded Recommendation to the Advisory
Committee.
Purpose: At this step, W3C indicates that it no longer endorses a previously
published Recommendation.
Entrance criteria: The Director publishes a Rescinded Recommendation when
satisfied that there is significant support from the Advisory Committee, the
Team, W3C Working Groups, and the public. The decision to advance a document to
Rescinded Recommendation is a W3C
decision.
The Team MAY publish one or more documents in
order to best communicate what has been rescinded and its relation to previous
Recommendations (e.g., the publication can be as simple as a cover sheet that
refers to a previously published Recommendation).
If there was any dissent in the
Proposed Rescinded Recommendation reviews, Advisory Committee representatives
MAY appeal the decision to
rescind the Recommendation.
Possible next step:
- End state: A technical report MAY remain a
Rescinded Recommendation indefinitely
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 will make
every effort 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.
Every technical report published as part of the technical report development
process is edited by one or more editors appointed by a Working 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 for the TAG or Advisory Board who is not an elected or appointed
participant in that group MUST fulfill the same
participation requirements for that group, as a Member representative, Team
representative, or Invited Expert. All other W3C editors MUST be participants in the group responsible for the
document(s) they are editing. Note that an editor is NOT
REQUIRED to be a Team representative.
The Team is NOT REQUIRED to publish a technical
report that does not conform to the Team's Publication Rules (e.g., for naming, style, and copyright requirements). These
rules are subject to change. The Team MUST inform
group Chairs and the Advisory Board of any changes.
The Team reserves the right to reformat technical reports at any time so as
to conform to changes in W3C practice (e.g., changes to technical report styles
or the document status section).
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.
Each technical report MUST include a section
about the status of the document. The status section SHOULD explain why W3C has published the technical report,
expectations about next steps, who developed it, where to send comments about
it, whether implementation experience is being sought, any significant changes
from the previous version, why work on the technical report has ceased or been
subsumed, and any other relevant information or rationale.
The Team's Publication Rules
include status section requirements for each maturity level.
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 Activity 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.
The Advisory Committee reviews:
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; this is the default
channel for reviews.
- an archived Member-only channel.
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).
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.
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:
Advisory Committee representatives MAY always
appeal the following decisions:
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.
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".
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).
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.
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.
A Member Submission
consists of:
- One or more documents developed outside of the W3C process, and
- Information about the documents, provided by the Submitter.
One or more Members (called the "Submitter(s)") MAY participate in a Member Submission. Only W3C Members
MAY be listed as 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.
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 part
of a W3C Activity.
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 an
Activity Proposal or 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].
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].
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.
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.
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.
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.
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 http://www.w3.org/Consortium/Patent-Policy/.
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
- [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.
The following individuals participated in the preparation of this document
while serving (at different times) on the W3C Advisory Board: Jean-François
Abramatic (ILOG, and before that W3C Chair), Ann Bassetti (The Boeing Company),
Jim Bell (HP), Klaus Birkenbihl (Fraunhofer Gesellschaft), Carl Cargill (Sun
Microsystems), Paul Cotton (Microsoft), Don Deutsch (Oracle), David Fallside
(IBM), Paul Grosso (Arbortext), Eduardo Gutentag (Sun Microsystems), Steve
Holbrook (IBM), Renato Iannella (IPR Systems), Ken Laskey (MITRE), Ora Lassila
(Nokia), Håkon Wium Lie (Opera Software), Larry Masinter (Adobe Systems), Bede
McCall (MITRE), Thomas Reardon (Microsoft), Claus von Riegen (SAP AG), David
Singer (IBM), Lauren Wood (unaffiliated), and Steve Zilles (Adobe Systems).
Early drafts of the W3C Process Document were prepared by a special Process Working Group. The Working Group was elected by the
Advisory Committee representatives on 16 September 1996 and closed in November
1997. The following individuals participated in the Process Working Group (with
their affiliations at that time): Carl Cargill (Netscape), Wendy Fong
(Hewlett-Packard), John Klensin (MCI), Tim Krauskopf (Spyglass), Kari Laihonen
(Ericsson), Thomas Reardon (Microsoft), David Singer (IBM), and Steve Zilles
(Adobe). The Team members involved in the Process Working Group were:
Jean-François Abramatic, Tim Berners-Lee, Ian Jacobs, and Sally Khudairi.
Thanks also to Don Brutzman (Web3D) for earlier work on liaisons.
