## Change History
### January 1, 2025 Analysis
[CGCharter-1727386911.html commit history](https://github.com/swicg/potential-charters/commits/main/CGCharter-1727386911.html)
Note the repository is named `potential-charters` implying that this history will be disassociated from the charter or even discarded entirely in the future.
What follows are the commits containing substantive changes made to the template W3C community group charter document relating to chair process.
Emphasis is mine. See each commit for full text of changes.
The related PRs appears to be [10](https://github.com/swicg/potential-charters/pull/10) and [14](https://github.com/swicg/potential-charters/pull/14).
Note the poorly written commit messages, typos and formatting changes commingled with substantive process changes and overall lack of linked discussion/justification/oversight.
***All changes listed serve to shift authority away from participants to chairs and .. task force leads?***
$def header(n, hash, message, contributors):
<h3>$(n). <q>$message</q></h3>
<p><small>[$hash](https://github.com/swicg/potential-charters/commit/$hash)
$for contributor in contributors:
$contributor\
$if not loop.last:
/ \
</small></p>
$:header(1, "2a1bba7", "bumblefudge edits", ["bumblefudge", "dmitrizagidulin"])
#### Removal
> The Community Group participants appoints (and re-appoints) Chairs for the group.
#### Addition
> The Community Group participants elect (<strong style=color:#2aa198>and/or other chairs appoint</strong>) no less than One (1) and no more than Three (3) Chairs for the group at any given time.
<strong style=color:#dc322f>ISSUE: Allows chair(s) to bypass election.</strong>
$:header(2, "6e20b16", "reformat solid precedent from markdown to html", ["bumblefudge", "dmitrizagidulin"])
#### Removals
> <strong style=color:#2aa198>Participants in this group choose their Chair(s) and can replace their
> Chair(s) at any time using whatever means they prefer</strong>. 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, <strong style=color:#2aa198>consulting the Community Development Lead on election
> operations</strong> (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
> organisation, is elected chair. In case of a tie, RFC2777 is used to
> break the tie. An elected Chair may appoint co-Chairs.
---
> <strong style=color:#2aa198>Participants dissatisfied with the outcome of an election may ask the
> Community Development Lead to intervene</strong>. The Community Development Lead,
> after evaluating the election, may take any action including no action.
#### Additions
> In the case of interim vacancy, <strong style=color:#2aa198>the remaining chairs may appoint a co-chair for each open seat</strong>, hold an election for the same, or wait until the next election, at their discretion.
---
> If a participant of the community group wishes to call for the recall of a chair, for any reason, that participant must first privately communicate with the other chairs their desire and reason for doing so.
> Those chairs must give the participant an opportunity to discuss their concerns with a goal of resolving them.
> If, after 30 days, the participant feels their issues are not addressed, they may then escalate to a public call for a no confidence vote.
> <strong style=color:#2aa198>Only one call for no-confidence, for one chair, may be in process at any given time.</strong>
> Priority shall be given to the first such vote to be publicly called.
> Any subsequent public calls must wait until any previous recalls are resolved, then must start with private communication as described above.
<p><strong style=color:#dc322f>ISSUE: Replaces a 5 participant call for immediate and sweeping [re-]election with a 30-day mandatorily private process and only allows one at a time.</strong></p>
<p><strong style=color:#dc322f>ISSUE: Removes language referring to W3C Community Development Lead's involvement in election process.</strong></p>
<p><strong style=color:#dc322f>ISSUE: Gives chairs ability to bypass election.</strong></p>
$:header(3, "fd6ad39", "merge core language from fep-37f2 into cg charter template", ["bumblefudge", "dmitrizagidulin"])
#### Change (addition emphasized)
> It is expected that participants can earn Committer status through a history of valuable <strong style=color:#2aa198>discursive</strong> 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).
<strong style=color:#dc322f>ISSUE: Increases ambiguity of "Committer".</strong>
$:header(4, "95793e3", "Assessing consensus in the CG Charter", ["evanp", "dmitrizagidulin"])
#### Removal
> Groups are free to decide how to make decisions (e.g. Participants who have
#### Addition
> The Group makes decisions in the following ways: either Participants who have
#### Context
> 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]
<strong style=color:#dc322f>ISSUE: Ambiguous which of the three decision making mechanisms is used. Doesn't track with justification in Issue #[30](https://github.com/swicg/potential-charters/issues/30).</strong>
