[PATCH] Documentation: propose community voting process

[Emily Shaffer <emilyshaffer@google.com>]

Not all discussions can be settled by community consensus. For truly
contentious decisions we need a way to democratically make a decision
that represents the majority will of the project. This doc outlines the
methodology we use in the rare case where we need to vote to make a
decision.

Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
---
Hi folks,

Thanks for your patience with this taking much longer than I expected or
wanted it to.

As we discussed in the Contributor Summit this past September[1], there's
interest in taking a formal community vote to decide whether and how to accept
AI contributions. The topic is of course a very contentious one, and I don't
think that we're going to come to general consensus the way we have on most
other concerns in the past.

With this patch I'm trying to outline only the process for collecting the vote,
NOT a proposal for the AI contribution policy itself. I'm interested in making
sure that the Git community is able to be heard fairly, and that we don't end
up dealing with tampering during the voting process (e.g. non-contributors
dogpiling to shift the vote one way or another

I expect the approval of the voting process itself to be fairly non-contentious
(or else I haven't managed to write a fair process!) so for approving the
voting process, I suggest we use a similar approach to the one we did with the
Code of Conduct back in 2019[2][3]: discussing the process itself, ultimately
coming to general consensus, and collecting a list of Acked-by: to put onto the
commit outlining the voting process. And by the way, I do think that we should
check in the voting process; it seems likely to me that we will want to revise
the AI policy again given the pace of development, and it may be useful for
other discussions that we've had trouble resolving in the past.

BTW, there are some parts of this proposal that I still don't have a good
answer for, so look for my self-review immediately to follow, highlighting open
questions.

[1]: https://lore.kernel.org/git/summit-2026.94e33e9ddf234334.06@ttaylorr.com/
[2]: https://lore.kernel.org/git/20190924064454.GA30419@sigill.intra.peff.net/
[3]: https://github.com/git/git/commit/5cdf2301d4a8b439f89fd2cdfed13736ccd64a30 

---

 Documentation/CommunityVoting.adoc | 100 +++++++++++++++++++++++++++++
 Documentation/DecisionMaking.adoc  |   6 ++
 Documentation/Makefile             |   1 +
 3 files changed, 107 insertions(+)
 create mode 100644 Documentation/CommunityVoting.adoc

diff --git a/Documentation/CommunityVoting.adoc b/Documentation/CommunityVoting.adoc
new file mode 100644
index 0000000000..155acc9777
--- /dev/null
+++ b/Documentation/CommunityVoting.adoc
@@ -0,0 +1,100 @@
+Voting in the Git Project
+=========================
+
+For the most part, technical concerns in Git should be resolved by community
+consensus - either on the mailing list or in one of the annual-ish Contributor
+Summits. Voting should be used as a last resort when the community really and
+truly cannot come to a compromise on a policy decision. As such, the initiation
+of a vote should be generally agreed on by the mailto:git@sfconservancy.org[Git
+PLC] or primary maintainer.
+
+The voting discussion should be held to a single (huge) thread, to make it easy
+to refer back to the decision process when looking at the successful proposal
+after the process concludes. The thread may be structured like so:
+
+--------
+Formal vote: Commit subject line style guide
+  Re: Formal vote: Commit subject line style guide
+  ...
+  [PROPOSAL] Require emojis in commit subjects
+    Re: [PROPOSAL] Require emojis in commit subjects
+    [PROPOSAL v2] Require emojis in commit subjects
+      Re: [PROPOSAL v2] Require emojis in commit subjects
+      ...
+          [PROPOSAL v4] Require emojis in commit subjects
+  [PROPOSAL] Require Camel Case In Commit Subjects
+    Re: [PROPOSAL] Require Camel Case In Commit Subjects
+    [PROPOSAL v2] Require Camel Case In Commit Subjects
+  [PROPOSAL] forbid capitalization in commit subjects
+  ...
+--------
+
+A formal vote has three phases:
+
+1. Proposal collection and refinement
+2. Voting window
+3. Implementation
+
+Phase 1: Proposal collection and refinement
+-------------------------------------------
+
+Proposals should be formatted as a patch to Git's documentation, for easier
+review and implementation once landed. Anyone who is eligible to vote is
+eligible to submit a proposal. To avoid noise on the final ballot, a proposal
+will only be added to the ballot if it has been seconded by another eligible
+voter, indicated by a `Seconded-by:` footer in the patch's commit message.
+
+After the first draft of the proposal has been sent, the community is
+encouraged to discuss and polish the proposal, just like any other code review.
+Keep in mind that these proposals still need to be voted on, so it is likely
+counterproductive to use the discussion period to try to completely change the
+nature of the proposal or the mind of the author.
+
+This phase should last around 4 weeks in order to provide plenty of time for
+community members to write proposals and respond to feedback, and make space
+for contributors' individual timezone and availability differences. The
+maintainer or PLC member who sends the kickoff message should also include the
+closing date for proposal collection.
+
+It may also be useful to invite expert feedback during this time, e.g. from
+Software Freedom Conservancy's legal counsel, depending on the topic under
+consideration.
+
+Phase 2: Voting window
+----------------------
+
+The final version of each seconded proposal will be collected into a ballot at
+the end of Phase 1. When the ballot is prepared, eligible voters will be able
+to vote by mail for two weeks, to make space for contributors' individual
+timezone and availability differences. During this time the proposals may no
+longer be altered; the ballot should refer to a specific version of the
+proposal (e.g. `[PROPOSAL v4] Require emojis in commit subjects`) and any later
+version of the proposal will be ignored.
+
+Votes will be decided using <mechanism TBD>.
+
+Phase 3: Implementation
+-----------------------
+
+When the voting window ends, the winning proposal should be merged to `main`
+without delay by the maintainer. The commit message should be appended to
+include a link to the top of the voting discussion thread so that the
+discussion can be revisited by history divers in the future, as well as a brief
+summary of the result of the vote (% in favor out of total number of
+proposals).
+
+Voting Eligibility
+------------------
+
+Votes are welcome from contributors who have authored a commit which has been
+merged to next, or who have provided 2 or more code reviews, and who have not
+been banned from participation in the project. All eligible contributor votes
+are weighed equally, regardless of the overall number of contributions they
+have landed.
+
+To prevent dogpiling, contributions are only eligible for a given vote if they
+landed before the beginning of the voting process (the kickoff email mentioned
+above). That is, the code reviews must have been sent or the patch must have
+been accepted before the initial email is sent. The intention is to ensure the
+mailing list isn't spammed with low-quality reviews during the voting process
+solely to increase the number of eligible voters on one side of the issue.
diff --git a/Documentation/DecisionMaking.adoc b/Documentation/DecisionMaking.adoc
index b43c472ae5..c08fb7abd5 100644
--- a/Documentation/DecisionMaking.adoc
+++ b/Documentation/DecisionMaking.adoc
@@ -72,3 +72,9 @@ We prefer that "official" discussion happens on the list so that the full
 community has opportunity to engage in discussion. This also means that the
 mailing list archives contain a more-or-less complete history of project
 discussions and decisions.
+
+Formal Voting
+-------------
+When a decision cannot be reached by general consensus or compromise, a formal
+vote may be called. See link:CommunityVoting.adoc[Community Voting] for details
+of this process.
diff --git a/Documentation/Makefile b/Documentation/Makefile
index f8dea4b395..314b8dc8f5 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -113,6 +113,7 @@ SP_ARTICLES += $(API_DOCS)
 
 TECH_DOCS += BreakingChanges
 TECH_DOCS += DecisionMaking
+TECH_DOCS += CommunityVoting
 TECH_DOCS += ReviewingGuidelines
 TECH_DOCS += MyFirstContribution
 TECH_DOCS += MyFirstObjectWalk
-- 
2.56.0.rc1.315.gc6ed9934b7-goog