{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.}
{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: Provide a brief description of each specification the group plans to produce. Where an estimate is possible, it can be useful to provide an estimated schedule for key deliverables. As described below, the group may later modify the charter deliverables. }
{TBD: if no specifications, delete the following paragraph and instead include: No Specifications are produced by this group.}
{TBD: Provide a brief description of each Community Group Report the group plans to publish. The description should be enough for those considering participation to know the general types of technologies that will be defined in the report.}
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.}
{TBD: 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.}
{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).
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.
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 The group will conduct all of its technical work in public.
Discussions MAY take place on the group's public mailing list. Other discussions MAY take place using Issues in the group's GitHub repository. For convenience, GitHub issues and pull requests will be archived to the group's contrib list. Other contributions MAY be directly posted to the contrib list.
Meetings MAY be restricted to Community Group participants, but a public summary or minutes MUST be posted to the group's public mail list.
Any decisions reached at any meeting are tentative. Any group participant may object to a decision reached at a 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.