This document has been superseded. Please consult the latest public 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 document was 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 Team Members involved in producing this document were:
A list of changes to public versions of this document is available online.
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:
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. 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. 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.
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.):
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.
W3C is built on several foundations:
Unless otherwise stated, all announcements, replies, confirmations, notifications, ballots, minutes, and other documents exchanged within W3C will be electronic (e.g., email, mailing lists, and 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.
At all times, the list of current W3C Members [PUB8] may be found at the W3C Web site.
W3C Members enjoy the following benefits:
The conditions and procedures for joining W3C [PUB5] are described at the W3C Web site.
Companies and organizations may subscribe according to the Full Member agreement [PUB6] or the Affiliate Member agreement [PUB7].
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:
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.
All individuals may participate in W3C Activities via W3C's public mailing lists.
An individual may have access to Member-only information by:
Please also consult the section on individual participation criteria.
The W3C Team consists of a Chairman, a Director, and Staff.
The Chairman manages the general operation of the Consortium, chairing Advisory Committee and Advisory Board meetings, formalizing relationships with Members, and addressing legal and policy issues.
The Director is the technical lead of W3C, coordinating the work carried out in W3C Activities. The Director's most visible role involves decisions to approve or reject certain proposals (see below).
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:
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.
The W3C Team is currently located on three continents at three host institutions:
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 (AC) has several roles within W3C:
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:
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.
At all times, the list of current Advisory Committee representatives [MEM1] is available at the Web site.
The Advisory Committee will make use of the following communication mechanisms:
The names of all AC representatives will appear on both lists.
Information about AC mailing lists [MEM2] may be found at the W3C Web site.
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:
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.
Information about future and past meetings [MEM5] (schedules, minutes, etc.) may be found at all times at the W3C Web site.
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 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:
The following types of comments are of particular interest to the Director:
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:
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.
The Advisory Board will use a mailing list for its communications.
The Advisory Board will organize both remote and face-to-face meetings, but the primary means of communication will be monthly remote meetings. Advisory Board meetings are chaired by the Chairman.
The Advisory Board will present a report at each AC meeting.
A Communication Team, composed of W3C Staff, will be responsible for managing communication within W3C and between W3C and the general public. The goals of the Communication Team are the following:
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 primary language for W3C is English.
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.
In addition to other information, the following documents will be available on the public portion of the W3C Web site at all times:
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.
A portion of the Member Web site will be reserved for each W3C group. It is each group's responsibility to maintain its own group archives (minutes, milestones, etc.) at this space.
The W3C Team will maintain one mailing list (mentioned above) for all official communications to AC representatives.
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 list of available mailing lists [MEM2] may be found at the W3C Web site.
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.
This section of the document specifies the mechanisms by which W3C initiates Activities, forms groups, and organizes 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.
At all times, the list of Activities currently being pursued by W3C [PUB9] is available at the public Web site. For Members, the list of Activities and all groups pursuing them [MEM7] is also available. A technological or policy area not declared at the Web site is not part of a W3C Activity.
An Activity is created as follows:
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).
The Team will establish mechanisms for publishing all documents related to an activity (see the guidebook [MEM9] for details). The list of Activity briefing packages [PUB12] is available at the W3C Web site.
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.
An Activity closes normally when its briefing package expires. It may close prematurely in the following circumstances:
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:
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.
Groups are created to carry out W3C Activities. The type of group created depends on the nature of its tasks. Each group is defined by a charter and managed by a Chair.
Every group must have one Chair to coordinate the group's tasks. The Chair is appointed (or reappointed) by the Director.
Every group must have a charter that describes the following:
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.
Group participants and their alternates exchange information via a mailing list. The Chair should ensure that new participants are subscribed to all relevant mailing lists.
The names of available mailing lists [MEM2] may be found at the W3C Web site.
Each group will maintain a Web site. Each group's home page will be linked from the home page of the Activity to which it belongs. The list of W3C Activities [PUB9] is available online.
The following must be accessible to W3C Members at the group Web site, with links from the Activity home page:
The following information must be accessible to group and Team members:
A group is created as follows:
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:
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.
Invited experts must agree to the terms of the invited expert and collaborators agreement [PUB17].
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.
A group closes normally when its charter expires. It may close prematurely in the following circumstances:
This document defines four types of groups that may carry out W3C's Activities.
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.
See also how to join a group.
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:
Participation on an ongoing basis implies a serious commitment to the Working Group charter. Participation includes:
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 and nor does it imply future participation or invitation to Working Group meetings.
Please consult the section on group communication for information about mailing lists and group Web sites.
Working Groups will organize both remote and face-to-face meetings.
From time to time, Working Group participants may choose to vote on issues such as the details of a specification. Only participants in good standing may vote. All votes shall be sent to both the group Chair (or a designee) and the Working Group mailing list.
The purpose of a Working Group vote is to identify roadblocks to consensus, and thus the voting process is designed to solicit constructive criticism from voters. All No votes must be accompanied by either a list of modifications that would change the vote to Yes, or an explanation as to why the project should be abandoned.
If more than one vote is received from a Member organization or a group of related Members, the votes are counted as one valid vote if they agree, otherwise they are ignored and the relevant Advisory Committee representatives(s) will be notified of the discrepancy.
Once all votes have been received, the Chair is responsible for resolving the issues that motivated the No votes. The Chair may do so either by revising the deliverable in such a way as to take the comments into account, or by providing a reason why the comment is not valid. The Chair may also eliminate stumbling blocks to consensus by creating two deliverables instead of one -- one for those topics amenable to consensus, the other for those topics requiring further study or agreement.
A successful yes vote occurs when three-fourths of the voting participants have voted yes and when the Working Group Chair decides that all substantive No comments have been addressed.
A Working Group may write slightly different voting rules into its charter. For example, experts may participate in Working Group votes if the charter explicitly requires it. If such a charter is approved, those Working Group-specific voting rules will apply.
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 will be labeled as such. They will also include the following disclaimer in a section specifying the status of the document:
This is an working draft. W3C is not responsible for any implementations based on this draft. This draft may or may not be proposed as a Recommendation, and may change at any time and without notice.
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).
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.
See also how to join a group.
Interest Group Membership is not, in principle, limited in size. The following people may participate in an Interest Group on an ongoing basis:
Please consult the section on group communication for information about mailing lists and group Web sites.
Interest Groups will organize both remote and face-to-face meetings, but remote meetings should be the more common mode of communication.
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.
Voting proceeds as for Working Groups unless otherwise indicated.
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.
See also how to join a group.
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.
Please consult the section on group communication for information about mailing lists and group Web sites.
A Coordination Group will organize remote and/or face-to-face meetings. Reports of these meetings are to be published to Members on the Coordination Group's Web space.
A Coordination Group will publish reports on the Member Web site assessing the work and progress of the groups it oversees.
Projects endeavor to develop systems that make use of Web technology. Projects develop proposals for Recommendations and implement them in pilot environments while maintaining close ties with technology innovators, implementors, and users with very different backgrounds.
Whereas Coordination Groups coordinate the work of a set of groups, Projects involve communication between external organizations and W3C, the management of software implementations, etc. Due to this additional responsibility, the Chair of a Project must have the skills of a project manager.
The Director appoints the Chair of a Project. If the Project includes a Coordination Group (the usual scenario), it must be chaired by the Project Chair.
A Project has the same structure and observes the same processes as a Coordination Group unless otherwise indicated.
See also how to join a group.
Projects may engage in partnerships with other organizations. Procedures for participation must be negotiated between the Project and the external organization and added to the Project charter.
Please consult the section on group communication for information about mailing lists and group Web sites.
The Project charter must specify the type of deliverable the group intends to produce and with what frequency (e.g., Recommendations, prototype software, reports, etc.).
W3C may organize several types of shorter term events that do not demand on-going participation by Members or the Team.
This document defines three types of W3C events:
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.
The Director announces (in a "call for participation") to the Advisory Committee that a workshop will take place. The call for participation must include the following information:
The Team schedules the workshop and coordinates (with Members and other interested parties) the workshop's program and organization.
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 brings interested parties together for expert presentations on a given subject. Typically lasting one or two days, a symposium is intended to educate.
A symposium is initiated following the same procedure as for a workshop (type one). However, the call for participation in a symposium includes the following information instead:
There are no deliverables or criteria for success for a symposium.
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.
Minutes shall be taken by the W3C Team and made available at the Member Web site.
A conference is a large, multi-subject, multi-day meeting. W3C does not, as a general rule, organize conferences. It does, however, sponsor the World Wide Web Conference. This conference is coordinated by the International World Wide Web Conference Committee (IW3C2).
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.
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 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 two weeks after the validation notice.
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.
Once the Director has acknowledged a Submission request, the Team:
The acknowledgment of a Submission request does not imply that any action will be taken by W3C. It does not imply an endorsement by W3C, the W3C Team, or any of the Members of W3C. It merely records publicly that the Submission request has been made by the submitting Member. The specification may not be referred to as "work in process" of the W3C.
The list of acknowledged Submissions [PUB10] may be found at the Web site.
A Submission request may be rejected by the Director on the following grounds:
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 Submission package must include the following information:
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:
W3C publishes several types of technical reports:
All public technical reports [PUB11] are available at the Web site.
All Notes, public working drafts, Proposed Recommendations, and Recommendations must include:
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.
The W3C Team will establish conventions for creating and maintaining document names and will publish these conventions on the Web site.
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. Notes may be published at any time. The publication of a Note implies no endorsement of any kind by W3C nor does it imply that W3C resources are allocated to issues addressed by the Note.
For example, the Note mechanism is used to publish documents that are part of an acknowledged Submission request. The Note mechanism is also 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."
Every Note will be allocated a document name to clearly indicate that the document is a Note.
A section entitled "Status of this Document" must appear at the beginning of a Note after the principle heading. It must include one of the following statements.
If the document was authored within the Team, include the following text:
This document is a NOTE made available by W3C for discussion only. This indicates no endorsement of its content, nor that W3C has, is, or will be allocating any resources to the issues addressed by the NOTE.
If the document was not prepared or authored by the Team, include the following text:
This document is a NOTE made available by W3C for discussion only. This indicates no endorsement of its content, nor that W3C has had any editorial control in its preparation, nor that W3C has, is, or will be allocating any resources to the issues addressed by the NOTE.
The "Status of this Document" section may also include a statement about the purpose of the document where this will help guide the public. There is no set form for this statement. Examples of statements include:
This document represents an early attempt to discuss the issues of diversification of archival retrieval reinsurance protocols that W3C is not working on at present, but would like to bring to the community's attention.
or
This document describes an experimental architecture differing significantly from the W3C's architecture for embedding obsolete computer simulations in virtual view walls, and is made available for comparison purposes. Section 6 is particularly relevant to the choices made in W3C-REC-inkpens-970101.
or
This document was referred to in Advisory Committee meetings last June and is made available here for convenience.
A Recommendation indicates that consensus has been reached within W3C about a specific topic and that a document - typically a specification - is appropriate for widespread use.
The process described below for creating a Recommendation is an alternative to, and not a replacement for, or modification of, the standards process in the W3C Member agreement.
The result of the W3C Recommendation process may be submitted to a formal standards body for ratification, however this is not required or guaranteed.
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. A working draft must be approved by the Director prior to its first public 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.
Once a group considers a working draft to be stable, it issues a last call for comments to the Team and all Working Group Chairs (copying Chairs of known dependent Working Groups). Last call announcements must include a deadline for comments (e.g., two to three weeks after the last call is issued).
To ensure the proper integration of a specification in the international community, documents at this phase must 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 proposes the document to the Advisory Committee 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.
In addition to the standard review information, the ballot in the call for review must contain:
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:
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.
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.
Voting will proceed as described for other Working Groups.
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.
The home page of the W3C Web site: http://www.w3.org/
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:
| Groups Relevant to W3C | Contribution to W3C or Web | Interested in working with W3C | Cost of Liaison | Special expertise from W3C |
| IETF Internet Engineering Task Force | Internet Infrastructure | Relationship needs to be focused, identify specific groups and people to meet. | High, knowledge of the organization is well known, but a close
relationship needs to be built.
Resource costs are high to participate in IETF Working Groups under their organizational structures rather than the W3C's. |
HTTP, URNs, Naming |
| ISO Standards - International
Organization for Standardization; includes national bodies standards |
ISO TC
46; Standards for Thesauri, Indexing, Bibliographies, and Searching.
ISO TC 68;
ISO TC 154;
ISO TC 187;
ISO/IEC WG2 SC2;
US Z39.50;
ANSI X9;
ISO/IEC JTC1; Information Processing, |
Yes, W3C was requested to provide liaison in HTML and graphics. | High, organization is complex. W3C AC meeting June 1996 was
against following the PAS ISO procedure.
ISO organizations run at a different speed. |
HTML and graphics. |
| OMG Object Management Group Consortium | CORBA, IIOP, Enterprise Users | Strong Yes | Low | Architecture Areas, HTTP |
| OASIS-open | SGML Standardization and Expertise | Medium/Low | Low; primarily requires knowledge of relevant activities as they happen and making comments about possible changes to SGML. | HTML, XML |
| The Open Group (X/Open, Uniforum, OSF, SAG) | Active X, Validation Suites, Reference Implementations | Strong Yes | Low | Architecture and User Interface Areas, PICS |
| Unicode Consortium | Character encoding, character properties | Yes | Low | Markup, Language tagging, etc. |
| WAP Forum - Wireless Application Protocol | Protocols for mobile devices | Strong Yes | Low, because Mobile Interest Group already exists | See WAP Forum - W3C Cooperation White Paper |
| Government Regulators, European Commission, US Govt., G7,... | Regulatory Control | Depends | High, personal visits to each government and group are required. | Technology and Society Areas |