Re: [Biopython] Generative AI policy for contributions to Biopython
Michiel de Hoon <[email protected]> Mon, 27 Apr 2026 13:22:39 +0000 (UTC)
| Newsgroups | gmane.comp.python.bio.general |
|---|---|
| Message-ID | <[email protected]> |
--===============6580323210827503286==
Content-Type: multipart/alternative;
boundary="----=_Part_3424713_843347634.1777296159308"
------=_Part_3424713_843347634.1777296159308
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
> How do you feel about the communication side (eg insisting on human> writ=
ten commit messages and pull request interactions)?
Yes, communication should be by a human. Sometimes the issue with PRs is no=
t so much the code itself, but how it fits in with the overall structure of=
Biopython, and the direction in which Biopython is heading. Those can be j=
udgement calls, which cannot easily be made by AI.
-Michiel
On Monday, April 27, 2026 at 07:53:50 PM GMT+9, Peter Cock <p.j.a.cock@=
googlemail.com> wrote: =20
=20
That sounds similar to the new Linux policy (linked to earlier). I'm
not convinced this is the right choice, but it is a pragmatic stance.
Would you like to try drafting a policy (perhaps as a draft pull
request editing at least the CONTRIBUTING file and the pull request
template)?
How do you feel about the communication side (eg insisting on human
written commit messages and pull request interactions)?
Peter
On Sat, Apr 25, 2026 at 12:44=E2=80=AFAM Michiel de Hoon <[email protected]=
om> wrote:
>
> I am in favor of accepting code generated by AI in principle, as long as =
whoever submits the code is responsible for the contributed code.
> Key points are:
> - Contributed code (whether generated by AI or not) must be understood by=
the PR submitter;
> - The PR submitter takes responsibility for guaranteeing that the contrib=
uted code is free of license restrictions, and therefore can be released un=
der Biopython's license. But the same requirement holds for any code contri=
buted to Biopython, not just AI-generated code.
>
> Best,
> -Michiel
> On Friday, April 24, 2026 at 07:16:23 PM GMT+9, Peter Cock <p.j.a.cock@go=
oglemail.com> wrote:
>
>
> Dear Biopythoneers,
>
> We need to set out a generative AI policy for contributions to Biopython.
>
> There are now multiple recent PRs submitted by new contributors which
> are openly using AI tools, more that I suspect are, and now even AI assis=
ted
> PRs from past contributors (where CV padding or other external metrics
> are unlikely to be driving this). These are generally more work to review
> than human written PRs, and that is a growing issue.
>
> I blogged about my views late last year - ending in the line "Right now, =
I
> still lean very much to saying no any PR using generative AI".
>
> https://blastedbio.blogspot.com/2025/11/thoughts-on-generative-ai-contrib=
utions.html
>
> Things will change (both tool capabilities, but also the social and legal
> interpetations) but that post still describes my views today - note I did
> not touch on the topic of communications there (see below).
>
> Recently Linux adopted what has been described as a balanced stance
> treating it as a tool with very clear expectations that usage MUST be dec=
lared
> and that the human submitter is responsible for (quoting these four point=
s):
>
> * Reviewing all AI-generated code
> * Ensuring compliance with licensing requirements
> * Adding their own Signed-off-by tag to certify the DCO
> * Taking full responsibility for the contribution
>
> https://docs.kernel.org/process/coding-assistants.html
>
> That is pragmatic but ignores the legal and ethical minefield. We don't
> have a Developer Certificate of Origin (DCO), but I think the other
> points are a bare minimum for any Biopython policy.
>
> Most of my personal open source projects have only had a very small
> number of contributors, and I am comfortable with outright rejecting
> generative AI. I know some of the past/current Biopython contributors
> are more willing to embrace this technology though - so I doubt support
> for a simple ban would be unanimous.
>
> Speaking for a moment as the current Open Bioinformatics Foundation
> president, the board has discussed this and agreed not to try to micro
> manage the member projects. For reference, BioPerl have started
> https://github.com/bioperl/bioperl-live/issues/407 which has some
> excellent points and examples to consider.
>
> In particular, this is not just a code or documentation changes issue - b=
ut
> also about the communication around any proposed change: the nature
> of the commit messages, pull request description, and discussion. This
> ties into the maintainers' burden - many of our recent AI generated PRs
> have fairy short code changes but the verbose text is exhausting to read
> and unhelpful. It has sometimes felt like I have been talking to an AI ag=
ent
> rather than a human - I actually liked the feeling of mentoring a new
> contributor and guiding them through minor hurdles to getting their
> change accepted, but you lose that with an AI agent inbetween you.
>
> I therefore very much like this line from the curreth Codeberg policy:
>
> > All communication, that includes: commit messages, pull request
> > messages, documentation, code comments and issues (and
> > comments on issues/pull requests), that is intended to be read
> > by people to understand your thoughts and work must not have
> > been generated with AI. We exclude machine translation and
> > tooling that helps with grammar and spelling check.
>
> https://codeberg.org/comaps/Governance/src/branch/main/AI_USAGE.md
>
> Would anyone like to speak in defence of accepting AI (assisted) PRs,
> and suggest an existing policy you would be happy we adopt or base
> ours on?
>
> Or should I start drafting a more draconian but likely much shorter one -
> a few lines like this in the CONTRIBUTING file and/or PR template: No
> generative AI to be used in any Biopython contributions, with the excepti=
on
> of machine translation to/from English (where you might consider includin=
g
> your original language text as well).
>
> Thank you,
>
> Peter
=20
------=_Part_3424713_843347634.1777296159308
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body><div class=3D"ydp1ddb82fyahoo-style-wrap" style=3D=
"font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:10px;">=
<div dir=3D"ltr">> How do you feel about the communication side (eg insi=
sting on human</div><div dir=3D"ltr" data-setdir=3D"false"><div><div dir=3D=
"ltr">> written commit messages and pull request interactions)?</div><di=
v dir=3D"ltr"><br></div><div dir=3D"ltr" data-setdir=3D"false">Yes, communi=
cation should be by a human. Sometimes the issue with PRs is not so much th=
e code itself, but how it fits in with the overall structure of Biopython, =
and the direction in which Biopython is heading. Those can be judgement cal=
ls, which cannot easily be made by AI.</div><div dir=3D"ltr" data-setdir=3D=
"false"><br></div><div dir=3D"ltr" data-setdir=3D"false">-Michiel</div><div=
dir=3D"ltr"><br></div><div dir=3D"ltr"><br></div></div><br></div><div><br>=
</div>
=20
</div><div id=3D"ydp4fbadd4fyahoo_quoted_8241258448" class=3D"ydp4f=
badd4fyahoo_quoted">
<div style=3D"font-family:'Helvetica Neue', Helvetica, Arial, s=
ans-serif;font-size:13px;color:#26282a;">
=20
<div>
On Monday, April 27, 2026 at 07:53:50 PM GMT+9, Pet=
er Cock <[email protected]> wrote:
</div>
<div><br></div>
<div><br></div>
=20
=20
<div><div dir=3D"ltr">That sounds similar to the new Linux =
policy (linked to earlier). I'm<br></div><div dir=3D"ltr">not convinced thi=
s is the right choice, but it is a pragmatic stance.<br></div><div dir=3D"l=
tr"><br></div><div dir=3D"ltr">Would you like to try drafting a policy (per=
haps as a draft pull<br></div><div dir=3D"ltr">request editing at least the=
CONTRIBUTING file and the pull request<br></div><div dir=3D"ltr">template)=
?<br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">How do you feel abou=
t the communication side (eg insisting on human<br></div><div dir=3D"ltr">w=
ritten commit messages and pull request interactions)?<br></div><div dir=3D=
"ltr"><br></div><div dir=3D"ltr">Peter<br></div><div dir=3D"ltr"><br></div>=
<div dir=3D"ltr">On Sat, Apr 25, 2026 at 12:44=E2=80=AFAM Michiel de Hoon &=
lt;<a href=3D"mailto:[email protected]" rel=3D"nofollow" target=3D"_blank=
">[email protected]</a>> wrote:<br></div><div dir=3D"ltr">><br></di=
v><div dir=3D"ltr">> I am in favor of accepting code generated by AI in =
principle, as long as whoever submits the code is responsible for the contr=
ibuted code.<br></div><div dir=3D"ltr">> Key points are:<br></div><div d=
ir=3D"ltr">> - Contributed code (whether generated by AI or not) must be=
understood by the PR submitter;<br></div><div dir=3D"ltr">> - The PR su=
bmitter takes responsibility for guaranteeing that the contributed code is =
free of license restrictions, and therefore can be released under Biopython=
's license. But the same requirement holds for any code contributed to Biop=
ython, not just AI-generated code.<br></div><div dir=3D"ltr">><br></div>=
<div dir=3D"ltr">> Best,<br></div><div dir=3D"ltr">> -Michiel<br></di=
v><div dir=3D"ltr">> On Friday, April 24, 2026 at 07:16:23 PM GMT+9, Pet=
er Cock <<a href=3D"mailto:[email protected]" rel=3D"nofollow" t=
arget=3D"_blank">[email protected]</a>> wrote:<br></div><div dir=
=3D"ltr">><br></div><div dir=3D"ltr">><br></div><div dir=3D"ltr">>=
Dear Biopythoneers,<br></div><div dir=3D"ltr">><br></div><div dir=3D"lt=
r">> We need to set out a generative AI policy for contributions to Biop=
ython.<br></div><div dir=3D"ltr">><br></div><div dir=3D"ltr">> There =
are now multiple recent PRs submitted by new contributors which<br></div><d=
iv dir=3D"ltr">> are openly using AI tools, more that I suspect are, and=
now even AI assisted<br></div><div dir=3D"ltr">> PRs from past contribu=
tors (where CV padding or other external metrics<br></div><div dir=3D"ltr">=
> are unlikely to be driving this). These are generally more work to rev=
iew<br></div><div dir=3D"ltr">> than human written PRs, and that is a gr=
owing issue.<br></div><div dir=3D"ltr">><br></div><div dir=3D"ltr">> =
I blogged about my views late last year - ending in the line "Right now, I<=
br></div><div dir=3D"ltr">> still lean very much to saying no any PR usi=
ng generative AI".<br></div><div dir=3D"ltr">><br></div><div dir=3D"ltr"=
>> <a href=3D"https://blastedbio.blogspot.com/2025/11/thoughts-on-genera=
tive-ai-contributions.html" rel=3D"nofollow" target=3D"_blank">https://blas=
tedbio.blogspot.com/2025/11/thoughts-on-generative-ai-contributions.html</a=
><br></div><div dir=3D"ltr">><br></div><div dir=3D"ltr">> Things will=
change (both tool capabilities, but also the social and legal<br></div><di=
v dir=3D"ltr">> interpetations) but that post still describes my views t=
oday - note I did<br></div><div dir=3D"ltr">> not touch on the topic of =
communications there (see below).<br></div><div dir=3D"ltr">><br></div><=
div dir=3D"ltr">> Recently Linux adopted what has been described as a ba=
lanced stance<br></div><div dir=3D"ltr">> treating it as a tool with ver=
y clear expectations that usage MUST be declared<br></div><div dir=3D"ltr">=
> and that the human submitter is responsible for (quoting these four po=
ints):<br></div><div dir=3D"ltr">><br></div><div dir=3D"ltr">> * Revi=
ewing all AI-generated code<br></div><div dir=3D"ltr">> * Ensuring compl=
iance with licensing requirements<br></div><div dir=3D"ltr">> * Adding t=
heir own Signed-off-by tag to certify the DCO<br></div><div dir=3D"ltr">>=
; * Taking full responsibility for the contribution<br></div><div dir=3D"lt=
r">><br></div><div dir=3D"ltr">> <a href=3D"https://docs.kernel.org/p=
rocess/coding-assistants.html" rel=3D"nofollow" target=3D"_blank">https://d=
ocs.kernel.org/process/coding-assistants.html</a><br></div><div dir=3D"ltr"=
>><br></div><div dir=3D"ltr">> That is pragmatic but ignores the lega=
l and ethical minefield. We don't<br></div><div dir=3D"ltr">> have a Dev=
eloper Certificate of Origin (DCO), but I think the other<br></div><div dir=
=3D"ltr">> points are a bare minimum for any Biopython policy.<br></div>=
<div dir=3D"ltr">><br></div><div dir=3D"ltr">> Most of my personal op=
en source projects have only had a very small<br></div><div dir=3D"ltr">>=
; number of contributors, and I am comfortable with outright rejecting<br><=
/div><div dir=3D"ltr">> generative AI. I know some of the past/current B=
iopython contributors<br></div><div dir=3D"ltr">> are more willing to em=
brace this technology though - so I doubt support<br></div><div dir=3D"ltr"=
>> for a simple ban would be unanimous.<br></div><div dir=3D"ltr">><b=
r></div><div dir=3D"ltr">> Speaking for a moment as the current Open Bio=
informatics Foundation<br></div><div dir=3D"ltr">> president, the board =
has discussed this and agreed not to try to micro<br></div><div dir=3D"ltr"=
>> manage the member projects. For reference, BioPerl have started<br></=
div><div dir=3D"ltr">> <a href=3D"https://github.com/bioperl/bioperl-liv=
e/issues/407" rel=3D"nofollow" target=3D"_blank">https://github.com/bioperl=
/bioperl-live/issues/407</a> which has some<br></div><div dir=3D"ltr">> =
excellent points and examples to consider.<br></div><div dir=3D"ltr">><b=
r></div><div dir=3D"ltr">> In particular, this is not just a code or doc=
umentation changes issue - but<br></div><div dir=3D"ltr">> also about th=
e communication around any proposed change: the nature<br></div><div dir=3D=
"ltr">> of the commit messages, pull request description, and discussion=
. This<br></div><div dir=3D"ltr">> ties into the maintainers' burden - m=
any of our recent AI generated PRs<br></div><div dir=3D"ltr">> have fair=
y short code changes but the verbose text is exhausting to read<br></div><d=
iv dir=3D"ltr">> and unhelpful. It has sometimes felt like I have been t=
alking to an AI agent<br></div><div dir=3D"ltr">> rather than a human - =
I actually liked the feeling of mentoring a new<br></div><div dir=3D"ltr">&=
gt; contributor and guiding them through minor hurdles to getting their<br>=
</div><div dir=3D"ltr">> change accepted, but you lose that with an AI a=
gent inbetween you.<br></div><div dir=3D"ltr">><br></div><div dir=3D"ltr=
">> I therefore very much like this line from the curreth Codeberg polic=
y:<br></div><div dir=3D"ltr">><br></div><div dir=3D"ltr">> > All c=
ommunication, that includes: commit messages, pull request<br></div><div di=
r=3D"ltr">> > messages, documentation, code comments and issues (and<=
br></div><div dir=3D"ltr">> > comments on issues/pull requests), that=
is intended to be read<br></div><div dir=3D"ltr">> > by people to un=
derstand your thoughts and work must not have<br></div><div dir=3D"ltr">>=
; > been generated with AI. We exclude machine translation and<br></div>=
<div dir=3D"ltr">> > tooling that helps with grammar and spelling che=
ck.<br></div><div dir=3D"ltr">><br></div><div dir=3D"ltr">> <a href=
=3D"https://codeberg.org/comaps/Governance/src/branch/main/AI_USAGE.md" rel=
=3D"nofollow" target=3D"_blank">https://codeberg.org/comaps/Governance/src/=
branch/main/AI_USAGE.md</a><br></div><div dir=3D"ltr">><br></div><div di=
r=3D"ltr">> Would anyone like to speak in defence of accepting AI (assis=
ted) PRs,<br></div><div dir=3D"ltr">> and suggest an existing policy you=
would be happy we adopt or base<br></div><div dir=3D"ltr">> ours on?<br=
></div><div dir=3D"ltr">><br></div><div dir=3D"ltr">> Or should I sta=
rt drafting a more draconian but likely much shorter one -<br></div><div di=
r=3D"ltr">> a few lines like this in the CONTRIBUTING file and/or PR tem=
plate: No<br></div><div dir=3D"ltr">> generative AI to be used in any Bi=
opython contributions, with the exception<br></div><div dir=3D"ltr">> of=
machine translation to/from English (where you might consider including<br=
></div><div dir=3D"ltr">> your original language text as well).<br></div=
><div dir=3D"ltr">><br></div><div dir=3D"ltr">> Thank you,<br></div><=
div dir=3D"ltr">><br></div><div dir=3D"ltr">> Peter<br></div></div>
</div>
</div></body></html>
------=_Part_3424713_843347634.1777296159308--
--===============6580323210827503286==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Biopython mailing list - [email protected]
https://mailman.open-bio.org/mailman/listinfo/biopython
--===============6580323210827503286==--