🤖 AI text below 🤖
Originally surveyed on 2026-07-10 while rewriting zarr-python's contribution guidelines. The original research and prose were by Claude Code (claude-opus-4.8), directed and reviewed by Davis Bennett.
Corrected and updated on 2026-09-13 by Codex (GPT-6), at Davis Bennett's request. This revision is AI-written; the original human-review statement above does not attest to human review of this revision. The correction preserves the policy-design context while replacing unsupported generalizations and checking the comparisons below against primary sources.
This is a selected comparison, not a representative study of open source. The linked documents can change. These summaries describe the sources checked on the correction date; they do not establish a majority position, a universal exception, or the best policy for another project.
The previous version misattributed research findings, overstated the relationship between contribution-signing instruments and attribution rules, treated an example disclosure sentence as mandatory wording, and made unsupported claims about the motives and effectiveness of prose restrictions. It also omitted exceptions in its summary table and included policy statements that are no longer current, notably Astropy's disclosure rule. Those claims are corrected below. Older revisions remain available in the gist's revision history.
The projects below differ about disclosure and generated communication, but their policies repeatedly require a human to review contributions, understand the changes, and engage with reviewers. That is a pattern in this selection, not evidence that every project has the same rule.
It is useful to distinguish four questions when reading a policy:
- What assistance is permitted in code, documentation, and conversation?
- What must the submitting human review, test, understand, or explain?
- What disclosure or attribution is required, and where?
- Which submissions can maintainers reject or restrict?
A rule about one of these questions should not be inferred from an answer to another.
| Project | Communication and human review | Disclosure and scope |
|---|---|---|
| NumPy | Contributors must understand and explain submitted code. AI must not speak for contributors in project communication, except for translation or grammar editing. | Disclosure must identify whether AI was used, which tools, how, and what content was generated. Autonomous code-and-PR submission is prohibited. |
| SciPy | Similar responsibility and communication rules, including explicit translation/grammar exceptions. Similar does not mean every sentence is identical to NumPy's policy. | Itemized disclosure is required; autonomous code-and-PR submission is prohibited. |
| scikit-learn | AI-produced changes must be reviewed, understood, and tested. Pasted generated descriptions/comments are prohibited, with allowances for grammar and assistance for non-native English speakers. | AI use must be stated in the PR description. Fully automated submissions are disallowed; apparent violations may be closed without review. |
| xarray | Descriptions and replies must express the contributor's own substance and reasoning. Language improvement is allowed. Generated code must be reviewed and tested. | PRs follow the project template. Large AI-assisted changes require an issue discussing scope first; this is not permission for autonomous submission. |
| CPython | Writing assistance, particularly for a non-native language, is permitted. Authors must review output and explain changes in their own words. | Disclosure is appreciated but not required. Unproductive submissions may be closed, and repeat disruption can lead to blocking. |
| Astropy | Human ownership, explainability, licensing responsibility, and direct engagement with reviewers are required. Copying replies between a reviewer and a generative tool is not engagement. | Current policy requires disclosure for substantive generative-AI use. The earlier “none” entry is not current. Reviewers expect a human controlling the account. |
| Ghostty | AI-assisted issues/discussions require human review and editing. The human must understand code. Generated media other than text/code is prohibited. | Outside contributors must disclose tools and extent of assistance. Maintainers are exempt. The policy also describes a public list restricting future contributions from bad AI drivers. |
| Kubernetes | Human understanding and verification are required; generated review responses, large generated PRs, and generated commit messages are prohibited. | AI use belongs in the PR description; the policy's sentence is an example, not fixed mandatory wording. AI coauthorship, cosigning, and attribution trailers are prohibited. Inability to explain a change or failure to engage directly can each lead to closure. |
These distinctions are lost in a simple “AI prose allowed/banned” column. Translation, grammar editing, original explanation, review replies, and generated commit messages can have different rules within the same project.
The Linux kernel's assistant guidance prohibits agents from adding Signed-off-by: the human submitter certifies the DCO. It specifies Assisted-by attribution; its current example uses Assisted-by: LLM [TOOL1] [TOOL2]. The earlier version of this survey quoted a different format. Contributors should use the current project guidance rather than assume all projects accept the same trailer.
Kubernetes' Steering Committee explanation separates two concerns. AI coauthorship and cosigning conflict with its CLA requirements. The prohibition on assisted-by and similar trailers also addresses vendors presenting accepted contributions as project endorsement or marketing. It is inaccurate to explain both prohibitions solely as “AI cannot sign a CLA.”
The Apache Software Foundation's guidance provides a counterexample to the proposed rule that a CLA entails an attribution-trailer ban: ASF discusses contributor obligations under its ICLA while recommending a Generated-by: token for generative tooling. Contributions remain subject to its detailed rights and third-party licensing conditions; the same guidance applies to documentation.
The practical lesson is to check the project's actual attribution and contribution policies. A project without a DCO or CLA cannot conclude from that fact alone that licensing concerns are irrelevant. Nor does an attribution label certify that the content is correct or properly licensed.
Airflow's agent instructions distinguish a draft posted without human review from one reviewed and approved before posting:
Drafted-by: <Agent Name and Version> (no human review before posting)
Drafted-by: <Agent Name and Version>; reviewed by @<github-handle> before posting
The named reviewer must actually have read and approved the draft; merely running an agent on someone's behalf does not satisfy that condition. Airflow also directs agents not to list themselves as commit coauthors.
This is a concrete example of recording review state separately from tool identity. It may help readers decide what to verify, but it is not proof of review quality and does not establish that labels outperform restrictions on generated prose. No count of how many projects use this approach is claimed here.
Lulla et al., On the Impact of AGENTS.md Files on the Efficiency of AI Coding Agents compared Codex runs with and without existing root AGENTS.md files across 10 repositories and 124 small PR tasks. It reported 28.64% lower median runtime and 16.58% lower output-token consumption, with comparable task completion behavior. The linked version identifies Journal Ahead Workshop 2026, not an ICSE main-track paper.
It did not compare human-written versus LLM-generated instruction files. The earlier attribution of roughly 2% lower success, 23% higher cost, and a recommendation to omit generated files was incorrect for this source. It also did not demonstrate a general distinction between reliable obedience to mechanical instructions and unreliable policy judgment.
The SciPy discussion of agent instruction files contains individual experiments, observations, and proposals about concise guidance. Those are useful practitioner observations, but they should not be merged with the paper's results or presented as a controlled general finding about all agents.
The original survey informed a proposed Zarr policy distinguishing human accountability from tool-composed text. That proposal's acceptance must be determined from the PR and project policy, not from this survey.
Possible design questions include:
- Should generated PR detail be allowed after a human-written explanation?
- Should labels identify both the tool and whether a human reviewed the text?
- Should review replies have stricter rules than initial descriptions?
- What must contributors test and be able to explain before requesting review?
- What enforcement can maintainers apply consistently within their available review time?
These are choices to evaluate, not consequences proven by the comparisons above. A first sentence does not guarantee understanding; reading and editing are distinct actions; an attestation can be false; and a reviewed summary still requires reviewer attention. A template checkbox records an assertion rather than independently enforcing compliance.
The earlier claims that prose restrictions are merely procedural tripwires, that labels are strictly better, or that a particular policy fits a project's contributor population were unsupported. Stated concerns about human communication, licensing, and reviewer time should not be replaced with an invented single motive.
These links preserve the broader reading list. Their current contents and policy status are not classified by this revision; a missing or unverified rule must not be treated as a finding that no policy exists. The detailed comparison above is limited to sources actually checked for its claims.
- pandas contribution guide
- Django patch-submission guide
- curl contribution guide
- QEMU code-provenance policy
- Gentoo AI policy
- NetBSD commit guidelines
- Servo contributor guide
- Rust policy discussion
- Jupyter AI page
- Home Assistant contribution guide
- Fedora's September 2025 policy proposal — the page's later comment links the approved revised text. The initial proposal alone is not evidence that every proposed provision was adopted unchanged.
Primary policy documents govern actual contributions. This survey summarizes selected rules and identifies differences; it does not substitute for reading the destination project's current requirements.