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 constituent organizations 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 19 July 2001 version of the W3C Process Document. This version
of the Process Document incorporates changes relevant to the Technical
Architecture Group (TAG). This document was produced by the
W3C Advisory Board.
Additional Member-only information about the Process Document (issues lists,
Member-only drafts, changes to Member-only drafts, etc.) is available from the
Process Plan page.
General information about W3C is
available on the Web, including information about becoming a W3C
Member.
Please send review comments about this document to process-issues@w3.org
(Member-only
archive).
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.
Employees may work as part of the Team (i.e., as W3C
Fellows);
Employees may access Member-only information;
The Member may display the W3C Member logo on promotional material and
publicize the Member's participation in W3C. For more information, please refer
to the Member logo usage policy described in the New Member orientation [MEM4].
In the case (described in paragraph 5g of the Full and Affiliate Member
agreements), 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 may exercise all the rights and privileges of
W3C Membership. In addition, the Advisory Committee representative may
designate up to four (or more at the Chairman's discretion) unpaid individuals
from the organization who may exercise the rights of Membership. 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.
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 or employee of the other, or
Both Members are subsidiaries of a common entity.
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].
Members must treat all Member-only documents as confidential within W3C and
use reasonable efforts to maintain this confidentiality and not to release this
information to the general public or press. Access to Member-only information
may be extended by Advisory Committee representatives to fellow employees
considered appropriate recipients. All recipients must respect the intended
(limited) scope of Member-only information. For instance, Advisory Committee
representatives and fellow employees should 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 [MEM4].
The Team must provide mechanisms to protect the confidentiality of
Member-only information and ensure that Members and other authorized people
have proper access to this information. Documents on the Web should clearly
indicate whether they require Member-only confidentiality.
When an organization joins W3C [PUB5], it must
name its Advisory Committee representative as part of the Membership agreement.
A New Member orientation [MEM4]
explains how to subscribe or unsubscribe to Advisory Committee mailing lists,
provides information about Advisory Committee meetings, etc. Advisory Committee
representatives must follow the conflict of interest policy
by disclosing information according to the mechanisms described in the New Member orientation [MEM4]. Additional
information for Members is available at the Member
Web site [MEM6].
The Team must use a mailing list for official announcements (e.g., those
required by this document) from the Team to the Advisory Committee. Each
Advisory Committee representative should be subscribed to this list. An
Advisory Committee representative may request that additional individuals from
their organization be subscribed to this list. Failure to contain distribution
internally may result in suspension of additional email addresses, at the
discretion of the Team.
The Team must also make available a mailing list for discussions among
Advisory Committee representatives.
The Team must organize a face-to-face meeting for
the Advisory Committee twice a year. The Chairman is the Chair of these meetings. 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. Mention
should be made of Activities that were started or terminated since the previous
Advisory Committee meeting.
Each Member organization should send one employee to each Advisory Committee
meeting as its representative. In exceptional circumstances (e.g., during a
period of transition between representatives from an organization), the
Chairman may allow a Member organization to send two employees to a meeting.
Additional employees may attend the meeting when invited by the Chairman (e.g.,
the Chairman may invite the Advisory Board or group
Chairs to attend the 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.
At least eight weeks before an Advisory
Committee meeting, the Chairman should solicit agenda suggestions from Advisory
Committee representatives. The Chairman should announce the agenda two weeks before the meeting. The Team should make
available minutes from each Advisory Committee meeting within two weeks of the meeting.
The Team consists of the W3C paid staff and
W3C Fellows (i.e., Member employees working as part of the Team). It is led
by the Chairman and the Director. 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 Chairman
manages the general operation of the Consortium, oversees the development of
the W3C international structure (e.g., role of Host
institutions, etc.), coordinates liaisons with other standards bodies, and
addresses legal and policy issues. The Chairman is the Chair of the Advisory Board and chairs Advisory
Committee Meetings.
Both the Director and the Chairman may delegate responsibility to the Team
for any of the Director's or Chairman's roles described in this document. Team
administrative information such as Team salaries, detailed budgeting, and other
business decisions are Team confidential, subject to oversight by the Host
institutions.
Note: W3C is not currently incorporated. For legal
contracts, W3C is represented by three "Host"
institutions: L'Institut National de Recherche en Informatique et
Automatique (INRIA), Keio University, and the Massachusetts
Institute of Technology (MIT). Each Host institution
exercises all the rights and privileges of W3C Membership.
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 is not a board of directors and
has no decision-making authority within W3C; its role is strictly advisory.
The Advisory Board will hear appeals of Member
Submission requests that are rejected for reasons unrelated to Web
architecture; see also the TAG.
The Team must make available a mailing list that the Advisory Board must use
for its communication, and that is confidential to the Advisory Board and the
Team.
The Advisory Board should send a summary of each of its meetings to the
Advisory Committee. Advisory Board representatives should attend Advisory Committee meetings. The
Chairman may invite other members of the Team to participate in
Advisory Board meetings.
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
[MEM13].
Individuals on the Advisory Board participate as individual contributors and
not representatives of their organizations. Advisory Board participants use
their best judgment to find the best solutions for the Web, not just for any
particular network, technology, vendor, or user.
The Advisory Board consists of nine elected participants and the Chairman, who is the Chair of the Advisory
Board. With the exception of the Chairman,
the terms of all Advisory Board participants are for two years. The terms are staggered so that four or
five terms expire each year. If an individual is elected to fill an incomplete
term, that individual's term will end at the normal expiration date of that
term.
Advisory Board participants are expected to participate regularly and fully.
The AB uses the same good standing rules as
Working Groups.
An Advisory Board participant may resign, change affiliations, or fail to
remain in good standing. When any one of these three occurs, the Chairman may
declare the participant's seat to be vacant. If more than four months remain in
the term of a vacated seat, a special election will be held to fill it;
otherwise, the vacant seat will be filled at the next regular AB election.
Created in 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 architectural brought to the
TAG;
to help coordinate cross-technology architecture developments inside and
outside W3C.
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 background and scope of the TAG,
as well as expected qualifications of TAG participants.
The TAG will hear appeals of Member Submission
requests that are rejected for reasons related to Web architecture; see
also the Advisory Board.
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-visible list for discussions within the TAG and for requests to
the TAG from Members that, for whatever reason, cannot be made on the public
list. For instance, if the TAG is helping two Member-only Working Groups
resolve an issue, it may be necessary to conduct business initially on this
list.
The TAG may also request the creation of additional topic-specific, public
mailing lists. For some TAG-only discussions (e.g., about a rejected Submission appeal), the TAG may require the
use of TAG-only lists that will be visible to the TAG and Team. Additional
information about communications mechanisms will be located at the TAG Web
site.
The TAG should send a summary of each of its
meetings to the Advisory Committee. TAG participants should attend Advisory
Committee meetings. The Director may invite other people to participate in TAG
meetings; these individuals do not have voting rights.
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].
Individuals on the TAG participate as individual contributors and not
representatives of their organizations. TAG participants use their best
judgment to find the best solutions for the Web, not just for any particular
network, technology, vendor, or user.
The TAG consists of eight elected or appointed participants, and the Director, who is the Chair of the TAG.
Three TAG participants are appointed by the W3C Team under the leadership of
the Director. Appointees need not be on the W3C Team.
The remaining five TAG participants are elected by the W3C Advisory
Committee following the AB/TAG nomination and election process. TAG elections
should be offset from Advisory Board elections by approximately six months. Nominees need not be employees of a
Member organization. A nominee from a Member organization should have employer
approval in order to participate. W3C Fellows (employees of W3C Members who are
part of the Team) may be appointed or elected to the TAG.
When the TAG must vote to resolve an issue, each TAG participant has one
vote (whether appointed, elected, or the Chair).
With the exception of the Director, the terms of all TAG participants are
for two years. Terms are staggered to
promote continuity across elections: each year, either two or three elected
terms, and either one or two appointed terms will expire. If an individual is
appointed or elected to fill an incomplete term, that individual's term will
end at the normal expiration date of that term.
TAG participants are expected to participate regularly and fully. The TAG
uses the same good standing rules as Working
Groups.
A TAG participant may resign, change affiliations, or fail to remain in good
standing. When any one of these three occurs, the Director may replace
appointed participants with a new appointment, or may declare an elected
participant's seat to be vacant. If more than four months remain in the term of
a vacated seat, a special election will be held to fill it; otherwise, the
vacant seat will be filled at the next regular TAG election.
Given the few seats available on the Advisory Board and the TAG, and in
order to ensure that the diversity of W3C Membership 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
Director will declare one participant's seat to be vacant. When more than one
individual is involved, the verifiable random procedure
described below will be used to choose one person for continued
participation.
Note: These participation constraints do not apply to the
W3C Team.
The Advisory Board and a portion of the Technical Architecture Group are
elected by the Advisory Committee.
The election process begins when the Chairman sends a call for nominations
to the Advisory Committee. The call specifies the number of available seats,
the deadline for nominations, and the address where nominations must be sent.
Nominations should be made with the consent of the nominee and 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.
Less than the number of available seats, calls for nominations are repeated
until a sufficient number of people have been nominated.
Greater than the number of available seats, the Chairman 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 must be sent. Each Advisory
Committee representative may vote for as many candidates as there are available
seats.
Once the deadline for votes has passed, the Chairman 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 candidates than
available seats (e.g., three candidates receive 10 votes each for two seats),
the verifiable random procedure described below will be
used to fill the available seats.
Nomination and election details will be verifiable but Team-confidential;
the only information that will be made public is the final list of
participants.
Terms begin with the announcement of the final election results.
For AB or TAG processes, when it is necessary to "draw straws" -- to choose
an individual in a random and verifiable manner (e.g., to fill a short term or
in case of a tie) -- the following random procedure based on RFC 2777 will be used:
The ballot must contain the following information:
A "reference date" for the values to be used in the RFC2777 algorithm. This
date should be the day after the closing date of the selection period; if any
value is not available on the reference date or time, then the next available
value will be used.
Three "sources of randomness" to be used in the RFC2777 algorithm (e.g.,
the closing value of the Standard & Poor's 500 Index on the reference date;
a chosen atmospheric pressure (e.g., low pressure) in millibars in Paris,
France, on the reference date; and the numbers drawn in the Massachusetts
Lottery "Numbers" game on the reference date).
After the election process is complete, the successful candidates are
assigned numbers in the order in which their names appeared on the ballot; the
first successful candidate is "1" and so forth.
Using the algorithm in RFC2777 to order the successful candidates, the
available terms are filled shortest first.
As an example, if there were two one-year seats and one two-year seat
available, then the example in section 5 of RFC2777 would lead to Pendragon and
Grouchy being assigned to the one-year seats and Sneazy being assigned to the
two-year seat.
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, managing calendars, etc.). Members should solicit review by
the Team prior to issuing press releases about their work within W3C.
The Team must make every effort to archive and ensure the 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) must be available free of charge to the general public; (refer
to the W3C document notice [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 contract ([PUB6], [PUB7])
and documentation of any legal commitments W3C may have to other entities (in
particular, the legal status of W3C with respect to Host
institutions).
To keep the Members abreast of W3C meetings, workshops, review deadlines,
etc., the Team should provide them with a regular (e.g., weekly) news service
and should maintain a calendar [MEM3] of official
W3C events. Members should send schedule and event information to the Team for
inclusion on this calendar.
Whenever possible, technical decisions should be made unencumbered by
intellectual property right (IPR) claims. To this end, W3C discloses to the
entire Membership which organizations have made IPR claims about a particular
technology, as well as the details of those claims where they have been
provided. Individuals should immediately disclose any IPR claims they know may
be essential to implementing a Recommendation track technical
report. To disclose patent and IPR claims, individuals must send email to
patent-issues@w3.org, which is an
archived mailing list readable by Members and the Team. Individuals disclosing
knowledge of IPR claims should copy the Team contact
responsible for a particular technology to ensure that the disclosure receives
prompt consideration. Individuals may also copy other recipients.
Advisory Committee representatives are responsible for facilitating
communication with IPR contacts in their organizations. When disclosing IPR
claims, employees of a Member organization should copy their Advisory Committee
representative.
An IPR disclosure about a given subject should include the following
language (appropriately completed):
I (do not) have personal knowledge of (any) IPR claims held by
[organization] regarding [subject].
Whenever possible, a disclosure should provide detail about the claims.
Activity proposals, calls for participation in groups, and other important
announcements and Web pages should include reminders of this IPR policy.
There are three qualities an individual must possess 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 participants.
Individuals participating in a Working Group or
Coordination Group, or on the Advisory
Committee, Advisory Board, or TAG must
disclose significant relationships they have with W3C Members other than their
employers, when those relationships might reasonably be perceived as creating a
conflict of interest with the individual's role at W3C. These disclosures
should be kept up-to-date as the individual's affiliations and W3C Membership
evolve. Disclosure mechanisms vary according to role and are described
elsewhere in this document and at the W3C Web site.
The ability of an individual to fulfill a role within a group without
risking a conflict of interests is clearly a function of the individual's
affiliations. When these affiliations change, the role in question must be
reassigned, possibly to the same individual, according to the process
appropriate to the role.
This section describes the mechanisms for establishing consensus within W3C
about 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. The
ongoing work of the Team to review
Submission requests, organize workshops, and
otherwise track Web developments may culminate in an Activity proposal to the Membership. 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 may produce technical reports, review the work of other groups,
develop sample code or test suites, etc.
The progress of each Activity is documented in an Activity statement. Activity statements should
describe the goals of the Activity, completed and unfinished deliverables,
changing perspectives based on experience, future plans, etc. At least before
each ordinary 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 includes some Activities that began prior to
the formalization in 1997 of the Activity creation process.
The Advisory Committee reviews and comments on the
proposal. The review period must be at least four
weeks. During the review period, Advisory Committee representatives must
disclose, according to the W3C IPR policy, knowledge of
relevant IPR claims.
The Director announces to the Advisory Committee whether there is consensus
within W3C to create the Activity (with possible modifications suggested during
the review). 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 an 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., Submission requests), increased
understanding of goals and context, etc., while remaining true to the intent of
the original Activity proposal. If it becomes necessary to make substantial
changes to an Activity (e.g., because significant additional resources are
required, the Activity's scope has clearly changed from the original proposal,
etc.) then the Director must propose the changes to the Advisory Committee by
following the same review process.
A proposal to extend the duration of an Activity without otherwise modifying
it substantially must indicate the new duration and include rationale for the
extension, but is not required to include all of the information required for a
full Activity proposal.
A proposal to modify or extend an Activity should provide rationale for the
change and include information about the current state of the Activity.
An Activity proposal must specify 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.
An Activity proposal defines the initial scope and structure of an Activity.
In general, the Team drafts Activity proposals based on perceived Member and
public interest in a particular area of Web development,
Submission requests from Members, input gathered during
workshops, discussions among group Chairs, etc.
An Activity 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, education, etc.)? Who or what group wants this (providers, users,
etc.)?
Context information. Why is this Activity being proposed now? What is the
situation in the world (community, market, research, society, etc.) 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? What must be
changed if the process is put into place?
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 in a new
group.
The expected timeline of the Activity, including proposed deliverable
dates, scheduled workshops, symposia, etc.
If known, the date of the first face-to-face
meeting of a 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 must pledge in order for the
Activity to be accepted.
Information about known dependencies within W3C or outside of W3C.
Intellectual property information. What intellectual property (for example,
an implementation) must be available for licensing and is this intellectual
property available for a reasonable fee and in a non-discriminatory manner? The
proposal should remind Advisory Committee representatives to disclose,
according to W3C's IPR policy, knowledge of relevant IPR
claims.
A list of supporters, references, etc. What community should benefit from
this Activity? Are members of this community part of W3C now? Are they expected
to join the effort?
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. There are not generally participation requirements for an Interest
Group.
Coordination Groups. A Coordination Group manages
dependencies and facilitates communication between groups within W3C or with
entities outside of W3C.
Each group must have a charter. Requirements for the charter depend on the
group type.
Each group must have a Chair
(or co-Chairs) to coordinate the group's tasks. The Director appoints (or
re-appoints) Chairs for all groups. The role of the Chair [MEM14] is
described in the Member Guide [MEM9].
The Chair and the Team contact of a group should not be the same individual.
The Chair may be from the Team.
Each group must have an archived mailing list for formal group communication
(e.g., meeting announcements, objections to decisions, etc.). The Chair and
Team contact should ensure that new participants are subscribed to all relevant
mailing lists. Refer to the list of group mailing
lists [MEM2].
A group 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 may have an informal "charter").
This document 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 by telephone, video conferencing, IRC, etc.
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 72 hours for Monday meetings)
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
must give 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.
The W3C process requires Chairs to ensure that groups consider all
legitimate views and objections, and endeavor to resolve them. Decisions may be
made during meetings (face-to-face or distributed) as well as through email. The
following terms are used in this document to describe the level of support for
a group decision:
Where unanimity is not possible, the group should strive to make decisions
where there is at least consensus with substantial support (i.e., few
abstentions) from all participants. To avoid decisions that are made despite
nearly universal apathy (i.e., with little support and substantial abstention),
groups are encouraged to set minimum thresholds of active support before a
decision can actually be recorded. The appropriate percentage may vary
depending on the size of the group and the nature of the decision. A group
charter may include a quorum requirement for consensus decisions.
In some cases, even after careful consideration of all points of view, a
group may find itself unable to reach consensus. When this happens, if there is
a need to advance (for example, to produce a deliverable in a timely manner),
the Chair may announce a decision to which there is dissent. When deciding to
announce such a decision, the Chair must be aware of which participants work
for the same (or related) Member organizations and
weigh their input accordingly. When a decision must be reached despite dissent,
groups should favor proposals that create the least strong objections. This is
preferred over proposals that are supported by a large majority of the group
but that cause strong objections from a few participants.
The Chair decides when to
resolve an issue in the face of dissent. In this case, a dissenter may request
that any formal objections be reported at
later review stages.
In the context of this document, a Working Group has formally addressed an
issue when the Chair can show (archived) evidence of having sent a response to
the party who raised the issue. This response should include the Working
Group's resolution and should ask the party who raised the issue to reply with
an indication of whether the resolution reverses the initial objection.
If dissenters say they can live with a given decision, this should be taken
as an indication that the group can move on to the next topic, but the inverse
is not necessarily true: dissenters cannot stop a group's work simply by saying
that they cannot live with the decision. When the Chair believes that the
legitimate concerns of the dissenters have received due consideration as far as
is possible and reasonable, then objections must be recorded and the group
should move on.
A formal objection should include technical arguments and propose changes
that would remove the dissenter's objection; these proposals may be vague or
incomplete. The Chair must report an objection that includes such information
to the Director at later review stages (e.g., in the request to the Director to
advance a technical report to Candidate Recommendation). If an objection does
not include this information, the Chair is not required to report it at later
review stages.
During an Advisory Committee Review, Advisory Committee representatives must
be able to refer to archived objections.
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, for cultural
reasons, etc.).
The Chair should archive that a decision has been reopened, and must do so
upon request from a group participant.
Participants should always try to resolve issues within the group and should
register with the Chair any objections they may have to a decision (e.g., a
decision made as the result of a vote). When
participants of a Member organization believe that their concerns are not being
duly considered within the group, they may ask the
Director (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 is responsible
for informing the Director when invited experts
raise 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
archived.
Only 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, should a group vote to resolve a
substantive issue. In this case, the Chair must archive:
the decision to conduct a vote (e.g., a simple majority vote) to resolve
the issue;
the outcome of the vote;
any objections.
A Working Group participant must be in good
standing in order to participate in a vote to resolve a substantive
issue.
Working Groups may vote for other purposes. For instance, the Chair may
conduct a "straw poll" vote as a means of determining whether there is
consensus about a potential decision. Votes may also be used for arbitrary
decisions. 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,
members of the minority are not required to state the reasons for their
dissent, and the votes of individuals need not be recorded.
On an exceptional basis, a Working or Interest Group participant may
designate an alternate to attend a meeting. For good
standing, voting, and other Working Group processes, "participant" means
"participant or alternate."
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, it may be
split into an Interest Group (a discussion forum) and a much smaller Working
Group (a core group of highly dedicated participants).
The Director creates, modifies, or extends a Working Group or Interest Group
by sending a call for participation to the Advisory
Committee. The call for participation must include 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.
A group does not exist prior to the initial call for participation.
To make substantial changes to a charter (e.g., to stop work on a
deliverable due to negative review by the Advisory Committee), the Director
must send a new call for participation to the Advisory Committee that indicates
the changes (e.g., regarding deliverables or resource requirements). Charter
modifications should not be made without substantial agreement in the group to
accept the changes. Group participants who do not agree with a decision to
modify the charter or with the proposed modifications may raise objections
through their Advisory Committee representative (or through the Team contact
for invited experts).
To extend a charter without otherwise modifying it substantially, the
Director must send a new call for participation to the Advisory Committee that
indicates the new duration. The new duration must not exceed the duration of
the Activity to which the group belongs.
A call for participation that modifies or extends an group charter should
provide rationale for the changes and include information about the current
state of the group.
The Director may create, modify, or extend a Working Group or Interest Group
at any time, but only as part of an approved
Activity.
Advisory Committee representatives may appeal the
creation, modification, or extension of a Working Group or Interest Group.
A Working Group or Interest Group charter must include the following
information.
The group's mission (e.g., develop a technology or process, review the work
of other groups, write the charter of another group, etc.);
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, software, etc.), 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 of a review of another group's deliverables;
Any dependencies of other entities on the deliverables of this group. For
any dependencies, the charter must specify the mechanisms for communication
about the deliverables (contact people, names of Coordination Groups, names of
W3C contacts, etc.). The charter should identify any requirements documents
that may be required by other entities;
Any dependencies of this group on other entities. For example, one group's
charter may 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 entities. The
charter should set expectations about how coordination with those entities will
take place. Finally, the charter should specify expected conformance to the
deliverables of the other entities;
The level of confidentiality of the group's proceedings and deliverables
and, in particular, whether the charter itself will be public. The charter
should include rationale for any level of confidentiality other than
public;
Communication mechanisms to be employed within the group, between the group
and the rest of W3C, and with the general public;
The expected level of involvement by the Team (e.g., to track developments,
write and edit technical reports, develop code, organize pilot experiments,
etc.).
A Working Group charter must also include an estimate of the expected time
commitment from participants.
A Working Group or Interest Group charter may also include the following
information:
Requirements that a quorum of group participants support any formal
decision of the group.
Each Member organization or group of related
Members must only be allowed one vote, even though each Member may have several
participants in the group. If more than one vote is received from a Member
organization or group of related Members, the
votes must be counted as one vote if they agree, otherwise they must be ignored
and the Chair must inform the participant's Advisory Committee
representative(s) of the discrepancy.
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 employed by the same Member organization or group of related Members who may
join a Working Group).
The following individuals may request to join a Working Group or Interest
Group:
An employee of a Member organization, in which case:
The request to join must either be sent by the nominee's Advisory Committee
representative or by the nominee directly, copying the Advisory Committee
representative. If the nominee will not be participating on behalf of the
Member organization, the request to join must say so. The Advisory Committee
representative must ensure that nominees are qualified; (refer to W3C's individual participation criteria). Chairs
should set expectations about the roles and qualifications of participants to
assist the Advisory Committee representative. The Chair must not reject a
request to join from an employee of a Member organization, but the Team may
reject a request in exceptional circumstances (e.g., situations that might
jeopardize the progress of the group).
An individual who is not an employee of a Member organization, in
which case:
The request to join must indicate that the nominee wishes to participate as
an invited expert (even for
participation in a meeting on a one-time basis). Invited experts have the same
rights and responsibilities in a group as employees of Member organizations.
Invited experts must agree to the terms set forth in the invited expert and collaborators agreement
[PUB17]. Invited experts must sign the W3C
Technical Reports Release Form [PUB19] when they contribute to a W3C
technical report; employees of Member organizations are covered by the Member
contract. Approval to participate as an invited expert must come from both the
Chair and the Team contact. When there is disagreement between the Chair and
the Team contact, the Director determines the outcome of the request.
To request to join a group, an individual must follow the instructions in
the call for participation. An
individual may request to join a group at any time during its existence,
following the instructions in the call for participation.
In each request to join a Working Group or Interest Group, the individual
must disclose, according to the W3C IPR policy, knowledge of
relevant IPR claims by the individual's employer.
Each request to join a Working Group must also include a statement that the
participant accepts the participation terms set forth in the charter (with an
indication of charter date or version).
Each request for a Member employee to join a Working Group must state that
the individual's Advisory Committee representative agrees that the Member will
provide the necessary financial support for participation (e.g., for travel,
telephone calls, conferences, etc.).
Working Group participants must follow the conflict of
interest policy by disclosing information to the rest of the group.
Participation on an ongoing basis implies a serious commitment to the
Working Group charter, including:
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).
When the Chair and the Team contact agree, the
Chair may declare a participant in bad standing. If there is disagreement
between the Chair and the Team contact about standing, the Director determines
the participant's standing.
A participant may be declared in bad standing in any of the following
circumstances:
the individual has not provided deliverables in a timely fashion twice in
sequence.
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 may 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). The Chair and Team contact should apply
criteria for good standing consistently.
When a participant risks losing good standing, the Chair and Team contact
must discuss the matter with the participant and the participant's Advisory
Committee representative 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 should ask the Team contact to
speak to the Director on their behalf.
In order for a participant to regain good standing, the participant must
meet the participation requirements for two consecutive meetings. The Chair
must inform the Advisory Committee representative of any change in
standing.
At least every three months, each Working
Group must provide the public with an update of their progress. A progress
report may take a variety of forms, including the publication of a technical
report (in which case, the status section and the
document itself serve as an update).
A Working Group or Interest Group charter must specify 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.
W3C Activities interact in many ways. There are dependencies between groups
within the same Activity or in different Activities. There may also be
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, the synchronization
of publicity for the announcement of deliverables, etc. 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. If
agreement cannot be found between the Coordination Group and other groups
involved, then the Team should arbitrate after consultation with parties
involved and other experts, and, if deemed necessary, the Advisory
Committee.
The Director creates or modifies a Coordination Group by sending the Coordination Group charter to the Advisory Committee.
Since the charter must include the names of the group's participants, the
announcement is not a call for participation.
Coordination Group participants should represent the coordinated groups;
participation should evolve as groups become newly dependent or independent. To
promote effective communication between a Coordination Group and each group
being coordinated, participation in a Coordination Group is mandatory for the
Chair of each group being coordinated. The Coordination Group's charter may
also specify other participants, such as invited
experts or liaisons with other groups internal or external to W3C. The role
of these additional participants should be clearly stated, as well as whether
they are invited experts specified by name, invited experts in a specific field
to be invited by the Chair, or representatives of particular organizations.
Note: Liaisons with external organizations must be coordinated
by the Team due to requirements for public communication, IPR policies,
confidentiality agreements, mutual membership agreements, etc. Please refer to
"Guidelines for Establishing Partnerships
[PUB22]."
Coordination Group participants must follow the conflict of
interest policy by disclosing information to the rest of the group.
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 dependencies have been resolved.
A Coordination Group charter must include the following information:
The group's mission;
The scope of the group's work, including the names of coordinated groups
and names of contacts in those groups;
Any dependencies of this group on other entities;
The level of confidentiality of the group's proceedings and, in particular,
whether the charter itself will be public. The charter should include rationale
for any level of confidentiality other than public;
A W3C Note is a dated, public record of an idea, comment, or document.
Notes are published at the discretion of the Director. Authorship of a Note may
vary greatly (e.g., by the Team, by a W3C Working Group, by a W3C Member,
etc.). Some examples of when W3C publishes a Note include:
Documents that are part of an acknowledged Member
Submission request. Members wishing to have ideas that are developed
outside of W3C Activities published at the W3C site as a Note must follow the
Submission process.
Informative resources produced by a Working Group or the Team.
All public technical reports [PUB11] are
available at the Web site. W3C will make every effort to make archival
documents indefinitely available at their original address in their original
form.
The Team is not required to publish a technical report that does not conform
to the Team's publication rules [MEM11] (for
naming, style, copyright requirements,
etc.). These rules are subject to change. The Team must inform group Chairs 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 "Status of this Document"
section).
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, whether or not it is part of the Recommendation track, who developed
it, where to send comments about it, whether implementation experience is being
sought, any significant changes from the previous version, and any other
relevant metadata.
The status section of a Working Draft must set expectations about the
stability of the work (e.g., that it may be superseded, obsoleted, or dropped
at any time, that it should not be cited as other than a work in progress,
etc.) and must indicate the how much consensus within W3C there is about the
Working Draft (e.g., no consensus, consensus among the Working Group
participants, etc.).
The status section of a Note must
indicate the level of endorsement within or by W3C for the material in the
Note, and set expectations about future commitments from W3C to pursue the
topics covered by the Note or to respond to comments about the Note.
The W3C "Recommendation track" is the process that W3C follows to build
consensus around a Web technology, both within W3C and in the Web community as
a whole. W3C turns a technical report into a Recommendation by following this
process. The labels that describe increasing levels of maturity and consensus
along the Recommendation track are:
A technical report on the Recommendation track begins as a Working Draft. A
Working Draft is a chartered work item of a Working Group and generally
represents work in progress and a commitment by W3C to pursue work in a
particular area. The label "Working Draft" does not imply that there is
consensus within W3C about the technical report.
A Last Call Working Draft is a special instance of a Working Draft that is
considered by the Working Group to fulfill the relevant requirements of its
charter and any accompanying requirements documents. A Last Call Working Draft
is a public technical report for which the Working Group seeks technical review
from other W3C groups, W3C Members, and the public.
A Candidate Recommendation is believed to meet the relevant requirements of
the Working Group's charter and any accompanying requirements documents, and
has been published in order to gather implementation experience and feedback.
Advancement of a technical report to Candidate Recommendation is an explicit
call for implementation experience to those outside of the related Working
Groups or the W3C itself.
A Proposed Recommendation is believed to meet the relevant requirements of
the Working Group's charter and any accompanying requirements documents, to
represent sufficient implementation experience, and to adequately address
dependencies from the W3C technical community and comments from previous
reviewers. A Proposed Recommendation is a technical report that the Director
has sent to the Advisory Committee for review.
A W3C Recommendation is a technical report that is the end result of
extensive
consensus-building inside and outside of W3C about a particular
technology or policy. W3C considers that the ideas or technology specified by a
Recommendation are appropriate for widespread deployment and promote W3C's mission [PUB15]
Possible transitions of the
Recommendation track
Generally, Working Groups create Working Drafts with the intent of advancing
them along the Recommendation track. However, publication of a technical report
at one maturity level does not guarantee that it will advance to the next. Some
technical reports may be dropped as active work or may be subsumed by other
technical reports. If, at any maturity level of the Recommendation track, work
on a technical report ceases (e.g., because a Working Group or Activity closes,
or because the work is subsumed by another technical report), the technical
report should be published as a W3C Note and the
status section should include the rationale.
Every technical report on the Recommendation track 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. Editors are
not required to be part of the Team.
Working Groups must archive each decision to request advancement of a
technical report to the next maturity level of the Recommendation track.
Any time a technical report advances to a higher maturity level, the
announcement of the transition must indicate any formal objections.
If, at any maturity level prior to Recommendation, review comments or
implementation experience result in substantive changes to a technical report,
the technical report should be returned to Working Draft for further work.
Entrance criteria. The Director must approve publication of
a first public Working Draft (or version for review beyond the Membership).
Publication of a Working Draft is not an assertion of
consensus, of endorsement, or of technical and editorial quality. 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.
Ongoing work. Once a Working Draft has been published, the
Working Group should continue to develop it by encouraging review and feedback
within and outside of W3C. To accommodate the schedules other Working Groups,
the Working Group should negotiate review by those Working Groups, possibly
prior to a formal review period such as Last Call.
Possible next maturity level. The Working Group may advance
a Working Draft to Last Call Working Draft.
Entrance criteria. Before advancing a technical report to
Last Call Working Draft, the Working Group must:
fulfill the relevant requirements of the Working Group charter and those of
any accompanying requirements documents, or document which relevant
requirements they have not fulfilled;
formally address all issues raised by Working
Group participants, other Working Groups, the Membership, and the public about
the Working Draft.
identify known dependencies and solicit review from all dependent Working
Groups;
solicit public review. Consequently, a Last Call Working Draft must be a
public document.
Duration of the review. Generally, a Last Call review
period is three weeks long, but it may be
longer if the technical report is complex or has significant external
dependencies. The Working Group should negotiate the Last Call schedule with
known dependent groups.
Ongoing work. During a Last Call review period, the Working
Group should solicit and respond to comments from the Team, the Members, other
W3C groups, and the public. Advisory Committee representatives are strongly
encouraged to review Last Call Working Drafts so that substantive issues are
raised and addressed prior to Candidate Recommendation and well before Proposed
Recommendation.
To ensure the proper integration of a technical report in the international
community, from this point on in the Recommendation process it must include a
statement about how the technology relates to existing international standards
and to related work outside of W3C.
Possible next maturity levels. After a Last Call review,
the Working Group may request that the Director advance the technical report to
Candidate Recommendation or Proposed Recommendation. If the Director does not
advance the technical report to Candidate Recommendation or Proposed
Recommendation, the Director must return it to Working Draft by announcement to
all W3C groups.
Entrance criteria. Before advancing a technical report to
Candidate Recommendation, the Director must be satisfied that:
the Working Group has fulfilled the relevant requirements of the Working
Group charter and those of any accompanying requirements documents. The
Director must be satisfied with the rationale for any relevant requirements
that have not been fulfilled;
the Working Group has formally addressed all
issues raised during the Last Call review period (possibly modifying the
technical report);
the Working Group has resolved dependencies with other groups.
The Working Group is not required to show that a technical report has two
independent and interoperable implementations as part of a request to advance
to Candidate Recommendation. However, the Working Group is encouraged to
include a report of present and expected implementation as part of the
request.
The request to the Director to advance a technical report to Candidate
Recommendation should indicate whether the Working Group expects to satisfy any
Proposed Recommendation entrance criteria beyond the default requirements
(described below).
The Director advances a technical report to Candidate Recommendation by
sending a call for implementation experience to the Advisory Committee (refer
to "How to organize a Candidate
Recommendation review" in the Member Guide
[MEM9]). Advisory Committee representatives may
appeal the decision to advance the technical report.
Duration of the implementation period. The Director's call
for implementation experience must indicate a minimal duration for the
Candidate Recommendation period (designed to allow time for review comments).
The announcement should also include the Working Group's estimate of the time
expected to gather sufficient implementation data.
Ongoing work. The Working Group may update the technical
report during the Candidate Recommendation period if those updates clarify
existing meaning or consensus.
Possible next maturity levels. After a Candidate
Recommendation implementation period, the Working Group may request that the
Director advance the technical report to Proposed Recommendation. If the
Director does not advance the technical report to Proposed Recommendation, the
Director must return the technical report to Working
Draft by announcement to the Advisory Committee.
Entrance criteria. Before advancing a technical report to
Proposed Recommendation, the Director must be satisfied that:
the Working Group has fulfilled the relevant requirements of the Working
Group charter and those of any accompanying requirements documents. The
Director must be satisfied with the rationale for any relevant requirements
that have not been fulfilled;
the Working Group has formally addressed
issues raised during the previous review or implementation period (possibly
modifying the technical report);
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
advance the technical report to Proposed Recommendation even without adequate
implementation experience. In this case, the technical report status section
should indicate why the Director advanced the technical report directly to
Proposed Recommendation;
the Working Group has satisfied any other announced entrance criteria
(e.g., any announced in the request to advance to Candidate
Recommendation).
Duration of the review. The Proposed Recommendation review
period must be at least four weeks.
Ongoing work. During the Proposed Recommendation review
period, the Working Group should request endorsement and support from the
Membership (e.g., testimonials for a press release).
The Director should ask the Working Group to address, in a timely manner,
significant issues raised by the Advisory Committee during a Proposed
Recommendation review. If asked by the Director, the Working Group must formally address these issues. Formal replies may be
sent to reviewers after the end of the review (e.g., for reviews sent at the
end of the review period). Note: The Team contact must make
every effort to ensure appropriate confidentiality when conveying issues raised
by Advisory Committee representatives to the Working Group.
During a Proposed Recommendation review, 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.
Advisory Committee representatives should encourage a thorough review by
their organization of the technical report at Last Call or earlier, rather than
at the Proposed Recommendation stage. Advisory Committee representatives may
still raise issues in their review about the technical content of a Proposed
Recommendation.
Possible next maturity levels. The Director may advance the
technical report to Recommendation, possibly with minor changes from the
version reviewed by the Advisory Committee. If the Director does not advance
the technical report to Recommendation, the Director must return the technical
report to either Candidate Recommendation or Working Draft.
Whatever the decision, it must take the form of an announcement to the
Advisory Committee. The Advisory Committee should not expect an announcement
sooner than two weeks after the 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.
Entrance criteria. The Director must be 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.
The Director advances a technical report to Recommendation by sending an
announcement to the Advisory Committee. If there was any
dissent in the Proposed Recommendation reviews, Advisory Committee
representatives may appeal the decision to advance the
technical report.
Ongoing work. W3C should make every effort to maintain its
Recommendations (e.g., by tracking errata, providing testbed applications,
helping to create test suites, etc.) and to encourage widespread
implementation. The Working Group and editors should track errata and document
clarifications.
W3C may publish a revised version of a Recommendation to make minor
clarifications, error corrections, or editorial repairs, without following the
Recommendation track. The status section of an
editorial revision must indicate its relationship to previous versions (e.g.,
that it supersedes previous versions). The Team must notify the Members when an
editorial revision of a Recommendation is published.
If more substantial revisions to a Recommendation are necessary, a Working
Group must follow the Recommendation process to produce the
revision. The status section of any
Recommendation must indicate its relationship to previous related
Recommendations (e.g., an indication that a Recommendation supersedes,
obsoletes, or subsumes another, etc.).
A W3C Recommendation may be submitted to another standards body for adoption
and formal approval by that body.
Possible next maturity levels. In this version of the
Process Document, there are no maturity level changes after Recommendation; a
technical report remains a Recommendation indefinitely.
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.
The Advisory Committee reviews proposals for new Activities,
Recommendations, and changes to the W3C Process. Each review period begins with
a call for review from the Director or the Chairman to the Advisory Committee.
The review form in this announcement
must clearly indicate:
The nature of the proposal;
The end of the review period (i.e., the deadline for returned review
forms);
One or more email addresses where completed review forms must be sent.
The announcement should also estimate the schedule of the entire review
process, up to and including the decision (e.g., the deadline for review
comments is on this date, and a decision is not likely sooner than two weeks
thereafter).
Each Member organization is allowed one review, which must be returned by
its Advisory Committee representative. If more than one review form is received
from a Member, the reviews are counted as one valid review if they agree,
otherwise they are ignored and the Team must notify the Member's Advisory
Committee representative of the discrepancy.
In the event that an Advisory Committee representative is unable to respond
to a call for review, another individual in the organization may submit the
review form accompanied by a statement that the individual is acting on behalf
of the Advisory Committee representative. The Advisory Committee representative
must receive a copy of this review form.
The Team must provide two channels for Advisory Committee review comments:
one visible to Members after the review (but not during), and one
Team-confidential. AC Representatives may send information to either or both
channels. For example, they may choose to make their opinion known to the
Membership but to send implementation schedules or other confidential
information to the Team only. After the outcome of the review is known, the
Team must make available to the Members comments sent to the Member-visible
channel.
After the review period, the Director must announce to the Advisory
Committee the level of support for the proposal (unanimity,
consensus, or dissent).
The Director must also indicate whether there were any documented objections,
while ensuring appropriate confidentiality. This
W3C decision must be one of the following:
The proposal is approved, possibly with minor changes integrated.
The proposal is returned for additional work, with a request to the
initiator to formally address certain
issues.
The proposal is rejected.
Note: 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.
Advisory Committee representatives may appeal certain decisions, though
appeals are only expected to occur in extraordinary circumstances.
For a Recommendation decision, Activity creation, modification, or extension, and
for changes to the W3C Process, Advisory Committee
representatives may only appeal when there is
dissent. In this case, the appeal must be initiated within two weeks of the decision.
For any of the following, the appeal must be initiated within four weeks of the decision:
Any Advisory Committee representative may initiate an appeal by sending a
request to the Team (explained in detail in the New
Member orientation [MEM4]). The Team must announce the appeal process to
the Advisory Committee and provide an address where Advisory Committee
representatives may send comments. 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 Team may organize 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 ideas about a technology or policy, or to
address the pressing concerns of W3C Members. Organizers of the first type of
workshop should 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.
In the call for participation in a workshop or symposium, the Team must
indicate participation requirements or limits. The Team should indicate
expected deliverables (e.g., reports, minutes, etc.). 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 for a workshop or
symposium 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.
The Member Submission process allows Members to propose technology or other
ideas for consideration by the Team. 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 Submission process also allows the Team to review proposed
technology and accurately relay the status of Submission requests to the
media.
Note: To avoid confusion about the Member Submission
process, please note that:
Members wishing to have ideas that are developed outside of W3C Activities
published by W3C as a Note must follow the Member Submission process.
Members do not submit Notes to W3C, they submit documents that are
published as Notes upon acknowledgment. Acknowledgment also results in
publication of Team comments on the submitted ideas.
Documents in a Member Submission request are developed outside of W3C. 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).
The Submission process consists of the following steps:
A Member (possibly on behalf of several cooperating Members) sends a
Submission request to the Team; (refer to "How to
send a Submission request [MEM8]"). The term "Submitter" is used below to
refer to all of the Members involved in a Submission request. Only W3C Members
may be listed as Submitting Members.
The Team reviews the request and the Director must either acknowledge or
reject it.
If acknowledged, the Team must publish submitted documents as W3C
Notes.
If a Submission request is rejected, the Submitter may appeal to either the
TAG or the Advisory Board; see details below.
Publication of a Note by W3C does not imply endorsement by W3C,
including the W3C Team or Membership. 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. Documents
that are part of an acknowledged Submission request may not be referred to as
"work in progress" of the W3C.
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 Submitting Member may withdraw
support for a Submission request (described in "How
to send a Submission request" [MEM8]"). A Submission request is "withdrawn"
when no submitting Members support it. The Team must not make statements about
withdrawn Submission requests.
Prior to acknowledgment, the Submitter 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 must not imply in public or
Member communication that W3C is working (with the Submitter) on the material
in the Submission request. The Submitter may publish the documents in the
Submission request prior to acknowledgment (without reference to the Submission
request).
After acknowledgment, the Submitter must not, under any
circumstances, imply W3C investment in the acknowledged material
until, and unless, the material has been adopted as part of a W3C Activity.
The Submitter must agree that, if acknowledged, published material will be
subject to the W3C document notice [PUB18] and
will include a reference to it. The Submitter may hold the copyright for the
content of a W3C Note published as the result of an acknowledged Submission
request.
A Submission request must fulfill the requirements established by the Team.
The Team must send a
validation notice to the Submitter as soon as the Team has reviewed any
Submission request and judged it complete and correct.
Prior to a decision to acknowledge or reject the request, the Team must
hold the request in the strictest confidentiality. In particular, the Team must
not comment to the media about the Submission request.
If a Working Group is already pursuing work in the area of a Submission
request, the Team should coordinate its evaluation of the request with the
Working Group, while ensuring confidentiality.
The Director acknowledges a Submission request
by sending an announcement to the Advisory Committee. This announcement must be
made between one and four weeks after the validation notice. The announcement may be made
at any time during the three-week window, but the Team must tell the Submitter,
within one week of the validation notice, when the announcement is most likely
to be made.
Once a Submission request has been acknowledged, the Team must:
Publish the Submission request.
Publish Team comments about the Submission request.
Publish any documents in the Submission request as W3C
Notes. These documents must conform to the
publication rules [MEM11] established by the Team. The status sections of
these documents must explain that these Notes are the result of an acknowledged
Member Submission request, that publication does not imply endorsement by W3C,
and that publication does not imply that any further action will be taken by
W3C.
The Director may reject a Submission request for a variety of reasons,
including the following:
The ideas expressed in the request are poor, may harm the Web, or run
counter to the W3C's mission [PUB15].
The topics covered in the request lie outside the scope of W3C's
Activities.
The IPR statement made by the Submitting organizations is too restrictive;
(see W3C's IPR policy).
In case of a rejection, the Team must inform the Submitter's Advisory
Committee representative(s). If requested by the Submitter, the Team must
provide rationale to the Submitter about the rejection. Other than to the
Submitter, the Team must not make statements about why a Submission request was
rejected.
The Advisory Committee representative(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 to the TAG its rationale for the
rejection. 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 documents on the Recommendation track,
with the Advisory Board acting as the sponsoring Working
Group. The Advisory Board initiates review of a Process Document as
follows:
The Chairman advances the Process Document to Last
Call by sending a call for review to the Advisory Committee and possibly
other recipients.
After comments have been formally addressed
and the document possibly modified, the Chairman calls for a four-week Advisory Committee review (in the manner
of a Proposed Recommendation review).
After comments have been formally addressed,
the Chairman 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 publish a revised version of Process Document to make minor
clarifications, error corrections, or editorial repairs, without following the
preceding review process. The status section of
an editorial revision must indicate its relationship to previous versions
(e.g., that it supersedes previous versions). The Team must notify the Members
when an editorial revision of a Process Document is published.
The following individuals participated in the preparation of this document
while serving (at different times) on the W3C Advisory Board: Ann Bassetti (The
Boeing Company), Carl Cargill (Sun Microsystems), Paul Cotton (Microsoft), Paul
Grosso (Arbortext), Renato Iannella (IPR Systems), Ora Lassila (Nokia),
Håkon Wium Lie (Opera Software), Larry Masinter (Adobe Systems), Bede
McCall (Mitre), Thomas Reardon (Microsoft), David Singer (IBM), and Steve
Zilles (Adobe Systems). Jean-François Abramatic was the W3C Chairman and
Chair of the Advisory Board.
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 September 16, 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.