Revisit project authorship policy for the AI era

[seisman]

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

1. “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.

2. 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.

3. 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

1. Should we revise our authorship policy to distinguish trivial/mechanical/AI-assisted one-off PRs from substantial, project-involved contributions for AUTHORS.md eligibility?
2. Do AI-generated drive-by contributions from non-project users qualify for formal authorship credit on Zenodo?
3. Should PyGMT adopt the upstream GMT Zenodo model, separating Creators and Contributors to clean up release metadata?
4. What can we do for "good first issues" to prioritize new user onboarding over automated drive-by contributions?

Related to #4759.

[willschlitzer]

Should we revise our authorship policy to distinguish trivial/mechanical/AI-assisted one-off PRs from substantial, project-involved contributions for AUTHORS.md eligibility?

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.

Do AI-generated drive-by contributions from non-project users qualify for formal authorship credit on Zenodo?

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 fitcircle in 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.

Should PyGMT adopt the upstream GMT Zenodo model, separating Creators and Contributors to clean up release metadata?

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 😆 ).

What can we do for "good first issues" to prioritize new user onboarding over automated drive-by contributions?

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.