{TBD: This Charter Template contains sections marked like this one to list instructions. Delete these from the Charter when it is completed and ready for use.}
This Charter assumes Reports are developed using a repository like Git. It is assumed the repository provides the ability to view older versions of documents and determine who made changes. It is also assumed the repository provides an archived Issues list where conversations can occur among participants on different Issues that have been raised.
This Charter is designed for Community Groups that may not know all their deliverables when the group forms. For Specifications or Software Projects, Participants must explicitly opt-in to working on that particular specification or project in order to Contribute. That is intended to allow flexibility in adding new work without increasing the risk of unauthorized contributions by Participants. Contributions subject to the CLA patent provisions only occur for Specifications where there has been explicit opt-in, by the Participant's AC Representative for W3C Members.
{TBD: describe the mission and goals of the Community Group. This should be a brief description describing the reason the group has been formed.}
{TBD: Describe topics that are in scope. For specifications that the CLA patent section applies to, it is helpful to describe the scope in a way that it is clear what types of technologies will be defined in specifications, as opposed to adoption by reference or underlying technology not defined in the proposed spec. Key use cases are often helpful in describing scope. If no specifications will be defined in the group that the CLA patent section applies to, the charter should clearly state that. A clear scope is particularly important where patent licensing obligations may apply.}
{TBD: Identify topics known in advance to be out of scope}
{TBD: if no specifications, delete the following paragraph and instead include: No Specifications are produced by this group.}
The group will maintain a document in the repository that contains the name of each Specification the group plans to work on, a shortname to use in email about the spec, and a brief description of what the specification is for and what technologies are relevant. Specification means a document the CLA patent provisions apply to. The description SHOULD be sufficient for readers to determine if the spec would be of interest to them and for use by others in evaluation what types of patents may be relevant in considering licensing implications of Contributing. Where an estimate is possible, it can be useful to provide an estimated schedule for key deliverables. The document MUST indicate the state of each Specification: inactive, active, completed, abandoned, paused (e.g. waiting for implementation feedback). Specifications MAY be listed as belonging to a group of Specifications with its own shortname for the group of Specifications. The description for each Specification, or group of Specifications, will contain a link to a document with information on which Participants have opted-in to Contribute to the Specification (see below). The Community Group can modify the list of deliverables as described below.
The group MAY produce other Community Group Reports within the scope of this charter but that are not Specifications covered by the CLA patent provisions.
{TBD: if no Software, delete the following paragraph and instead include: No Software is produced by this group.}
W3C test suites, please see Test the Web Forward, and take note of W3C's test suite contribution policy and licenses for W3C test suites.}
The group will maintain a document in the repository that contains the name of each Software project the group plans to work on, a shortname to use in email about the project, and a brief description of what the project is for and what technologies are relevant. For information about contributions to W3C test suites, please see Test the Web Forward, and take note of W3C's test suite contribution policy and licenses for W3C test suites. For other software contributions, clearly state which licenses will govern contributions and distribution. Each project description will contain a link to a document with information on which Participants have opted-in to Contribute to the project(see below). The Community Group can modify the list of deliverables as described below.
{TBD: List any significant dependencies on other groups (inside or outside W3C) or materials. }
Terms of in this charter that conflict with those of the Community and Business Group Process are void.
The group will not publish Community Group Reports that are Specifications on topics other than those listed as described under "Community Group Reports that are Specifications" above. The CLA patent section applies to these Community Group Reports that are Specifications.
Contributions can only be made by Community Group Participants (so all Contributors have agreed to the CLA). For Specifications (where the CLA patent provisions apply), participants MUST have explicitly opted-in to contributing to that particular Specification or group of Specifications. For W3C Members, the act of participant opting-in MUST be performed by the participant's W3C AC representative. To opt-in to contributing to a Specification, an email is sent to the Community Group "contrib" list indicating the Specification short name and the name of the person who is opting in. The body of these messages must be in the format: {"name":"tbd-participant name", "specification":"tbd-specification or group of specifications short name", "opt-in":"yes"}. This is JSON object format. opt-in for multiple specifications and participants MAY be included in a single email by including the JSON objects in a JSON array. A Community Group or the W3C may provide a Web page for automating posting this email in the correct format. The CLA patent provisions apply only to Participants who have opted-in at the time of their attempted Contribution. Participants who opt-in remain in that state until they quit the Community Group
Community Group Participants agree that all Contributions will be documented in pull requests and commits for a particular document in the group's GitHub repository.
For Contributions to Specifications, if someone other than the Contributor makes the pull request, the pull request MUST indicate who the request was made on behalf of and MUST provide a link to the archived change request in a GitHub Issue or in the archived Community Group contrib or general mail list. This could be a link to archived meeeting minutes that clearly indicate who requested changes to a Specification. The information MUST be specific enough to easily determine who the Contributors were and that the intention was to change a particular Specification.
For software, the GitHub Contributing and License files describes how to Contribute and the license under which Contributions are made.
The Document describing the List of Specifications or Projects can be modified by the Chair issuing a 7 day CfC on the proposed change, as described in the Decision Process. The state of a Specification MAY be updated by the Community Group using the usual Decision Process.
Participants in this group choose their Chair(s) and can replace their Chair(s) at any time using whatever means they prefer. However, if 5 participants —no two from the same organization— call for an election, the group must use the following process to replace any current Chair(s) with a new Chair, consulting the Community Development Lead on election operations (e.g., voting infrastructure and using RFC 2777). Participants announce their candidacies. Participants have 14 days to announce their candidacies, but this period ends as soon as all participants have announced their intentions. If there is only one candidate, that person becomes the Chair. If there are two or more candidates, there is a vote. Otherwise, nothing changes. Participants vote. Participants have 21 days to vote for a single candidate, but this period ends as soon as all participants have voted. The individual who receives the most votes —no two from the same organization— is elected chair. In case of a tie, RFC2777 is used to break the tie. An elected Chair may appoint co-Chairs. Participants dissatisfied with the outcome of an election may ask the Community Development Lead to intervene. The Community Development Lead, after evaluating the election, may take any action including no action.
This group will seek to make decisions when there is consensus. When the group discusses an issue on the mailing or Issues list and there is a call from the group for assessing consensus, after due consideration of different opinions, the Chair should record a decision and any objections. A common way to determine consensus for important decisions is to conduct a Call for Consenus (CfC) where the Chair puts a proposal to the group on the public mail list and asks for feedback from the Participants within some period of time that is at least 7 days. Not responding indicates going along with the proposal. Direct feedback is encouraged, especially to weigh the degree of consensus when there is dissent. Participants may call for an online vote if they feel the Chair has not accurately determined the consensus of the group or if the Chair refuses to assess consensus. At least 5 participants —no two from the same organization - must agree with the call for a formal vote. The call for a vote must specify the duration of the vote which must be at least 7 days and should be no more than 14 days. The Chair must start the vote within 7 days of the request. The decision will be based on the majority of the ballots cast. It is the Chair’s responsibility to ensure that the decision process is fair, respects the consensus of the CG, and does not unreasonably favor or discriminate against any group participant or their employer. The Chair may delegate the role usually taken by the Chair to a Lead for the Specification or Project, and may also withdraw that assignment.
The group will conduct all of its technical work on its public mailing list or Issues list. Any decisions reached at any meeting are tentative and must be reported on the public mail list in meeting minutes. Any group participant may object to a decision reached at an online meeting within 7 days of publication of the decision on the mail list. That decision must then be confirmed on the mail list by the Decision Process above.
The group MAY decide to work on a proposed amended charter, editing the text using the Decision Process described above. The decision on whether to adopt the amended charter is made by conducting a 30-day vote on the proposed new charter. The new charter, if approved, takes effect on either the proposed date in the charter itself, or 7 days after the result of the election is announced, whichever is later. A new charter must receive 2/3 of the votes cast in the approval vote to pass. The group may make simple corrections to the charter such as deliverable dates by the simpler group decision process rather than this charter amendment process. The group will use the amendment process for any substantive changes to the goals, scope, deliverables, decision process or rules for amending the charter.