Git development
 help / color / mirror / Atom feed
From: Taylor Blau <ttaylorr@openai.com>
To: git@vger.kernel.org
Subject: [NOTES 06/07] AI contribution policy
Date: Tue, 6 Oct 2026 11:06:35 -0700	[thread overview]
Message-ID: <summit-2026.94e33e9ddf234334.06@ttaylorr.com> (raw)
In-Reply-To: <summit-2026.94e33e9ddf234334.00@ttaylorr.com>

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.

  parent reply	other threads:[~2026-10-06 18:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-06 18:05 Notes from the Git Contributor's Summit, 2026 Taylor Blau
2026-10-06 18:06 ` [NOTES 01/07] Security mailing list and security process Taylor Blau
2026-10-06 18:06 ` [NOTES 02/07] Git 3.0 Taylor Blau
2026-10-06 18:06 ` [NOTES 03/07] Documentation Taylor Blau
2026-10-07  4:49   ` Todd Zullinger
2026-10-07 17:38     ` Junio C Hamano
2026-10-06 18:06 ` [NOTES 04/07] Outreachy sponsorship Taylor Blau
2026-10-06 18:06 ` [NOTES 05/07] What can we do next with pluggable ODB? Taylor Blau
2026-10-06 18:06 ` Taylor Blau [this message]
2026-10-06 18:06 ` [NOTES 07/07] Protocol v2 for pushes Taylor Blau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=summit-2026.94e33e9ddf234334.06@ttaylorr.com \
    --to=ttaylorr@openai.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox