GenericMappingTools / GenericMappingTools/pygmt
Revisit project authorship policy for the AI era
- Dominant language
- Python
- Stars
- 874
- Forks
- 255
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 40
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
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: #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](https://help.zenodo.org/docs/deposit/describe-records/creators/) and [Contributors](https://help.zenodo.org/docs/deposit/describe-records/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 https://github.com/GenericMappingTools/pygmt/issues/4759.
Contributor guide
Research direction
Start by reading AUTHORSHIP.md and AUTHORS.md, then review the related issue #4759 and the linked Zenodo creator/contributor guidance. The issue is currently a policy discussion, so work is done only when maintainers agree on a revised authorship and release-credit policy and document the decision.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100