On Fri, 2026-02-06 at 11:04 -0700, Nathan via NumPy-Discussion wrote: > On Fri, Feb 6, 2026 at 10:57 AM Charles R Harris via NumPy-Discussion > < > [email protected]> wrote: > >
<snip> > > > > I don't think we have a formal position at this point. > > > > It’s probably time to adopt one and/or add an AGENTS.md file to the > repo. > > I mostly agree with Chuck that there’s mot much we can do to avoid > it. > People will use the tools and not disclose, so any copyright issues > will > happen no matter what policy we have. > > I’m nervous about subtle inconsistencies and hallucinations, > especially > from contributions that are mostly vibe-coded. To me, that means the > code > needs much more careful review than human-written contributions > because the > nature of the errors made are different. > I am just going to third this sentiment. There is a lot of interesting discussions around this but at the core of it, to me there isn't actually a real core policy shift yet. (Which doesn't mean it wouldn't be good to adopt one.) What I mean is that I think contributors always should explain where code comes from (you can map this to copyright, or AI, or a colleague attribution). Also, I expect a contributor to understand the code they are proposing as well as why they propose the change and, to some extend [1], what impact that change has on backwards compatibility. The same is true for the maintainer merging that change, giving us the four eyes principle (you may stress that it is at least four human eyes). And that leaves me fine with contributions even largely written by a tool so long the understanding is still there (and as a reviewer I may need to know about the tool use, I think). And I expect the project could lose a lot of user trust if the number of human eyes on a changeset suddenly dropped. [2] All that said. I am happy to be rather ruthless with suspect tool use and closing of PRs/issues (especially if they don't disclose use). If contributors lack understanding or don't take care they shift work on maintainers and, unfortunately, a perceived increase in such issues/PRs means I am fine if maintainers react rather harshly. [3] - Sebastian [1] This part is hard for many contributors, it indeed falls more on the maintainer. [2] I am not sure it matters how well it might work now or in the future, because NumPy seems like the wrong project to trail-blaze shifts in culture. [3] I don't like the cultural implications of being trigger happy with closing PRs, especially since it is hard to be sure about anything here. But, unfortunately, more tool use may mean that contributors have to do actually do more work to make PRs nice to review. > > > Chuck > > _______________________________________________ > > NumPy-Discussion mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > https://mail.python.org/mailman3//lists/numpy-discussion.python.org > > Member address: [email protected] > > > _______________________________________________ > NumPy-Discussion mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3//lists/numpy-discussion.python.org > Member address: [email protected] _______________________________________________ NumPy-Discussion mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3//lists/numpy-discussion.python.org Member address: [email protected]
