This section of the document specifies the mechanisms by which W3C initiates Activities, forms groups, and organizes events.
When W3C decides to become involved in an area of Web technology or policy, it initiates an Activity in that area. An Activity means that W3C resources -- people, time, money, etc. -- are dedicated to work in that area. Generally, an Activity is carried out by one or more groups.
At all times, the list of Activities currently being pursued by W3C [PUB9] is available at the public Web site. For Members, the list of Activities and all groups pursuing them [MEM7] is also available. A technological or policy area not declared at the Web site is not part of a W3C Activity.
Each Activity has an Activity Lead, the Team member who coordinates the work carried out within the Activity.
An Activity is created as follows:
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).
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.
An Activity closes normally when its briefing package expires. It may close prematurely in the following circumstances:
Each Activity is initially defined by an Activity briefing package. Members or the Team (generally working together) create a briefing package and submit it to the Director for approval according to mechanisms established by the Team.
If the briefing package is rejected, the Director must provide the submitter(s) with a justification for the rejection.
If the briefing package is approved, it must be amended by the submitter(s) to include a detailed W3C resource statement (administrative, technical, and financial). The Director may also request an indication of resource commitment on the part of the submitter(s).
A briefing package must include the following information:
Groups are created to carry out W3C Activities. The type of group created depends on the nature of its tasks. Each group is defined by a charter and managed by a Chair.
Every group must have one Chair to coordinate the group's tasks. The Chair is appointed (or reappointed) by the Director.
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].
Every group must have a charter that describes the following:
A group's charter must be approved by the Director (according to mechanisms established by the Team) before the Director can create the group.
For all face-to-face meetings, the group Chair will announce the dates and location of the group's next meeting at least eight weeks before the meeting. Shorter notice for a meeting is allowed provided that there is unanimous consent from every person on the group mailing list.
At least two weeks before the meeting, all group participants will be notified of the meeting's agenda. Participants must confirm their attendance with the Chair and the meeting organizer at least three days before the meeting.
Minutes of the meeting must be posted (through a mailing list and to the group's Web space) within two weeks after the meeting. Action items must be posted within two days after the meeting.
For all meetings, each absent group participant may nominate an alternate. At any one time, a participant may have one and only one chosen alternate.
For all remote meetings (telephone, IRC, etc.), the group Chair will announce that a meeting will take place at least one week before the meeting.
At least 24 hours before the meeting (or 72 hours if the meeting is on a Monday) all group participants will be sent an email specifying how to join the meeting (e.g., the telephone number) and the meeting's agenda. Participants unable to attend a meeting should notify the Chair at least 24 hours before the meeting.
Minutes of the meeting shall be posted (through a mailing list and to the group's Web space) within 48 hours of the meeting. Action items must be posted within 24 hours of the meeting.
For all meetings, absent group participants may nominate an alternate to act on their behalf.
Group participants and their alternates exchange information via a mailing list. The Chair should ensure that new participants are subscribed to all relevant mailing lists.
The names of available mailing lists [MEM2] may be found at the W3C Web site.
Each group will maintain a Web site. Each group's home page will be linked from the home page of the Activity to which it belongs. The list of W3C Activities [PUB9] is available online.
The following must be accessible to W3C Members at the group Web site, with links from the Activity home page:
The following information must be accessible to group and Team members:
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.
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:
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.
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.
A group closes normally when its charter expires. It may close prematurely in the following circumstances:
This document defines four types of groups that may carry out W3C's Activities.
The following sections describe the procedures that govern each type of group.
A Working Group's purpose is to study a technical or policy issue involving the Web and to develop proposals for W3C Recommendations. Working Groups are created according to the procedures indicated in this document, including the procedure for charter submission and approval.
Someone is considered to participate in a Working Group if:
The following people may participate in a Working Group on an ongoing basis:
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.
Participation on an ongoing basis implies a serious commitment to the Working Group charter, including:
A Chair may decide that a participant has lost good standing if either:
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.
Please consult the section on group communication for information about mailing lists and group Web sites.
Working Groups will organize both remote and face-to-face meetings.
Each Working Group (in conjunction with related Coordination Groups and the Communication Team) will post its intermediate results (called working drafts) to a public area of the Working Group Web space. Working drafts must be labeled as such. Please refer to the section on working drafts for information required in the status section of a draft document.
If a deliverable is code, proofs of concept and demonstrations should be published along with the code.
In addition to the deliverables specified in the Working Group charter, a Working Group will post its intermediate results to the public Web site at three-month intervals. The Working Group charter must specify the process for approving the release of these intermediate reports (e.g., consensus from the Working Group).
The following sections describe the processes by which Working Groups reach consensus, record minority views, appeal decisions, and vote when appropriate.
When resolving issues and making decisions, the goal of a W3C Working Group should always be to achieve unanimity of opinion.
Where unanimity is not possible, the Group must reach consensus (see the W3C consensus policy) by considering the ideas and viewpoints of all participants (including invited experts) who are in good standing. The Chair must be aware of which participants work for the same Member organization (or related Members) and weigh their input accordingly.
In establishing consensus, the Working Group must address the legitimate concerns of the minority. When a solution is available that addresses everyone's concerns, it should be preferred to a solution that carries approval of a majority (even a large one) but that causes severe problems to some members of the community. In general, it is desirable that a large majority of the Group favor a decision and that the minority accept the majority decision. However, at times it may be necessary (e.g., for timely delivery of a specification) to proceed with a large majority in favor and a small minority convinced in their hearts that the majority is making a mistake (possibly minor, possibly grave).
In order to ensure that the Chair can judge whether minority viewpoints can be accommodated, dissenting opinions must be accompanied by an indication of the technical reasons for the dissent and of what changes in the proposal, if any, would suffice to change the opinion to one assenting to the majority proposal. Dissents not explained in this manner need not be considered when the Chair decides whether consensus has been reached.
The Chair of the Working Group is responsible for ensuring that minority views are accommodated if possible. To that end, a Chair may occasionally ask members of the minority questions of the general form "Can you live with this decision?"
If holders of the minority view say they can live with a given decision, this will normally be taken as an indication that the group can move on to the next topic, but the inverse is not necessarily true: the minority cannot stop a Group's work simply by saying that they cannot live with the decision. When the Chair believes that the legitimate concerns of the minority have in fact been addressed as far as is possible and reasonable, then dissenting views will be recorded and the Group will move on.
Decisions may be made during meetings (face-to-face or teleconference) as well as through email. All decisions must be archived.
The Chair should archive decisions that are reconsidered (and must do so if requested by a Working Group participant). New information includes:
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.
All appeals, counterarguments, rationales, and decisions must be archived for reference (e.g., by the Working Group Chair).
At times, the Working Group may settle an issue by simple majority rather than by trying to establish consensus; the Chair will decide when majority voting is appropriate.
Working Groups should not use simple majority votes to resolve issues that have a technical or process impact, but only when the outcome is "arbitrary". As an example, while it is appropriate to decide by simple majority whether to hold a meeting in San Francisco or San Jose (there's not much difference geographically), it is inappropriate to vote on substantive technical decisions regarding the Working Group's deliverables.
When simple majority votes are used to decide minor issues, members of the minority are not required to state the reasons for their dissent, and the votes of individuals need not be recorded.
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.
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:
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:
An Interest Group brings together people who wish to evaluate potential Web technologies and policies. An Interest Group does not have the goals of a Working Group -- development of specifications or code. Instead, it serves as a forum to explore cooperation and exchange ideas.
It is quite possible that an Interest Group's studies will lead to the creation of a Working Group, but this may not be known in advance nor is it guaranteed. Interest Groups are created according to the procedures indicated in this document, including the procedure for charter submission and approval.
See also how to join a group.
Interest Group Membership is not, in principle, limited in size. The following people may participate in an Interest Group on an ongoing basis:
Please consult the section on group communication for information about mailing lists and group Web sites.
Interest Groups will organize both remote and face-to-face meetings, but remote meetings should be the more common mode of communication.
From time to time, Interest Group participants may choose to vote on issues of policy or direction.
In an Interest Group, each Member organization or group of related Members is allowed one vote, even though each Member may have several participants in the group. If more than one vote is received from a Member organization or group of related Members, the votes are counted as one valid vote if they agree, otherwise they are ignored and the relevant Advisory Committee representative(s) will be notified of the discrepancy.
Voting proceeds as for Working Groups unless otherwise indicated.
The Interest Group charter must specify the type of deliverable the group intends to produce and with what frequency (e.g., a report summarizing the group's findings or comments on and requirements for the activities of other groups).
W3C Activities interact in many ways. There are dependencies between groups within the same Activity or in different Activities. There may also be dependencies between W3C Activities and the activities of other organizations. Examples of dependencies include the use by one technology of another being developed elsewhere, scheduling constraints between groups, the synchronization of publicity for the announcement of deliverables, etc. Or, a Working Group may decide that to pursue its goals more effectively, it should assign specific work to smaller task forces. In this case, the Chair may ask for a Coordination Group to be formed to manage the cooperating task forces (which may be either Working Groups or Interest Groups).
Coordination Groups are created when dependencies exist so that issues are resolved fairly and the solutions are consistent with W3C's mission and results.
When an Activity is proposed, dependencies should be made as explicit as possible in the briefing package. The briefing package may include a proposed charter for a Coordination Group (designed to coordinate groups described in the Activity proposal or to draw up charters of future groups).
It is also the case that dependencies arise after the creation of groups, and the Team should ensure that these are recognized and accepted by the parties involved. The Team should, where necessary, in consultation with Working Group Chairs, inform, create, and modify Coordination Groups when a new dependency is detected. When the issues within the scope of the Coordination Group are no longer being (or to be) addressed by W3C, then the Coordination Group should be closed.
Arbitration
W3C is a forum for those wishing to agree; it is not a battleground. At times, unforeseen dependencies may arise that are proposed by one group but that a related group does not wish to accept. Tension may also mount when expectations defined in a dependency are misunderstood or are not met. The Team should be informed of such tensions. Where a Coordination Group's scope covers the issues and parties involved, it is the first locus of resolution of such tensions. If agreement cannot be found between the Coordination Group and other groups involved, then the Team should arbitrate after consultation with parties involved and other experts, and, if deemed necessary, the Advisory Committee.
The charter of a Coordination Group must specify the scope of the group's work and the frequency of its meetings. The charter must also list the Working Groups or Interest Groups involved and the name of each group's contact for communication with the Coordination Group.
The charter of a Coordination Group must also specify whether the group may create new Working Groups. When new groups are created, they may not exceed the scope of the Coordination Group. In addition, any proposed Working Group may only proceed subject to the Director's decision that sufficient Team resources are available to support it and that other organizational and coordination work is not first required.
See also how to join a group.
The participants in a Coordination Group (defined in the charter) should represent the coordinated groups; participation should evolve as groups become newly dependent or independent. To promote effective communication between a Coordination Group and each group being coordinated, participation in a Coordination Group is mandatory for the Chair of each group being coordinated. The Coordination Group's charter may also specify other participants, such as invited experts or liaisons with other groups internal or external to W3C. The role of these additional participants should be clearly stated, as well as whether they are invited experts specified by name, invited experts in a specific field to be invited by the Chair, or representatives of particular organizations.
The Team, after consultation with Working Group Chairs, is responsible for ensuring that the Coordination Group structure is efficient and appropriate to its needs at each point in time, and making modifications to the list of participants as appropriate.
The Director appoints the Chair of a Coordination Group unless the majority of participants of the Coordination Group requests an election of the Chair. In case of an election, the Chair of the Coordination Group will be elected by majority vote from and by the Membership of the Coordination Group.
Please consult the section on group communication for information about mailing lists and group Web sites.
A Coordination Group will organize remote and/or face-to-face meetings. Reports of these meetings are to be published to Members on the Coordination Group's Web space.
A Coordination Group will publish reports on the Member Web site assessing the work and progress of the groups it oversees.