W3C World Wide Web Consortium Process Document This document describes the processes that govern the operation of the World Wide Web Consortium (W3C) and the relationships between W3C Members, the W3C Team, and the general public. This version of the Process Document was made available to the Advisory Committee on 1 November 1999 and to the general public on 11 November 1999. This document was initially prepared by the Process Working Group (WG) of the World Wide Web Consortium. A list of changes to this document is available online. This document is available in the following formats: a single HTML file, a PostScript file, a PDF file, a plain text file, a self-contained gzipped tar archive, or a self-contained zip archive. W3C Members who have comments about this document should consult the Member guide for information about Process Document feedback. Comments from the Team should be sent to the appropriate Team mailing list. If you're not a Member, please refer to "About the W3C" at the W3C Web site for Membership information. Copyright © 1999 W3C (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Table of Contents * 1 W3C Background + 1.1 What is W3C? + 1.2 W3C's mission + 1.3 W3C's consensus policy + 1.4 W3C's dissemination policy + 1.5 W3C's Intellectual Property Rights (IPR) policy + 1.6 Individual participation criteria * 2 W3C Organization + 2.1 Members o 2.1.1 Member benefits o 2.1.2 Member subscription o 2.1.3 Related Members o 2.1.4 Participation in W3C by individuals + 2.2 The W3C Team o 2.2.1 Director decisions + 2.3 Host Institutions + 2.4 Advisory Committee (AC) o 2.4.1 Participation o 2.4.2 Communication o 2.4.3 Meetings o 2.4.4 Advisory Committee reviews and ballots + 2.5 Advisory Board (AB) o 2.5.1 Participation o 2.5.2 Communication o 2.5.3 Meetings o 2.5.4 Deliverables + 2.6 Communication Team o 2.6.1 W3C Web sites o 2.6.2 Mailing Lists o 2.6.3 Press Releases o 2.6.4 Calendar of Events o 2.6.5 Newsletter * 3 W3C Activities and Groups + 3.1 Activities o 3.1.1 How to Create an Activity o 3.1.2 Activity Statements o 3.1.3 Conditions for Activity Closure o 3.1.4 Activity briefing packages + 3.2 General Information about Groups o 3.2.1 Chair o 3.2.2 Team contact o 3.2.3 Charters o 3.2.4 Meetings o 3.2.5 Communication o 3.2.6 How to Create a Group o 3.2.7 How to Join a Group o 3.2.8 How to Modify a Group Charter o 3.2.9 Conditions for Group Closure + 3.3 Group Types o 3.3.1 Working Groups o 3.3.2 Working Group consensus and votes o 3.3.3 Interest Groups o 3.3.4 Coordination Groups * 4 W3C Events + 4.1 Workshops o 4.1.1 How to Announce a Workshop o 4.1.2 Communication o 4.1.3 Deliverables + 4.2 Symposia o 4.2.1 Participation o 4.2.2 Communication + 4.3 Conferences * 5 The W3C Submission process + 5.1 How to Send a Submission Request + 5.2 Submitter Rights and Obligations + 5.3 Acknowledgment of a Submission request + 5.4 Rejection of a Submission request + 5.5 The Submission package * 6 W3C Technical Reports + 6.1 General information about documents o 6.1.1 Releasing confidential documents + 6.2 The W3C Recommendation track o 6.2.1 Working Drafts (WD) o 6.2.2 Last Call Working Draft o 6.2.3 Candidate Recommendations (CR) o 6.2.4 Proposed Recommendations (PR) o 6.2.5 Recommendations (REC) + 6.3 Notes o 6.3.1 Note status * 7 W3C Process + 7.1 The Process Document * 8 Appendix + 8.1 W3C Process Working Group + 8.2 Summary of Process Schedules + 8.3 Information at the W3C Web site o 8.3.1 Public information o 8.3.2 Member-only information + 8.4 W3C and the Internet Engineering Task Force (IETF) o 8.4.1 Role o 8.4.2 Domain + 8.5 Partnerships + 8.6 Potential Partner Organizations * 9 Glossary _________________________________________________________________ 1 W3C Background 1.1 What is W3C? 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. 1.2 W3C's mission W3C's mission is to lead the evolution of the Web -- the universe of information accessible through networked computers. W3C's long term goals are: * Superior Web Technology. By promoting interoperability and encouraging an open forum for discussion, W3C commits to leading the technical evolution of the Web. W3C must ensure that the Web remains a robust, scalable, and adaptive infrastructure. * Universal Web Accessibility. W3C strives to make the Web accessible to as many users as possible and to promote technologies that take into account the vast differences in culture, education, ability, material resources, and physical limitations of users on all continents. * Responsible Web Application. However vast the Web becomes, it remains essentially a medium for human communication. As such, the Web's impact on society cannot be dissociated from decisions that guide its development. W3C must guide the Web's development with careful consideration for the novel legal, commercial, and social issues raised by this technology. 1.3 W3C's consensus policy Integral to the W3C process is the notion of consensus. The W3C process requires those who are considering an issue to address all participants' views and objections and strive to resolve them. Consensus is established when substantial agreement has been reached by the participants. Substantial agreement means more than a simple majority, but not necessarily unanimity. While unanimity is preferred, it is not practical to require that Working Groups, for example, reach unanimity on all issues. In some circumstances, consensus is achieved when the minority no longer wishes to articulate its objections. When disagreement is strong, the opinions of the minority are recorded in appropriate documents alongside those of the majority. Groups strive to reach consensus in order to provide a single solution acceptable to the market at large. If a group makes a decision that causes the market to fragment -- despite agreement by those participating in the decision -- the decision does not reflect a single market and therefore the group has failed to reach true consensus. Please also refer to the discussion of Working Group consensus and votes. 1.4 W3C's dissemination policy All W3C technical reports and software are made available free of charge to the general public (refer to the W3C document notice [PUB18]). 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. 1.5 W3C's Intellectual Property Rights (IPR) policy W3C promotes an open working environment. Whenever possible, technical decisions should be made unencumbered by intellectual property right (IPR) claims. To this end, W3C discloses to the entire Membership all IPR claims made by Members. Members may disclose IPR claims at any time. Members disclose patent and other IPR claims by sending email to an archived mailing list that is readable by Members and the Team: patent-issues@w3.org. Members must disclose all IPR claims to this mailing list but they may also copy other recipients. For instance, they should copy the Activity Lead responsible for a particular technology to ensure that the IPR claims receive prompt consideration. Advisory Committee representatives are responsible for facilitating communication with IPR contacts in their organization. When disclosing IPR claims, individuals should therefore copy their Advisory Committee representative. Member disclosures of IPR claims about a particular subject should include the following language: To the best of my knowledge, I believe my organization has/doesn't have IPR claims regarding [subject]. Members are encouraged to disclose their claims in detail whenever possible. Announcements, important documents, and frequently visited Web pages should remind Members to disclose IPR claims. Important places of interaction include: Activity proposals and briefing packages, calls for participation in groups and their charters, the Member home page, Activity home pages, and Group home pages. Invited experts are required to disclose IPR claims in the same manner as individuals from Member organizations. 1.6 Individual participation criteria There are three qualities an individual must possess in order to join the W3C Team or participate in a W3C Activity (e.g., act as a Chair, editor, etc.): * Technical competence in one's role * The ability to act fairly * Social competence in one's role Advisory Committee representatives who nominate individuals for participation in W3C Activities are responsible for assessing and attesting to the qualities of participants from their organization. Individuals participating in a W3C Activity (e.g., within a Working Group) represent not only their own ideas but also the interests of the companies or organizations with which they have relationships. As these companies and organizations are often Members of W3C, all participants in a W3C Activity should clearly disclose, as is customary, the financial interests and affiliations they have with W3C Members. These disclosures should be kept up-to-date as the individual's professional relationships and W3C Membership evolve. The ability of an individual to fulfill a role within a group without risking a conflict of interests is clearly a function of the individual's affiliations. When these affiliations change, the role in question must be reassigned, possibly to the same individual, according to the process appropriate to the role. When an individual accepts a role as Chair or editor, the Member organization that employs that individual recognizes that this work as unbiased officer of the Group is done as part of the individual's work for the Member. _________________________________________________________________ 2 W3C Organization W3C is built on several foundations: * The Members. Through active investment in W3C Activities, the Members ensure the strength and direction of the Consortium. * The Team. Informed, fair, and consistent guidance from the Team keeps the Consortium running smoothly. * The Offices. The Offices attract new Members from different regions around the world, ensuring the distribution of W3C's message with the proper sensitivity to cultural differences, and gathering input from national entities. Please consult the list of W3C Offices [PUB16] at the Web site. 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). 2.1 Members 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. 2.1.1 Member benefits W3C Members enjoy the following benefits: * A seat on the Advisory Committee. * The opportunity to provide strategic direction to W3C. * The opportunity to participate directly in W3C Activities. * Access to the Member Web site, where Members can find newsletters, announcements, and information on events, technologies, software releases, Activity and group news, discussion forums, and mailing lists. * The right to display the W3C logo on promotional material and to publicize the Member's participation in W3C Activities. 2.1.2 Member subscription 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]. 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 will exercise all the rights and privileges of W3C Membership. In addition, the Advisory Committee representative may designate up to four (or more at the Director's discretion) unpaid agents from the organization who will exercise Membership. These agents shall disclose their employment affiliation when participating in W3C activities. The provisions for Related Members will apply. Furthermore, these agents are expected to represent the broad interests of the W3C Member organization and not the parochial interests of their employers. 2.1.3 Related Members 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: 1. Either Member is a subsidiary of the other, or 2. Both Members are subsidiaries of a common entity. A subsidiary is an organization of which effective control and/or majority ownership rests with another, single organization. Under any circumstance where restrictions apply to related Members, it is the responsibility of those Members to disclose the relationship. 2.1.4 Participation in W3C by individuals All individuals may participate in W3C Activities via W3C's public mailing lists. An individual may have access to Member-only information by: * Being asked by the Director to participate in W3C Activities as an invited expert. Invited experts must agree to the terms set forth in the invited expert and collaborators agreement [PUB17] and the W3C IPR Policy. They must also sign the W3C Technical Reports and Specifications Release Form [PUB19] when they contribute to a W3C technical report. * Joining W3C as an Affiliate Member. In this case, the same restrictions pertaining to related Members apply should the individual be affiliated with another W3C Member. Please also consult the section on individual participation criteria. 2.2 The W3C Team The W3C Team consists of a Chairman, a Director, and Staff. The Chairman manages the general operation of the Consortium, chairs Advisory Committee and Advisory Board meetings, oversees the development of the W3C international structure (e.g., role of Hosts, creation of W3C Offices, etc.), coordinates liaisons with other standards bodies, and addresses legal and policy issues. The Director is the lead architect for the technologies developed at the Consortium. The Director also approves Recommendations, Activity proposals, and charters; designates Group Chairs; and acknowledges Submission requests. The Team manages W3C Activities and establishes the mechanisms and procedures for doing so; this document does not include the details of those mechanisms. The Team provides information to the Members (through email, at the Member Web site, etc.) and may be reached directly by Members through the appropriate Team contact. As coordinators of W3C Activities, the Team has the following responsibilities: * Provide direction to W3C by keeping up-to-date on new technology, market fluctuations, and the activities of related organizations. * Ensure cooperation between Members while promoting innovation. * Encourage Member initiatives and Submission requests and establish efficient administrative mechanisms that allow these initiatives to flourish. * Organize and manage W3C Activities so as to optimize the achievement of goals within practical constraints (such as resources available). * Keep Members abreast of W3C Activities. * Inform the general public of W3C Activities and gather ideas and input from outside sources. * Market W3C results to gain wide acceptance for them in the Web community. * Market W3C to attract new Members -- the larger the member base, the easier it will be to promote W3C Recommendations. To promote cooperation between the Members and the Team, Member organizations may send engineers - called "W3C Fellows" - to work with the Team at Host institutions. 2.2.1 Director decisions 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. 2.3 Host Institutions The W3C Team is currently located on three continents at three Host institutions: * In North America: Massachusetts Institute of Technology Laboratory for Computer Science [MIT/LCS]. * In Europe: Institut National de Recherche en Informatique et en Automatique [INRIA]. * In Asia: Keio University [KEIO]. 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. Each Host institution exercises all the rights and privileges of W3C Membership. The resident W3C Associate Chairman or Deputy Director will hold the office of Advisory Committee representative for the Host. The Advisory Committee representative from a Host will not normally respond to calls for review (to reduce the potential of a conflict of interest) but will respond to calls for participation (to coordinate participation by non-Team employees of the Host). At Advisory Committee meetings, this person will act as W3C Team, not an Advisory Committee representative. 2.4 Advisory Committee (AC) The Advisory Committee has several roles within W3C: * Review proposals (proposed Activities, Proposed Recommendations). * Review annual plans. * Assess the W3C's progress. * Suggest future directions for W3C. 2.4.1 Participation The Advisory Committee consists of one representative from each Member organization. The Advisory Committee representative is the official link between the Member organization and the Team. Advisory Committee representatives have the following responsibilities: * Attend Advisory Committee meetings. * Transmit information from the Team (official statements, newsletters, calls for participation, acknowledgments, etc.) to their Member organization and ensure the confidentiality and proper circulation of this information. * Send any Submission requests from their organization to the Team. * Review Activity proposals. * Review Proposed Recommendations. * Nominate candidates for participation in Working Groups. * Respond to calls for participation in workshops. * Nominate candidates for participation on the Advisory Board. * Review proposals to release confidential documents. * Resolve conflicting votes from group participants representing their organization. Each Advisory Committee representative is named in the Membership Agreement when the organization joins W3C [PUB5]. When a Member organization wishes to change its Advisory Committee representative, the departing representative must notify the Director of the change by email. If the departing Advisory Committee 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. 2.4.2 Communication The Advisory Committee will make use of the following communication mechanisms: * Within the AC: A mailing list open only to Advisory Committee representatives, for internal discussions. * Within W3C: A mailing list for communication between the Team and the AC representatives. The names of all Advisory Committee representatives will appear on both lists. Information about Advisory Committee mailing lists [MEM2] may be found at the W3C Web site. 2.4.3 Meetings The Advisory Committee will hold face-to-face meetings approximately twice a year. These meetings will be geographically distributed to areas where there is a significant portion of the Membership. At each Advisory Committee meeting, the W3C Team will provide Member organizations with an update of key W3C information, including: Resources + The number of Full and Affiliate W3C Members. + An overview of the financial status of W3C. Allocations + The allocation of the annual budget, including size of the Team and their approximate deployment. + A list of all Activities and brief status statement about each. + A list of Activities started since the previous Advisory Committee meeting. + A list of Activities completed or terminated since the previous Advisory Committee meeting. The date and location of each meeting shall be announced at least six months (and preferably one year) before the planned date. In general, only one representative from each Member organization attends each Advisory Committee 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 Advisory Committee meeting, a mailing list will be established (and Advisory Committee representatives notified) by which Advisory Committee representatives may suggest topics of discussion for the meeting. Suggestions must also be sent to the mailing list for internal Advisory Committee 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. 2.4.4 Advisory Committee reviews and ballots 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 Advisory Committee mailing list. A ballot accompanies each call for review. The ballot must clearly indicate: * The nature of the proposal. * The deadline for returned ballots (and possibly other deadlines). * One or more email addresses where completed ballots must be sent. The review period ends on the date specified in the ballot (unless extended as described below). Each unrelated Member organization is allowed one ballot, which must be returned by its Advisory Committee representative. Each group of related Members is also allowed one ballot, which must be returned by a single Advisory Committee representative chosen by the group. In the event that the Advisory Committee 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 Advisory Committee 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 Advisory Committee representative will be notified of the discrepancy. Each ballot will ask the Advisory Committee representative to return the ballot completed with the following information: * Reviewer information (name, email address, Member organization, etc.) * An opinion of the proposal, one of the following: 1. The proposal is satisfactory as is (or with insubstantial changes proposed by others). 2. The proposal is satisfactory, but only if certain changes are integrated. The returned ballot must be accompanied by a list of proposed changes. 3. The proposal should be amended due to substantial problems. The returned ballot must be accompanied by explanatory comments. 4. The proposal should be rejected. The returned ballot must be accompanied by a detailed explanation. 5. The reviewer abstains. * Information about related IPR claims. Recall that IPR disclosures must be sent to the mailing list described in the section on W3C's IPR policy. * A provisional statement of concrete support for the proposal if approved (e.g., implementation of a specification, dedication of resources to an Activity, participation in a newly formed group, etc.). * A provisional statement of any foreseen constraints. * Additional comments and information, depending on the ballot. The following types of comments are of particular interest to the Director: * Comments about dependencies between the proposal and other Activities, documents, organizations, standards, etc. * Comments that demonstrate serious flaws in the proposal, reflect burdensome resource allocations, reveal invalid or confused deployment methodologies, or illustrate an "out of scope proposal". * Comments that help the submitters amend documents, charters, etc. enclosed in the proposal. * Statements of intention to participate in Activities, groups, events, etc. * Statements of intention to commit resources to Activities, groups, events, etc. These comments and statements are non-binding, but do help the Director reach a decision. The Team will provide two channels for Advisory Committee review comments: one Member-visible and one Team-confidential. AC Representatives may send information to one or both channels. For example, they may choose to make their choice known to the Membership but to send implementation schedule or other confidential information to the Team only. Comments sent to the Member-visible channel during the review period will be archived and made available to the Members no later than one week after the end of the review period. If any ballots express opposition to the proposal (opinions three and four above), the Director must inform the Advisory Committee within one week after the end of the review period. The Director's comments should explain the opposition while ensuring the appropriate level of confidentiality. For a two-week period thereafter, Advisory Committee representatives may request to change their ballots. 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. After the review period and any re-balloting, the Director announces the outcome of the proposal to the Advisory Committee. The Director may: 1. Approve the proposal. 2. Approve the proposal with minor changes integrated. 3. Return the proposal for work, with a request to the initiator to address certain issues. 4. Reject the proposal. 2.5 Advisory Board (AB) 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. 2.5.1 Participation Advisory Board representatives are not required to work for Member Organizations. 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. Participants are expected to devote at least one day per month to Advisory Board activities and to participate in Advisory Board mailing list discussions. Participants are elected to serve on the Advisory Board for two years. Elections are staggered; each year, the Advisory Committee elects representatives for half of the seats on the Advisory Board. The election process begins with a call for nominations sent 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. 2.5.2 Communication The Advisory Board will use a mailing list for its communications. 2.5.3 Meetings The Advisory Board will hold one remote meeting monthly and one face-to-face meeting annually. Advisory Board meetings are chaired by the Chairman. Advisory Board representatives are also encouraged to attend Advisory Committee meetings. The W3C Chairman and Director (and possibly other members of the Team) participate in Advisory Board meetings. 2.5.4 Deliverables The Advisory Board will present a report at each Advisory Committee meeting. 2.6 Communication Team 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: * Disseminate key information appropriately, whether the scope is within W3C or around the world. * Protect confidential information. * Keep Member organizations abreast of W3C Activities: the progress of groups, changes in Membership status, release of press information, etc. * Publicize W3C's Activities through press releases. * Strengthen W3C's image in the Web community through good public relations. * Establish efficient communication tools that promote fairness, openness, and participation within W3C. * Ensure that W3C communication observes legal requirements, such as those relating to anti-trust laws. * Maintain an accurate historical record of W3C Activities and accomplishments. * Assist Advisory Committee representatives in their role as communicators within their organizations. * Help Member companies who wish to contribute their resources (notably for communication) to W3C Activities. Unless otherwise stated (e.g., in legal matters), electronic documents have primacy over paper documents. When legal notifications, contracts, and other forms of communication requiring hardcopy must be exchanged between the Team and a Member organization, they must be sent to the appropriate Advisory Committee representative via a guaranteed-delivery service. Billing information may be sent to the designated contact person for each Member organization. The primary language for W3C is English. 2.6.1 W3C Web sites 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 Technical Reports. 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. Public Web Site In addition to other information, the following documents will be available on the public portion of the W3C Web site at all times: * A vision statement [PUB15] that explains the purpose and mission of W3C, the key benefits for Members, and the organizational structure of W3C. * Legal documents, including the Membership contract and a review of any legal commitments W3C may have to other entities (in particular, the legal status of W3C with respect to Host institutions). * The Process Document. * Results of W3C Activities, standards efforts, and special events. Member Web site 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 Advisory Committee 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. Group Web sites 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. 2.6.2 Mailing Lists 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 Advisory Committee representative's email address should suffice. However, upon request from the Advisory Committee 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 Advisory Committee 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. 2.6.3 Press Releases 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. 2.6.4 Calendar of Events 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. 2.6.5 Newsletter 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. _________________________________________________________________ 3 W3C Activities and Groups This section of the document specifies the mechanisms by which W3C initiates Activities, forms groups, and organizes events. 3.1 Activities 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. Each Activity has an Activity Lead, the Team member who coordinates the work carried out within the Activity. 3.1.1 How to Create an Activity An Activity is created as follows: 1. The Director proposes an Activity to the Advisory Committee in a call for review that includes a reference to a defining briefing package. 2. The Advisory Committee has four weeks to review the proposal. During the review period, Advisory Committee representatives must make known relevant IPR claims according to the W3C IPR policy. 3. Once the review period has ended, based on comments received during the review period, the Director announces a decision about the disposition of the proposal to the Advisory Committee. The Director also announces the creation of groups described by the briefing package. Activities are extended, renewed or otherwise modified by following the Activity creation process. The proposal should explain the nature and rationale of the modification (e.g., there is a substantial increase in resources, a significant change in scope, etc.). The new briefing package should include the most recent Activity statement for the old Activity and a reference to the briefing package of the old Activity. The Team will establish mechanisms for publishing all documents related to an Activity (see the guidebook [MEM9] for details). 3.1.2 Activity Statements An Activity statement documents the progress and evolution of an Activity. Activity statements should describe the goals of the Activity, list delivered work, changing perspectives based on experience, future plans, etc. Each Activity statement must be revised at least before each ordinary Advisory Committee meeting. 3.1.3 Conditions for Activity Closure An Activity closes normally when its briefing package expires. It may close prematurely in the following circumstances: * Groups pursuing the Activity fail to produce the deliverables required by their charters. * Groups have delivered their results ahead of schedule. * There are insufficient resources to maintain the Activity, according to priorities established by the Advisory Committee and the Director. 3.1.4 Activity briefing packages Each Activity is initially defined by an Activity briefing package. Members or the Team (generally working together) create a briefing package and submit it to the Director for approval according to mechanisms established by the Team. If the briefing package is rejected, the Director must provide the submitter(s) with a justification for the rejection. If the briefing package is approved, it must be amended by the submitter(s) to include a detailed W3C resource statement (administrative, technical, and financial). The Director may also request an indication of resource commitment on the part of the submitter(s). A briefing package must include the following information: * An Activity summary. What is the nature of the Activity (e.g., to track developments, create a specification, develop code, organize pilot experiments, education, etc.)? Who or what group wants this (providers, users, etc.)? * Context information. Why is this Activity being proposed now? What is the market within the area of the proposal? Who or what currently exists in the market? Is the market mature/growing/developing a niche? What competing technologies exist? What competing organizations exist? * A description of the Activity's scope. How might a potential Recommendation interact and overlap with existing international standards and Recommendations? What organizations are likely to be affected by potential overlap? What must be changed if the process is put into place? * A description of the Activity's initial deployment, including: + Who will be the Activity Lead. + What 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). + If known, the date of the first face-to-face meeting of a proposed group. The date of the first face-to-face meeting of a proposed group may be no sooner than eight weeks after the date of the Activity proposal. + The briefing package must also specify any events (e.g., workshops) foreseen for the proposed Activity. * A summary of resources (Member, Team, administrative, etc.) that will be dedicated to the Activity. The briefing package may specify the threshold level of effort that Members must pledge in order for the Activity to be accepted. * Intellectual property information. What intellectual property (for example, an implementation) must be available for licensing and is this intellectual property available for a reasonable fee and in a non-discriminatory manner? The briefing package should remind Advisory Committee representatives to disclose IPR claims according to W3C's IPR policy. * Timeline and schedule. The timeline must include the following: + The deadline for review. + The expected duration of the Activity. + Other critical dates or events. * A list of supporters, references, etc. What community will benefit from this Activity? Are members of this community part of W3C now? Will they join the effort? 3.2 General Information about Groups 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. 3.2.1 Chair Every group must have one Chair to coordinate the group's tasks. The Chair is appointed (or reappointed) by the Director. 3.2.2 Team contact W3C designates a Team contact for every group. The Team contact acts as the interface between the Chair, Group Members, and the Team. The roles of the Team contact are described in [MEM10]. 3.2.3 Charters Every group must have a charter that describes the following: * The group's mission, * The scope of the group's work items and criteria for success, * The duration of the charter. Groups are expected to carry out their work for a period lasting from six months up to two years. * The nature of the deliverables to be produced (including minutes, reports, specifications, and software), their frequency, and the process for the group participants to approve the release of these deliverables. * Any dependencies of other entities on the deliverables of this group. For any dependencies, the charter must specify how communication about the deliverables (contact people, Coordination Groups, W3C contacts, etc) will take place. * Any dependencies of this group on other entities. For any dependencies, the charter must specify when required deliverables are expected from the other entities. The charter should also include any requirements documents that may serve the other entities. Finally, the charter should specify expected conformance of this group with the deliverables of the other entities. If a Coordination Group is managing a Working Group, the Coordination Group must monitor these dependencies to ensure they are respected; otherwise the Working Group Chair has this responsibility. For example, one group's charter may specify that another group must review a specification before that document can become a Recommendation. A Coordination Group must ensure that this review takes place. * The intended degree of confidentiality of the Group proceedings and its deliverables (Group, Members, Public). In particular, whether the charter itself is for Members' eyes only or is a public document. * A statement about how the group's work and deliverables relate to and depend on the work and deliverables of other groups (external or W3C). * How participants should disclose IPR claims according to W3C's IPR policy. * Milestones for work items and deliverables, * Meeting mechanisms and schedules, * Communication mechanisms to be employed within the group, between the group and the rest of W3C, and with the general public. The scope of each communication mechanism must be clearly indicated in the charter, * Voting mechanisms, * The level of involvement of the Team (track developments, write and edit specifications, develop code, organize pilot experiments). * The Team contact, if known, * An estimate of the time commitment a group member would have to make in order to participate in the above. A group's charter must be approved by the Director (according to mechanisms established by the Team) before the Director can create the group. 3.2.4 Meetings Face-to-Face meetings 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. Remote Meetings 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. 3.2.5 Communication Mailing list 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. 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 group's charter as well as other information deemed appropriate by the Chair. * Links to current working drafts and intermediate results. The following information must be accessible to group and Team members: * Intermediate results of the group. * An archive of the group's mailing list. * Details of past and future meetings (directly or in the list archive) . 3.2.6 How to Create a Group The Director creates a group by announcing a call for participation to the Advisory Committee that includes a reference to the defining charter, the name of the group's Chair(s), the name of the Team contact, and an email address for participant nominations. The group does not exist prior to this announcement. A call for participation in an group may be issued at the same time as the Director's announcement of a new Activity. 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. A group must be created within the scope of an approved Activity. Note that no Activity statement may refer to a group until the group exists. 3.2.7 How to Join a Group To join a group, individuals must be nominated by an Advisory Committee representative, either directly or indirectly. The Advisory Committee representative nominates the individual directly by sending email to the address indicated in the Director's call for participation in the group. Individuals are nominated indirectly by sending email to the address themselves, and copying their Advisory Committee representative. Group participants who do not represent a Member organization (invited experts) must still join a group by sending email to the indicated address. Nominations must include the following information: * An estimate of the amount of time per week the individual will dedicate to the group. * Disclosure, as described in W3C's IPR policy, of IPR claims by the organization employing the individual that are relevant to the group's work. * A description of how expenses incurred due to group commitments (e.g., travel, telephone conference calls, conferences, etc.) will be covered. Individuals may join a group at any time during its existence and follow the nomination procedure specified in the original call for participation. A group Chair may not 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. See also the conditions that must be met by invited experts. 3.2.8 How to Modify a Group Charter 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 Advisory Committee 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. 3.2.9 Conditions for Group Closure A group closes normally when its charter expires. It may close prematurely in the following circumstances: * The group fails to meet the milestones established in the group charter. * There are insufficient resources to maintain the group, according to priorities established by the Advisory Committee and the Director. * The Activity to which the group belongs terminates. 3.3 Group Types This document defines four types of groups that may carry out W3C's Activities. * Working Groups. The primary goal of a Working Group is to produce specifications or prototype software. * Interest Groups. The primary goal of an Interest Group is to explore and evaluate Web technologies. * Coordination Groups. A Coordination Group facilitates communication among Working Groups and Interest Groups. Coordination Groups are used by the Team to help manage W3C on behalf of the Members, and ensure the consistency and architectural integrity of its work. The following sections describe the procedures that govern each type of group. 3.3.1 Working Groups 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. Participation Someone is considered to participate in a Working Group if: * The individual has joined the group and is in good standing, or * The individual is an invited expert. The following people may participate in a Working Group on an ongoing basis: * Representatives of W3C Member organizations. If a participant does not speak on behalf of the organization for which the participant works, the participant must indicate this when joining the group. * Experts who do not represent a Member organization. These invited experts must be approved by the Chair. The Chair may ask an invited expert (who may or may not belong to a Member organization) to participate in a Working Group on a one-time basis. They may not participate in Working Group votes. One-time participation implies no commitment from the participant nor does it imply future participation or invitation to Working Group meetings. 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. Good standing Participation on an ongoing basis implies a serious commitment to the Working Group charter, including: * attending most meetings of the Working Group. * providing deliverables or drafts of deliverables in a timely fashion. * being familiar with the relevant documents of the Working Group, including minutes of past meetings. A Chair may decide that a participant has lost good standing if either: 1. the person has missed more than one of every three remote meetings or more than one of every three face-to-face meetings, or 2. the person has not provided deliverables in a timely fashion twice in sequence. Chairs may relax these criteria if doing so will not set back the Working Group. For example, the Chair may relax the attendance requirement for expensive meetings (international phone calls or travel) for participants who do not have financial support. The Chair is expected to apply standards for good standing consistently. When a participant risks losing good standing, the Chair must discuss the matter with the participant and the participant's Advisory Committee representative before declaring the participant in bad standing. The Chair declares the participant in bad standing by informing the participant's Advisory Committee representative and the participant of the decision. The Advisory Committee representative may appeal the decision to the Director. The Advisory Committee representative must make the appeal known to the Chair and the Team contact. In case of an appeal, the Chair may not alter the participant's standing before the Director has confirmed or denied the decision. A participant regains good standing by meeting the participation requirements for two consecutive meetings. The Chair must inform the Advisory Committee representative of any change in standing. Good standing is required to be able to vote. W3C considers that a Member organization is participating in a Working Group if at least one representative from the organization is in good standing. Communication Please consult the section on group communication for information about mailing lists and group Web sites. Meetings Working Groups will organize both remote and face-to-face meetings. Deliverables Each Working Group (in conjunction with related Coordination Groups and the Communication Team) will post its intermediate results (called working drafts) to a public area of the Working Group Web space. Working drafts must be labeled as such. Please refer to the section on working drafts for information required in the status section of a draft document. If a deliverable is code, proofs of concept and demonstrations should be published along with the code. In addition to the deliverables specified in the Working Group charter, a Working Group will post its intermediate results to the public Web site at three-month intervals. The Working Group charter must specify the process for approving the release of these intermediate reports (e.g., consensus from the Working Group). 3.3.2 Working Group consensus and votes The following sections describe the processes by which Working Groups reach consensus, record minority views, appeal decisions, and vote when appropriate. When resolving issues and making decisions, the goal of a W3C Working Group should always be to achieve unanimity of opinion. Where unanimity is not possible, the Group must reach consensus (see the W3C consensus policy) by considering the ideas and viewpoints of all participants (including invited experts) who are in good standing. The Chair must be aware of which participants work for the same Member organization (or related Members) and weigh their input accordingly. In establishing consensus, the Working Group must address the legitimate concerns of the minority. When a solution is available that addresses everyone's concerns, it should be preferred to a solution that carries approval of a majority (even a large one) but that causes severe problems to some members of the community. In general, it is desirable that a large majority of the Group favor a decision and that the minority accept the majority decision. However, at times it may be necessary (e.g., for timely delivery of a specification) to proceed with a large majority in favor and a small minority convinced in their hearts that the majority is making a mistake (possibly minor, possibly grave). In order to ensure that the Chair can judge whether minority viewpoints can be accommodated, dissenting opinions must be accompanied by an indication of the technical reasons for the dissent and of what changes in the proposal, if any, would suffice to change the opinion to one assenting to the majority proposal. Dissents not explained in this manner need not be considered when the Chair decides whether consensus has been reached. The Chair decides when consensus has been reached. The Chair of the Working Group is responsible for ensuring that minority views are accommodated if possible. To that end, a Chair may occasionally ask members of the minority questions of the general form "Can you live with this decision?" If holders of the minority view say they can live with a given decision, this will normally be taken as an indication that the group can move on to the next topic, but the inverse is not necessarily true: the minority cannot stop a Group's work simply by saying that they cannot live with the decision. When the Chair believes that the legitimate concerns of the minority have in fact been addressed as far as is possible and reasonable, then dissenting views will be recorded and the Group will move on. Decisions may be made during meetings (face-to-face or teleconference) as well as through email. All decisions must be archived. The Chair may reopen a decision when presented with new information. The Chair should archive decisions that are reconsidered (and must do so if requested by a Working Group participant). New information includes: * additional technical information, * comments by email from participants who were unable to attend a scheduled meeting, * comments by email from meeting attendees who chose not to speak out during a meeting (e.g., so they could confer later with colleagues, for cultural reasons, etc.). Minority views must be archived and deliverable. Minority views must be archived. If requested, the Chair must include archived minority views with other deliverables (e.g., in the Chair's report to the Director when a document goes to Proposed Recommendation). During an Advisory Committee Review, representatives must be able to refer to archived minority views. Minority views from the Team that are to be recorded should be sent by the Team contact for the Group. How to appeal a Working Group decision 1. The Working Group participant presents a summary of the issue being appealed to the Working Group Chair. The summary should describe whether the issue is procedural or technical. The Working Group participant should also make the appeal known to the Group's Team contact and the participant's Advisory Committee representative. 2. Within two weeks, the Chair must answer the appeal and document the decision in writing (e.g., by email). The W3C Team contact should try to obtain the concurrence of the Advisory Committee representative that the appeal has been addressed. 3. If the Working Group participant is not satisfied with the decision, the appeal may be taken to the Director. The Working Group participant should also make this appeal known to the Chair, the Team contact, and the Advisory Committee representative. The Director may consult with the Advisory Board in deciding the outcome of the appeal. All appeals, counterarguments, rationales, and decisions must be archived for reference (e.g., by the Working Group Chair). Majority Votes At times, the Working Group may settle an issue by simple majority rather than by trying to establish consensus; the Chair will decide when majority voting is appropriate. Working Groups should not use simple majority votes to resolve issues that have a technical or process impact, but only when the outcome is "arbitrary". As an example, while it is appropriate to decide by simple majority whether to hold a meeting in San Francisco or San Jose (there's not much difference geographically), it is inappropriate to vote on substantive technical decisions regarding the Working Group's deliverables. When simple majority votes are used to decide minor issues, members of the minority are not required to state the reasons for their dissent, and the votes of individuals need not be recorded. An issue resolved by simple majority vote may be reopened by the Chair as described above. A decision reached by majority vote may be appealed by a Working Group participant as described above. Chartered voting procedures The charter of a Working Group may include provisions for Working Group voting procedures (for example, in order for a proposal to pass, it must gain a particular proportion of participant votes or a particular proportion of the total membership of the Group). Any such voting procedure must include the following: * Only participants in good standing may vote. * All votes must be archived. In cases of deadlock, the Group or Chair may decide that it is necessary to proceed by way of simple majority vote; this step should be taken only in extreme circumstances. When simple majority voting is used to break a deadlock on a major issue when consensus cannot be reached, then the Chair must archive: * the decision to proceed by simple majority vote rather than by consensus, * the outcome of the vote, * the minority views. 3.3.3 Interest Groups 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. Participation 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: * Representatives of Member organizations. If a participant does not speak on behalf of the organization for which the participant works, this must be indicated in the charter. * Individuals who do not represent a Member organization. The Interest Group Chair may invite individuals to participate when their participation is deemed appropriate. Communication Please consult the section on group communication for information about mailing lists and group Web sites. Meetings Interest Groups will organize both remote and face-to-face meetings, but remote meetings should be the more common mode of communication. Votes 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. Deliverables 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). 3.3.4 Coordination 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. Charter 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. Participation 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. Communication Please consult the section on group communication for information about mailing lists and group Web sites. Meetings 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. Deliverables A Coordination Group will publish reports on the Member Web site assessing the work and progress of the groups it oversees. _________________________________________________________________ 4 W3C Events 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: * Workshops * Symposia * Conferences 4.1 Workshops 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. 4.1.1 How to Announce a Workshop 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 date, city, and (if possible) exact location of the workshop. * The attendance criteria for the workshop. Can non-Members participate as well as Members? * The goals of the workshop. Why will people come to an event on the subject? What community is the audience for this topic? What is the expected outcome of the event? * A description of the scope of the workshop and criteria for success. Are members of this community part of W3C now? Will they join the effort? * The list of the deliverables to be produced (including minutes and reports). * The fee structure, if any. If non-Members can participate, will they be charged a different fee than Members? * The names of the W3C Team members who will coordinate the workshop * The names of people to participate on the program committee. The program committee should be chaired (or at least co-chaired) by a W3C Team member. The Team schedules the workshop and coordinates (with Members and other interested parties) the workshop's program and organization. 4.1.2 Communication Workshop minutes will be taken by the W3C Team and made available in the Member 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. 4.1.3 Deliverables 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). 4.2 Symposia 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: * The date, city, and (if possible) exact location of the symposium. * The attendance criteria for the symposium, including the capacity limit. * The program of the symposium. * The name of the W3C Team member to chair (or co-chair) the symposium. There are no deliverables or criteria for success for a symposium. 4.2.1 Participation 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. 4.2.2 Communication Minutes shall be taken by the W3C Team and made available at the Member Web site. 4.3 Conferences 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). _________________________________________________________________ 5 The W3C Submission process The W3C Submission process allows Members to propose technology or other ideas for consideration by W3C. The formal process affords the submitters a record of their contribution and gives them a mechanism for disclosing the details of the transaction with the Team (including IPR claims). The Submission process also allows the Team to review proposed technology and accurately relay the status of Submission requests to the media. Note. Members do not submit Notes to W3C; they make Submission requests. A Note is one artifact of an acknowledged Submission request. Note. The Submissions process is not related to the W3C Recommendations track. Documents that are part of a Submission request have been developed outside of W3C. Members do not submit documents to W3C for "ratification" as Recommendations. 5.1 How to Send a Submission Request The Submission process begins with a Submission request from representatives of one or more Member organizations (and only Member organizations) to the Director. Organizations that are not Members of W3C may not send Submission requests directly to W3C (either alone or in conjunction with submitting Members). Submitters should refer to the submission request template [PUB13] published at the W3C Web site. To send a Submission request: * The Submitter (an Advisory Committee representative) sends a Submission package to submissions@w3.org. When several Members participate in a Submission request, the Submission package must only be sent by one of the submitting Members. The other submitting Advisory Committee representatives must be copied. * Advisory Committee representatives from all participating organizations must confirm their position statements by sending individual email to submissions@w3.org. This email should not contain the original Submission package. The Submitter will receive prompt notification that the Team has received the Submission package. If for any reason the Submission request is deemed incomplete or incorrect by the Team (e.g., the Submission package lacks information, documents in the Submission package are invalid, confirmations of position statements have not been received, Member agreements from participating companies have not been signed, etc.), the Team will help the Submitter complete and correct the request. The Team sends a validation notice to the Submitter as soon as the Team has reviewed any Submission request and judged it complete and correct. The Director then reviews the validated Submission request and either acknowledges or rejects it. The Submission request is acknowledged only after the Director has announced the decision to the Advisory Committee. This announcement must occur between one and four weeks after the validation notice. The announcement may come at any time during the three-week window, but the Team must tell the Submitter, within one week of the validation notice, when the announcement is most likely to occur. Prior to the acknowledgment, the Submission request must be held in the strictest confidentiality by the Team. In particular, the Team must not comment to the media about the Submission request. Under no circumstances may a document be referred to as "submitted to the World Wide Web Consortium" or "under consideration by W3C" or any similar phrase, nor should there be any implication made that W3C is working on a specification or with a company prior to the acknowledgment. 5.2 Submitter Rights and Obligations 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. 5.3 Acknowledgment of a Submission request Once the Director has acknowledged a Submission request, the Team: * Archives the Submission package at the Web site. The archives will clearly state that the acknowledgment does not guarantee any further action by W3C related to the submission request. * Archives any Team comments about the Submission request. * Publishes any documents in the Submission package as W3C Notes. Though submitting Members may hold the copyright for the content of a Note, every Note is governed by the W3C document notice [PUB18] and must include a reference to it. Publication of a Note by W3C indicates no endorsement by W3C, the W3C Team, or any W3C Members. The acknowledgment of a Submission request does not imply that any action will be taken by W3C. It merely records publicly that the Submission request has been made by the submitting Member. This document may not be referred to as "work in progress" of the W3C. The list of acknowledged Submissions [PUB10] may be found at the Web site. 5.4 Rejection of a Submission request A Submission request may be rejected by the Director on the following grounds: * The ideas expressed in the request are poor, may harm the Web, or run counter to the W3C mission. * The topics addressed in the request lie outside the scope of W3C's Activities. * The IPR statement made by the Submitting organizations is too restrictive (see W3C's IPR policy). If the subject of a Submission request is already being addressed by a Working Group and the Director feels that acknowledging the Submission request would interfere with the group's work (e.g., for reasons of confidentiality), the Director may ask the Submitter to take the proposal to the Working Group. The Submitter may proceed with the Submission track nevertheless, but ultimately the Director may choose to reject the request. In case of a rejection, the Director will inform the Submitter's Advisory Committee representative. The Submitter may appeal the decision to the Advisory Committee. No statements will be made by W3C about the reasons why a Submission request was rejected. 5.5 The Submission package A Submission package must include the following information: * A document for consideration (e.g., a technical specification, a position paper, etc.) * The list of all submitting Members * Position statements from all submitting Members (gathered by the Submitter). All position statements must appear in a separate document. The Submission request must include complete electronic copies of any pertinent documents. The Communication Team will establish a policy for which electronic formats (e.g., HTML) it will accept and criteria that must be met prior to publication (refer to conventions for creating and publishing documents [MEM11]). Please refer to general information about documents and the section describing W3C Notes for more information. The Submission request must also address the following questions: * What is the Submitter's position towards any intellectual property rights (IPR) associated with the technology? Any answer (from "we place this in the public domain" to "we have a patent on this") is legitimate, but the answer will affect the Director's decision to acknowledge the Submission request. Please consult the section on W3C's IPR policy. * What proprietary technology is required to implement the areas addressed by the request, and what terms are associated with its use? Again, many answers are possible, but the specific answer will affect the Director's decision. * What resources, if any, does the Submitter intend to make available if the W3C acknowledges the Submission request and takes action on it? * What action would the Submitter like W3C to take if W3C acknowledges the Submission request? * What mechanisms are there to make changes to the specification being submitted? This includes, but is not limited to, stating where change control will reside if the request is acknowledged by the Director. _________________________________________________________________ 6 W3C Technical Reports W3C publishes several types of technical reports: Recommendation track documents These are technical specifications, guidelines, etc. at various maturity levels: Working Drafts, Candidate Recommendations, Proposed Recommendations, and Recommendations. Notes A Note is a dated, public record of an idea, comment, or document. Members wishing to have their ideas published at the W3C site as a Note must follow the Submission process. 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. 6.1 General information about documents The W3C Team will establish conventions for creating and publishing documents [MEM11] and will publish these conventions on the Web site. In general, the Team will not publish a document as a public W3C Technical Report unless it follows these conventions (for naming, style, copyright requirements, etc.). The Team reserves the right to reformat documents at any time so as to conform to changes in W3C practice (e.g., changes to document style or the "Status of this Document" section). All Notes, Working Drafts, Candidate Recommendations, and Recommendations must include a section indicating the status of the document. The status section of a document should explain why W3C has published the document, whether or not it is part of the Recommendation track, who developed the document, where comments about the document may be sent, and any other metadata about the document deemed relevant by the editors. The status section indicate the document's maturity level (Working Draft, Candidate Recommendation, or Recommendation). 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 primary language for official W3C documents is English. In addition to the official English version of a document, W3C welcomes translated versions. Information about translations of W3C documents [PUB18] is available at the Web site. 6.1.1 Releasing confidential documents 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 Web site (e.g., as a Note) at the discretion of the Director. 6.2 The W3C Recommendation track W3C Working Groups are generally chartered to produce documents (e.g., technical specifications, guidelines, etc.) The W3C "Recommendation Track" refers to the process by which a document is revised and reviewed until considered mature enough by the Membership and Director to be published as a Recommendation. The following labels refer to the level of maturity of a document: Working Draft A Working Draft generally represents work in progress and a commitment by W3C to pursue work in a particular area. The label "Working Draft" does not imply consensus within W3C about the document. Candidate Recommendation A Candidate Recommendation is a stable Working Draft that the Director has proposed to the community for implementation experience and feedback. Proposed Recommendation A Proposed Recommendation is a Candidate Recommendation that has benefitted from implementation experience and has been sent to the Advisory Committee for review. Recommendation A Recommendation reflects consensus within W3C, as represented by the Director's approval. W3C considers that the ideas or technology specified by a Recommendation are appropriate for widespread deployment and promote W3C's mission. Every document must clearly indicate its maturity level. For a document to become a Recommendation, it must begin as a Working Draft and follow the process described below. Generally, Working Groups create Working Drafts with the intent of advancing them along the Recommendation track. However, publication of a Working Draft does not guarantee that it will advance to Candidate Recommendation or Recommendation. Some Working Drafts may be dropped as active work, others may be subsumed by other Working Drafts, still others may be published as Notes. A W3C Recommendation may be submitted to other standards bodies for ratification by their constituencies, however this is not required or guaranteed. Additionally, steps in the process below might be modified in order to properly coordinate W3C activities with other related Standards Development Organizations. 6.2.1 Working Drafts (WD) Requirements for Entrance The Director must approve a Chair's first request for publication as a Technical Report. Technical consensus in not a requirement for publication. Associated activities A Working Group develops the document during this period. Public review and feedback to the Working Group is welcome during this period. Duration A document can stay at the Working Draft level as long as the Working Group remains active (sanctioned by the Director and Advisory Committee) and has not met its requirements. However, Working Groups must update a Working Draft every three months. Next State A Working Draft can be updated or advanced to the Last Call phase when the Working Group feels it has met its charter requirements. A Working Draft is a chartered work item of a Working Group and generally represents work in progress and a commitment by W3C to pursue work in a particular area. At least every three months, a Working Group must publish a (public) Working Draft to keep the community abreast of its progress and to prompt the Working Group to resolve issues in a timely fashion. The first public Working Draft (or release of the document for review beyond the Working Group) must be approved by the Director. Publication of a Working Draft is not an assertion of consensus, endorsement or technical and editorial quality. The Working Draft may be unstable and it may not address all Working Group requirements, though the Chair should endeavor to obtain Working Group support for publication within the constraints of the requirement to publish every three months. A Working Draft must include a paragraph in the status section of the document that makes clear that the document may change at any time, does not represent consensus from W3C or its Members, and may not be cited as other than a work in progress. Here is a sample paragraph for a public Working Draft: This is a public W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current public W3C Working Drafts can be found at http://www.w3.org/TR. 6.2.2 Last Call Working Draft Requirements for Entrance The Working Group has resolved all known issues and the Chair issues a Last Call. Associated activities The Working Group solicits and responds to review and comments from W3C Working and Coordination Groups and external sources. Duration The Duration is specified by the Chair. A Last Call typically lasts three weeks. The Chair may request a longer period may if the document is complex or has significant external dependencies. Next State Upon Director approval, a Working Draft is advanced to Candidate Recommendation. Otherwise it is sent back to the Working Group for further work. A Last Call Working Draft is a special instance of a Working Draft that is considered by the Working Group to meet the requirements of its charter. The Working Group publishes a Last Call Working Draft in order to solicit review from at least all dependent Working Groups (copying Chairs of known dependent groups). External feedback is also encouraged. A last call announcement must recapitulate known dependencies. It must also state the deadline for comments (e.g., three to four weeks is issued). The Last Call Working Draft must be a public document. To ensure the proper integration of a specification in the international community, documents must, from this point on in the Recommendation process, contain a statement about how the technology relates to existing international standards and to relevant activities being pursued by other organizations. Once the last call period has ended, all issues raised during the last call period resolved, and the Working Draft modified if necessary, the Working Group may request that the Director submit the document for review by the Advisory Committee as a Candidate Recommendation. It is possible that comments will cause substantive changes that require that the document return to Working Draft status before being advanced to Last Call again. 6.2.3 Candidate Recommendations (CR) Requirements for Entrance The Director must be satisfied that the Working Draft has successfully completed the Last Call with all comments resolved and that the Working Group has prepared an adequate implementation report. Associated activities The Working Group requests implementation experience and uses this to refine the specification as necessary. Duration The duration is specified as part of the request for advancement. The duration may range from zero delay (skipped) to one year. Next State A Candidate Recommendation can be updated, or upon Director approval, advanced to Proposed Recommendation. Otherwise it returns to Working Draft for further work. A Candidate Recommendation has received significant review from its immediate technical community (resulting from the Last Call). Advancement of a document to Candidate Recommendation is an explicit call to those outside of the related Working Groups or the W3C itself for implementation and technical feedback. There is no requirement that a Working Draft have two independent and interoperable implementations to become a Candidate Recommendation. Instead, this is the phase at which the Working Group is responsible for formally acquiring that experience or at least defining the expectations of implementation. The Working Group's request for advancement to Candidate Recommendation should include a report of present and expected implementation of the specification. The request must also specify a duration for the implementation period. If, at the end of that time, the Working Group has not requested that the document advance to Proposed Recommendation, the document returns to Working Draft status. A Candidate Recommendation may be updated while in review if those updates clarify existing meaning or consensus. Substantive changes that require coordination with other groups will cause the document to return to Working Draft status. The Working Group may request that the implementation period be shortened or lengthened, subject to approval by the Director. The request must explain the reasons for the change. The Working Group may request that the Director advance a document directly from Working Draft to Proposed Recommendation status under two conditions: 1. The Working Group has expressed in its implementation report that they have already acquired the necessary implementation experience, or 2. The Working Group believes that immediate Advisory Committee review is critical to the success of the document. 6.2.4 Proposed Recommendations (PR) Requirements for Entrance The Director must be satisfied that the Candidate Recommendation has a sufficient level of implementation experience or requires immediate Advisory Committee review. Associated activities The Working Group requests political and promotional support from the Advisory Committee. Duration The duration is specified as part of the request for Advisory Committee review. The review period may not be less than four weeks. Next State Upon Director approval based on Advisory Committee review a Proposed Recommendation is advanced to Recommendation. Otherwise it reverts to Working Draft for further work. A Proposed Recommendation is believed by the Working Group to meet the requirements of the Working Group's charter and to adequately address dependencies from the W3C technical community and comments from external reviewers. The Director issues a call for review of a Proposed Recommendation (accompanied by other materials such as documented minority opinions, implementation status, etc.) for political and promotional support and feedback from the Advisory Committee (refer to how to start Member review of a Proposed Recommendation [MEM12]). The review period may not be less than four weeks. Although the Advisory Committee may also comment on technical aspects of a specification, most technical issues should have already been resolved at this phase. There is no requirement that a Candidate Recommendation have two independent and interoperable implementations to become a Proposed Recommendation. However, such experience is strongly encouraged and will generally strengthen its case before the Advisory Committee. The editors of the Proposed Recommendation must respond to substantive comments from the Advisory Committee until the end of the review period. No sooner than two weeks after the end of the review period, the Director announces the outcome of the proposal to the Advisory Committee. The Director may: 1. Issue the document as a Recommendation. 2. Issue the document as a Recommendation with minor changes indicated. 3. Return the document for work as a Working Draft, with a request to the editors to address certain issues. 4. Abandon the document and remove it from the W3C agenda. 6.2.5 Recommendations (REC) Requirements for Entrance Director approval based on Advisory Committee review. Associated Activities Management of errata and clarification if necessary. Duration Indefinite. Next State Not applicable, though the document may be superseded. A Recommendation reflects consensus within W3C, as indicated by the Director's approval. W3C considers that the ideas or technology specified by a Recommendation are appropriate for widespread deployment and promote W3C's mission. W3C will 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. 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 status section of a revision should indicate that it supersedes previous versions. The Communication Team will notify the Members when a revised Recommendation 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. Documents may stay at the Recommendation level indefinitely, though the status section of a Recommendation should indicate whether other documents supersede it (or are expected to). 6.3 Notes A Note is a dated, public record of an idea, comment, or document. Notes are published on the Web site at the discretion of the Director and may be published at any time. The publication of a Note does not imply endorsement of its contents by W3C. The status section of a Note indicates whether or not W3C has allocated resources to the topics covered by the Note. Notes are used in the following situations: * Notes are used to publish documents that are part of an acknowledged Submission request. * Notes are used to encapsulate a document that is not published by W3C (e.g., due to copyright issues) or under W3C's control so that W3C authors may refer to it precisely (i.e., a dated version) rather than simply "the current version." 6.3.1 Note status The status section of a Note must state whether W3C has allocated and/or will allocate resources to the work covered by the Note. The status sections of every Note must include this statement: This document is a NOTE made available by the W3C for discussion only. Publication of this Note by W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members. If W3C has no resources allocated to the note, include this statement (modifying it appropriately) as well: No W3C resources were, are, or will be allocated to the issues addressed by the NOTE. If the document was not prepared or authored by the Team, include this statement as well: W3C has had no editorial control over the preparation of this Note. If the Note is the result of a acknowledged Submission request, it must contain the following statement: This Note is the result of an acknowledged Submission request. Publication of this Note by W3C indicates no endorsement by W3C, the W3C Team, or any W3C Members. W3C has had no editorial control over the preparation of this Note. The acknowledgment of a Submission request does not imply that any action will be taken by W3C. It merely records publicly that the Submission request has been made by the submitting Member. This document may not be referred to as "work in progress" of the W3C. _________________________________________________________________ 7 W3C Process Like any other Activity in W3C, the W3C process may require amendment from time to time. * When expected changes are major (important and numerous), a Working Group must be created to draft a proposal for changes. * When expected changes are medium (important but few), the Director may decide that the creation of a Process Working Group is not warranted. In this case, the Director may propose changes to the Advisory Committee for review. * When changes are minor (clarification rather than content), the Director may decide to incorporate them, announce the changes to the Advisory Committee, and make the new process the one under which W3C operates. The Advisory Committee has four weeks after the announcement to appeal the changes. If a Working Group is created to amend the process, participation in the Working Group is open to any Advisory Committee representative. Participants are expected to attend all the Advisory Committee meetings that take place during the Working Group's existence. Voting will proceed as described for other Working Groups. 7.1 The Process Document 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. _________________________________________________________________ 8 Appendix 8.1 W3C Process Working Group This document was initially prepared by the Process Working Group (WG) of the World Wide Web Consortium. The Working Group was elected by the W3C Advisory Committee representatives on September 16, 1996 and consisted of the following individuals: * Carl Cargill - Netscape * Wendy Fong - Hewlett-Packard * John Klensin - MCI * Tim Krauskopf - Spyglass * Kari Laihonen - Ericsson * Thomas Reardon - Microsoft * David Singer - IBM * Steve Zilles - Adobe The Team Members involved in producing this document were: * Jean-Francois Abramatic - W3C Chairman and Working Group Chair * Tim Berners-Lee - W3C Director * Ian Jacobs - Editor * (Alumna) Sally Khudairi - Editor 8.2 Summary of Process Schedules Process Initiated by Intended for Time to next step Next step Activity proposal Director Advisory Committee Four weeks Director's decision. If approved, Director issues calls for participation in Working Groups. Director sends comments received during the review period within one week after end of review. Working Group Meeting announcement. Working Group Chair Working Group (notably Team contact) Eight weeks for face-to-face. One week for remote. Meeting, followed by publication of minutes. Working Draft Last call A Working Group Chair All Working Group Chairs Generally two to four weeks Proposed Recommendation Proposed Recommendation Director Advisory Committee At least four weeks Director's decision, which comes at least two weeks later. If approved, becomes a Recommendation. Submission request Member W3C Team After Submission package is validated by Team, one to four weeks. Director's acknowledgment or rejection of request. Call for nomination to Advisory Board Director Advisory Committee Specified in call. Call for votes from Director to Advisory Committee. Duration of election period specified in call. Workshop announcement W3C Team Advisory Committee Eight weeks if for information gathering, six weeks if to deal with pressing issues. Workshop. 8.3 Information at the W3C Web site The home page of the W3C Web site: http://www.w3.org/ 8.3.1 Public information [PUB5] How to Join W3C: http://www.w3.org/Consortium/Prospectus/Joining [PUB6] Full Membership Agreement: http://www.w3.org/Consortium/Agreement/Full [PUB7] Affiliate Membership Agreement: http://www.w3.org/Consortium/Agreement/Affiliate [PUB8] The list of current W3C Members: http://www.w3.org/Consortium/Member/List [PUB9] The list of Activities currently being pursued by W3C: http://www.w3.org/Consortium/Activities [PUB10] The list of acknowledged Submissions: http://www.w3.org/Submission/ [PUB11] The list of public technical reports (and other publications): http://www.w3.org/TR/ [PUB12] List of briefing packages. In this version of the Process Document, there is no public reference to the list of briefing packages. [PUB13] Submission package overview: http://www.w3.org/Submission/1996/Template/ [PUB14] People of W3C: http://www.w3.org/People/ [PUB15] W3C vision statement: http://www.w3.org/Consortium/ [PUB16] W3C Offices: http://www.w3.org/Consortium/Offices [PUB17] Invited expert and collaborators agreement: http://www.w3.org/Consortium/Legal/collaborators-agreement [PUB18] W3C Document Notice: http://www.w3.org/Consortium/Legal/copyright-documents [PUB19] W3C Technical Reports and Specifications Release Form http://www.w3.org/TR/Release [PUB20] Information about translations of W3C documents http://www.w3.org/Consortium/Translation 8.3.2 Member-only information [MEM1] The list of current Advisory Committee representatives: http://www.w3.org/Member/ACList [MEM2] The list of available mailing lists: http://www.w3.org/Member/Mail/ [MEM3] The calendar of all scheduled official events of W3C: http://www.w3.org/Member/Eventscal [MEM4] The Newsletter: http://www.w3.org/Member/Newsletter/ [MEM5] Information about future and past Advisory Committee meetings: http://www.w3.org/Member/Meeting/ [MEM6] Member help page: http://www.w3.org/Member/Help [MEM7] Activities, Activity Lead, and groups organized by domain: http://www.w3.org/Member/Mail [MEM8] The Newswire: http://www.w3.org/Member/News/NewsWire [MEM9] The "Art of Consensus", a guidebook for W3C Working Group Chairs and other Collaborators: http://www.w3.org/Guide/ [MEM10] Role of the Team Contact http://www.w3.org/Guide/staff-contact [MEM11] How to publish W3C Technical Reports http://www.w3.org/Guide/Reports [MEM12] How to start Member review of Proposed Recommendation http://www.w3.org/Guide/StartReview 8.4 W3C and the Internet Engineering Task Force (IETF) 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. 8.4.1 Role 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 fashion, a specification that is likely (though not guaranteed) to meet the needs of its Members and the community. 8.4.2 Domain 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. 8.5 Partnerships 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: 1. What would working with this organization contribute to W3C or the Web? Why is this important? 2. Is the organization truly interested in working with the W3C? Would W3C have to coerce them into participating? 3. What is a liaison going to cost (in dollars, staff time, research, travel, etc.) and where do these resources come from? 4. What expertise can W3C offer? 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; Banking, Securities, and Other Financial Services. ISO TC 154; Documents and data elements in administration, commerce, and industry. ISO TC 187; Color Notations ISO/IEC WG2 SC2; Character encoding US Z39.50; US (ANSI) standard identical to ISO standard 23950 (see "ISO TC 46") for search and retrieval, widely deployed in the bibliographic and information retrieval community. ANSI X9; Payment Negotiation Working Group ISO/IEC JTC1; Information Processing, Subcommittees: SC21, SC24, SC29, SC30, and SC34 Yes, W3C was requested to provide liaison in HTML and graphics. High, organization is complex. W3C Advisory Committee 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 8.6 Potential Partner Organizations * ANSA Consortium * AFII - Association for Font Information Interchange * CommerceNet Consortium * DAVIC - Digital Audio Visual Council * Dublin Core * E2S - End to End Security Consortium * ECMA - European Computer Manufacturers' Association * ETSI - European Telecommunications Standards Institute * EUROBIT - European Association of Manufacturers of Business Machines and Information Technology * FSTC - Financial Services Technical Consortium * ICC - The International Color Consortium * ITU - International Telecommunication Union * NIST - National Institute for Standards and Technology * OGC - Open GIS Consortium * OTP - Open Trading Protocol * POSC - Petrotechnical Open Systems Consortium * Web 3D * XML/EDI Group - Electronic Data Exchange _________________________________________________________________ 9 Glossary Activity Work carried out by W3C is organized into different Activities. Each Activity has been reviewed by the Advisory Committee and approved by the Director. Activity Lead The Team member responsible for coordinating the work carried out within an Activity. Activity Proposal A proposal to the Advisory Committee from the Director to create, renew, or modify an Activity. Advisory Committee The review body composed of one representative from each Member organization. Activity Statement A summary of the work being carried out as part of an Activity. Briefing Package The initial description (scope, structure, process, context, etc.) of a Proposed Activity. Call For Participation A call from the Director to the Membership (and possibly public) for participation in a Working Group or other Group. Call For Review A call from the Director to the Advisory Committee to review a proposal (including Activity Proposal and Proposed Recommendation). Candidate Recommendation A Candidate Recommendation is a stable Working Draft that the Director has proposed to the community for implementation experience and feedback. Chair The head of Working Group, Interest Group, or Coordination Group. Chairman The Chairman manages the general operation of the Consortium. Charter A document that describes the scope, deliverables, dependencies, and process of a Working Group or other Group. Consensus Substantial agreement. Coordination Group A Coordination Group facilitates communication among Working Groups and Interest Groups. Coordination Groups are used by the Team to help manage W3C on behalf of the Members, and ensure the consistency and architectural integrity of its work. Director The lead architect for W3C. The Director also approves Recommendations, Activity proposals, and charters; designates Group Chairs; and acknowledges Submission requests. Document Status A section of every W3C Technical Report that describes the context in which the document was published. Good Standing An indication that a Working Group participant has attended meetings diligently and produced deliverables in a timely manner. Host One of the primary sites where the Team is physically located. Interest Group A W3C group that explores and evaluates Web technologies. Invited Expert Someone invited to participate in a Working Group who does not represent a W3C Member organization or someone invited to participate on a one-time basis. Last Call A Working Draft that a Working Group considers essentially finished that has been sent to other groups for review. Note A Note is a dated, public record of an idea, comment, or document. Office Local points of contact in other countries that help ensure that W3C and its specifications are known in their country. Offices work with their regional Web community to develop participation in W3C Working Groups. Proposed Recommendation A Proposed Recommendation is a Candidate Recommendation that has benefitted from implementation experience and has been sent to the Advisory Committee for review. Recommendation A Recommendation reflects consensus within W3C, as represented by the Director's approval. W3C considers that the ideas or technology specified by a Recommendation are appropriate for widespread deployment and promote W3C's mission. Related Member Two Members are related if either Member is a subsidiary of the other, or if both Members are subsidiaries of a common entity. Submission The W3C Submission process allows Members to propose technology or other ideas for consideration by W3C. Team The Team (Director, Chairman, and Staff) manages W3C Activities and establishes the mechanisms and procedures for doing so. Technical Report Documents that are on the Recommendation track or W3C Notes. Working Draft A Working Draft generally represents work in progress and a commitment by W3C to pursue work in a particular area. The label "Working Draft" does not imply consensus within W3C about the document. Working Group The primary goal of a Working Group is to produce specifications or prototype software. Workshop 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. _________________________________________________________________