{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 are affiliated with a Working Group or an Interest Group, called the Parent Group in this Charter
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.
This Community Group is affiliated with the {TBD: name of Parent WG or IG}. The group serves to perform early exploratory work on possible future Specifications or to provide other Reports requested by the Parent Group. Membership, like for any Community Group, is open and members of the Parent Group are not required to join this Community Group. The Parent Group deterines what Specifications this Community Group MAY work on and defines this Community Group Charter. The Parent Group determines when, or if, to adopt work from this Community Group.
The Scope of this Community Group includes the Scope from the Parent Group's Charter. However, the Deliverables requested by the Parent Group MAY include work beyond that Charter to explore possible future extensions of the Parent Group's scope. Because of this larger scope, participation that leads to patent licensing obligation under the CLA only occurs if the participant has explicitly opted-in to work on a particular Specification.
Anything the Parent Group indicates is out of Scope. For example, if the Community Group undertakes to explore some area, the Parent Group can decide that it is out of scope for the Community Group and the work would halt in the Community Group
{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 is not permitted to produce any Specification unless instructed to do so by the Parent Group. 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 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 Parent Group can approve or amend this Community Group's Charter by a 30 day CfC in the Parent Group. An amended Charter takes effect 2 weeks after notification from the Parent Group on the Community Group public mail list. The Parent Group MAY also suspend or terminate the Community Group through a CfC in the Parent Group.