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.
The list of changes to the public Process Document is available on the Web.
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 firstname.lastname@example.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.
W3C Members are primarily represented in W3C processes as follows:
W3C Membership is open to all entities, as described in "How to Join W3C" [PUB5]; (refer to the public list of current W3C Members [PUB8]). Organizations may subscribe according to the Full Member agreement [PUB6] or the Affiliate Member agreement [PUB7]. The Team must ensure that Member participation agreements remain Team confidential and that no Member receives preferential treatment within W3C.
W3C does not have a class of Membership tailored to, or priced for individuals. However, an individual may join W3C as an Affiliate Member [PUB7]. In this case, the same restrictions pertaining to related Members apply should the individual be employed by or affiliated with another W3C Member.
Each Member organization enjoys the following rights and benefits:
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:
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:
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.
More information about Advisory Committee meetings [MEM5] is available at the Member Web site.
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.
The Director is the lead technical architect at W3C and as such, is responsible for assessing consensus within W3C for architectural choices, publication of technical reports, and new Activities. The Director appoints group Chairs and has the role of "tie-breaker" for questions of good standing in a Working Group or appeal of a Working Group decision. The Director is Chair of the TAG.
It is likely that some of the Team will be appointed to the TAG by the Director.
A W3C decision is one where either:
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.
Advisory Board participants who are not employees of a Member organization must agree to the terms of the invited expert and collaborators agreement [PUB17]. Advisory Board participants must follow the conflict of interest policy by disclosing information to the rest of the Advisory Board.
Created in 2001, the mission of the TAG is stewardship of the Web architecture. There are three aspects to this mission:
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:
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.
TAG participants who are not employees of a Member organization must agree to the terms of the invited expert and collaborators agreement [PUB17]. TAG participants must follow the conflict of interest policy by disclosing information to the rest of the TAG.
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:
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:
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:
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.
This section describes general policies for distribution of materials, intellectual property rights, and individual participation in W3C.
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:
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 email@example.com, 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:
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.
Team members must agree to the W3C Team conflict of interest policy [PUB23].
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.
W3C creates, modifies, or extends an Activity as follows:
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:
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:
This document defines three types of groups:
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].
Each group must have a Team contact, who acts as the interface between the Chair, group participants, and the Team. The role of the Team contact 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:
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:
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:
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.
A group charter may include voting procedures.
An individual is a Working Group participant if the individual has joined the Working Group and is in good standing. An individual is an Interest Group participant if the individual has joined the Interest Group. A Member organization may claim to participate in a Working Group or Interest Group if it has at least one employee who is a participant.
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.
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:
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:
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:
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 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:
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:
A Coordination Group charter may also include the following information:
W3C publishes two types of technical reports:
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 public technical report must clearly indicate whether it is a Note, Working Draft, Last Call Working Draft, Candidate Recommendation, Proposed Recommendation, or Recommendation.
The primary language for W3C technical reports is English. W3C encourages the translation of its technical reports. Information about translations of W3C technical reports [PUB18] is available at the Web site.
Each technical report must include a section about the status of the document. The status section should explain why W3C has published the technical report, 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:
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:
The Working Group advances a technical report to Last Call by sending a call for review to other W3C groups (refer to "How to organize a Last Call review" in the Member Guide [MEM9]). A Last Call announcement must:
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 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 Director advances a technical report to Proposed Recommendation by sending a call for review to the Advisory Committee (refer to "How to start Member review of a Proposed Recommendation" in the Member Guide [MEM9]). Advisory Committee representatives may appeal the decision to advance the technical report.
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 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:
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.
Note: In general, W3C does not organize conferences. Currently, W3C presents its work to the public at the annual World Wide Web Conference, which is coordinated by the International World Wide Web Conference Committee (IW3C2).
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:
The Submission process consists of the following steps:
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.
The list of acknowledged Submissions [PUB10] may be found at the Web site.
When more than one Member jointly participates in a Submission request, only one Member formally sends in the request. That Member must copy each of the Advisory Committee representatives of the other participating Members, and each of those Advisory Committee representatives must confirm (by email to the Team) their participation in the Submission request.
At any time prior to acknowledgment, any 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:
The Director may reject a Submission request for a variety of reasons, including the following:
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:
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 information is available at the W3C Web site.
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.