Notes from the Git Contributor's Summit, 2026

Notes from the Git Contributor's Summit, 2026

[Taylor Blau]

Thanks to everybody who participated in this year's Contributor's
Summit, and to the folks who took notes during the discussions.

I'm sharing the notes here so that people who could not attend can catch
up, and so we can continue the discussions on the list. The shared notes
are also in Google Docs:

  https://docs.google.com/document/d/15gDNTjCh9-aQ1ES2MDot5_Qnxj6vRMGwxbH7eixxT84/edit

The topics covered in the replies below are:

 - Security mailing list and security process
 - Git 3.0
 - Documentation
 - Outreachy sponsorship
 - What can we do next with pluggable ODB?
 - AI contribution policy
 - Protocol v2 for pushes

I've lightly edited the notes for readability and kept the speaker
attributions. These are discussion notes, rather than a verbatim
transcript; please reply with corrections or anything the notes missed.
Release dates and reports of work in progress reflect the discussion at
the summit.

Each topic has its own reply to this message so that follow-up
discussion can stay with the relevant notes.

If you have feedback about the summit itself, please share it here or
with me off-list.

Thanks,
Taylor

[NOTES 01/07] Security mailing list and security process

[Taylor Blau]

Topic: Security mailing list and security process
Leader: Toon Claes
Notetaker: Peff

* Toon: We have a high influx of reports on the security list from
  outside the community, probably from people using AI. There are many
  unaddressed reports. We need a better process for addressing them, and
  to figure out who will do the work.

* Emily: How are we cutting security releases now? Are we waiting for
  the reports to stop before cutting a release?

* Taylor: There are many reports we still need to triage and determine
  which are important.

* Toon: I have been organizing the reports, and some patches have been
  sitting around for months.

* Patrick: Eventually we have to cut a release, because the influx will
  not stop.

* Peff: We should act on what we have triaged once we have enough for a
  release.

* Patrick: We get many duplicate reports from AI findings. We should be
  more willing to cut releases, with a well-defined timeline. We should
  document the process, perhaps in terms of a number of weeks after a
  report.

* Peff: I am hesitant to promise a response to reports within a fixed
  number of weeks.

* Patrick: We should try to rely on companies investing in fixes,
  without forcing volunteers to work on them.

* brian: We should document our security model. Many reports are not
  vulnerabilities, but explaining why takes work.

* Patrick: Documenting the model might also help AI tools respect it.

* Emily: Are we interested in following the Linux kernel's approach of
  not embargoing AI-found vulnerabilities?

* Patrick: I am worried about that because of vulnerabilities affecting
  forges.

* Taylor: It depends on the models; some are better than others.

* Patrick: We should fix non-security issues on the public mailing list,
  and be more proactive about moving reports there when nobody else
  replies.

* brian: Sometimes there is pushback about whether something is a
  vulnerability.

* Patrick: There should probably be a period after which it is assumed
  that a report can go public.

* Patrick: GitLab has put some resources into this, but I would like to
  see more from other companies.

* Emily: It has been difficult to get resources from companies. The
  response is often that AI could help with triage, but putting
  non-public knowledge into public AI systems feels risky.

* Taylor: We could consider using AI to help with triage and writing
  patches. It might be easier to get companies to sponsor the work if it
  is less arduous.

* brian: There are DCO questions, which I would like to leave for the AI
  discussion. At GitHub, Elijah is our only person in git-contrib. There
  is more work than we have staff for, and corporate email requirements
  make list work difficult.

* Peff: We can coordinate in the cabal repository.

* Patrick: Could we put money into a fund to pay somebody to work on
  security, perhaps using AI, and get ahead of the findings?

* Martin: The project has a bucket of money.

* Taylor: I do not have the exact figure, but probably around $100k.
  Would we hire a third party, or somebody from one of the companies?

* Patrick: We probably need somebody from the project.

* Emily: Why is there resistance to hiring a third party?

* Peff: I am skeptical because the onboarding cost and time might be
  substantial.

* Emily: There are contracting firms suited to open source. We have been
  happy with Collabora, and I am happy to explore similar options,
  though it costs a bit more.

* Adrian: Such projects are hard to pitch internally. We do address
  security issues in other projects, but at a normal rate of $200/hour,
  a $100k project is difficult to pitch.

* Peff: Toon has already made a list, and we have fixes. Can we make a
  release with what we have? The list may not be as long as we think.

* Patrick: Can we write down the process, and perhaps automate it?

* Taylor: It is not primarily a scripting issue. We need to assemble the
  required tags and have the confidence to say we have enough to cut a
  release. We should discuss it on the list. The list of reports is long
  enough that we may never get through all of it.

* Patrick: We should get more comfortable with faster releases.

* brian: Anyone should be able to propose a new release.

* Patrick: We can try to accommodate different release schedules, but
  eventually we should put our foot down.

* Taylor: Microsoft needs around seven weeks for a release.

* brian: Microsoft needs to provide staffing if it wants a particular
  schedule.

* Taylor: Does anybody object to telling Microsoft that we will not
  follow its schedule?

* [No objections recorded.]

* Patrick: Agreed. Who wants to tell them?

* Taylor: I do not want to make an ultimatum about adding resources.
  They might add a third party that does not work well with us and still
  stick with Patch Tuesday.

* Peff: I had hoped to goad Toon into handling a release.

* Toon: OK, but I mostly do not know how.

* Patrick: That is a general problem: the process is not documented, and
  we need to figure it out.

* Peff: I will see if I can dig up the resources I remember. Is it OK to
  discuss the process on the public list?

* [General agreement that discussion on the public list is OK.]

* Peff: I will write an email to the public list to start the process
  discussion.

* Taylor: Johannes, Junio, and I should contribute our experience.

* Patrick: Would scripting make it easier?

* Taylor: No, it is the work of merging fixes up through the versions.

* Junio: Fixes do not always apply to both old and new code.

* Peff: There is also the work of writing security advisories and
  obtaining CVEs.

[NOTES 02/07] Git 3.0

[Taylor Blau]

Topic: Git 3.0
Leader: Patrick Steinhardt
Notetaker: Justin

* Patrick: The blocker was GitHub not having SHA-256 support. When will
  GitHub fully support it?

* brian: GitHub has shipped it experimentally, with general availability
  probably in November.

* Patrick: GitLab already has public, non-experimental support. We are
  looking at spring next year for Git 3.0. libgit2 has support; JGit
  does not.

* Emily: Google will not fund SHA-256 support in JGit.

* brian: It does not look like Bitbucket will support it.

* Emily: Gitoxide may have funding for SHA-256 support.

* brian: There will be a couple more releases: 2.56, then 2.9x, and so
  on.

* Taylor: We could use 2.99 and then 2.999 if needed.

* Patrick: 2.99 would be a stronger signal than 2.95.

* Peff: Why might users not want to jump to 3.0? Rust support will be
  mandatory.

* Patrick: A possible schedule is 2.56 in September 2026, 2.98 in
  December 2026, and 2.99 and 3.0 in March 2027. We need to find out
  whether anybody is interested in an LTS release.

* brian: Gentoo would be interested in a 2.99 LTS release.

* Patrick: We could potentially cut out one of the releases.

* Peff: We could make one of the cycles shorter.

* Taylor: The 3.0 release could be small, containing only the changes to
  the defaults.

* Patrick: The counterargument is that we want to use 2.99 as a signal.

* Peff: We should release 2.99.1 and 3.0 at the same time, with only the
  BREAKING_CHANGES defaults flipped in 3.0.

* [Consensus among the attendees.]

* brian: Are there any objections to Rust in 3.0?

* [No objections recorded.]

* Peff: Are there timing concerns around distribution release cycles? We
  might want to synchronize with them.

* brian: If we do 2.99 and 3.0 back to back, that puts us in the April
  timeframe.

* Patrick: Do we want to drop 2.57?

* [The notes record dropping 2.57 in favor of an earlier 2.98.]

* Peff: GitHub might encounter bugs once users start using SHA-256.
  Would we see similar bugs in Git?

* brian: Codeberg exposes this in its UI, and has a decent number of
  users.

* Patrick: GitLab has test suites covering this, and we have upstreamed
  a few fixes. I am confident there are very few bugs.

* Patrick: Should we migrate?

* Taylor: I may be a little behind on the interoperability work. Would
  it also handle historical tags?

* brian: Yes. The work is done, but not on the list. You can clone a
  normal SHA-1 repository and get interoperability with SHA-256.

[NOTES 03/07] Documentation

[Taylor Blau]

Topic: Documentation

* Julia: There is a big gap between contributors who know Git's concepts
  and users who do not know what objects or the index are. I have been
  working on a website to bridge that gap. We do not explain some basic
  terms, such as "upstream". Some documentation receives hundreds of
  comments. How can we bring that feedback to the mailing list without
  overwhelming it, and improve the documentation with very little
  funding?

* Patrick: Could we expand the funding? This work is important, and we
  are not technical writers.

* brian: We have gitglossary and the Pro Git book, but it would be good
  to have beginner documentation. Many users arrive from university
  without knowing these concepts. I have submitted some documentation in
  this area.

* Patrick: Pro Git may be outdated in places. Scott wants a new version
  and could fund somebody to work on it.

* Emily: We can suggest a huge book to somebody who is new and just
  wants to use Git.

* Peff: The manpages are reference material, so they should be terse.
  Most users also need something less terse. If somebody is interested
  in working on this, we should consider replacing outdated
  documentation rather than preserving it for its own sake.

* Patrick: We should allow iterative work. Review can be nitpicky, but
  perhaps we can be more accommodating so this can move faster.

* Julia: Being able to merge quickly and iterate would help.
  Mailing-list feedback is useful.

* brian: Thank you for working on the documentation. Bad documentation,
  or no documentation, makes software hard to use.

* Patrick: Terse does not necessarily mean accessible. We could learn
  from TLDR and include examples.

* Julia: Examples are useful, and we should update the existing ones.

* Josh: We could consider Diataxis, which separates tutorials, guides,
  explanations, and reference material:
  https://diataxis.fr/

* Julia: The format of the reference manpages makes sense.

* Peff: I did not mean to defend the manpages. New-user documentation
  and manpages are two separate things, and both need work.

* Julia: Git has guides and manpages, which is a useful separation. The
  guides are harder to discover; the manpages are more accessible.

* Patrick: How much time do you have funding for?

* Julia: We have 100 hours split between two people.

* Patrick and others: Perhaps we could use the Git fund.

* Peff: Other companies might also be interested in funding the work.

* [OpenAI, GitHub, and GitButler were mentioned as possibilities.]

* brian / Emily / Mark: We can ask about funding.

* Mark: We have both machine-readable and human-readable material.

* Toon: We are only discussing written documentation.

* Peff: Costs can escalate with video. I am biased toward written
  documentation.

* Patrick: GitButler has resources, and younger users may prefer videos.

* Julia: We could link good Git videos from the website.

* Emily: There are links on Discord that we could include.

* Julia: We do not have a good entry point on the Git website explaining
  how to learn Git.

* Peff: The site had one, but it gets outdated. We should refresh it as
  we go.

* Julia: Some documentation says "see section XYZ" without linking it.
  We cannot link to subsections of manpages.

* Peff: I spent some time generating subsection links.

* Julia: We have links to other pages, but not to subsections.

* Peff: References in the text need the linkgit markup. This could be an
  incremental project.

* Julia: I added a cheatsheet to the website. Do we want to move away
  from ASCII diagrams?

* Patrick: Could we use different sources for different outputs, with
  SVG for HTML and ASCII for manpages?

* brian: We could do that.

* Patrick: Perhaps Mermaid would let us keep a plain-text source and
  choose the output format.

* Julia: It should be possible. We have CI scripts that Johannes worked
  on, and we used Graphviz.

* brian: There are extensions, but they are not packaged for
  distributions.

* Peff: We support both AsciiDoc and Asciidoctor. Would it help to get
  out of that dual world?

* Patrick: Traditionally this was for migration. AsciiDoc was thought to
  be unmaintained, but it is maintained now.

* Peff: We could move to Asciidoctor.

* brian: Fedora still uses AsciiDoc. Asciidoctor is well maintained,
  written in Ruby, and reasonably portable. It depends on how much we
  want to support. I do not know whether Fedora is still an obstacle.

* Peff: Who would object to moving, and how strongly?

* Junio: We could include it in Git 3.0 and add it to BreakingChanges.

* Josh: Some documentation already renders poorly with old versions of
  AsciiDoc.

* Peff: Send those bugs to the list; somebody may be interested in
  fixing them.

* Josh: We could use this to fix the build pipeline and move away from
  AsciiDoc.

* Patrick: Fedora does have Asciidoctor, version 2.0.26.

* Peff: I tried Asciidoctor on Debian, and it works well. There are some
  rendering issues, though it mostly gets things right. Julia, would you
  be interested in using doc-diff to compare the outputs?

* [Patrick created an issue during the discussion.]

* Emily: Do we have traffic metrics for git-scm.com?

* Taylor: Some high-level metrics in Cloudflare.

* Peff: We had Google Analytics, but were not comfortable with it and
  removed it.

* Emily: It would be useful to know how many users read the
  documentation.

* brian: It would be useful to know which manpages people read, while
  being mindful of privacy as an open-source project.

* Taylor: Could we self-host metrics, or use a third party that supports
  this?

* Mark: Fathom is one privacy-focused option:
  https://usefathom.com/

* brian: Even webserver logs would be useful for getting some numbers.

* Peff: On Heroku, the caching layer meant we did not see accurate
  numbers.

* Patrick: Will AI scrapers drown out the useful signal?

* Toon: I opened an issue about this some time ago:
  https://github.com/git/git-scm.com/issues/2054

* Taylor: We enabled it, but did not see useful information.

[NOTES 04/07] Outreachy sponsorship

[Taylor Blau]

Topic: Outreachy sponsorship

* Chris: We want three interns, at $10k per intern. Are any companies
  interested in helping? The session starts in early December. GitLab or
  GitHub sponsored this in the past, but as of last year neither wanted
  to, so Git has had to pay.

* Patrick: Talk to GitLab's contributor success person.

* Elijah: We need to identify the right person to ask.

* Emily: I can ask Google's OSPO whether there is interest, though I am
  not expecting much.

Git Merge 2027:

* [There was some interest in holding Git Merge in Canada, given the
  political climate.]

* [Announcing the location early would help Outreachy and GSoC interns
  who want to attend.]

[NOTES 05/07] What can we do next with pluggable ODB?

[Taylor Blau]

Topic: What can we do next with pluggable ODB?

* Emily: We saw this working in Patrick's talk. What do we want to do
  with it next?

* Patrick: Most things work, but we are not all the way there yet;
  commit-graph and MIDX are examples. The plan is to add a repository
  extension in 2.57.

* Peff: From the Mercurial talk, you can convince Git to make good
  deltas, but doing so has a cost. I do not think the ODB API is at a
  level where deltas can be created on the fly.

* Patrick: I think we can do that. They have information we do not have.
  Renames are tricky.

* Peff: The ODB does not know anything beyond the content. Could we give
  it more information?

* Patrick: We may want to evolve this based on the representation. We
  could pass a `struct commit *` into the ODB API instead of just
  content.

* Peff: What we have now is a reasonable stopgap.

* Patrick: Content-defined chunking is another possibility.

* Taylor: Would that be at the object layer, or a property of a
  particular ODB store implementation?

* Patrick: I would like to do it natively, but that seems like a large
  change.

* brian: It could be part of a new pack/index format. I am very much in
  favor of content-defined chunking.

* Peff: There is a logical object model. Would this be a new object
  type, where a chunked object and a blob have different hashes, or
  something below that?

* Patrick: We could start at the storage layer and eventually move it to
  the object layer.

* Taylor: Perhaps, but perhaps not. This may be easier than we are
  thinking.

* Patrick: Moving the ecosystem may be difficult.

* brian: We could have a compatibility fallback.

* Peff: Then we would have two equivalent representations of an object
  which do not hash to the same thing.

* brian: We could introduce a pack-only object type.

* Peff: Which OID would I refer to?

* brian: The blob's OID.

* Taylor: That is analogous to REF_DELTA and OFS_DELTA: multiple
  representations of the same thing.

* brian: We would need a format extension, because we are out of bits.

* Patrick: Would we still want to put it in a pack?

* brian: Yes.

* Patrick: Start with the storage layer, then see where it goes.

* Patrick: Would this only be for blobs?

* Taylor: Is "chunked" a refinement of a blob, or an attribute
  independent of object type?

* brian: Trees are not currently binary-searchable. It would be nice to
  fix that too.

* Patrick: Perhaps reftable could provide inspiration there.

* Emily: After Patrick's talk, my skip-level manager asked whether we
  could build a commit cloud with Git. What else could we do that is
  totally wild?

[NOTES 06/07] AI contribution policy

[Taylor Blau]

Topic: AI contribution policy

* Josh: What is the current AI policy?

* Elijah: [Reading from SubmittingPatches.] The DCO requires
  contributors to certify their contributions, and it is not clear
  whether they can do that for AI-generated output.

* Taylor: If we take AI out of the picture, is any of that inconsistent
  with how we already treat patches?

* brian: It often has a distinct character. It may get better, but
  currently it can be noticeable and awkward to read.

* Elijah: It is often useful for proofreading and improving writing.

* Emily: One thing missing from the policy is attribution. Johannes sent
  something with an Assisted-by trailer, which helps us understand
  whether and how a tool was used.

* Taylor: Would I review Johannes's patches differently if I knew AI was
  used?

* Emily: It is different for new contributors and people with whom we
  have established trust.

* Patrick: Sometimes knowing helps us avoid reading complete garbage.

* Emily: Having the policy in SubmittingPatches helps because people and
  agents will read it.

* brian: Many people do not read SubmittingPatches often, but honesty
  about where code came from is useful. Using AI for language cleanup is
  useful too.

* Taylor: The policy effectively says we cannot do anything significant
  with these tools.

* Peff: We are seeing more contributions where an agent makes the
  changes and a person acts as a "meat proxy".

* Emily: Those proxies are getting thinner.

* brian: The Linux kernel requires people to state that they have
  authority to submit the code.

* Peff: What is the rest of the open-source world doing? Are we missing
  useful tools by being conservative?

* brian: Some people will no longer trust us if we accept AI-generated
  code.

* Taylor: The Linux kernel is much more permissive than we are.

* Peff: We imagine that we will be sued, while the rest of the world
  does not seem to.

* Patrick: Opening the policy further would open the door to an even
  greater influx of contributions.

* Emily: That is why I want more attribution.

* brian: When I contribute to open source, I am attributed as the
  author. With AI-written code, I am implicitly using other people's
  code.

* Taylor: When I read code from a project with a license incompatible
  with Git's, I learn from it, and that knowledge may implicitly
  influence my work on Git.

* brian: That is a coherent position, but not everybody agrees. The
  project has to decide.

* Emily: Have we used a voting process for something like this before?

* Patrick: We need proposals and a vote. Who would be allowed to vote?

* Peff: Active developers with a track record; perhaps a threshold such
  as 50 merged patches.

* Taylor: We asked the SFC lawyers, and the result is what is in
  SubmittingPatches.

* brian: SFC is very American in its legal approach.

* Peff: We should give SFC more credit; it is more worldwide than that.

* Emily: This was a problem with GSoC. There was a record amount of
  contributions, but the quality was poor.

* Peff: We need to agree on a policy. Do we accept AI at all, and to
  what degree?

* Taylor: One possibility is a process similar to Debian's, with
  proposals and voting.

* Patrick: We need to follow legal counsel, and we do not need to use
  the same proposals as Debian.

* Peff: We got legal advice on the current text. We should work out the
  voting options, take them through SFC counsel, communicate the risks
  and concerns, and then hold the vote.

* Emily: I am happy to set this up. I have been doing something similar
  with Jujutsu.

* Peff: We depend on Junio. If people disagree with the policy, they
  could fork into Git-AI.

* Josh: Let a few key people put forward their opinions and see how much
  they differ.

* Patrick: Let us do that on the mailing list.

* Peff: brian, would you champion one position?

* brian: Sure. I will take some things from the Debian project.

* Peff: Taylor, would you put forward another position?

* Taylor: Sure, though I am not yet sure what it would be.

* Patrick: Then we need to decide what the vote would be.

* Martin: If there is a vote, how would the result be enforced?

* Peff: Junio is the source of authority, and usually follows the crowd.

* Peff: Emily, are you leading the voting procedure?

* Emily: Yes.

[NOTES 07/07] Protocol v2 for pushes

[Taylor Blau]

Topic: Protocol v2 for pushes
Notetaker: Emily

* brian: Some customers have millions of refs. Reftable has helped us
  push up to 100k at a time, which was a big increase. AI means more
  branches and refs, so the problem keeps getting worse. One customer
  was unhappy about an 896 MB ref advertisement. Protocol v2 for pushes
  would help. Much of the code already exists and needs wiring up.

* Peff: We were waiting for somebody with a use case they care about.
  Protocol v2 has a capability advertisement that leaves room for
  further extensions.

* Elijah: With fetch v2, it would be useful to request only a handful of
  heads rather than advertise all refs and tags.

* Jonathan Tan: We have prefix filtering for fetch v2. A client can
  request refs/heads/somename, and the server sends refs matching that
  prefix.

* Peff: The client needs a better refspec, and the user interface is
  hard. How do we specify the mainline? Even excluding HEAD can speed
  things up. This is an optimization; a push is correct as long as the
  objects are reachable.

* Peff: Could we use multiple passes, trying a smaller set and falling
  back to a larger one if some objects are still unreachable? Many
  advertised refs are not useful, such as abandoned development
  branches.

* [There was a related discussion about showing fewer refs in GitHub's
  UI.]

* Peff: Could a server-side configuration limit the advertisement and UI
  to a smaller set of refs, with the client ignoring the others?

* brian: It is useful to control what the client requests. During a
  push, we want to say that we care about only a handful of branches.

* Peff: That still sounds like a refspec problem; the default asks for
  too much.

* Jonathan Tan: This is push, though.

* Peff: The client could suggest useful branches more intelligently.
  Guessing the main branches is a heuristic, but upstream tracking
  branches might be useful.

* brian: A project setup script, perhaps linked from its documentation,
  could provide useful initial configuration.

* Jonathan Tan: Instead of a ref advertisement during push, it would be
  useful to negotiate. Restricting the advertised refs may cause the
  client to send everything if the optimization does not work. Relying
  on the remote to know what matters is error-prone. We would be happier
  with a few round trips: advertise capabilities, exchange haves and
  acknowledgments, negotiate the push, and send the pack.

* Elijah: During a repack, the server might give a false negative. This
  may be relevant to shallow clones.

* Peff: We could race and miss a common commit, then be unable to look
  further back because the client is shallow.

* Elijah: Geometric repacking may help because it is less likely to miss
  something. A push to the wrong place should fail quickly. Let us leave
  shallow clones to develop their own story.

* Peff: Successful negotiation could also make connectivity checks
  easier. We could cache information in receive-pack and pass it to
  check-connected.

* brian: Shallow clones can spend much more time trying to minimize the
  wire transfer. One push went from two seconds to 35 seconds because of
  that optimization. `objects-edge-aggressive` is relevant here.

* Jonathan Tan: We might get substantial savings from simply disabling
  ref advertisements with a configuration option.

* Peff: Even without a protocol change, the server could decide which
  refs are interesting and limit its advertisement. That might be easier
  than introducing v2 for pushes.

* Jonathan Tan: The client needs to tell the server that it wants to
  negotiate.

* Peff: It might not need to negotiate.

* Jonathan Tan: Would that not be bad?

* Peff: In practice the drawback may be small, though completely
  unrelated histories would be a bad case.

* Elijah: That can happen when appending a shallow commit.

* brian: I have seen that happen too.

* Peff: In that degenerate case, do these optimizations already have
  problems?

* Jonathan Tan: Negotiation does not have as much trouble because it
  starts at the tip the client is pushing.

* [General agreement that putting unrelated histories into one
  repository is best avoided.]

* Peff: Nobody objects to push v2. We have the hooks and the fetch-v2
  infrastructure. There may be an easier place to start, though.

* brian: Another benefit of push v2 is interoperability. Currently a
  client must push using the server's hash algorithm; it cannot
  negotiate a different one. Fetch can do some negotiation.

* Peff: If v2 makes interoperability easier, go for it.

* Emily: What is the failure mode?

* brian: Without it, the client must know the server's main hash
  algorithm and the mapping from object IDs in that algorithm to
  content.

* Martin Fick: I would like push v2 for automated replication, where a
  forge pushes to mirrors. Gerrit does this with thousands of targets.
  Ref advertisements are expensive when checking all of them. We need a
  way to know whether an advertisement differs from ours, so we can skip
  targets that are already up to date.

* Emily: Push negotiation?

* Martin Fick: The ref advertisement happens before negotiation.

* Peff: You want an answer in tens of bytes rather than thousands. A
  checksum could provide a small initial step.

* brian: With reftable, generation numbers make this easy.

* Martin Fick: That might work for this case, but assumes the
  repositories are in lockstep and covers fewer cases than a full
  protocol change.

* Peff: Would the rest of the push not fix it?

* Martin Fick: Parallelism makes that assumption harder.

* Peff: We discussed an ETag-style approach with reftable at GitHub
  years ago. It would be useful to see an implementation, and it could
  fit as an option in the existing protocol.

* Martin Fick: The server could also send a diff or a leaner pack.

* [Caching was also mentioned.]

* Patrick: Should we shrink the advertisement format?

* Peff: Perhaps compress it with zlib.

* Patrick: Let us explore options and benchmark them. We need v2 on the
  push side. We also proposed sending reftable directly.

* Martin Fick: A reftable could contain extra information.

* Patrick: A compressed format may be simpler.

* brian: We also do not want to send hidden refs.

* Patrick: I mean using the reftable format, rather than sending the
  whole reftable.

Re: [NOTES 03/07] Documentation

[Todd Zullinger]

Thank you for the nice summaries Taylor.

Taylor Blau wrote:
> Topic: Documentation
> * Peff: We support both AsciiDoc and Asciidoctor. Would it help to get
>   out of that dual world?
> 
> * Patrick: Traditionally this was for migration. AsciiDoc was thought to
>   be unmaintained, but it is maintained now.
> 
> * Peff: We could move to Asciidoctor.
> 
> * brian: Fedora still uses AsciiDoc. Asciidoctor is well maintained,
>   written in Ruby, and reasonably portable. It depends on how much we
>   want to support. I do not know whether Fedora is still an obstacle.

The Fedora packages have used Asciidoctor by default since
e942c8d (use Asciidoctor to build documentation when
possible, 2020-02-25).

    https://src.fedoraproject.org/rpms/git/c/e942c8d

That hasn't changed since I stopped maintaining the git
package, so Fedora hasn't had an issue with a switch to
Asciidoctor for quite a long time.

CentOS Stream / RHEL uses AsciiDoc (with the odd exception
of 9).  They _could_ use Asciidoctor relatively easily; it
is maintained for EPEL already.

But if Red Hat really dislike requiring Asciidoctor for git
builds in RHEL, they could ship the pre-built docs, as I
used to do for EL-5 builds due to an unsupported (read:
ancient) AsciiDoc version.

If we switched to Asciidoctor, it _might_ open the door to
replacing the docbook/xmlto dependencies and having
Asciidoctor directly generate the man pages.

I haven't thought about or looked at that in a long, long
time, so I don't know if that would be a worthwhile change
or not.  I don't recall if we need the XML step for other
outputs, like info or PDF (neither of which I ever spent
much time trying to build).

-- 
Todd

Re: [NOTES 03/07] Documentation

[Junio C Hamano]

Todd Zullinger <tmz@pobox.com> writes:

> But if Red Hat really dislike requiring Asciidoctor for git
> builds in RHEL, they could ship the pre-built docs, as I
> used to do for EL-5 builds due to an unsupported (read:
> ancient) AsciiDoc version.

FYI.

The prebuilt docs I publish, which I presume is the one you are
referring to here, switched to use Asciidoctor in mid 2024.

[PATCH] Documentation: propose community voting process

[Emily Shaffer]

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

Re: [PATCH] Documentation: propose community voting process

[Emily Shaffer]

On Wed, Oct 21, 2026 at 1:03 PM Emily Shaffer <emilyshaffer@google.com> wrote:
>
> 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>.

There are a few appealing options.

* Debian uses devotee (https://salsa.debian.org/debian/devotee), which
appears to require hosting. Finding neutral hosting may prove tricky.
* Konstantin let me know that The Linux Foundation's Technical
Advisory Board has used CIVS (https://civs1.civs.us/) in the past. He
says he wasn't involved in setting it up but doesn't think it looks
too challenging. CIVS and devotee use the same tallying algorithm.

* jj used voting on a GitHub poll in the past. That would just give us
simple majority, and it would require GitHub accounts, which may be a
barrier.

These all have their pros and cons; devotee and CIVS seem to me to be
better suited to many options that may be somewhat similar to each
other.

The other factor that I haven't dug into too much is how to only allow
eligible voters to cast a vote. GitHub isn't a great fit for this,
we'd need to collect GH IDs of every eligible voter and put them into
a group or something, if I understand best how this would work. CIVS
emails a link to each eligible voter - since I propose basing
eligibility on mailing list participation and patch submissions I
think there is no problem there. devotee also appears to be email
based.

> +
> +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.

The specifics of this eligibility rule can change a little. I'm trying
to figure a balance between a few principles:
* Not all contributions are code (e.g. community moderation is
contribution but a moderator may never send a patch). I think in the
Git project we have less issue with that, because we don't have a
community moderator unless we're counting the mods in the low-traffic
Discord, and I believe all of those mods have code or review
contributions anyways.
* Avoiding dogpiling. This is my biggest fear, 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.

* Easy (scriptable) eligibility determination. If we start to explore
other types of contribution, like user support in non-mailing-list
platforms, it becomes really difficult to send a ballot to everyone
who's supposed to get one.

> 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
>

Re: [PATCH] Documentation: propose community voting process

[Junio C Hamano]

Emily Shaffer <emilyshaffer@google.com> writes:

> 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>
> ---
> 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.

Sounds sensible.  One request to change the wording of the title is
to use a verb stronger than "propose".  The act of sending this
patch alone is a proposal, but once committed and merged, that is
not "propose a process", but "define the process used in this
community".

> 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.

Thanks for starting the process.

Re: [PATCH] Documentation: propose community voting process

[Junio C Hamano]

Emily Shaffer <emilyshaffer@google.com> writes:

Emily Shaffer <emilyshaffer@google.com> writes:

> +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.

Nicely described.  I particularly like that this prevents us from
putting technical decisions to a vote, reserving voting strictly for
policy decisions.


> +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.

Or any earlier ones for that matter.  Perhaps there should be a way
to uniquely identify the version.  By the time the proposal is so
solidified, it is likely to be in my tree, so we can use the commit
object name that adds such a proposal document (or the blob ID).

Then we can tell people that

    $ git fetch https://git.kernel.org/pub/scm/git/git.git/ seen
    $ git cat-file blob $BLOB_OBJECT_NAME

would give them the exact thing they are voting on.

I presume that this can be used for multiple-choice votes easily,
and can be adjusted for a proposal with multiple things to vote on
independently (i.e., "allow emojis in commit titles?" and "require
CamelCase in commit titles?" can be asked at the same time and
voters can give answers to each question separately).


> +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).

Do you mean "number of votes"?  Or are we envisioning that there
will be N competing proposals and we vote to find out which one is
the most favored?

> +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.

That is a fairly low bar to cross, especially the code review count,
as it will not be easy to define and enforce some rule that rejects
a response to a patch that only says "thanks, I like the feature
this proposes" without reading any parts of the message.  

As it is hard to track patches that as in 'next' a few release
cycles ago without graduating in the end and the authors of such a
patch should have the same voting power as those whose patch is in
'next' in the current cycle, I would suggest strongly against using
'next' as a yardstick.

I would have expected to see something like "two or more topics that
appear in any released versions" instead.  Note that I said "topics"
here and not "commits", so your topic that consists of 17-patch
still counts as one.

> +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.

Hopefully the "in released versions" criteria makes the above a
non-issue.

Re: [PATCH] Documentation: propose community voting process

[Kristoffer Haugsbakk]

On Wed, Oct 21, 2026, at 22:03, Emily Shaffer wrote:
> 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.

I’m a lurker when it comes to these things, but this is the first time
I’ve seen that the Git project aspires to be democratic. Or that I’ve
seen any wish for that from relative insiders to relative outsiders.

>
> 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.

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.

>
>[snip]
> 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.

Even the Himalayas will flatten one day.

There is overall great acceptance from the powers that be towards those
that don’t use GenAI. Because either you adopt it today, or three months
from now; it’s inevitable.

>
> 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
>
> ---
>[snip]

Re: [PATCH] Documentation: propose community voting process

[Phillip Wood]

Hi Emily

Thanks for working on this

On 21/10/2026 21:05, Emily Shaffer wrote:
> On Wed, Oct 21, 2026 at 1:03 PM Emily Shaffer <emilyshaffer@google.com> wrote:
>>
>> +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.
> 
> The specifics of this eligibility rule can change a little. I'm trying
> to figure a balance between a few principles:
> * Not all contributions are code (e.g. community moderation is
> contribution but a moderator may never send a patch). I think in the
> Git project we have less issue with that, because we don't have a
> community moderator unless we're counting the mods in the low-traffic
> Discord, and I believe all of those mods have code or review
> contributions anyways.

I agree we want to include those who contribute more widely, but I think 
restricting the criteria to contributions on the mailing list where the 
development of git takes place and the impact of any decision will be 
felt the most is a reasonable place to draw the line. I'm not sure how 
easy it is going to be to count reviews - does posting "LGTM" count or 
do we want a more substantial contribution? Should verified bug reports 
count? - that's also a useful contribution to the project. I agree with 
Junio that we should count patch series, rather than individual patches 
and I think it would be easier to measure when they're merged to master 
rather than next.

> * Avoiding dogpiling. This is my biggest fear, 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.

I agree this is important. Before a vote is proposed it is likely that 
there will be some (possibly contentious) discussion on the list so I 
wonder if we should require that eligible contributions are made at 
least a month before the first draft of a proposal is posted. Junio's 
suggestion that we restrict eligibility to released code has a similar 
effect but I'm not sure how that would work for non code contributions.
I also think it would be sensible to restrict eligibility to the current 
set of active contributors, who will have to live with the consequences 
of the decision, by requiring eligible contributions to have been made 
in the previous two years. I have historic contributions in a couple of 
projects that I'm not active in anymore and I would not expect to be 
able to influence an decisions those projects make now.

> * Easy (scriptable) eligibility determination. If we start to explore
> other types of contribution, like user support in non-mailing-list
> platforms, it becomes really difficult to send a ballot to everyone
> who's supposed to get one.

I think this is tricky even for mailing list contributions, as I said 
above what constitutes a useful review? I'm afraid I don't have any 
useful suggestions. (It would be interesting to see if an LLM can 
usefully classify the emails on the list but I don't think we want to be 
using an LLM determining eligibility to vote on a proposal about whether 
to accept AI!)

Thanks

Phillip
>> 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
>>
> 

Re: [PATCH] Documentation: propose community voting process

[Patrick Steinhardt]

On Thu, Oct 22, 2026 at 09:29:26AM +0200, Kristoffer Haugsbakk wrote:
> On Wed, Oct 21, 2026, at 22:03, Emily Shaffer wrote:
[snip]
> > 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.
> 
> 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.

That's not exactly what I observe myself -- I work for one of these
companies, but I still am highly sceptical of the technology, and I know
others are, as well.

But I agree with the sentiment. It's part of the reason why 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.

Patrick

Re: [PATCH] Documentation: propose community voting process

[Justin Tobler]

On 26/10/21 03:06PM, Junio C Hamano wrote:
> Emily Shaffer <emilyshaffer@google.com> writes:
> > +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.
> 
> That is a fairly low bar to cross, especially the code review count,
> as it will not be easy to define and enforce some rule that rejects
> a response to a patch that only says "thanks, I like the feature
> this proposes" without reading any parts of the message.  

I also agree that the proposed eligibility requirements here seem quite
too low. From my point of view, ideally eligible voters would primarily
consist of individuals in the community that have both a vested and
current interest in the project. If an individual submitted a handful of
patches 15 years ago, but have not been involved in the community since,
should they still be eligible to vote? Maybe it would be worth
discussing whether contributions must have come from one of last X
releases in order to be considered eligible?

At the same time, if the requirements are too restrictive, the eligible
pool of voters may be significantly biased towards the most active
contributors which tend to work on Git for tech companies. That is not
to say this would inherrently effect how these individuals would vote,
but I worry it may not be entirely reflective of wider community
sentiment.

> As it is hard to track patches that as in 'next' a few release
> cycles ago without graduating in the end and the authors of such a
> patch should have the same voting power as those whose patch is in
> 'next' in the current cycle, I would suggest strongly against using
> 'next' as a yardstick.
> 
> I would have expected to see something like "two or more topics that
> appear in any released versions" instead.  Note that I said "topics"
> here and not "commits", so your topic that consists of 17-patch
> still counts as one.

I agree that counting topics in released versions seems better than an
commits in next.

-Justin

Re: [PATCH] Documentation: propose community voting process

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1595 bytes --]

On 2026-10-22 at 07:29:26, Kristoffer Haugsbakk wrote:
> On Wed, Oct 21, 2026, at 22:03, Emily Shaffer wrote:
> > 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.
> 
> 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.

I do usually work on Git at least once a month and I do work for a tech
company, although I sent my first patch while I was in university.
Despite what some people might believe, I don't parrot my employer's
company line from my personal account.  Even when I'm speaking for my
employer, I don't speak in ways that I don't personally believe in
because I'm a person of integrity.  To the contrary, I think most people
who know me know that I'm a person who calls it as they see it.

I think anyone who was at the Contributor Summit or has read my emails
to the list knows how I feel about LLMs and how I vote as a contributor
will not be influenced by my employer.  I do think, though, that this is
a reason that votes should be secret because that prevents people from
having to prove their votes to others.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA
Speaking for myself only

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 325 bytes --]

Re: [PATCH] Documentation: propose community voting process

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2269 bytes --]

On 2026-10-21 at 20:05:06, Emily Shaffer wrote:
> There are a few appealing options.
> 
> * Debian uses devotee (https://salsa.debian.org/debian/devotee), which
> appears to require hosting. Finding neutral hosting may prove tricky.
> * Konstantin let me know that The Linux Foundation's Technical
> Advisory Board has used CIVS (https://civs1.civs.us/) in the past. He
> says he wasn't involved in setting it up but doesn't think it looks
> too challenging. CIVS and devotee use the same tallying algorithm.

I'm not volunteering to set this up or maintain things, but I do follow
Debian stuff reasonably closely and I have a positive opinion of
devotee.

> * jj used voting on a GitHub poll in the past. That would just give us
> simple majority, and it would require GitHub accounts, which may be a
> barrier.

I think some people who are contributors will not want to use GitHub and
we've historically been neutral on forges and tooling, so we should
continue that policy here.

> > +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.

I think this is too few contributions.  Other projects use a much
tighter mechanism for choosing contributors and some even restrict
access to a core team.  I'm not saying that we should do that here, but
we should put a threshold in place where people are not incentivized to
contribute only to vote.  That is, we want contributors to contribute
for the sake of contributing and have voting be merely a consequence
of being a serious contributor.

At this moment, I'm not sure exactly where that threshold should be set,
though.

> * Easy (scriptable) eligibility determination. If we start to explore
> other types of contribution, like user support in non-mailing-list
> platforms, it becomes really difficult to send a ballot to everyone
> who's supposed to get one.

Scriptability is important, I agree.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA
Speaking for myself only

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 325 bytes --]

Re: [PATCH] Documentation: propose community voting process

[Junio C Hamano]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> I think anyone who was at the Contributor Summit or has read my emails
> to the list knows how I feel about LLMs and how I vote as a contributor
> will not be influenced by my employer.  I do think, though, that this is
> a reason that votes should be secret because that prevents people from
> having to prove their votes to others.

Thanks for raising an important point that I did not remember seeing
in the proposal.

FWIW, I do not parrot the company line of my employer, mostly
because I do not know what it is for each week ;-).

Re: [PATCH] Documentation: propose community voting process

[Junio C Hamano]

Phillip Wood <phillip.wood123@gmail.com> writes:

> I agree we want to include those who contribute more widely, but I think 
> restricting the criteria to contributions on the mailing list where the 
> development of git takes place and the impact of any decision will be 
> felt the most is a reasonable place to draw the line. I'm not sure how 
> easy it is going to be to count reviews - does posting "LGTM" count or 
> do we want a more substantial contribution? Should verified bug reports 
> count? - that's also a useful contribution to the project.

We have patches focusing on documentation as well.  I do not think
commit count necessarily gives undue advantage to code contributors.

> I also think it would be sensible to restrict eligibility to the current 
> set of active contributors, who will have to live with the consequences 
> of the decision, by requiring eligible contributions to have been made 
> in the previous two years. I have historic contributions in a couple of 
> projects that I'm not active in anymore and I would not expect to be 
> able to influence an decisions those projects make now.

But do you care about these past projects enough to (1) notice that
they are having a policy discussion, (2) bother visiting them again
to learn their current voting procedures, and (3) actually cast a
vote to help improve them?  You may not have been active recently,
but if you care enough, and if your past knowledge of how the
project works still applies, wouldn't the project participants
appreciate your input?

I would recommend reducing the number and complexity of conditions.
Immediately after you say "last two years", I can hear someone else
arguing "too short -- why not three?" or "too long -- why not one?".
I previously mentioned "topic count", but commits are far easier to
count.  So instead of requiring two topics in released versions,
perhaps requiring five commits would be easier to implement and
explain.

Re: [PATCH] Documentation: propose community voting process

[Kristoffer Haugsbakk]

On Fri, Oct 23, 2026, at 00:51, brian m. carlson wrote:
> On 2026-10-22 at 07:29:26, Kristoffer Haugsbakk wrote:
>> On Wed, Oct 21, 2026, at 22:03, Emily Shaffer wrote:
>> > 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.
>> 
>> 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.
>
> I do usually work on Git at least once a month and I do work for a tech
> company, although I sent my first patch while I was in university.
> Despite what some people might believe, I don't parrot my employer's
> company line from my personal account.  Even when I'm speaking for my
> employer, I don't speak in ways that I don't personally believe in
> because I'm a person of integrity.  To the contrary, I think most people
> who know me know that I'm a person who calls it as they see it.
>
> I think anyone who was at the Contributor Summit or has read my emails
> to the list knows how I feel about LLMs and how I vote as a contributor
> will not be influenced by my employer.  I do think, though, that this is
> a reason that votes should be secret because that prevents people from
> having to prove their votes to others.

I was not being precise. That was about being *paid*
to work *on Git* and with some regularity. And it
would only *drift towards* agreement with managemt in
the aggregate. A further clarification. This would
not hold if the group of people who work on X
is small.

I don't know who or what “Despite what some 
people might believe” is about and I don't care.

Sent from mobile

Re: [PATCH] Documentation: propose community voting process

[Junio C Hamano]

Justin Tobler <jltobler@gmail.com> writes:

>> That is a fairly low bar to cross, especially the code review count,
>> as it will not be easy to define and enforce some rule that rejects
>> a response to a patch that only says "thanks, I like the feature
>> this proposes" without reading any parts of the message.  
>
> I also agree that the proposed eligibility requirements here seem quite
> too low. From my point of view, ideally eligible voters would primarily
> consist of individuals in the community that have both a vested and
> current interest in the project. If an individual submitted a handful of
> patches 15 years ago, but have not been involved in the community since,
> should they still be eligible to vote? Maybe it would be worth
> discussing whether contributions must have come from one of last X
> releases in order to be considered eligible?

Again, I would urge us to resist the temptation to make the rules
more elaborate (see my response to Phillip elsewhere in the thread).
Once we start saying "such an ancient contribution alone shouldn't
qualify you to vote", it is essentially the same as saying "with
more recent involvement, and with more vested and current interest,
you should have more influence".  With that line of thought, we
would end up with rules like "your commit made X days ago earns you
1/X vote" (where influence decays with the age of contribution) or
"summing votes earned across all commits in released versions, and
that is the number of votes you can cast" (where the more you have
contributed, the more valuable your input would be to the project).

I do not think we want to go there, and we should instead limit
ourselves to "each of you gets one vote, and this is the simple rule
to tell if you can vote."  That is simpler to explain and makes it
hard for any potential detractors to claim unfairness.

Thanks.

Re: [PATCH] Documentation: propose community voting process

[Phillip Wood]

Hi Junio

On 23/10/2026 05:48, Junio C Hamano wrote:
> Phillip Wood <phillip.wood123@gmail.com> writes:
> 
>> I agree we want to include those who contribute more widely, but I think
>> restricting the criteria to contributions on the mailing list where the
>> development of git takes place and the impact of any decision will be
>> felt the most is a reasonable place to draw the line. I'm not sure how
>> easy it is going to be to count reviews - does posting "LGTM" count or
>> do we want a more substantial contribution? Should verified bug reports
>> count? - that's also a useful contribution to the project.
> 
> We have patches focusing on documentation as well.  I do not think
> commit count necessarily gives undue advantage to code contributors.

Limiting it to commits does make it much easier to count. Thinking about 
the way the list works, I suspect anyone who would be included by 
counting reviews is probably going to have authored sufficient patches 
that counting reviews does not make much difference.

>> I also think it would be sensible to restrict eligibility to the current
>> set of active contributors, who will have to live with the consequences
>> of the decision, by requiring eligible contributions to have been made
>> in the previous two years. I have historic contributions in a couple of
>> projects that I'm not active in anymore and I would not expect to be
>> able to influence an decisions those projects make now.
> 
> But do you care about these past projects enough to (1) notice that
> they are having a policy discussion, (2) bother visiting them again
> to learn their current voting procedures, and (3) actually cast a
> vote to help improve them?  You may not have been active recently,
> but if you care enough, and if your past knowledge of how the
> project works still applies, wouldn't the project participants
> appreciate your input?

As I understand it the voting systems that are being proposed 
automatically send a voting link to those eligible to vote so I would be 
aware because I'd have received a voting link. Having a time limit also 
limits the amount of admin for the person running the vote, for example 
handling messages from someone claiming to be a past contributor whose 
email address has changed. The voting system is only going to be used 
when we cannot reach a consensus. Having seen how much time and energy 
people, with no real interest in contributing to git, put into posting 
to the list when we we first discussing changing the default branch 
name, I think we should be careful to limit the potential for bad actors 
to try and derail the vote.

> I would recommend reducing the number and complexity of conditions.
> Immediately after you say "last two years", I can hear someone else
> arguing "too short -- why not three?" or "too long -- why not one?".
> I previously mentioned "topic count", but commits are far easier to
> count.  So instead of requiring two topics in released versions,
> perhaps requiring five commits would be easier to implement and
> explain.

People could choose to bike-shed over any aspect of the eligibility so I 
don't think that is a reason not to consider a time limit. Justin has 
also raised the issue of restricting eligibility to current 
participants. I suggested 2 years as it includes regular contributors 
who are having a break for whatever reason while excluding those who 
have not contributed in the recent past, but I don't think the exact 
number matters too much. I don't have a strong opinion either way on 
patch series vs commit count so long as we don't set the bar too low. 
Whether we count commits, or merged patch series, it is quite easy to 
limit the date range that we consider.

Thanks

Phillip

Re: [PATCH] Documentation: propose community voting process

[Kristoffer Haugsbakk]

On Fri, Oct 23, 2026, at 15:49, Phillip Wood wrote:
> Hi Junio
>
> On 23/10/2026 05:48, Junio C Hamano wrote:
>> Phillip Wood <phillip.wood123@gmail.com> writes:
>>[snip]
>>> I also think it would be sensible to restrict eligibility to the current
>>> set of active contributors, who will have to live with the consequences
>>> of the decision, by requiring eligible contributions to have been made
>>> in the previous two years. I have historic contributions in a couple of
>>> projects that I'm not active in anymore and I would not expect to be
>>> able to influence an decisions those projects make now.
>>
>> But do you care about these past projects enough to (1) notice that
>> they are having a policy discussion, (2) bother visiting them again
>> to learn their current voting procedures, and (3) actually cast a
>> vote to help improve them?  You may not have been active recently,
>> but if you care enough, and if your past knowledge of how the
>> project works still applies, wouldn't the project participants
>> appreciate your input?
>
> As I understand it the voting systems that are being proposed
> automatically send a voting link to those eligible to vote so I would be
> aware because I'd have received a voting link. Having a time limit also
> limits the amount of admin for the person running the vote, for example
> handling messages from someone claiming to be a past contributor whose
> email address has changed. The voting system is only going to be used
> when we cannot reach a consensus. Having seen how much time and energy
> people, with no real interest in contributing to git, put into posting
> to the list when we we first discussing changing the default branch
> name, I think we should be careful to limit the potential for bad actors
> to try and derail the vote.

And this is a very relevant example since everyone can have an opinion
on GenAI, just like main branch name bikeshedding. Contrast with some
technical topic that you would have to be involved in the project to
even care about.

Some people care whether software projects that they use but don’t
contribute to use GenAI.

>
>>[snip]

Re: [PATCH] Documentation: propose community voting process

[Kristoffer Haugsbakk]

On Fri, Oct 23, 2026, at 06:48, Junio C Hamano wrote:
> Phillip Wood <phillip.wood123@gmail.com> writes:
>>[snip]
>> I also think it would be sensible to restrict eligibility to the current
>> set of active contributors, who will have to live with the consequences
>> of the decision, by requiring eligible contributions to have been made
>> in the previous two years. I have historic contributions in a couple of
>> projects that I'm not active in anymore and I would not expect to be
>> able to influence an decisions those projects make now.
>
> But do you care about these past projects enough to (1) notice that
> they are having a policy discussion, (2) bother visiting them again
> to learn their current voting procedures, and (3) actually cast a
> vote to help improve them?  You may not have been active recently,
> but if you care enough, and if your past knowledge of how the
> project works still applies, wouldn't the project participants
> appreciate your input?
>

I see the concern wrt. dogpiling from non-active contributors,[1] but it
seems very impractical. A dogpile (this was the word used so I’ll just
stick to it) a la GitHub issues means that someone links to a GitHub
issue (which is open to all) and many, many outsiders comment on the
issue. For example. But imagine this happening via social media. All of
the people ready to dogpile would also need to have contributed in the
past. How could you get a flood of such a filtered set?

Imagine vote whipping former Git contributors who have scratched an
itch, fixed a bug, or fixed three typos, 5–20 years ago, to get them
all to vote for or against something. Okay, again no one made this
argument.[1] But this is to illustrate that the worst-case dogpiling
(or vote whipping) is not feasible.

† 1: This is not to say that anyone in particular had this concern. But
     I could imagine it.

>[snip]

Re: [PATCH] Documentation: propose community voting process

[Junio C Hamano]

"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:

> Some people care whether software projects that they use but don’t
> contribute to use GenAI.

Sorry, but I cannot quite parse this to guess what you want to say.

Re: [PATCH] Documentation: propose community voting process

[Kristoffer Haugsbakk]

On Fri, Oct 23, 2026, at 18:26, Junio C Hamano wrote:
> "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
>
>> Some people care whether software projects that they use but don’t
>> contribute to use GenAI.
>
> Sorry, but I cannot quite parse this to guess what you want to say.

There are people who actively dislike software projects over the fact
that they use GenAI.

Re: [PATCH] Documentation: propose community voting process

[Junio C Hamano]

"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:

> On Fri, Oct 23, 2026, at 18:26, Junio C Hamano wrote:
>> "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
>>
>>> Some people care whether software projects that they use but don’t
>>> contribute to use GenAI.
>>
>> Sorry, but I cannot quite parse this to guess what you want to say.
>
> There are people who actively dislike software projects over the fact
> that they use GenAI.

Ah, that is what you meant.  I understand what you wanted to say,
even though I do not understand the reasoning of those people you
describe.

Thanks.

Re: [PATCH] Documentation: propose community voting process

[Tuomas Ahola]

Junio C Hamano <gitster@pobox.com> wrote:

> [...]
> I previously mentioned "topic count", but commits are far easier to
> count.  So instead of requiring two topics in released versions,
> perhaps requiring five commits would be easier to implement and
> explain.
> 

Quoting the summit notes:

} * Emily: Have we used a voting process for something like this before?
} 
} * Patrick: We need proposals and a vote. Who would be allowed to vote?
} 
} * Peff: Active developers with a track record; perhaps a threshold such
}   as 50 merged patches.
} 

So it seems that Peff's proposed threshold was substantially higher
than what has been put forth in this thread.  Any comments on that?

--Tuomas

Re: [PATCH] Documentation: propose community voting process

[Weijie Yuan]

Tuomas Ahola <taahol@utu.fi> writes:

> Junio C Hamano <gitster@pobox.com> wrote:
> 
> > [...]
> > I previously mentioned "topic count", but commits are far easier to
> > count.  So instead of requiring two topics in released versions,
> > perhaps requiring five commits would be easier to implement and
> > explain.
> > 
> 
> Quoting the summit notes:
> 
> } * Emily: Have we used a voting process for something like this before?
> } 
> } * Patrick: We need proposals and a vote. Who would be allowed to vote?
> } 
> } * Peff: Active developers with a track record; perhaps a threshold such
> }   as 50 merged patches.
> } 
> 
> So it seems that Peff's proposed threshold was substantially higher
> than what has been put forth in this thread.  Any comments on that?

Although I could selfishly say that I'd like to have a vote, since I
might just meet the threshold in Junio's example, I'm rather afraid that
I'm not qualified enough and don't have the kind of foresight like Junio
and Peff have to justify having an equal say in Git's direction.

Thanks.

Re: [PATCH] Documentation: propose community voting process

[Junio C Hamano]

Tuomas Ahola <taahol@utu.fi> writes:

> Junio C Hamano <gitster@pobox.com> wrote:
>
>> [...]
>> I previously mentioned "topic count", but commits are far easier to
>> count.  So instead of requiring two topics in released versions,
>> perhaps requiring five commits would be easier to implement and
>> explain.
>> 
>
> Quoting the summit notes:
>
> } * Emily: Have we used a voting process for something like this before?
> } 
> } * Patrick: We need proposals and a vote. Who would be allowed to vote?
> } 
> } * Peff: Active developers with a track record; perhaps a threshold such
> }   as 50 merged patches.
> } 
>
> So it seems that Peff's proposed threshold was substantially higher
> than what has been put forth in this thread.  Any comments on that?

I do not know which between 50 or 200 is more appropriate, but I
think these are more realistic threshold.  FWIW, I made the first
review comment that pointed out that the bar set by Emily's document
was too low to cross.  The "2 vs 5" you are reacting to was merely
to point out that commit count would be higher than equivalent topic
count and without bringing "2 is too low" topic again, which I
already gave an input to.

Re: [PATCH] Documentation: propose community voting process

[Weijie Yuan]

Junio C Hamano <gitster@pobox.com> writes:

> Tuomas Ahola <taahol@utu.fi> writes:
> 
> > Junio C Hamano <gitster@pobox.com> wrote:
> >
> >> [...]
> >> I previously mentioned "topic count", but commits are far easier to
> >> count.  So instead of requiring two topics in released versions,
> >> perhaps requiring five commits would be easier to implement and
> >> explain.
> >> 
> >
> > Quoting the summit notes:
> >
> > } * Emily: Have we used a voting process for something like this before?
> > } 
> > } * Patrick: We need proposals and a vote. Who would be allowed to vote?
> > } 
> > } * Peff: Active developers with a track record; perhaps a threshold such
> > }   as 50 merged patches.
> > } 
> >
> > So it seems that Peff's proposed threshold was substantially higher
> > than what has been put forth in this thread.  Any comments on that?
> 
> I do not know which between 50 or 200 is more appropriate, but I
> think these are more realistic threshold.  FWIW, I made the first
> review comment that pointed out that the bar set by Emily's document
> was too low to cross.  The "2 vs 5" you are reacting to was merely
> to point out that commit count would be higher than equivalent topic
> count and without bringing "2 is too low" topic again, which I
> already gave an input to.

Oh, so sorry that I was misreading.

Re: [PATCH] Documentation: propose community voting process

[Jeff King]

On Sat, Oct 24, 2026 at 02:18:56PM +0300, Tuomas Ahola wrote:

> Junio C Hamano <gitster@pobox.com> wrote:
> 
> > [...]
> > I previously mentioned "topic count", but commits are far easier to
> > count.  So instead of requiring two topics in released versions,
> > perhaps requiring five commits would be easier to implement and
> > explain.
> > 
> 
> Quoting the summit notes:
> 
> } * Emily: Have we used a voting process for something like this before?
> } 
> } * Patrick: We need proposals and a vote. Who would be allowed to vote?
> } 
> } * Peff: Active developers with a track record; perhaps a threshold such
> }   as 50 merged patches.
> } 
> 
> So it seems that Peff's proposed threshold was substantially higher
> than what has been put forth in this thread.  Any comments on that?

I'm a bit behind on the list and haven't been following this discussion
closely yet, but I'll just say: the number 50 was made up by me on the
spot. So I wouldn't read too much into it.

But if somebody is picking a number, looking at "git shortlog -ns
--no-merges | sort -rn" may be interesting, just to get a sense of how
many people we are talking about:

  - there are 44 people with >= 200 commits
  - there are 133 people with >= 50 commits
  - there are 439 people with >= 10 commits
  - there are 2388 people with >= 1 commit

At some point it gets kind of unwieldy.

I saw proposals elsewhere to cut it by time. I think "N commits in the
last M years" is awkward, because there are people who have been around
for a long time with steady but slow participation steady-but-slow
participation. But if you just intersect "N commits over all time" and
"has _any_ commits in the last M years", then you can get a table like:

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

Those aren't necessarily perfect metrics, but if we consider them good
enough and just want to tune the parameters, we could probably pick a
spot in the table that has about the number of votes we'd want to deal
with.

-Peff

Re: [PATCH] Documentation: propose community voting process

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> But if somebody is picking a number, looking at "git shortlog -ns
> --no-merges | sort -rn" may be interesting, just to get a sense of how

I very much appreciate the "--no-merges" part of the command line ;-)

> ... But if you just intersect "N commits over all time" and
> "has _any_ commits in the last M years", then you can get a table like:
>
> 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
>
> Those aren't necessarily perfect metrics, but if we consider them good
> enough and just want to tune the parameters, we could probably pick a
> spot in the table that has about the number of votes we'd want to deal
> with.

Sounds like an interesting approach.

Re: [PATCH] Documentation: propose community voting process

[Patrick Steinhardt]

On Sun, Oct 25, 2026 at 09:17:31PM -0400, Jeff King wrote:
> On Sat, Oct 24, 2026 at 02:18:56PM +0300, Tuomas Ahola wrote:
> 
> > Junio C Hamano <gitster@pobox.com> wrote:
> > 
> > > [...]
> > > I previously mentioned "topic count", but commits are far easier to
> > > count.  So instead of requiring two topics in released versions,
> > > perhaps requiring five commits would be easier to implement and
> > > explain.
> > > 
> > 
> > Quoting the summit notes:
> > 
> > } * Emily: Have we used a voting process for something like this before?
> > } 
> > } * Patrick: We need proposals and a vote. Who would be allowed to vote?
> > } 
> > } * Peff: Active developers with a track record; perhaps a threshold such
> > }   as 50 merged patches.
> > } 
> > 
> > So it seems that Peff's proposed threshold was substantially higher
> > than what has been put forth in this thread.  Any comments on that?
> 
> I'm a bit behind on the list and haven't been following this discussion
> closely yet, but I'll just say: the number 50 was made up by me on the
> spot. So I wouldn't read too much into it.
> 
> But if somebody is picking a number, looking at "git shortlog -ns
> --no-merges | sort -rn" may be interesting, just to get a sense of how
> many people we are talking about:
> 
>   - there are 44 people with >= 200 commits
>   - there are 133 people with >= 50 commits
>   - there are 439 people with >= 10 commits
>   - there are 2388 people with >= 1 commit
> 
> At some point it gets kind of unwieldy.
> 
> I saw proposals elsewhere to cut it by time. I think "N commits in the
> last M years" is awkward, because there are people who have been around
> for a long time with steady but slow participation steady-but-slow
> participation. But if you just intersect "N commits over all time" and
> "has _any_ commits in the last M years", then you can get a table like:
> 
> 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
> 
> Those aren't necessarily perfect metrics, but if we consider them good
> enough and just want to tune the parameters, we could probably pick a
> spot in the table that has about the number of votes we'd want to deal
> with.

That sounds very reasonable to me. Though I have to say that we
shouldn't only consider "the number of votes we'd want to deal with",
but also the shape of the voting population that we want to see.

I think it's fair to say that everyone has a single vote to cast no
matter their seniority so that the vote doesn't get overly skewed
towards the opinion of long-term contributors, as those tend to be
employed to work on Git. But the other side of the coin is that the vote
would get overly skewed towards newcomers in case we set the total
commit bar too low. So picking the right spot in the table would
essentially be balancing out the interests of oldtimers versus
newcomers.

How exactly we want to balance that is a different question. I am of
course heavily biased as an oldtimer and would thus think that 10
commits is a rather low bar. So from that table I myself would probably
pick 50 with N=2 or N=3, but maybe a commit count of 25 or 30 would be
more reasonable as a middle ground.

In any case, there is no "correct" value anyway.

Patrick

Re: [PATCH] Documentation: propose community voting process

[Tuomas Ahola]

Patrick Steinhardt <ps@pks.im> wrote:

> On Sun, Oct 25, 2026 at 09:17:31PM -0400, Jeff King wrote:
> >          [...] But if you just intersect "N commits over all time" and
> > "has _any_ commits in the last M years", then you can get a table like:
> > 
> > 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
> > 
> > Those aren't necessarily perfect metrics, but if we consider them good
> > enough and just want to tune the parameters, we could probably pick a
> > spot in the table that has about the number of votes we'd want to deal
> > with.
> 

Ah, brilliant!  That adds, quite literally, a new dimension to the debate.

> That sounds very reasonable to me. Though I have to say that we
> shouldn't only consider "the number of votes we'd want to deal with",
> but also the shape of the voting population that we want to see.
> 
> I think it's fair to say that everyone has a single vote to cast no
> matter their seniority so that the vote doesn't get overly skewed
> towards the opinion of long-term contributors, as those tend to be
> employed to work on Git. But the other side of the coin is that the vote
> would get overly skewed towards newcomers in case we set the total
> commit bar too low. So picking the right spot in the table would
> essentially be balancing out the interests of oldtimers versus
> newcomers.
> 
> How exactly we want to balance that is a different question. I am of
> course heavily biased as an oldtimer and would thus think that 10
> commits is a rather low bar. So from that table I myself would probably
> pick 50 with N=2 or N=3, but maybe a commit count of 25 or 30 would be
> more reasonable as a middle ground.
> 

My argument isn't exactly the strongest but if we calculate the average of
`git shortlog -s`,

	$ git shortlog -s --no-merges | awk '{sum+=$1} END {print sum/NR}' 
	25.7022

that number does look quite nice to me.  So something between 25 and 30,
perhaps, for the commit count threshold?

> In any case, there is no "correct" value anyway.
> 

Very true.

> Patrick

Re: [PATCH] Documentation: propose community voting process

[Phillip Wood]

On 26/10/2026 01:17, Jeff King wrote:
> 
> I saw proposals elsewhere to cut it by time. I think "N commits in the
> last M years" is awkward, because there are people who have been around
> for a long time with steady but slow participation steady-but-slow
> participation.

I think it depends on N, with the low values that were in the proposal 
most long term contributors would have that number of commits in the 
last couple of years, but I agree that if we're going to raise the bar 
on the number of contributions then N commits over all time with at 
least one recent one makes sense.

Thanks

Phillip

> But if you just intersect "N commits over all time" and
> "has _any_ commits in the last M years", then you can get a table like:
> 
> 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
> 
> Those aren't necessarily perfect metrics, but if we consider them good
> enough and just want to tune the parameters, we could probably pick a
> spot in the table that has about the number of votes we'd want to deal
> with.
> 
> -Peff