World Wide Web Consortium Process Document

This document describes the processes that govern the operation of the World
Wide Web Consortium (W3C) and the relationships between W3C Members,
the W3C Team, and the general public. This version of the Process
Document was published 8 June 1999.

W3C Members who have comments about this document should consult
the Member guide for
information about Process Document feedback. Comments from
the Team should be sent to the appropriate Team mailing
list. If you're not a Member, please refer to "About the W3C" at
the W3C Web site for Membership information.

Founded in 1994 to develop common protocols for the evolution of the World
Wide Web, the World Wide Web Consortium (W3C) is an international association
of industrial and service companies, research laboratories, educational
institutions, and organizations of all sizes. All of these organizations share
a compelling interest in the long term evolution and stability of the World
Wide Web (Web).

W3C is a non-profit organization funded partly by commercial members.
Its activities remain vendor neutral, however. W3C also receives the support
of governments who consider the Web the platform of choice for a global
information infrastructure.

W3C was originally established in collaboration with CERN, birthplace of
the Web, with support from DARPA and the European Commission.

W3C's mission is to lead the evolution of the Web -- the universe of information
accessible through networked computers.

W3C's long term goals are:

Superior Web Technology. By promoting interoperability and encouraging
an open forum for discussion, W3C commits to leading the technical evolution
of the Web. W3C must ensure that the Web remains a robust, scalable, and
adaptive infrastructure.

Universal Web Accessibility. W3C strives to make the Web accessible
to as many users as possible and to promote technologies that take into account
the vast differences in culture, education, ability, material resources,
and physical limitations of users on all continents.

Responsible Web Application. However vast the Web becomes, it remains
essentially a medium for human communication. As such, the Web's impact on
society cannot be dissociated from decisions that guide its development.
W3C must guide the Web's development with careful consideration for the novel
legal, commercial, and social issues raised by this technology.

Integral to the W3C process is the notion of consensus. The W3C
process requires those who are considering an issue to address all participants'
views and objections and strive to resolve them. Consensus is established
when substantial agreement has been reached by the participants. Substantial
agreement means more than a simple majority, but not necessarily
unanimity. While unanimity is preferred,
it is not practical to require that Working Groups, for example,
reach unanimity on all issues.
In some circumstances, consensus is achieved when the minority no longer
wishes to articulate its objections. When disagreement is strong, the opinions
of the minority are recorded in appropriate documents
alongside those of the majority.

Groups strive to reach consensus in order to provide a single solution acceptable
to the market at large. If a group makes a decision that causes the market
to fragment -- despite agreement by those participating in the decision --
the decision does not reflect a single market and therefore the group has
failed to reach true consensus.

All W3C technical reports and software are made available
free of charge to the general public (see the
document notice).
This policy comes from the core goal of W3C to keep the Web as one and is
part of the Membership agreement.
Moreover, to ensure that its results are acceptable to the general public
and to promote trial implementations, W3C may call for
public comments about working drafts and software releases.

W3C promotes an open working environment. Whenever possible,
technical decisions should be made unencumbered by intellectual
property right (IPR) claims. To this end, W3C discloses to the entire
Membership all IPR claims made by Members. Members may disclose IPR
claims at any time. Members disclose patent and other IPR claims by
sending email to an archived mailing list that is readable by Members
and the Team: patent-issues@w3.org. Members
must disclose all IPR claims to this mailing list but
they may also copy other recipients. For instance, they should copy
the Activity Lead responsible for a particular technology to ensure
that the IPR claims receive prompt consideration.

Advisory Committee representatives are responsible for facilitating
communication with IPR contacts in their organization. When disclosing
IPR claims, individuals should therefore copy their Advisory Committee
representative.

Member disclosures of IPR claims about a particular subject should
include the following language:

To the best of my knowledge, I believe my organization
has/doesn't have IPR claims regarding [subject].

Members are encouraged to disclose their claims in detail whenever
possible.

Announcements, important documents, and frequently visited Web
pages should remind Members to disclose IPR claims. Important places
of interaction include: Activity proposals and briefing packages,
calls for participation in groups and their charters, the Member
home page, Activity home pages, and Group home pages.

Invited experts are required to
disclose IPR claims in the same manner as individuals from Member
organizations.

There are three qualities an individual must possess
in order to join the W3C Team or participate in a
W3C Activity (e.g., act as a Chair, editor, etc.):

Technical competence in one's role

The ability to act fairly

Social competence in one's role

Advisory Committee representatives who nominate individuals for
participation in W3C Activities are responsible for assessing and
attesting to the qualities of participants from their organization.

Individuals participating in a W3C Activity (e.g., within a Working Group)
represent not only their own ideas but also the interests of the companies
or organizations with which they have relationships. As these companies and
organizations are often Members of W3C, all participants in a W3C Activity
should clearly disclose, as is customary, the financial interests and
affiliations they have with W3C Members. These disclosures should be kept
up-to-date as the individual's professional relationships and W3C Membership
evolve.

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.

When an individual accepts a role as Chair or editor, the Member
organization that employs that individual recognizes that this work as
unbiased officer of the Group is done as part of the individual's work
for the Member.

The Members. Through
active investment in W3C Activities,
the Members ensure the strength and direction of the Consortium.

The Team. Informed, fair, and consistent
guidance from the Team keeps the Consortium running smoothly.

The Offices. The Offices attract
new Members from different regions around the world,
ensuring the distribution of W3C's message with the proper
sensitivity to cultural differences, and gathering input from
national entities. Please consult the
list of W3C Offices
[PUB16] at the Web site.

As part of its mission to make the Web
accessible to all, W3C seeks a diverse Membership from around the
world. To meet the needs of a heterogeneous global population of Web
users, W3C interacts with vendors of technology products and services,
content providers, corporate users, research laboratories, standards
bodies, and governments. By working together, W3C's member
organizations (hereafter, "Members") reach consensus on specifications, thus encouraging
stability in this rapidly evolving technology. W3C also maintains
close ties with related organizations such as the IETF, notably for
the development of specifications.

Access to the Member Web site, where Members can find
newsletters, announcements,
and information on events, technologies, software releases, Activity
and group news, discussion forums, and mailing lists.

The right to display the W3C logo on promotional material and
to publicize the Member's participation in W3C Activities.

W3C Membership is open to all entities (as described in "How to Join W3C" [PUB5]). In the interest of
ensuring the integrity of the consensus process, W3C may limit the
influence of related Members in some
circumstances. 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.

A subsidiary is an organization of which
effective control and/or majority ownership rests with another, single
organization.

Under any circumstance where restrictions apply to related Members,
it is the responsibility of those Members to disclose the
relationship.

The Chairman manages the general operation of the Consortium,
chairs Advisory Committee and Advisory Board meetings, oversees the
development of the W3C international structure (e.g., role of hosts,
creation of W3C Offices, etc.), coordinates liaisons with other
standards bodies, and addresses legal and policy issues.

The Director is the lead architect for the technologies developed
at the Consortium. The Director also approves Recommendations,
Activity proposals, and charters; designates Group Chairs; and
acknowledges Submission requests.

The Team manages W3C Activities and
establishes the mechanisms and procedures for doing so; this document
does not include the details of those mechanisms. The Team provides
information to the Members (through email, at the Member Web site,
etc.) and may be reached directly by Members through the appropriate
Team contact (see [MEM10]).

As coordinators of W3C Activities, the Team has the following
responsibilities:

Provide direction to W3C by keeping up-to-date on new technology, market
fluctuations, and the activities of related organizations.

Ensure cooperation between Members while promoting innovation.

Encourage Member initiatives and Submission
requests and establish efficient
administrative mechanisms that allow these initiatives to flourish.

Organize and manage W3C Activities so as to optimize the achievement of goals
within practical constraints (such as resources available).

Keep Members abreast of W3C Activities.

Inform the general public of W3C Activities and gather ideas and input from
outside sources.

Market W3C results to gain wide acceptance for them in the Web community.

Market W3C to attract new Members -- the larger the member base, the easier
it will be to promote W3C Recommendations.

To promote cooperation between the Members and the Team, Member
organizations may send visiting engineers to work with the Team at host institutions.

The W3C Director's most visible role involves approving or
rejecting proposals that have been reviewed by the Advisory Committee
(Activity proposals, Proposed Recommendations) or the Team (Submission requests). A Director's
decision implies that consensus has been
reached by the Advisory Committee or the Team and
accounts for comments collected during a review, projections as
to whether W3C is likely to achieve market consensus, and personal
experience.

Each Director's decision must be announced to the Advisory
Committee through an appropriate mailing list.

For most of the procedures described in the Process Document, the
Director's decision follows a review by the Advisory Committee. Time intervals between the end of
an Advisory Committee review period and the Director's decision are
not specified in this document. This is to ensure that the Director
has take sufficient time to consider comments gathered during a
review.

For those parts of the process when a
Director's decision is not preceded by a review by the Advisory
Committee (namely, charter or process modifications), the Advisory
Committee may appeal the decision. If five percent (5%) or more of the
representatives appeal, the proposals in question will be submitted to
the Advisory Committee for review.

W3C is not a legal entity. W3C contracts and details of Membership are
established between each Member company and the host institutions. Host
institutions pledge that no Member will receive preferential treatment within
W3C and that individual contracts will remain confidential.

Internal administrative details, including Team salaries, detailed budgeting,
and other business decisions must be held in confidentiality between the
Team and the host institutions.

The Advisory Committee consists of one representative from each
Member organization. The AC representative is the official link
between the Member organization and the Team. AC representatives
have the following responsibilities:

Transmit information from the Team
(official statements, newsletters,
calls for participation, acknowledgments, etc.) to their
Member organization and ensure the confidentiality and proper
circulation of this information.

Resolve conflicting votes from group participants representing their organization.

Each AC representative is named in the Membership Agreement when
the organization joins W3C [PUB5]. When a
Member organization wishes to change its AC representative, the
departing representative must notify the Director of the change by
email. If the departing AC representative cannot be contacted, the new
representative shall be confirmed by a responsible officer of the
Member organization.

The Advisory Committee will hold face-to-face meetings approximately
twice
a year. These meetings will be geographically distributed to areas where
there is a significant portion of the Membership.
At each Advisory Committee meeting, the W3C Team will provide Member
organizations with an update of key W3C information, including:

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.

A list of Activities started since the previous AC meeting.

A list of Activities completed or terminated since the previous AC meeting.

The date and location of each meeting shall be announced at least
six months (and preferably one year)
before the planned date. In general, only one representative from each
Member organization attends each AC meeting. In exceptional
circumstances (e.g., a period of transition between representatives
from an organization), the Member may petition the Director for
permission to send a second representative.

At least eight weeks
before an AC meeting, a mailing list will be established
(and AC representatives notified) by which AC representatives may suggest
topics of discussion for the meeting. Suggestions must also be sent to the
mailing list for internal AC discussions. The agenda for the meeting will
be prepared by the Team two weeks before the meeting. The agenda will incorporate
Member suggestions, Team reports required by the W3C process, and other topics
approved by the Director.

Advisory Committee meetings are chaired by the Chairman. Minutes of the meeting
must be posted within two weeks after the meeting. These minutes will include
the agenda, a summary of discussions, and any action items identified during
the meeting.

From time to time, Advisory Committee representatives are asked to
review proposals (Activity proposals, Proposed Recommendations,
proposed process changes, etc.). Each review period begins with an
announcement (the "call for review") from the Director to the Advisory
Committee on the AC mailing list. A ballot, to be completed and
returned to a specified address, accompanies each call for review.
The ballot must clearly indicate:

The nature of the proposal.

The deadline for returned ballots (and possibly other deadlines).

One or more email addresses where completed ballots must be sent.

The review period ends on the date specified in the ballot (unless
extended as described below).

Each unrelated Member organization is
allowed one ballot, which must be returned by its AC representative.
Each group of related Members is also allowed one ballot, which must
be returned by a single AC representative chosen by the group. In the
event that the AC representative is unable to participate, another
person in the organization may submit the ballot accompanied by a
statement that the person is acting on behalf of the AC
representative. The AC representative must receive a copy of this
ballot. If more than one ballot is received from a Member
organization, the ballots are counted as one valid ballot if they
agree, otherwise they are ignored and the AC representative will be
notified of the discrepancy.

Each ballot will ask the AC representative to provide
the following information:

Reviewer information (name, email address, Member organization, etc.)

An opinion of the proposal, one of the following:

The proposal is satisfactory as is (or with insubstantial changes
proposed by others).

The proposal is satisfactory, but only if certain
changes are integrated. The returned ballot must be accompanied
by a list of proposed changes.

The proposal should be amended due to substantial problems.
The returned ballot must be accompanied by explanatory comments.

The proposal should be rejected.
The returned ballot must be accompanied by a detailed explanation.

Information about related IPR claims. Recall that
IPR disclosures must
be sent to the mailing list described in the section on W3C's IPR policy.

A provisional statement of concrete support for the proposal
if approved (e.g., implementation of a specification,
dedication of resources to an Activity, participation in
a newly formed group, etc.).

A provisional statement of any foreseen constraints.

Additional comments and information, depending on the ballot.

The following types of comments are of particular interest to the
Director:

Comments about dependencies between the proposal and other
Activities, documents, organizations, standards, etc.

These comments and statements are non-binding, but do help
the Director reach a decision.

Comments received during the review period shall be sent by the
Director to all AC representatives within one week after the end of the review
period.
If any ballots expressed opposition to the proposal (opinions
three and four above), for a two week
period representatives may request to change their ballots based on
comments and other new information. If five percent (5%) or more of the
representatives (or fewer at the discretion of the Director) request
to change their ballots, the entire review process will start from
scratch according to the same procedures.

Once the review period has ended, the Director issues a decision as to the outcome of the
proposal. The Director may:

Approve the proposal.

Approve the proposal with minor changes integrated.

Return the proposal for work, with a request to the initiator to
address certain issues.

Reject the proposal.

All comments will be archived so that anyone on the AC may review
them.

Created in March 1998 to provide guidance on strategy, management,
legal matters, process issues, and conflict resolution, the
Advisory Board ensures that W3C remains responsive to the
needs of the Members as well as entities outside of W3C (notably
other standards bodies).

The Advisory Board exists to provide rapid feedback to the Team on
issues that are vital to W3C's operation and cannot wait until the
next Advisory Committee meeting for resolution. The dynamism of the
Advisory Board also enhances the quality of life for Members as
Advisory Committee representatives may bring important issues to the
attention of the Advisory Board.

The Advisory Board is not a board of directors
that determines W3C's Activities and direction; the Members and Team
have this role.

In addition to the Chairman and Director, the Advisory Board
consists of individuals belonging to Member organizations. Advisory
Board participants are not required to be Advisory Committee
representatives.

Participants are elected to serve on the Advisory Board for one year. The yearly election process
begins with a call for nominations by the Director to the Advisory
Committee. The call must specify the number of available seats, the
deadline for nominations, the mailing list where nominations
must be sent, and any other relevant information.

Nominations should be made with the consent of the nominee
and should include a few informative paragraphs about the nominee.

Once the deadline for nominations has passed, the Director issues a
call for votes that includes the names of all nominees, the number of
available seats, the deadline for votes, the mailing list where votes
must be sent, and any other relevant information.

Once the deadline for votes has passed, the Director announces the
results to the Advisory Committee. The nominees with the most votes
are elected to fill the available seats. The term of those elected
begins with the announcement to the Advisory Committee.

Participants are expected to devote at least one day per month to
Advisory Board activities.

While Advisory Board participants are expected to act with the
interests of the Consortium in mind, they are not expected to act
against the interests of their organizations while doing so.

Ensure that W3C communication observes legal requirements, such as those
relating to anti-trust laws.

Maintain an accurate historical record of W3C Activities and accomplishments.

Assist Advisory Committee representatives in their role as communicators
within their organizations.

Help Member companies who wish to contribute their resources (notably for
communication) to W3C Activities.

Unless otherwise stated (e.g., in legal matters), electronic documents have
primacy over paper documents. When legal notifications, contracts, and other
forms of communication requiring hardcopy must be exchanged between the Team
and a Member organization, they must be sent to the appropriate Advisory
Committee representative via a guaranteed-delivery service. Billing information
may be sent to the designated contact person for each Member organization.

The W3C World Wide Web server has the address
http://www.w3.org/. All documents,
archives, and updates must be published at this site. The Web site must be
kept up-to-date by the Communication Team and all other contributors to the
site. Because the Web site is the sole source of so much critical information,
every reasonable means must be used to guarantee its availability at all
times. W3C assumes that public information on the Web site has a worldwide
audience.

The Communication Team will maintain a document registry on the
Web site. This registry will archive all active and obsolete W3C
documents (including URIs to each document) that bear a document name.

The Web site will also provide references to pertinent sources of
information (electronic or other). This will allow W3C Members and the
Team to keep up-to-date on external activities, and will lend
credibility to W3C's Web site as a trustworthy source of impartial and
quality information about the Web.

A portion of the Web site, known as the Member Web
site, will be reserved for access by authorized W3C
Members, Team, and other authorized people only. Members have access
to this information at all times.

The Communication Team will provide security mechanisms to protect
information at this site and will ensure that Members have proper
access.

All documents appearing on the Member Web site must be treated as
confidential within W3C. W3C Members must agree to use reasonable
efforts to maintain this confidentiality and not to release this
information to the general public or press. Documents that require
particularly confidential treatment must be marked as such.
An AC representative may extend access to Member-only
information to those fellow employees considered by the representative to
be appropriate recipients. All recipients are expected to respect the intended
(limited) scope of Member-only information.

The Member Web site includes a help page
[MEM6] to assist Members in finding information and appropriate
contacts within the Team.

The W3C Team will maintain one mailing list for sending general
information to W3C Members (including Newsletters, News announcements,
etc.). The email address of each Member organization's AC
representative will be on this list.

For both lists, the AC representative's email address should
suffice. However, upon request from the AC representative and subject
to approval by the Communication Team, additional addresses for the
Member organization may be added to each list. The Member company
must agree that redistribution of W3C mailings will be for internal
use only. Failure to contain distribution internally may result in
suspension of additional email addresses until the W3C Team can be
assured of appropriate distribution.

An AC representative may ask the Director, at the Director's
discretion, to forward an open letter to either list.

The Communication Team may also establish other mailing lists to
facilitate communication within a group. Only members of the group and
W3C Team may be listed in such a mailing list. Each group is
responsible for maintaining archives of these mailing lists on its
group space.

For interaction with the general public, the Communication Team maintains
general mailing lists to which anyone may subscribe and send messages.

The Communication Team will establish a mechanism for confirming and releasing
W3C information to the press and/or general public. Press releases and comments
to the press and public are primarily issued at the discretion of the W3C
Director, except for those processes explicitly defined in this document.

To promote the active and open participation of all Member organizations,
the Communication Team will maintain a calendar
[MEM3] of events that shows all official events scheduled by W3C.
Consortium-wide events will be differentiated from group events on this calendar.
Archives of the calendar will be maintained on the Member Web site, with
links to conclusions, email archives, and minutes from scheduled events.

Members and the Team should notify the Communication Team of events and schedules
that should appear on the calendar and of changes to the calendar. The
Communication Team will also notify Members of upcoming events through one
of the Member mailing lists.

The Communication Team will provide a weekly news service to the
Members. The Newswire [MEM8] provides
brief information about Activities, calls for review, calls for
participation, notifications of upcoming events, Director's decisions,
acknowledged Submission requests, and more. The Newsletter [MEM4] provides more in-depth
coverage of publications and events.

When W3C decides to become involved in an area of Web technology
or policy, it initiates an Activity in that area.
An Activity means that W3C resources -- people, time, money, etc. --
are dedicated to work in that area. Generally, an Activity is
carried out by one or more groups.

The Advisory Committee
has four weeks
to review the proposal.
During the review period, Advisory Committee representatives
must make known relevant IPR claims according
to the W3C IPR policy.

Once the review period has ended,
based on comments received during the review period, the Director
announces a decision about the disposition
of the proposal to the Advisory Committee. The announcement may
include calls for participation
in groups created as part of the Activity proposal.

Activities are not renewed. If
an Activity briefing package expires or if the Director decides that
the Activity's goals have changed significantly from those described
in the Activity briefing package, (e.g., there is a substantial
increase in resources, a significant change in scope, etc.), and there
is still interest in the Activity, then a new Activity must be
created. The Activity statement from the old Activity should be part
of the new Activity proposal (in the briefing package).

It is natural for an Activity to evolve over time. This evolution
must be recorded in an Activity statement.
Activity statements should include statements of delivered work,
goals as they evolve, changing perspectives based on experience,
etc.

The Activity statement must be revised at least before each
ordinary Advisory Committee meeting.

Each Activity is initially defined by an Activity briefing package.
Members or the Team (generally working together) create a briefing
package and submit it to the Director for approval according to
mechanisms established by the Team.

If the briefing package is rejected, the Director must
provide the submitter(s) with a justification for the rejection.

If the briefing package is approved, it must be amended by the
submitter(s) to include a detailed W3C resource statement
(administrative, technical, and financial). The Director may also
request an indication of resource commitment on the part of the
submitter(s).

A briefing package must include the following information:

An Activity summary. What is the nature
of the Activity (e.g., to track developments, create
a specification, 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 market within the area of the proposal?
Who or what currently exists in the market?
Is the market 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 who will be the
Activity lead and what
groups will be created initially to pursue
the Activity. Provisional charters
for these groups must be included in the briefing package.
The date of the first face-to-face meeting of a proposed group
must be included in the
briefing package. The date of the first face-to-face
meeting of a proposed group may be no sooner
than eight weeks after
the date of the Activity proposal
to the Advisory Committee.

A summary of resources
(Member, Team, administrative, etc.) that will be dedicated
to the Activity. The briefing package may specify the
threshold level of effort that
Members must pledge in order for the Activity to be accepted.

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 briefing package
should remind AC representatives to disclose IPR claims
according to W3C's IPR policy.

A list of supporters, references, etc.
What community will benefit from this Activity?
Are members of this community part of W3C now?
Will they join the effort?

The briefing package must specify which groups will be created to
carry out this Activity and how those groups will be coordinated. For
each group, the briefing package 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).

The briefing package must also specify any events (e.g., workshops) foreseen for the
proposed Activity.

the duration of the charter. Groups are expected to carry out
their work for a period lasting from six months up to two years.

the nature of the deliverables to be produced (including minutes, reports,
specifications, and software), their frequency, and the process
for the group participants to approve the release of these deliverables.

any dependencies of other entities on the deliverables
of this group. For any dependencies, the charter must
specify how communication about the deliverables
(contact people, Coordination Groups, W3C contacts, etc) will take
place.

any dependencies of this group on other entities. For any
dependencies, the charter must specify when required
deliverables are expected from the other entities. The charter
should also include any requirements documents
that may serve the other entities. Finally, the charter should
specify expected conformance of this group with the deliverables
of the other entities. If a
Coordination Group is managing a Working Group, the Coordination
Group must monitor these dependencies to ensure they are respected;
otherwise the Working Group Chair has this responsibility.
For example, one group's charter may specify that another group
must review a specification before that document can become a
Recommendation. A Coordination Group must ensure that this
review takes place.

the intended degree of confidentiality of the Group proceedings and its
deliverables (Group, Members, Public). In particular, whether the charter
itself is for Members' eyes only or is a public document.

a statement about how the group's work and deliverables relate to and
depend on the work and deliverables of other groups (external or W3C).

communication mechanisms to be employed within the group, between the group
and the rest of W3C, and with the general public. The scope of each communication
mechanism must be clearly indicated in the charter,

voting mechanisms,

the level of involvement of the Team (track developments, write and edit
specifications, develop code, organize pilot experiments).

the W3C Team contact if known,

an estimate of the time commitment a group member would have to make in order
to participate in the above.

A group's charter must be approved by the Director (according to
mechanisms established by the Team) before the Director can create the group.

For all face-to-face meetings, the group Chair will announce the dates and
location of the group's next meeting at least eight weeks before the meeting.
Shorter notice for a meeting is allowed provided that there is unanimous
consent from every person on the group mailing list.

At least two weeks before the meeting, all group participants will be notified
of the meeting's agenda. Participants must confirm their attendance with
the Chair and the meeting organizer at least three days before the meeting.

Minutes of the meeting must be posted (through a mailing list and to the
group's Web space) within two weeks after the meeting. Action items must
be posted within two days after the meeting.

For all meetings, each absent group participant may nominate an alternate.
At any one time, a participant may have one and only one chosen alternate.

For all remote meetings (telephone, IRC, etc.), the group Chair will announce
that a meeting will take place at least one week before the meeting.

At least 24 hours before the meeting (or 72 hours if the meeting is on a
Monday) all group participants will be sent an email specifying how to join
the meeting (e.g., the telephone number) and the meeting's agenda. Participants
unable to attend a meeting should notify the Chair at least 24 hours before
the meeting.

Minutes of the meeting shall be posted (through a mailing list and to the
group's Web space) within 48 hours of the meeting. Action items must be posted
within 24 hours of the meeting.

For all meetings, absent group participants may nominate an alternate to
act on their behalf.

The Director announces the existence of a group by sending a
call for participation
to the Advisory Committee that includes a reference
to the defining charter, the name of the group's Chair(s),
the name of the Team contact, and an email
address for participant nominations. The group does
not exist prior to this announcement. Note that no Activity statement may refer to a group
until the group exists.

For groups created as part of an Activity proposal, the call for
participation may be issued at the same time as the Director's
decision to approve the Activity proposal. In this case, the
referenced charters are the provisional charters of the Activity
proposal, potentially amended according to comments received during
the review period, input from a Coordination group, etc.

To join a group, individuals must be nominated by an
Advisory Committee representative, either directly or indirectly. The
AC representative nominates the individual directly by sending email
to the address indicated in the Director's call for participation in the
group. Individuals are nominated indirectly by sending email to the
address themselves, and copying their Advisory Committee
representative. Group participants who do not represent a Member
organization (invited experts) must
still join a group by sending email to the indicated address.

Nominations must include the following information:

An estimate of the amount of time per week the
individual will dedicate to the group.

Disclosure, as described in W3C's IPR policy,
of IPR claims by the organization employing the
individual that are relevant to the group's work.

A description of how expenses incurred due to group
commitments (e.g., travel, telephone
conference calls, conferences, etc.) will be covered.

Individuals may join a group at any time during its existence and
follow the nomination procedure specified in the original call for
participation.

Group Chairs cannot reject a nomination, but the Director may. It
is the responsibility of the Advisory Committee representative to
ensure that nominees are qualified. Chairs should set expectations
about the roles and qualifications of participants to assist the
Advisory Committee representative.

At times it may be necessary or desirable to modify a group's
charter (e.g., to prolong it, to add a new work item,
etc.).

Before any modifications are made, the Chair must determine whether
the change is appropriate for the group (e.g., whether the group is
the appropriate forum for a new work item) and reach consensus in the group about the change. Group
participants who do not agree with the Chair's decision may raise
objections through their AC representative. In cases of unresolved
disagreement, the final decision is the responsibility of the
Coordination Group Chair, when the group is part of a Coordination
Group. Otherwise, the Director will decide which groups will pursue
which work items.

The Director must approve all proposed modifications to a charter.
The Director must announce the modifications to the Advisory
Committee and highlight significant changes (e.g., in resource
requirements). The Advisory Committee has four
weeks after the announcement
to appeal the decision.

This document defines four types of groups that may carry out W3C's Activities.

Working Groups. The primary goal of a Working Group
is to produce specifications or prototype software.

Interest Groups. The primary goal of an Interest
Group is to explore and evaluate Web technologies.

Coordination Groups. A Coordination Group facilitates
communication among Working Groups and Interest Groups. Coordination Groups
are used by the Team to help manage W3C on behalf of the Members, and ensure
the consistency and architectural integrity of its work.

The following sections describe the procedures that govern each type of group.

A Working Group's purpose is to study a technical or policy issue involving
the Web and to develop proposals for W3C Recommendations.
Working Groups are created according to the procedures indicated in this
document, including the procedure for charter
submission and approval.

To allow rapid progress, Working Groups are intended to be small (typically
less than 15 people) and composed of experts in the area defined by the charter.
The following people may participate in a Working Group on an ongoing basis:

Representatives of W3C Member organizations. If a participant does not speak
on behalf of the organization for which the participant works, this must
be indicated in the charter.

Experts who do not represent a Member organization. These
invited experts must
be approved by the Working Group Chair.

Participation on an ongoing basis implies a serious commitment to the Working
Group charter. Participation includes:

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.

Participants who meet these criteria (and new participants) are considered
to be "participants in good standing". If a participant cannot meet
these criteria, either (a) by missing more than one of every three remote
meetings or more than one of every three face-to-face meetings, or (b) by
not providing deliverables in a timely fashion twice in sequence, the participant
falls out of good standing. The AC representative of a participant's
organization will be informed of all failures by the participant to remain
in good standing.

The Chair may relax the attendance requirement for expensive meetings
(international phone calls or travel) for
invited experts who do not have
financial support.

Good standing may be regained by meeting the participation
requirements for two consecutive meetings.
Good standing is required to be able to vote. Those not in good standing
(and their alternates) are dropped from the Working Group
mailing lists.
W3C considers that a Member organization is participating in a Working
Group if at least one representative from the organization is in good standing.

The Chair may ask an invited expert
(who may or may not belong to a Member organization) to participate in
a Working Group on a one-time basis. They may not participate in
Working Group votes. One-time participation implies no commitment
from the participant nor does it imply future participation or
invitation to Working Group meetings.

Each Working Group (in conjunction with related Coordination
Groups and the Communication Team) will post its intermediate results
(called working drafts) to a public area of the
Working Group Web space. Working drafts must be labeled as such.
Please refer to the section on working drafts
for information required in the status section of a draft document.

If a deliverable is code, proofs of concept and demonstrations should
be published along with the code.

In addition to the deliverables specified in the Working Group charter, a
Working Group will post its intermediate results to the public Web site
at three-month intervals. The Working Group charter
must specify the process for approving the release of these intermediate
reports (e.g., consensus from the Working Group).

The following sections describe the processes by which Working
Groups reach consensus, record minority views, appeal decisions,
and vote when appropriate.

When resolving issues and making decisions, the goal of a W3C
Working Group should always be to achieve unanimity of opinion.

Where unanimity is not possible, the Group must reach consensus
(see the W3C consensus policy) by
considering the ideas and viewpoints of all participants (including invited experts) who are in good
standing. The Chair must be aware of which participants work for the
same Member organization (or related Members) and weigh their input
accordingly.

In establishing consensus, the Working Group must address the
legitimate concerns of the minority. When a solution is available that
addresses everyone's concerns, it should be preferred to a solution
that carries approval of a majority (even a large one) but that causes
severe problems to some members of the community. In general, it is
desirable that a large majority of the Group favor a decision and that
the minority accept the majority decision. However, at times it may be
necessary (e.g., for timely delivery of a specification)
to proceed with a large majority in favor and a small
minority convinced in their hearts that the majority is making a
mistake (possibly minor, possibly grave).

In order to ensure that the Chair can judge whether minority
viewpoints can be accommodated, dissenting opinions must be
accompanied by an indication of the technical reasons for the dissent
and of what changes in the proposal, if any, would suffice to change
the opinion to one assenting to the majority proposal. Dissents not
explained in this manner need not be considered when the Chair decides
whether consensus has been reached.

The Chair of the Working Group is responsible for ensuring that
minority views are accommodated if possible. To that end, a Chair may
occasionally ask members of the minority questions of the general form
"Can you live with this decision?"

If holders of the minority view say they can live with a given
decision, this will normally be taken as an indication that the group
can move on to the next topic, but the inverse is not necessarily
true: the minority 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 minority have in fact been addressed as far
as is possible and reasonable, then dissenting views will be recorded
and the Group will move on.

Decisions may be made during meetings (face-to-face or teleconference) as
well as through email. All decisions must be archived.

Minority views must be archived. If requested, the Chair must include
archived minority views with other deliverables (e.g., in the Chair's
report to the Director when a document goes to Proposed
Recommendation). During an Advisory Committee Review, representatives
must be able to refer to archived minority views. Minority views from the
Team that are to be recorded should be sent by the Team Contact for
the Group.

The Working Group participant presents a summary of the issue
being appealed to the Working Group Chair. The summary should
describe whether the issue is procedural or technical.
The Working Group participant should also
make the appeal known to the W3C Team contact for the Group
and the participant's Advisory Committee representative.

Within two weeks,
the Chair must answer the appeal and document
the decision in writing (e.g., by email). The W3C
Team contact should try to obtain the concurrence of the
Advisory Committee representative that the appeal has been addressed.

If the Working Group participant is not
satisfied with the decision, the appeal may be taken to the W3C
Director. The Working Group participant should also
make this appeal known to the Chair, the
Team contact, and the
Advisory Committee representative. The Director
may consult with the Advisory Board in
deciding the outcome of the appeal.

All appeals, counterarguments, rationales, and decisions must be
archived for reference (e.g., by the Working Group Chair).

At times, the Working Group may settle an issue by simple majority
rather than by trying to establish consensus; the Chair will decide
when majority voting is appropriate.

Working Groups should not use simple majority votes to resolve
issues that have a technical or process impact, but only when the
outcome is "arbitrary". As an example, while 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), it is
inappropriate to vote on substantive technical decisions regarding the
Working Group's deliverables.

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.

The charter of a Working Group may include provisions for Working
Group voting procedures (for example, in order for a proposal to pass,
it must gain a particular proportion of participant votes or a
particular proportion of the total membership of the Group).

In cases of deadlock, the Group or Chair may decide that it is
necessary to proceed by way of simple majority vote; this step should
be taken only in extreme circumstances. When simple majority voting
is used to break a deadlock on a major issue when consensus cannot be
reached, then the Chair must archive:

the decision to proceed
by simple majority vote rather than by consensus,

An Interest Group brings together people who wish to evaluate potential Web
technologies and policies. An Interest Group does not have the goals of a
Working Group -- development of specifications or code. Instead, it serves
as a forum to explore cooperation and exchange ideas.

It is quite possible that an Interest Group's studies will lead to the creation
of a Working Group, but this may not be known in advance nor is it guaranteed.
Interest Groups are created according to the procedures indicated in this
document, including the procedure for charter
submission and approval.

From time to time, Interest Group participants may choose to vote on issues
of policy or direction.

In an Interest Group, each Member organization or group of related Members is 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 are counted as one valid vote if they
agree, otherwise they are ignored and the relevant Advisory Committee
representative(s) will be notified of the discrepancy.

The Interest Group charter must specify the type of deliverable the group
intends to produce and with what frequency (e.g., a report summarizing the
group's findings or comments on and requirements for the activities of other
groups).

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.
Or, a Working Group may decide that to pursue its goals
more effectively, it should assign specific work to
smaller task forces. In this case, the Chair may ask for a
Coordination Group to be formed to manage the cooperating task forces
(which may be either Working Groups or Interest Groups).

Coordination Groups are created when dependencies exist so that
issues are resolved fairly and the solutions are consistent with W3C's
mission and results.

When an Activity is proposed,
dependencies should be made as explicit as possible in the briefing package. The briefing package may
include a proposed charter for a Coordination Group (designed to
coordinate groups described in the Activity proposal or to draw up
charters of future groups).

It is also the case that dependencies arise after the creation of
groups, and the Team should ensure that these are recognized and
accepted by the parties involved. The Team should, where necessary,
in consultation with Working Group Chairs, inform, create, and modify
Coordination Groups when a new dependency is detected. When the
issues within the scope of the Coordination Group are no longer being
(or to be) addressed by W3C, then the Coordination Group should be
closed.

Arbitration

W3C is a forum for those wishing to agree; it is not a battleground.
At times, unforeseen dependencies may arise that are proposed by one group
but that a related group does not wish to accept. Tension may also mount
when expectations defined in a dependency are misunderstood or are not met.
The Team should be informed of such tensions. Where a Coordination Group's
scope covers the issues and parties involved, it is the first locus of resolution
of such tensions. 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 charter of a Coordination Group must specify the scope of the group's
work and the frequency of its meetings. The charter must also list
the Working Groups or Interest Groups involved and the name of each group's
contact for communication with the Coordination Group.

The charter of a Coordination Group must also specify whether the group may
create new Working Groups. When new groups are created, they may not exceed
the scope of the Coordination Group.
In addition, any proposed Working Group may only
proceed subject to the Director's decision that sufficient Team resources
are available to support it
and that other organizational and coordination work is not first required.

The participants in a Coordination Group (defined
in the charter) 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.

The Team, after consultation with Working Group Chairs, is responsible for ensuring
that the Coordination Group structure is efficient and appropriate to its
needs at each point in time, and making modifications to the
list of participants as appropriate.

The Director appoints the Chair of a Coordination Group unless the majority
of participants of the Coordination Group requests an election of the Chair.
In case of an election, the Chair of the Coordination Group will be elected
by majority vote from and by the Membership of the Coordination Group.

A workshop brings experts together for a single meeting, typically for one
or two days. Workshops generally fall into two categories: those convened
so that Members may exchange ideas about a technology or policy and those
convened to address the pressing concerns of W3C Members.

Organizers of the first type of
workshop should use the workshop to gather information about
issues that interest its Members, opportunities to pursue activities,
directions for W3C, and possible resource commitments. The organizers
should plan a workshop program that includes position papers and
talks. These papers should be distributed to other workshop
attendees. The organizers may select among position papers to choose
attendees and/or presenters.
In order to allow speakers and authors adequate preparation time,
the call for participation must occur no later than eight weeks prior to the workshop's
scheduled date.

Organizers of the second type of
workshop have a different goal: to address concerns of Members and
resolve differences as quickly as possible. Although organizers must
clearly specify the scope of the workshop in their proposal, they will
not solicit papers. Due to the more urgent nature of this type of
workshop, the call for participation must occur no later than six weeks prior to the workshop's
scheduled date.

A workshop does not guarantee further investment by W3C in a
particular topic. However, a workshop may result in proposals for new
Activities or groups.

Workshop minutes will be taken by the W3C Team and made available
in the Member Area at the W3C Web site. The minutes of the workshop
must be published at the Member Web site before the Director may
propose any new Activities to the Advisory Committee based on
the workshop.

Any deliverables must be specified in the workshop call for participation.
A W3C Team member will be assigned to edit any conclusions reached as a result
of the workshop (e.g., a proposal that W3C examine
this topic more closely in a new or existing group).

A symposium is open to all W3C Member organizations. Seats should be allocated
evenly to all W3C Member organizations, but seats not claimed
one month before
the registration deadline may be released and re-allocated equitably to other
W3C Members.

The W3C Submission process allows Members to propose technology or
other ideas for consideration by W3C. The formal process affords the
submitters 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. Members do not submit Notes to W3C; they
make Submission requests. A Note is one artifact of an acknowledged
Submission request.

Note. The Submissions process is not related to
the W3C Recommendations track. Documents that are
part of a Submission request have been developed outside of W3C.
Members do not submit documents to W3C for "ratification" as
Recommendations.

The Submission process begins with a Submission request from representatives
of one or more Member organizations (and only Member organizations) to
the Director. Organizations that are not Members of W3C may not send
Submission requests directly to W3C (either alone or in conjunction
with submitting Members). Submitters should refer to the submission request template
[PUB13] published at the W3C Web site.

To send a Submission request:

The Submitter (an Advisory Committee representative) sends a Submission package to
submissions@w3.org.
When several Members participate in a Submission request,
the Submission package must
only be sent by one of the submitting Members. The
other submitting Advisory Committee representatives must be copied.

Advisory Committee representatives from all participating
organizations must confirm their
position statements by sending individual
email to submissions@w3.org. This email should not contain
the original Submission package.

The Submitter will receive prompt notification that the Team has
received the Submission package.

If for any reason the Submission request is deemed incomplete or
incorrect by the Team (e.g., the Submission package lacks information,
documents in the Submission package are invalid, confirmations of
position statements have not been received, Member agreements from
participating companies have not been signed, etc.), the Team will
help the Submitter complete and correct the request.

The Team sends a validation notice to the Submitter as soon as the
Team has reviewed any Submission request and judged it complete and
correct. The Director then reviews the validated Submission request
and either acknowledges or rejects it. The Submission request is
acknowledged only after the Director has announced
the decision to the Advisory
Committee. This announcement must occur between one and four weeks after the
validation notice. The announcement may come 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 occur.

Prior to the acknowledgment, the Submission request
must be held in the strictest confidentiality by the
Team. In particular, the Team must not comment to the media about the
Submission request.

Under no circumstances may a document be referred to as
"submitted to the World Wide Web Consortium" or "under consideration
by W3C" or any similar phrase, nor should there be any implication
made that W3C is working on a specification or with a company prior to
the acknowledgment.

The Submitter may withdraw the Submission request at any time prior
to acknowledgment. W3C will not make statements about withdrawn
Submission requests.

Submitting organizations have the right to publish the documents
in the Submission package before acknowledgment. However, the W3C name
cannot be used in this publication.

Only after the Director has acknowledged the
Submission may the submitting organizations refer to it as having been
submitted to W3C. There may be no implication made to any further or
required action by W3C until and unless the item is taken up as part
of a W3C Activity.

Archives the Submission package
at the Web site.
The archives will clearly state that the acknowledgment
does not guarantee any further action by W3C
related to the submission request.

Archives any Team comments about the Submission request.

Publishes any documents in the Submission package
as W3C Notes. Though submitting Members
may hold the copyright for the content of a Note,
every Note is governed by the
W3C document
notice [PUB18] and must include a reference to it.

Publication of a Note by W3C indicates no endorsement by W3C, the
W3C Team, or any W3C 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 submitting
Member. This document may not be referred to as "work in progress"
of the W3C.

A Submission request may be rejected by
the Director on the following grounds:

The ideas expressed
in the request are poor, may harm the Web,
or run counter to the W3C mission.

The topics addressed 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).

If the subject of a Submission request is already being addressed
by a Working Group and the Director feels that acknowledging the
Submission request would interfere with the group's work (e.g., for
reasons of confidentiality), the Director may ask the Submitter to
take the proposal to the Working Group. The Submitter may proceed
with the Submission track nevertheless, but ultimately
the Director may choose to reject the request.

In case of a rejection, the Director will inform the Submitter's
Advisory Committee representative. The Submitter may appeal the
decision to the Advisory Committee. No statements will be made by W3C
about the reasons why a Submission request was rejected.

A document for consideration (e.g., a technical specification,
a position paper, etc.)

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.

The Submission request must include complete electronic copies of
any pertinent documents. The Communication Team will establish a
policy for which electronic formats (e.g., HTML) it will accept. The
Submission request must also address the following questions:

What is the Submitter's position towards any intellectual property rights
(IPR) associated with the technology? Any answer (from "we place this in
the public domain" to "we have a patent on this") is legitimate, but the
answer will affect the Director's decision
to acknowledge the Submission request. Please consult
the section on W3C's IPR policy.

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
Director'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 W3C acknowledges the
Submission request?

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 by the Director.

A Recommendation is work that
represents consensus within W3C
and has the Director's stamp of approval. W3C
considers that the ideas or technology specified by a Recommendation
are appropriate for widespread deployment and promote
W3C's mission.

a section indicating the status of the
document. The status section of a document should explain
why W3C has published the document, whether or not it is part
of the Recommendation track, who developed the document,
where comments about the document may be sent, and any other
metadata about the document deemed relevant by the editors.

Each document produced by a group will be edited by one or more editors appointed
by the 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 document. Document editors need not belong to the W3C Team.

The Team reserves the right to reformat documents at any time, including
changing the "Status of this Document" section and the document style, so
as to conform to changes in W3C practice.

Electronic documents have primacy over paper versions except when legal issues
are involved.

The primary language for official W3C documents is English. In addition to
the official English version of a document, W3C welcomes translated versions.

At times, it may be deemed necessary to make hitherto confidential documents
public. Any proposal to make a document public must be approved by a majority
of the Advisory Committee through the review
process. If approved, the document
may be published in the public area of the W3C Web site (e.g., as a Note)
at the discretion of the Director.

A Note is a dated, public record of an idea, comment, or document.
Notes are published on the Web site at the discretion of the Director
and may be published at any time. The publication of a Note does not
imply endorsement of its contents by W3C. The status section of a Note indicates whether or
not W3C has allocated resources to the topics covered by the Note.

Notes are used to encapsulate a document
that is not published by W3C (e.g., due to copyright issues) or under
W3C's control so that W3C authors may refer to it precisely (i.e., a
dated version) rather than simply "the current version."

W3C Working Groups may publish Notes for work that is ongoing but
not meant for the Recommendation track (e.g.,
a requirements document).

This Note is the result of an acknowledged Submission request.
Publication of this Note by W3C indicates no endorsement by W3C, the
W3C Team, or any W3C Members.
W3C has had no editorial control over the preparation of this Note.
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 submitting
Member. This document may not be referred to as "work in progress"
of the W3C.

A document must begin the path to Recommendation as a working
draft produced by a Working Group.

Working drafts may be released publicly or only to a limited group
of reviewers, at the Director's discretion. The first public version
of a working draft must be approved by the Director prior to
publication. Publication of a working draft does not imply a
commitment to a future proposal as a Recommendation. Every working
draft will be allocated a document name to
clearly indicate that the document is a working draft.

A working draft must include a paragraph in the status section of
the document that makes clear that the document may change at any
time, does not represent consensus from W3C or its Members, and may
not be cited other than a work in progress. Here is a sample
paragraph for a public working draft:

This is a public W3C Working Draft for review by W3C members and other
interested parties. It is a draft document and may be updated,
replaced, or obsoleted by other documents at any time. It is
inappropriate to use W3C Working Drafts as reference material or to
cite them as other than "work in progress". A list of current public W3C
working drafts can be found at http://www.w3.org/TR.

Once a group considers that a working draft meets the requirements
of its charter, it publishes a stable Working Draft and issues a last call for comments to the
Team and all Working Group Chairs (copying Chairs of known dependent
groups). Last call announcements must recapitulate known
dependencies. The last call must also state the deadline
for comments (e.g.,
three to four weeks after the last call is
issued).

To ensure the proper integration of a specification in the
international community, documents must, from this point on in the
Recommendation process, contain a statement about how the technology
relates to existing international standards and to relevant activities
being pursued by other organizations.

Once the last call period has ended and any issues raised during
the last call period resolved, the document is submitted to the
Director for approval. If approved, the Director announces to the
Advisory Committee that the document is now a Proposed Recommendation
available for review. The review period may
not be less than four weeks.

A Proposed Recommendation is given a new document name to clearly indicate that the
document is a Proposed Recommendation.

the name of the specific editor(s) assigned or to be assigned by the Team

a deadline for the Director's
decision as to the disposition of the proposal.
This date must be at least two weeks
after the end of the review period. Editors must reply to
substantive ballot comments before this deadline.

Advisory Committee representatives must send their ballot to one of
the two return addresses. Public comments may be made available to
Members or the public at the discretion of the proposal's
editors. Confidential comments will remain within the Team.

The proposal's editors must respond to substantive comments until
the end of the review period. During the review period, any Advisory
Committee representative may demand a specific response from the
editors to any public comment made by the representative's Member
organization.

Once the review period has ended and all ballots
and pertinent comments have been considered, the
Director may elect to do one of the following:

Issue the document as a Recommendation.

Issue the document as a Recommendation with minor changes indicated.

Return the document for work at the working draft stage,
with a request to the editors to address certain issues.

Abandon the document and remove it from the W3C agenda.

The Director must announce the disposition of the proposal to the
Advisory Committee.

Once a document becomes a W3C Recommendation, it receives a new document name to clearly indicate that it is
a Recommendation.

Editorial changes may be made to a W3C Recommendation after its
release in order, for example, to clarify an issue or correct minor
errors. The date code must be changed when published, and any previous
versions marked as superseded. The Communication Team will notify the
Members when a revised document is published.

If more substantial revisions to a Recommendation are necessary,
the document must be returned to the working draft phase and the
Recommendation process followed from the beginning.

Like any other Activity in W3C, the W3C process may require amendment from time to time.

When expected changes are major (important and numerous), a
Working Group must be created to draft
a proposal for changes.

When expected changes are medium (important but few), the Director
may decide that the creation of a Process Working Group is not
warranted. In this case, the Director may propose changes to the
Advisory Committee for review.

When changes are minor (clarification rather than content), the
Director may decide to incorporate them and announce the changes to
the Advisory Committee. The Advisory Committee has four weeks after the announcement to appeal the changes.

If a Working Group is created to amend the process,
participation in the Working Group is open to any AC representative.
Participants are expected to attend all the AC meetings that take place
during the Working Group's existence.

The Process Document describes the processes that govern the
W3C. The Process Document must be revised after a decision to modify the
process. It may be revised regularly to incorporate clarifications
or correct errors.

When a Process Working Group is created to modify the process (major changes),
its charter must propose the editor(s) who will revise the process
document.
When no Process Working Group is created to modify the process (medium or
minor changes), the Director appoints the editor(s) who will revise the process
document.

This document was initially prepared by the Process Working Group
(WG) of the World Wide Web Consortium. The Working Group was elected
by the W3C Advisory Committee Representatives on September 16, 1996
and consisted of the following individuals:

The work of the IETF in places may overlap with the Activities of W3C. To
allow clear progress, it is important for the role and domain of operation
of each organization to be well defined and for communication between the
two organizations to be efficient.

The IETF works in an entirely open manner: meetings are generally attended,
by email or physically, by anyone who wishes to participate. W3C, by contrast,
is a Consortium of organizations that pay a Membership fee to support its
operation (Membership is open to any organization). W3C has a process for
assigning defined groups of committed experts to solve specific tasks.

As a result of these differences, IETF working groups tend to be effective
both for the collection of ideas from a wide community, and also, when a
specification exists, for providing criticism from a wide community. W3C
is effective at producing, in a timely manner, a specification that is likely
(though not guaranteed) to meet the needs of its Members and the community.

The IETF addresses specifically issues of Internet protocols while W3C addresses
the architecture of the Web -- the global information space that is implemented
by using Internet protocols and other tools.

W3C defines the Web, Web documents, and protocols for their access and
distribution. W3C is the home of the HTML specifications, for which it brings
together expertise in many areas outside the IETF. It also addresses the
questions of intellectual ownership of documents, rating schemes for documents
and the transport of labels (PICS), and in general the metadata that is
information about documents.

W3C intends not to be involved with the specifications for IP, TCP, or DNS,
for security at any of these levels; with SMTP or NNTP protocols.

The HTTP protocol has been developed with W3C participation in an IETF context.
This is the area in which IETF experience has been very relevant, and W3C
effort is provided in order to help attain a timely result.

The URI scheme is the central specification of the Web. Although it is fairly
stable, its extension, where necessary, lies within the scope of W3C Activities.
It would be appropriate for W3C to include a new naming scheme developed
by a third party (or the IETF) into the URI specification.

Every effort must be made for open communication and cooperation between
W3C and the IETF so that, for example, two versions of a specification do
not evolve independently as a result of separate work. Such fragmentation
thwarts the principle of interoperability so vital to W3C success.

This section summarizes the partnerships (potential or other) for the W3C
with other organizations. A partnership begins with a written agreement between
W3C and some other organization that specifies how the partners will participate
in a given Activity.

Each table entry below addresses the following questions:

What would working with this organization contribute to W3C or the Web? Why
is this important?

Is the organization truly interested in working with the W3C? Would W3C have
to coerce them into participating?

What is a liaison going to cost (in dollars, staff time, research, travel,
etc.) and where do these resources come from?