New maintainer induction checklist in Maintenance guide

[leouieda]

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]

@seisman @weiji14 what do you think?

[weiji14]

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:

• Update "Continuous Integration" section to mention Azure Github Actions builds (it's not just Travis.CI anymore) Edit: should be finalized with Run style checks using GitHub Actions instead of Azure Pipelines #519.
• Update "Making a Release" section - could do this in a Release 0.1.0. (Done in Simplify PyGMT Release process #446)

[weiji14]

@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]

@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:

• python team
• python-contributors team

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]

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]

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]

@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]

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]

Done with the python-maintainers team.

[willschlitzer]

@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]

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

• Join python-maintainers team
• Join PyPI organization
• etc