search

GenericMappingTools / pygmt

A Python interface for the Generic Mapping Tools.
https://www.pygmt.org
BSD 3-Clause "New" or "Revised" License
747 stars 216 forks source link

New maintainer induction checklist in Maintenance guide #346

Closed leouieda closed 3 years ago

leouieda commented 4 years ago

Whenever a new package maintainer is added to the project, they will need to be informed of some procedures (protocols for merging PRs, review, releasing, etc) and be added to other accounts (CI, conda-forge, GitHub, PyPI, Google analytics, etc).

After discussion in #344, it’s clear that we need a checklist with these things to go over new maintainers when they join so we can make sure they are equipped with the proper permissions and information.

leouieda commented 4 years ago

@seisman @weiji14 what do you think?

weiji14 commented 4 years ago

Agree on having a checklist. The MAINTENANCE.md file does need a good refresh (see also #443). I think we can spin off (at least) two separate PRs to tackle this:

weiji14 commented 3 years ago

@seisman, what do you think about bringing @willschlitzer on as a maintainer? I haven't got too much headspace these few months but don't want to slow down the momentum that's going on into PyGMT, but it would be good to get a new face on board, especially someone good at documentation!

seisman commented 3 years ago

@seisman, what do you think about bringing @willschlitzer on as a maintainer?

Yes, I'm thinking about it too. We can give more permissions to @willschlitzer if he is willing to join.

Before that, I'm a little concerned about our current maintenance/permission model. Currently, we have two teams related to PyGMT project:

The python-contributors team only have read permission to the repository, just like any other external contributors. The team is useful when we want to ping them to hear their voices.

The python team have admin permission to the repository, so they can do anything to the repository. They may be able to even delete the repository or force-push the master branch. I think we should keep the team as small as possible.

So, I suggest we add one more team (e.g., python-maintainers) which have write or maintain permission only?

References: https://docs.github.com/en/free-pro-team@latest/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization#permission-levels-for-repositories-owned-by-an-organization

weiji14 commented 3 years ago

The python-contributors team only have read permission to the repository, just like any other external contributors. The team is useful when we want to ping them to hear their voices.

This group probably should have triage permissions set, otherwise the read permissions are just like any other Github user. That way they can at least add labels to issues and stuff.

The python team have admin permission to the repository, so they can do anything to the repository. They may be able to even delete the repository or force-push the master branch. I think we should keep the team as small as possible.

So, I suggest we add one more team (e.g., python-maintainers) which have write or maintain permission only?

I'd prefer to have less of a hierarchy, but ok with a middle ground write/maintain team here. Let's see what @willschlitzer prefers.

seisman commented 3 years ago

This group probably should have triage permissions set, otherwise the read permissions are just like any other Github user. That way they can at least add labels to issues and stuff.

Yes, I agree. I just made this change at https://github.com/orgs/GenericMappingTools/teams/python-contributors/repositories.

willschlitzer commented 3 years ago

@seisman @weiji14 I'd be happy to take on additional roles in the project. Full disclosure , I'm still very new to open-source development (this is the first project I've contributed to), and I don't have a good understanding of the more advanced parts of the project (how the testing deployment works, how PyGMT communicates with the GMT API, compatibility with different Python versions, some of the Python decorators, how to wrap functions, etc.). I'd welcome the chance to do and learn more, but I want to manage expectations that some of the pull requests/issues are above my current knowledge level.

Regarding the permission levels, I am in support of a python-maintainers team that still doesn't grant full admin permissions. While I understand not trying to make a hierarchy in an open-source project, I think it's best to limit the number of people who can force-push or delete the repository. As I understand the repository permissions, maintain permissions still allow merging and closing issues/pull requests, which I think is level that allows additional contributions from a team member but limits the risk that they (or someone who compromises their account) destructively edit the repository.

weiji14 commented 3 years ago

You'll do great, don't worry about knowing all the advanced parts. There's a lot of trial and error involved in open source and we pretty much learn things as we go along! I definitely think you've got a good enough grasp on the PyGMT API and Python testing to be an active contributor/maintainer :D

@seisman, could you set up the python-maintainers team please? I haven't got permissions in the GenericMappingTools org to do so. Once that's done, we should get @willschlitzer to draft up an onboarding checklist and close this issue ;)

seisman commented 3 years ago

Done with the python-maintainers team.

willschlitzer commented 3 years ago

@weiji14 What do you have in mind for an onboarding checklist? I know @leouieda mentioned procedures and accounts, but I'm not sure what those are/how one would have access?

weiji14 commented 3 years ago

Yeah, some stuff like Azure won't be needed anymore. If I were you, I'd start an 'Onboarding maintainer' PR, and add stuff to it everytime you get access to something in the coming days/weeks. E.g.: