Repository navigation
Revisit project authorship policy for the AI era #4839
Description
Summary
Our current authorship policy (AUTHORSHIP.md) has served PyGMT well since its initial adoption: any contributor with merged pull requests can be added to AUTHORS.md and listed as a formal author on Zenodo release archives. However, the growing AI-generated contributions have changed open-source contributions significantly. This issue initiates a discussion to re-evaluate whether our current authorship policy remains suitable and sustainable for PyGMT’s future development.
Current Observations & Problems
-
“Good First Issue” original purpose is diminished
Our good first issue labels were originally designed to onboard new open-source contributors, especially GMT and PyGMT users, helping beginners learn the codebase and open-source collaboration workflows. Recently, these issues are instantly claimed by anonymous contributors submitting fully AI-generated PRs (xref: Deprecated parameters that are planned to be removed in PyGMT 0.20.0 #4824 and more). Most of these contributors have no prior experience using or understanding GMT/PyGMT, and likely, they won't contribute to this project anymore in the future (I'm not blaming any contributors). This undermines the core onboarding purpose of good first issue. -
Ambiguous authorship eligibility for AI-generated contributions
I fully support AI-assisted development and actively use AI tools myself. External contributors resolving trivial tasks also helps free maintainers to focus on complex feature development. Even so, a critical policy ambiguity has emerged: should one-off, trivial, AI-generated PRs submitted by non-PyGMT/GMT users qualify for formal authorship credit in AUTHORS.md and Zenodo listings? The increasing number of AI-powered contributions dilutes the value of official authorship and results in overly long, low-significance author lists for each release. -
Bloated Zenodo author list
PyGMT currently uses a flat authorship model for Zenodo releases, where all contributors can be listed as formal authors, which makes the authorship very long to maintain. In contrast, the recent GMT release seems to distinguish Creators and Contributors on Zenodo records (https://zenodo.org/records/19398868).
Key Discussion Questions
- Should we revise our authorship policy to distinguish trivial/mechanical/AI-assisted one-off PRs from substantial, project-involved contributions for AUTHORS.md eligibility?
- Do AI-generated drive-by contributions from non-project users qualify for formal authorship credit on Zenodo?
- Should PyGMT adopt the upstream GMT Zenodo model, separating Creators and Contributors to clean up release metadata?
- What can we do for "good first issues" to prioritize new user onboarding over automated drive-by contributions?
Related to #4759.
Activity
willschlitzer commentedon Aug 14, 2026
The authorship policy should be revised to not include one-off PRs. I don't think the bar should be set particularly high (not more than a few PRs and several weeks of contributing), but I think that this project has received enough attention and diverse contributions that having an authorship policy that is inclusive of every one-time contributor will create an absurdly long authorship list. I don't mean to make the PyGMT maintainers gatekeepers, but I think the "easiest" way is to have them be the ones who choose to invite a contributor to be an author. I think it would be tough to write a formal authorship policy that codifies what it means to be an author, and there will ultimately have to be some subjective judgement.
I do not think that AI generated drive-by contributions from non-project users qualify for formal authorship credit. As someone who actively uses AI for code review and suggestions when I hit any sort of blocker (it has been really helpful as I try to wrap my head around
fitcirclein the 4+ years since I last worked on it), I was curious if it could autonomously wrap modules, and directed Claude Code to wrap 4-5 modules and develop tests for them. It took about half an hour, and while I didn't review the code too closely, everything looked fine with a once over and and the tests passed. My point is, I contributed absolutely nothing beyond a paid subscription to an AI lab and it was able to do some of the more demanding work on the project (I'm assuming it could much more easily tackle something like deprecating features or creating tutorials) without any sort of code authorship on my part.Yes, I think this acknowledges contributions on a given release, but there won't be an expectation that contributions from long ago will mean continued inclusion as an author (I feel like I'm writing an argument against my inclusion in future releases 😆 ).
My initial reaction for this was that the maintainers would be the judges of whether or not a contribution is a drive-by AI contribution based upon their perception of the PR as well as the level of engagement from the contributor (asking questions, making follow updates, engaging with the reviewers).
I realized this creates more work for the volunteer maintainers, so with a great sense of irony...I asked Claude what are some measures that can be implemented to keep "good first issues" away from AI.
Some non technical measures it recommended: include in the CONTRIBUTING guideline that "good first issues" are reserved for contributors doing work themselves and AI-assisted/generated PRs will be closed without review, along with an explanation that these issues exist to educate newcomers about the project. It would also have an AI disclosure requirement on the PR template, and requiring a "claim before code", which requires a request for assignment (and a maintainer assigning it); failure to do so would get the PR closed.
Some technical measures it recommended: A GitHub Action bot to check bot heuristics (opening PR soon after the issue is open, no prior commits from the account, commit messages that appear AI generated) and flags the PR; a bot that requires the PR's author to be assigned to the issue, a GitHub Action bot that checks if the account is actively submitting a bunch of "good first issue" PRs, a status check on if the "good first issue" label present and if there is an AI assistance disclosure, and (my favorite) that "good first issue" PRs/issues have some "human questions" like "Describe what you learned or found confusing while working on this". I think that last one not only serves as a check on the human behind the contribution, but also shows some insight to the PyGMT team about how approachable the project's documentation is to a newcomer.
Thanks for letting me ramble for a long time, @seisman. As someone who went from writing Python scripts for myself to now working as a professional software engineer, I owe a lot to the PyGMT team and how welcoming they were to a stranger on the internet who started out by making incredibly minor documentation contributions that later progressed to becoming a project maintainer for several years. The issue of generative AI snatching up the low hanging fruit is something I've thought about since the story about the bot made the PR for matplotlib earlier this year, and I would like future PyGMT maintainers to similarly be able to join the project without having to know all the ins and outs before they can meaningfully contribute.
weiji14 commentedon Aug 27, 2026
Another semi-related issue is how to attribute AI-assisted commits. E.g. The Linux kernel uses
Assisted-by:instead ofCo-authored by:in the commit message (https://docs.kernel.org/process/coding-assistants.html#attribution).One idea might be to restrict authorship to those who have made at least 1 or 2 non-AI-assisted commits (determined by
AI-assisted:labelled commits, which we could enforce)? Obviously this raises the bar, but my general stance on authorship for papers or software in general is that you should have read and understood some aspect of the work itself, and struggled enough to know how to genuinely answer questions about the method/code and its limitations/nuances (and not just have the AI analyze it), before being listed as a co-author.I can draft a revision to the
AUTHORSHIP.mdbased on Will's comment, and then we can maybe do some threaded discussion there?seisman commentedon Aug 28, 2026
Assisted-bysounds good, but we need to find ways to identify the AI use and add it to commit messages automatically. Maybe by a git hook? Or instructions inAGENTS.md(xref: #4677).Sounds good.
yvonnefroehlich commentedon Nov 2, 2026
I am sorry for not commenting on this issue earlier. I find this topic super complex, and thus this issue very difficult to answer. My opinions are not meant in any way to be personal and may change over time. Overall, I am super critical regarding AI and any related technology and against their usage.
I think with AI open-source projects and contributions are lost in the way we had and enjoyed them for the last years. Many contributions are documentation-related. With AI, docstrings, examples, and tutorials can be generated in seconds; there is no value in doing this work by humans anymore. Now people are just asking whatever AI to write the code for them to create the map or figure they need. They will not try to understand the code based on the documentation or adjust the provided examples for their own use case. I do not want to spend my free time reviewing AI-generated content, especially if the submitting person never looked at the AI answer (and does not [want to] understand it), and definitely not in case the PR is generated (and directly submitted) by an AI agent. There is very likely no honest interest in GMT or PyGMT and no real connection to the projects or the community. Thus, it is unlikely these people are contributing more than this PR or longterm. In the end I do their [thinking] work.
I do not think contributions made mainly or entirely with AI should qualify for authorship. Reviewing an AI answer before submitting the PR is not enough, because you are still not the (initial) author of this content (you just paid for an AI subscription). AI should never be seen as an author in a human context. The responsibility is and must always be on the human side. It’s our decision to develop and use AI instead of learning, understanding, thinking, and being creative on our own. AI tools or agents, as well as underlying data or trained models, use content generated by other humans often without properly citing their works, and it's often impossible to figure out from which resources AI got an answer. I never asked for such a technology; I never agreed on using my contents in training AI models. Thinking about and playing with any kind of data, analyzing and modeling it, testing hypotheses, and creating visualizations was the part I enjoyed most and loved so much during my time in academia. I find it highly problematic and personally very sad to accept that people are now forced to either use AI for these working steps or to leave data- or programming-related fields.
A good example is a proposed solution for one of the millennium problems (not officially accepted so far). However, no proper references were given, and after complaints, citations were added to works previously done by leading mathematicians. This is a super unscientific practice and steals people’s ideas and work. I respect that people cannot understand (or ignore) that doing research is not just a job you do or a business deal you finish, and why it is very humiliating to take other people’s ideas as your own. At a certain level, your research represents you as a person, how you see this world, and how you understand it a bit better than before. I feel this is not just a personal feeling, and we have to be very careful that we do not lose what we are passionate about and what defines us as humans by using AI more and more in almost every aspect of our lives. I do not need an AI to craft maps, plots, and sketches of my research; I do not want AI to write the text of my manuscripts. Structuring, formulating, visualizing ideas and approaches is essential to find errors, inconsistencies, oversimplifications, invalid assumptions, or limitations in an argumentation and to communicate new findings and insights. The feeling when looking back to almost ten years of studying and seeing what I was (am) able to learn, understand, and create would not be the same if I knew I had mainly used (reviewed) AI answers. I can think, I can decide based on data and arguments. This makes me free and independent. I do not want to outsource the thinking and creativity process to [pseudo-intelligent] machines. I do not want to become a prisoner of AI or related technology.
weiji14 commentedon Nov 6, 2026
Thanks for voicing your thoughts @yvonnefroehlich, I share much of your sentiments that something meaningful has been lost in open source and research communities this year, and am saddened by the reduction in critical thinking and craft that is going into software and scientific outputs. Personally I still 'hand'write my code (though I have experimented with local models a little bit), which sounds crazy for someone doing GeoAI work, but I don't believe in using AI to do AI (specifically, the vision/non-language parts). For PyGMT, I'm not sure what's the best way forward, but I think we're starting to see an uptick in AI-generated contributions since the past two weeks from folks that don't seem to have a geoscience background, and I'd like to at least learn how to navigate this 'era' with people that I trust here.
Maybe it is worth it to discuss this synchronously in an online meeting. I've personally found it productive to discuss these types of issues in person at workshops/conferences this year, and think it will be much better hearing everyone's actual voice on this topic.
In the meantime, would it be ok if we put a pause on new project authors in AUTHORS.md (note: contributors will still go in the changelog), until we decide on a proper policy?