Charter development and review process

Context:

This is a draft process for creating and reviewing charters. Once approved by the ProcessCG / AB, it is intended to be voluntarily followed by the team, and once well understood and well debugged, to be included in the formal W3C Process.

See https://github.com/w3c/w3process/issues/182 in general for context about the rationale for having this, and within that issue, these comments in particular: 1, 2, 3, first part of 4.

This is intended to be compatible with, but stricter than, the official W3C Process as it exists today.

Out of scope

This does not attempt to define:

• What triggers the creation of a new charter
• How chairs and team contacts get chosen / appointed
• The process to extend charters without substantial modifications (already defined as a prerogative of the Director, in https://www.w3.org/2018/Process-20180201/#charter-extension)

Process for developing, reviewing, and adopting Charters

1. A first draft of the charter is prepared by the team.
   • If it is a renewed charter for an existing group, this draft should be prepared by the existing team contact of the group, and should be done in collaboration with the the chair(s) of the group.
   • If it is a renewed charter for an existing group, it must include a change section.
   • The draft should be hosted in a public and version controlled system.
   • The draft must include information about how to send comments about it, which must include at least:
     • A confidential way to contact the team about this draft
     • A public archived venue for raising and discussing issues about this draft.
2. It is announced, with a minimum review period (no shorter than 4 weeks), to:
   • the TAG (to check that intended work is compatible with Web Platform architecture)
   • the AB (to check that the charter is consistent with the W3C Process)
   • [email protected]
   • [email protected]
   • the public mailing list of all groups listed as liaisons in the charter
   • the public mailing list of the existing WG in the case of a charter renewal
   • or the public mailing list of the relevant CG(s) in the case where the WG is created from CG incubation
3. All issues raised get discussed, and and the charter is updated if needed based on the conclusion of the discussion of each individual issue. The team should make decisions based on consensus of the participants, and is responsible for assessing consensus.
4. Each change to the Charter since the announced draft must be documented in the change section, including changes made without public discussion made in reaction to confidential feedback, if any.
5. A Disposition of Comments is produced by the team. It lists every comment/change request made publicly, and for each, gives:
   • Who raised the issue (can be an individual, or a WG, CG, the AB, the TAG…)
   • Its status: Accepted / Accepted (Editorial), Retracted, Rejected, Invalid, Duplicate.
   • A link (or links) to the discussion and to the resolution that concludes it if the discussion was public.
   • In the case of Rejected or Invalid, a rationale for rejecting (or a link to it)
6. If the team concludes that there are deep and irreconcilable differences about the charter, it may, after consulting with W3M (issue: and the TAG? and the AB? The Director) declare the chartering attempt a failure and abort. If this happens, all participants must be informed of this decision.
7. Once all issues have been closed, and both the DoC and Changes section are complete and up to date, (but no sooner than then end of the minimum review period),
   1. The Team announces that the review period is closed Issue: announces to who? AB+W3M?
   2. The AB validates that all the above has been done properly (if not, rerun until it has)
   3. Call for an AC vote, and announce it to:
      • [email protected]
      • [email protected]
      • [email protected]
      • the public mailing list of all groups listed as liaisons in the charter
      • the public mailing list of the existing WG in case of renewal, or the public mailing list of the CG in case of incubation
      • each person who filed a comment, whether publicly or confidentially. The announcement must include:
      • A link to the Proposed Charter
      • A link to the DoC Note: Only AC-Reps can vote, but others are notified so that they have the opportunity to report (Issue: How? To who?) any discrepancy between a discussion they took part in the the claims made by the DoC and so that they may share any concerns they have with AC-Reps.
8. If all votes are in favor, the charter is accepted and published as is. Otherwise, rerun from step 2, with the following differences:
   • each person who previously filled a comment or voted must be informed of proposed changes and be included in the corresponding discussions
   • if all the issues raised during the vote either result in editorial changes only, or there reach a consensus for no change, there is no need for a new vote (7.iii). The AB still needs to validate that comments have been addressed properly (7.ii)