blog.rust.gay

Git considers a vote to settle its LLM contribution policy

2026-11-10 · git llm open-source governance

Git has been debating LLM assisted contributions for over a year now. It seems to not be converging. On November 9th, LWN reported that the project is exploring a formal voting process to resolve it. The actual artefact isn't a policy. It's a process. It's a documentation patch by Emily Shaffer, posted on October 21st to the mailing list. It introduces Documentation/CommunityVoting.adoc and details how Git would gather and count a vote if consensus isn't reached. No vote has been triggered. There's no ballot. The AI policy hasn't changed.

One caveat about sources. Until November 19th, 2026, the LWN article is subscriber-only. So all you can read today is the first paragraph. The first paragraph clearly states the claim. The project "which is not a democracy from the get go" is considering a voting process to reach an acceptable conclusion. Everything else in this post comes from the public mailing list threads linked in the article. (These are the actual records. The September Contributor Summit notes, Shaffer's patch and its review. Also, the other policy proposal posted two weeks earlier.) Below are quotations from the relevant messages.

What Git's policy says today

The existing rule is in Documentation/SubmittingPatches. It's in a section called "Use of Artificial Intelligence (AI)". It was added by Christian Couder in commit 7b0c37953d on October 1st, 2025. It was tightened during the review process. The key sentence is very direct.

We will reject anything that looks AI generated. Anything that sounds overly formal or bloated. Anything that looks like AI slop. Anything that appears good but doesn't make sense. Anything that senders don't understand or can't explain.

This is a test based on appearance. It's a conservative approach. The same section also suggests using AI gradually, for debugging, and pre-send self-review. So, the contributor is left in an awkward position. They're allowed to use the tooling. But if they disclose significant use, they risk rejection. This was a point raised in RFC by Scott Chacon. Posted on October 7th, 2026. "Our current policy is to use AI carefully. Then we'll reject anything that looks AI generated. So, someone with a useful reviewed patch may wonder if we'll reject it if they tell us how they made it."

That text is unaffected by Shaffer's patch. Instead she introduces a new document. Documentation/CommunityVoting.adoc. It adds a "Formal Voting" section to Documentation/DecisionMaking.adoc. And it integrates the new file into Documentation/Makefile. As a technical doc. In her cover letter, she's explicit about the scope. "With this patch I'm trying to outline just the process of collecting the vote. NOT a proposal for the AI contribution policy itself." The rationale is also very clear. The AI issue is "very contentious". She doesn't think the project will achieve general consensus in the usual way.

There are three stages in the draft process. First, proposal collection. Anyone eligible to vote can submit a proposal. The proposal is a patch to Git's documentation. So, it can be reviewed as code. If it's accepted, it can be merged. In order to make it to the ballot, the proposal needs to be seconded by a second eligible voter. They do so with a Seconded-by: trailer. This avoids filling the ballot with noise. The idea is to have this phase last about four weeks. The kickoff mail will indicate the closing date. Second, the voting period. Two weeks. Mail-based. The proposals are frozen during this time. Third, implementation. The winning proposal is merged by the maintainer "without delay". The commit message will include a link to the discussion thread. It'll also include the outcome.

There are two placeholders in the draft process. One is for the eligibility rule. Most of the review has focused on these. It's not design. The document says "Votes will be decided using <mechanism TBD>". And the first version of the eligibility rule is explicitly provided as a starting point.

Why consensus stopped working

The Contributor Summit notes help explain the deadlock better than any summary of positions. On October 6th, Taylor Blaut posted the 2026 Contributor's Summit notes to the list. It's seven replies. So each topic can be discussed separately. The AI contribution policy is in part six. The notes are discussion notes. Not a transcript. But Blaut makes this clear. Still, they capture who said what.

The starting point was DCO. Elijah Newren quoted SubmittingPatches. Developer's Certificate of Origin. Contributors must declare they understand the origin of their contribution. They must declare they have the right to submit it. It's unclear if that's possible for AI generated output. From there, the discussion circled around two different concerns. They're often confused.

One concern is provenance. brian m. carlson argued AI-written code implicitly uses other people's code. When he contributes to open source, he's credited as the author. But when it's generated code, the credit is less clear. Junio Hamano and Blaut both pointed out that human authors also learn from code with incompatible licenses. And we don't ask them to justify everything they've read. The notes also mention the project asked the Software Freedom Conservancy's lawyers. "And the answer is what's in SubmittingPatches."

The other concern is volume and reviewer time. Jeff King explained the pattern he's observed. "We are seeing more contributions where an agent makes the changes. And a person is acting as a 'meat proxy'". In the notes, Shaffer replied. "Those proxies are getting thinner". Patrick Steinhardt objected to relaxing anything. "It would open the door for even more contributions to come in." Later on the RFC thread, carlson wrote that the project is "already underwater on the security list. Because of the flood of LLM-assisted bug reports". Many of them are questionable. Shaffer linked it to the 2025 Google Summer of Code. They had a record number of poor quality contributions.

They also discussed the idea of a comparative approach. This works both ways. Blaut: "Linux kernel is much more permissive than we are." King: "We think we're gonna get sued. But the rest of the world doesn't seem to." Steinhardt responded to the legal risk framing. Git doesn't need to copy Debian's proposals. But it does need to follow its own counsel. King suggested the next steps. Work out the options for voting. Get it past SFC counsel. Explain the risks. Then vote.

Shaffer's process patch was preceded by the competing policy on the list. Chacon's RFC was posted on October 7th. It replaces the appearance test with concrete obligations. Review and understand the entire submission. Test it. Meet the existing DCO and license requirements. Include an Assisted-by: trailer for significant assistance. This trailer should describe what the tool did. Also, how it was validated. It mentions Linux's generated content and coding assistant documents. It mentions Xen's Assisted-by approach. It mentions Debian's general resolution from August 2026. It mentions SFC's recommendations from 2026. The example trailer is Assisted-by: OpenAI GPT-6 Astra.

The replies to the RFC help articulate the opposite view. Hamano: The only thing we can promise is "that an OpenAI model produced plausible sounding utterances". The proposed text is "just a little more than 'the world would be a wonderful place if everybody behaved this way'". carlson: If they get a chunk of their MIT/BSD licensed code in Git without the copyright notice. Because it's been laundered through a model. They'll file a copyright complaint. Steinhardt: If we loosen the policy without first addressing reviewer capacity. "It'll just make an existing problem significantly worse." Hamano wrapped up the subthread with "Well articulated. Nothing more to add."

Reading both threads together, it's easy to see why there was interest in a vote. It's not a debate about whether models produce good code today. It's about whether you can honestly certify a DCO for generated output. And it's about who bears the cost of reviewing more patches that are plausible. These are value questions as much as technical ones. And value questions don't get resolved by the maintainer merging a patch series.

Who counts as the community

The eligibility rule is the most vulnerable part of the proposal. Because it determines whose preferences are reflected in the outcome. The draft says: Contributors that have authored a commit merged to next or provided two or more code reviews are welcome to vote. And that they're not banned. All votes are equal. To avoid last minute packing, contributions must be submitted before the kickoff mail.Hamano's review objected on two grounds. The bar is low, especially the review count, because there is no practical way to reject a reply that says "thanks, I like the feature" without reading the patch. And next is the wrong yardstick, since patches that were in next a few releases ago are hard to track: "I would suggest strongly against using 'next' as a yardstick." He proposed counting topics in released versions instead, then simplified further to five commits, because commits are easier to count than topics. His summary of the principle is the line the thread keeps returning to: "we should instead limit ourselves to 'each of you gets one vote, and this is the simple rule to tell if you can vote.'"

Others wanted the rule to reflect current involvement. Phillip Wood suggested requiring contributions within the previous two years, partly to reduce administration when someone's address has changed, and partly because of what he saw during the default-branch-name debate: "Having seen how much time and energy people, with no real interest in contributing to git, put into posting to the list ... I think we should be careful to limit the potential for bad actors to try and derail the vote." Justin Tobler agreed the bar was too low but worried about the other tail: too strict a rule biases the electorate toward the most active contributors, who tend to be paid to work on Git. carlson wanted a threshold high enough that "people are not incentivized to contribute only to vote", without committing to a number.

King then supplied the numbers that turned the argument into parameter tuning. From git shortlog -ns --no-merges, there are 44 people with 200 or more commits, 133 with 50 or more, 439 with 10 or more, and 2,388 with at least one. He also produced an intersection table of total commits against recent activity:

total    | Active in the last N years
commits  |  N=1    N=2    N=3    N=5
-------------------
    200  |   17     22     24     30
     50  |   34     47     56     67
     10  |   71    104    124    155
      1  |  239    357    457    628

He was candid that the 50 in the summit notes was not a considered figure: "the number 50 was made up by me on the spot. So I wouldn't read too much into it." Steinhardt's reading of the table balanced the two failure modes — a low bar skews the vote toward newcomers, a high one toward long-term contributors who are often employed to work on Git — and landed on 50 commits with activity in the last two or three years, or 25 to 30 commits as a middle ground. Tuomas Ahola computed the mean commits per author, 25.7, and suggested 25 to 30 for that reason.

Shaffer's own summary on October 30 conceded the point without defending the draft: "Universally, people don't like my proposed limits - that's fine, I didn't think very hard about them because I assumed that there would be a lot of discussion on the parameters." She also disclosed her own interest, noting she has not had capacity for meaningful code contributions for several years because of her role at Google but still considers herself a community member and would like to vote. Hamano's reply to that was a one-line correction with a broader point behind it: "Drop 'code'. Documentation contributions do matter." He went on to ask for a way to measure non-patch contributions — reviews, IRC and Discord support, correcting users' mistakes — in the past N years, alongside commit counts.

The unresolved question is whether the roll can be algorithmic at all. King's suggestion was to accept that it cannot be perfect and add a human override: a metric that gets 99% of the way there, plus Junio or the PLC naming additional voters, with Steinhardt's condition that any such list be published well before the vote, with reasons, so it can be challenged. Wood's counterargument was that exclusions are not obviously wrong: an informed vote often requires context that a decade-old contributor no longer has.

Secrecy, employers, and the dogpile problem

Two design questions have drawn more heat than the thresholds: whether the ballot is secret, and what software runs it.

The secrecy argument started from a claim by Kristoffer Haugsbakk that the result is predetermined: "The vote will pass. Those who work on Git at least once a month work for tech companies. Those tech companies are now AI companies. The votes will happen to drift towards agreement with their management." carlson answered personally — they do not parrot an employer's line from a personal account — but agreed on the mechanism, arguing that secret votes "prevent people from having to prove their votes to others". Steinhardt put it in terms of retribution: "I strongly feel like the vote needs to be secret, so that voters feel free to voice their honest opinion even if it was different to their employer's stance. I don't want anyone to fear any kind of retribution." Haugsbakk later narrowed the claim to paid, regular work on Git and to aggregate drift, which is a fairer version of it and still an argument for a secret ballot.

Shaffer accepted the change. In her October 30 summary of what she would carry into a reroll, the second item is "Make explicit the requirement for secret votes", alongside renaming the document from "propose" to "specify" a voting process, per Hamano's note that a merged document defines the process rather than proposing it.

The platform question is unresolved. The draft named no mechanism, and Shaffer's follow-up listed three candidates: Debian's devotee, which needs hosting and neutral hosting is hard; CIVS, which the Linux Foundation's Technical Advisory Board has used, and which she believed could be used as a hosted service; and a GitHub poll, which she and carlson both effectively ruled out, since it gives only a simple majority and requires GitHub accounts, against the project's long-standing forge neutrality. CIVS and devotee both tally with Condorcet-family ranked methods, which suits a ballot with several similar proposals better than a yes/no question. Jonathan Corbet added first-hand experience: he ran TAB elections on CIVS and found it "a bit of a vulnerability - depending on a free service run by an unrelated party", while noting that running a private instance for occasional polls is probably overkill, and that CIVS requires voters to sign up before it will notify them. On November 9, Stéphane Glondu suggested a fourth option, Belenios, which supports Condorcet voting and has a Debian-run instance, or can be deployed elsewhere.

The dogpile concern is what the eligibility freeze is for. Shaffer's framing: "Git is a very well-known project and there will be a lot of big opinions on the open internet once people know we're voting on this policy. I want us to measure the opinions of those who participate in the project, not the opinions of random passers-by." Haugsbakk argued the fear is overstated, since a flood of voters would all need prior contributions; Wood thought the risk real enough to justify a time window. Neither position can be tested before the first ballot, which is itself an argument for keeping the first vote's stakes low.

What a vote can and cannot settle

The summit notes contain the sentence that explains why this is delicate for Git specifically. Asked how a vote result would be enforced, King's answer was: "Junio is the source of authority, and usually follows the crowd." There is no constitutional mechanism behind the ballot. The winning proposal gets merged because the maintainer merges it, and its authority afterwards is the same as any other documentation in the tree: a written statement of what the project has agreed to, which reviewers and contributors can point at.

That is not nothing. Debian's August 2026 resolution is the model being borrowed, and its practical value was exactly this — a written answer that ends per-thread relitigation. But the Git version has three soft spots. First, the process document itself has to be approved, and Shaffer proposes doing that the way the Code of Conduct was handled in 2019: discuss, reach rough consensus, collect Acked-by: trailers, and merge. If that consensus fails, there is no vote to decide whether to have votes. Second, the AI policy question will not stay settled; Shaffer says as much, arguing the process should be checked in because "it seems likely to me that we will want to revise the AI policy again given the pace of development". Third, a ballot decides which text wins, not whether the underlying concerns were answered. A vote for a permissive policy does not resolve the DCO question carlson raised, and a vote for the status quo does not create review capacity.

Hamano's endorsement of the draft's scope is the part most likely to survive review unchanged: he liked that it "prevents us from putting technical decisions to a vote, reserving voting strictly for policy decisions." The draft says voting is a last resort, initiated with the general agreement of the Git PLC or the primary maintainer. Technical judgment stays with the maintainer and the list.

For contributors, the practical consequences are concrete. If you want a say in the AI ballot, the draft's eligibility rule means your commit or review has to land before the kickoff mail, not during the campaign; two reviews might be enough under the current text, and might not be after the reroll, so the safe assumption is that the bar goes up rather than down. If you want to shape the options, proposals are patches to documentation, they need a second, and they will be reviewed like code. Abstaining is expected to be possible, which matters for people who have opinions about the process but not about the policy.

For maintainers and distributors, the more useful signal is that the project is treating this as a governance problem rather than a tooling one. The SFC's counsel is in the loop for the options, per King's proposal at the summit, and the DCO is not being renegotiated. Whatever the ballot produces, SubmittingPatches will still be the file contributors read, and its current text — reject what looks generated — remains in force until a merged patch says otherwise.

What to watch

Shaffer said she would be away until roughly November 12 or 13, then intended to draft the reroll from the list of changes and open questions she posted on October 30. That reroll is the next real event: it will show whether secret ballots, Message-ID-based proposal references, and a higher eligibility bar can be written into a document that gets Acked-by: consensus. After that comes the harder question of whether a ballot is actually called, and on what timetable — the summit notes have Git 3.0 pencilled in for spring 2027, and a policy fight running alongside a major release is not obviously an improvement over the mailing list.

Two numbers will decide how much the result means: the eligibility threshold, somewhere between 25 and 50 commits by the sound of the thread, and the turnout among the several hundred people who qualify. A vote that 40 people participate in settles the text and not the argument. The argument, after all, was never only about code quality. It is about whether a certificate of origin can be signed in good faith for output nobody can trace, and about who reviews the next thousand patches. No tally answers either.

Sources

← back to posts