Add contributing guides for wrapping a GMT module #1687
Conversation
doc/contributing.md
Outdated
| These steps will be tracked in the 'Wrapper for `<module-name>`' issue and the | ||
| ['wrapping GMT modules'](https://github.com/GenericMappingTools/pygmt/projects/9) | ||
| project board. The pull requests can be split between multiple contributors and |
There was a problem hiding this comment.
I think we should either track the module updates in a project board (my preference) or an issue, but not both.
There was a problem hiding this comment.
Do you think we should abandon the 'Wrapper for <module-name>' issues entirely or keep the issues/issue-template and just move the checklist to the project board? I think the main benefit of the issues is that from my understanding any GitHub user can open/comment on an issue whereas writing on the project board requires special permissions.
There was a problem hiding this comment.
I think the project board works better for tracking the progress of wrapping a module, and that having a separate issue for wrapping the function is a bit redundant. I see what you mean about the benefits of issues being open to everyone, but my thought is that wrapping modules is a pretty routine process and doesn't need to first be raised as an issue (unlike a bug or a feature request). We can add some/all of the GMT modules to the project board to track their process. Users who don't have write permission are still free to open up an issue requesting a module/feature (or a pull request! 🤞) as a way to let us know that a certain feature would be useful to them.
There was a problem hiding this comment.
the benefits of issues being open to everyone
IMHO, issues are also more visible than project boards, so that we may have more potential contributors helping wrap new modules and add more aliases.
Co-authored-by: Will Schlitzer <[email protected]>
Co-authored-by: Will Schlitzer <[email protected]>
yvonnefroehlich
left a comment
yvonnefroehlich
left a comment
There was a problem hiding this comment.
Just to be consistent with the other headings.
Co-authored-by: Yvonne Fröhlich <[email protected]>
|
@GenericMappingTools/pygmt-maintainers We usually wait for a few days after a new release, just in case someone reports critical bugs in the new release, which may deserve a quick patch release. I think it's a good time to have some discussions on non-code changes during this time. |
There was a problem hiding this comment.
Pull request overview
This PR adds comprehensive guidance for wrapping GMT modules to the contributing guide and streamlines pull request reminders by clarifying that gallery examples/tutorials should be submitted in separate PRs.
Changes:
- Added a detailed "Wrapping a GMT Module" section with step-by-step guidance
- Updated pull request workflow to specify that gallery examples should be in separate PRs
- Minor grammar fixes ("follow" → "follows", "xarray" → "Xarray")
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <[email protected]>
Description of proposed changes
This PR adds the guidance from #1599 to the contributing guide and shortens the pull request reminders based on the conversation at #1629 (comment).
Fixes #1599
Preview: https://pygmt-dev--1687.org.readthedocs.build/en/1687/contributing.html#wrapping-a-gmt-module