Skip to content

Tighten the AI guidelines and rules for new contributors #1956

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
picnixz wants to merge 1 commit into
base: main
Choose a base branch
from
+46 −5
Open

Tighten the AI guidelines and rules for new contributors #1956

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 44 additions & 5 deletions getting-started/ai-tools.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,9 @@ Authors must review the work done by AI tooling in detail to ensure it
actually makes sense before proposing it as a PR or filing it as an issue.

We expect PR authors and those filing issues to be able to explain their
proposed changes in their own words.
proposed changes in their own words. If you are new to contributing to
Python or only started recently, also read the :ref:`additional rules for
new contributors <ai-tools-new-contributors>`.

Disclosure of the use of AI tools in the PR description is appreciated,
while not required. Be prepared to explain how the tool was used and what
Expand All @@ -45,10 +47,26 @@ Acceptable uses

Some of the acceptable uses of generative AI include:

- Assistance with writing comments, especially in a non-native language
- Assistance with writing issues, PR descriptions and comments, especially
in a non-native language
- Gaining understanding of existing code
- Supplementing contributor knowledge for code, tests, and documentation

AI-generated text is often verbose and hides the point. When an AI tool helps
you write, remove filler, repetition and generic phrasing, and keep only what
you have checked and agree with. When it translates text you wrote in another
language, consider saying so and including your original text, unedited, in a
``<details>`` block, so that readers can refer to your own words:

.. code-block:: html

<details>
<summary>Original text</summary>

Elen síla lúmenn' omentielvo.

</details>

Unacceptable uses
=================

Expand All @@ -59,9 +77,30 @@ If a contributor repeatedly opens unproductive issues or PRs, they may be
blocked from contributing to the project because it is disruptive and
disrespectful of the maintainers time.

It is not acceptable to alter or bypass existing tests, or remove desired
functionality, in order to make a failing test pass. Such changes are not
a real fix.
Other unacceptable uses include:

- Communicating only through an AI tool, for example by passing reviewers'
questions to it and posting its answers as your own. Apart from
translating text you wrote, reviewers expect to discuss the change with
you. If you do not know the answer to a question, say so.
- Altering or bypassing existing tests, or removing desired functionality,
in order to make a failing test pass. Such changes are not a real fix.

.. _ai-tools-new-contributors:

Additional rules for new contributors

@willingc willingc Nov 3, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't these rules apply to all contributors?

@picnixz picnixz Nov 3, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I want to allow "regular" contributors use of AI because of the trust they built, even if they are neither triagers nor core devs. But I don't want that the first contributions of users is solely AI. But if you want a stronger policy where this applies to everyone, I'm fine as well, though I think it's sad that core devs can't use what the AI generated for them.

It's hard to convene that but informally:

  • Newcomers: please don't use AI, you need to prove yourself.
  • Others: we can trust your judgment more so you also generate your PRs with AI. But please, make it so that it's not annoying to read.

@Mariatta Mariatta Nov 3, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that llm-based contributions are annoying, and I agree that we need a way to trust the new contributos and for the new contributors to earn our trust.
But I disagree with this particular approach of creating yet another class of contributors: those who are allowed to use AI and those who are not.

I've been asking myself what I want to know from contributors when they use AI. I still don't have answers or solutions, but these are the things I've been thinking about:I want to know what is their contribution to the PR, did they simply point the agent to the issue and click accept? Did they ask the agent first to explain and clarify? Did they try to verify, replicate, weigh the options from the agents. Did they make any judgement calls, was there a time that they went against the agents recommendations, if so what was that? These are the things that would help me gain trust in the contributor, not the number of PRs they've made and not their status or core dev or not. (I've shared a long form reflection on my personal blog)

@willingc willingc Nov 3, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's hard to convene that but informally:

Newcomers: please don't use AI, you need to prove yourself.
Others: we can trust your judgment more so you also generate your PRs with AI. But please, make it so that it's not annoying to read.

The examples and additional text in the first two sections make sense. Thanks for taking the time to add additional detail.

I wasn't clear earlier that my question was in the "Additional rules for new contributors" section. I do want PRs from the core team, triagers, and contributors to be used responsibly. I don't think that we should have a different process for first-time contributors. To me, it feels elitist and creates an additional barrier for contributors.

I believe that it would be most effective to guide the first-time contributor (or their AI tool) to create a well-scoped PR. Basically, helping the AI tool follow a template for a valuable contribution:

  • the length of the PR message
  • tests
  • avoid unnecessary churn, etc.

For the human, strengthening the wording to respect maintainers' time and "demonstrating commitment to the project".

"Demonstrating commitment to the project" could encourage most of what you suggested.

=====================================

People who want to start contributing to Python, or who have only recently
started and are still learning the code base, are welcome, and we want their
first contributions to reflect their own understanding.

As a new contributor, you may use AI tools to understand an issue or the
code it involves, but the work itself must be yours: writing the change,
its tests and its description is how you learn the code base. Reading a
finished change is not the same as understanding it; as such, letting an AI
tool do the work and only reviewing its output is not considered
acceptable.

How these guidelines are applied
================================
Expand Down
2 changes: 2 additions & 0 deletions triage/triage-team.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -81,6 +81,8 @@ Apply only one of these labels to an issue or PR. When you add
text), add :gh-label:`AI-guidelines-not-met`. The bot removes
:gh-label:`AI-needs-explanation`, posts the closing comment and closes the
issue or PR. If you have any doubt, consult a core team member first.
* For repeated abuse, mention ``@python/organization-owners`` on the issue or
PR to have the author blocked.
* If the author responds and the concern is resolved, remove the label.
For a closed issue or PR, reopen it as well.

Expand Down
Loading