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