+ {TBD: remove next sentence before submitting for + approval} This Charter is work in progress. To submit feedback, + please use GitHub repository Issues + where Charter is being developed. +
+
+ The group aims to provide a meeting point for Security, Privacy, Human Rights experts, and technology domain experts to create Threat Models together, following the Threat Modeling Manifesto.
+
+ This group will not publish Specifications.
+
+ Create Threat Models and other groups that develop specifications or otherwise produce other deliverables, providing specific expertise related to + Threat Modeling and threat categories such as Security, Privacy, and Human Rights. +
++ This group will not publish Specifications. +
+
+ The group may produce other Community Group Reports within the scope of
+ this charter but that are not Specifications, for instance, threat models,
+ threat lists, use cases, requirements, or white papers.
+
+ Deliverables can be published as deliverables of the group itself or adopted by other groups.
+
+
+ The group operates under the Community and Business + Group Process. Terms in this Charter that conflict with those of the + Community and Business Group Process are void. +
++ As with other Community Groups, W3C seeks organizational licensing + commitments under the W3C Community + Contributor License Agreement (CLA). When people request to + participate without representing their organization's legal interests, + W3C will in general approve those requests for this group with the + following understanding: W3C will seek and expect an organizational + commitment under the CLA starting with the individual's first request to + make a contribution to a group Deliverable. + The section on Contribution Mechanics describes + how W3C expects to monitor these contribution requests. +
+ ++ The W3C Code of + Ethics and Professional Conduct applies to participation in + this group. +
+ ++ The group will not publish Specifications. + See below for how to modify the charter. +
++ Substantive Contributions to Specifications can only be made by Community + Group Participants who have agreed to the W3C Community + Contributor License Agreement (CLA). +
++ Specifications created in the Community Group must use the + W3C Software and Document License. All other documents produced by + the group should use that License where possible. +
++ {TBD: if CG doesn't use GitHub replace the remaining paragraphs in this + section with: "All Contributions are made on the groups public mail list + or public contrib list"} +
++ Community Group participants agree to make all contributions in the + GitHub repo the group is using for the particular document. This may be + in the form of a pull request (preferred), by raising an issue, or by + adding a comment to an existing issue. +
++ All Github repositories attached to the Community Group must contain a + copy of the CONTRIBUTING + and LICENSE + files. +
++ The group will conduct all of its technical work in public. If the group + uses GitHub, all technical work will occur in its GitHub repositories + (and not in mailing list discussions). This is to ensure contributions + can be tracked through a software tool. +
++ Meetings may be restricted to Community Group participants, but a public + summary or minutes must be posted to the group's public mailing list, or + to a GitHub issue if the group uses GitHub. +
++ If the decision policy is documented somewhere, update this section accordingly to link to it. +
++ This group will seek to make decisions where there is consensus. Groups + are free to decide how to make decisions (e.g. Participants who have + earned Committer status for a history of useful contributions assess + consensus, or the Chair assesses consensus, or where consensus isn't + clear there is a Call for Consensus [CfC] to allow multi-day online + feedback for a proposed course of action). It is expected that + participants can earn Committer status through a history of valuable + contributions as is common in open source projects. After discussion and + due consideration of different opinions, a decision should be publicly + recorded (where GitHub is used as the resolution of an Issue). +
++ If substantial disagreement remains (e.g. the group is divided) and the + group needs to decide an Issue in order to continue to make progress, the + Committers will choose an alternative that had substantial support (with + a vote of Committers if necessary). Individuals who disagree with the + choice are strongly encouraged to take ownership of their objection by + taking ownership of an alternative fork. This is explicitly allowed (and + preferred to blocking progress) with a goal of letting implementation + experience inform which spec is ultimately chosen by the group to move + ahead with. +
++ Any decisions reached at any meeting are tentative and should be recorded + in a GitHub Issue for groups that use GitHub and otherwise on the group's + public mail list. Any group participant may object to a decision reached + at an online or in-person meeting within 7 days of publication of the + decision provided that they include clear technical reasons for their + objection. The Chairs will facilitate discussion to try to resolve the + objection according to this decision process. +
++ It is the Chairs' responsibility to ensure that the decision process is + fair, respects the consensus of the CG, and does not unreasonably favour + or discriminate against any group participant or their employer. +
++ 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 organisation, 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 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. +
++ The group can 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. +
+ +