<div dir="ltr"><div>I like the NumPy/SciPy policy.<br><br></div><div>Their outline resonates well with my intuition of how to (1) avoid slop / malicious code; (2) avoid agentic submission (3) mitigate copyright violations (4) using disclosures to understand the AI component of any PR.</div><div><br></div><div>I suggest to also add the following requirement: submissions should include meaningful inline documentation / docstrings, that is NOT AI generated. This will require the submitter to prove code understanding AND ensure that communication is not via AI. This is on top of a meaningful (read: "long") documentation and reasoning as part of the PR.</div><div><br></div><div>My humble $0.02</div><div><br></div><div>./I </div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Oct 21, 2026 at 12:51 PM Roo Sczesnak <<a href="mailto:andrewscz@gmail.com">andrewscz@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">+1 to adopting a more moderate AI contribution policy, following NumPy/SciPy's example. IMHO, a blanket ban on all AI tool usage is heavy-handed. It is entirely possible to write great code with AI tools. A blanket ban won't stop anyone from using the tools, it just forces them to obscure their usage.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 21, 2026 at 4:42 AM Peter Cock <<a href="mailto:p.j.a.cock@googlemail.com" target="_blank">p.j.a.cock@googlemail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, Oct 11, 2026 at 11:48 AM Peter Cock <<a href="mailto:p.j.a.cock@googlemail.com" target="_blank">p.j.a.cock@googlemail.com</a>> wrote:<br>
><br>
> ... I understand that Michiel favours a more<br>
> permissive policy like NumPy or SciPy adopted, based on technical<br>
> merits and still expecting human understanding of the code. ...<br>
><br>
> Would any of you like to put forward an alternative AI policy draft<br>
> pull request based on NumPy and SciPy please (I find the Python<br>
> project text too light on detail), including our consensus that the<br>
> communications at least should be human written (but possibly computer<br>
> translated into English). I think we need something concretely enough<br>
> that we can review PRs consistently. One of the advantages of a no-AI<br>
> policy is the line for what is or isn't acceptable is much easier to<br>
> follow.<br>
<br>
As I noted on my no-AI PR yesterday, BioPerl is looking at adopting<br>
the CoMaps/Forejo AI policy:<br>
<br>
<a href="https://github.com/bioperl/bioperl-live/issues/407#issuecomment-6275498900" rel="noreferrer" target="_blank">https://github.com/bioperl/bioperl-live/issues/407#issuecomment-6275498900</a><br>
<a href="https://codeberg.org/comaps/Governance/src/branch/main/AI_USAGE.md" rel="noreferrer" target="_blank">https://codeberg.org/comaps/Governance/src/branch/main/AI_USAGE.md</a><br>
<br>
It has a lot in common with the NumPy/SciPy policy (both based on<br>
SymPy), both stress human communications and no autonomous agents<br>
(which if followed would limit some of the worst aspects of slop PRs),<br>
but these are more explicit about copyright (but not explicitly about<br>
attribution):<br>
<br>
<a href="https://numpy.org/doc/stable/dev/ai_policy.html" rel="noreferrer" target="_blank">https://numpy.org/doc/stable/dev/ai_policy.html</a><br>
<a href="https://docs.scipy.org/doc/scipy/dev/conduct/ai_policy.html" rel="noreferrer" target="_blank">https://docs.scipy.org/doc/scipy/dev/conduct/ai_policy.html</a><br>
<br>
NumPy/SciPy have a minimal PR template which includes an "AI<br>
Generation Disclosure" point. CoMap's PR template is closer to ours<br>
with checkboxes:<br>
<br>
<a href="https://codeberg.org/comaps/comaps/src/branch/main/.forgejo/PULL_REQUEST_TEMPLATE.yml" rel="noreferrer" target="_blank">https://codeberg.org/comaps/comaps/src/branch/main/.forgejo/PULL_REQUEST_TEMPLATE.yml</a><br>
<br>
If Biopython is going to adopt a moderate stance on AI contributions<br>
(which I remain opposed to in principle), these are a reasonable<br>
starting point. I can see arguments in following either (consistency<br>
with sister project BioPerl, or Biopython's main dependency library,<br>
NumPy), or drawing on both.<br>
<br>
Again, would anyone like to put together an alternative AI policy PR<br>
along these lines?<br>
<br>
Peter<br>
_______________________________________________<br>
Biopython mailing list  -  <a href="mailto:Biopython@biopython.org" target="_blank">Biopython@biopython.org</a><br>
<a href="https://mailman.open-bio.org/mailman/listinfo/biopython" rel="noreferrer" target="_blank">https://mailman.open-bio.org/mailman/listinfo/biopython</a><br>
</blockquote></div>
_______________________________________________<br>
Biopython mailing list  -  <a href="mailto:Biopython@biopython.org" target="_blank">Biopython@biopython.org</a><br>
<a href="https://mailman.open-bio.org/mailman/listinfo/biopython" rel="noreferrer" target="_blank">https://mailman.open-bio.org/mailman/listinfo/biopython</a><br>
</blockquote></div><div><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Iddo Friedberg</div><div><br>++++++++++[>+++>++++++>++++++++>++++++++++>+++++++++++<<<<<-]>>>>++++.><br>++++++..----.<<<<++++++++++++++++++++++++++++.-----------..>>>+.-----.<br>.>-.<<<<--.>>>++.>+++.<+++.----.-.<++++++++++++++++++.>+.>.<++.<<<+.>><br>>>----.<--.>++++++.<<<<------------------------------------.<br></div></div></div>