Create nested teams for GenericMappingTools organization

[weiji14]

The GenericMappingTools organization is growing (Woohoo!), and maybe we should think about organizing the teams a bit more. @seisman suggested at GenericMappingTools/pygmt#828 (comment) to use nested teams (see https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/about-teams#nested-teams) for the PyGMT folks, and we're thinking whether to apply it to the wider GMT organization (or not).

Current state

-- core - Developers of the core GMT C project (8 members)
-- python - Core devs of PyGMT (5 members)
-- python-contributors - Contributors to PyGMT (6 members)
-- python-maintainers - Maintainers of Python projects (2 members)
-- sphinx_gmt - Core devs of the GMT sphinx extension (2 members)

Proposed state

Names and structure are up for discussion. Members on the top level has least amount of permissions, and those further down the nesting hierarchy have more permissions (e.g. maintain/admin)

 members - All members in the GMT project, includes GMT, GMTmex, GMT.jl, PyGMT, etc
 ├── gmt-contributors - Contributors to GMT C project
 |    ├── gmt-core - Developers of the core GMT C project
 |    └── sphinx_gmt - Core devs of the GMT sphinx extension
 ├── python-contributors - Contributors to PyGMT
 |    ├── python-core - Core devs (administrators) of PyGMT
 |    └── python-maintainers - Maintainers of PyGMT
 └── julia-contributors

For permission levels, see https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/managing-access-to-your-organizations-repositories

[weiji14]

Ok, how about we start restructuring the pygmt team first since it's the messiest bunch 😛. Following on from GenericMappingTools/pygmt#1056 (comment), maybe do something like this:

└── python-contributors - Contributors to PyGMT (write permission)
      ├── python-maintainers - Maintainers of PyGMT (maintain permission)
      └── python - Core developers of PyGMT (admin permission)

What this means that every python contributor has 'write' permission as a baseline (instead of 'triage' currently), and mentioning @GenericMappingTools/python-contributors will ping everyone working on the PyGMT project. We could have @GenericMappingTools/python nested under @GenericMappingTools/python-maintainers, but I think it might be better put them on the same nesting level so we could ping either the maintainers or the core-devs separately. Thoughts?

[core-man]

I think option 1 is better. but I have a question about pygmt-contributors. Do we still need to put any pygmt-maintainer or -admin/core in python-contributors? Or when we want to give more permission to a pygmt-contributors, copy or move to another team? I feel move better since already have a pygmt umbrella team with everyone. If copy is used, it's better to put pygmt-maintainers and -admin/core within pygmt-contributors. Or we will use both copy and move？

[maxrjones]

I also prefer option 1. My preference is for pygmt to be read access (I don't see people being assigned to a team at that level) and for us to create a pygmt-triage sub-team if needed later on. I do not expect this decision to matter, but prefer to leave the option open. Regarding @core-man's question, I agree that moving would probably be simpler than copying.

[seisman]

If I understand @core-man correctly, "moving" means that any user only belong to one team (pygmt-contributors, pygmt-maitainers or pygmt-admin). So @meghanrjones @weiji14 and I will be in the pygmt-admin team, and @core-man will be in the pygmt-contributors team. When contributors (including us) submit PRs and want to ping someone for review or help, how do they ping us? They have to ping all the 3 teams. I'm afraid it will cause more confusion.

If we use the "copying" mechanism, then we only need to ping pygmt-contributors for review, and ping pygmt-maintainers for merging the PR, and ping pygnt-admin for rare cases that may need admin permission.

So "nested teams" (Option 3) makes more sense, although the nested structure looks complicated.

[maxrjones]

Good points, @seisman and @core-man.

[core-man]

@seisman good summary. you got me. it is the question that confuses me since I began to contribute to PyGMT.

I think nested team is only complicated at the begining and we need put all members at the right teams. But when we want to update one member's permission, it is easy (just copy).

Isn't it like Python base and sub classes? 😄

[core-man]

Perhaps we can give python-contributors "write" permission, but only add people who make continuous contributions to the project.

So the team structure and permission levels are still like the one @weiji14 proposed (#4732 (comment)), but the process is a little different:

1. Invite contributors to add themselves to the AUTHORS.md after their first PR
2. Invite them to the python-contributors team (with write permission) after they make more PRs and show good git skills (e.g., @core-man)
3. Invite/promote them to the python-maintainer team (with maintaining permission) when they actively submit PRs and participant in discussions (e.g., @willschlitzer)

What's the difference between pygmt-maintainers (maintain) and pygmt-admin/core (admin)? Or equally, If pygmt-contributors has the access to write, it seems that there is little difference between pygmt-maintainers and pygmt-contributors. Is my understanding right?

4. Invite/promote them to the python team (with admin permission) when we feel someone should be given admin permission. (As I mentioned somewhere, we should limit the number of people in this team for security reasons).

Yes, I also think so. The admin permission is very important and should have a limited number. Most contributors do not need admin permission to help with PyGMT development. I'd like to suggest PyGMT should only give admin permission to some contributors who continuously contribute to PyGMT, have some good skills (e.g., git, teamwork), win the trust from pygmt-admin and/or other contributors, and (most important) have the passion and responsibility to maintain PyGMT. Meanwhile, when we have enough active administration (e.g., 3~4?), we should not increase pygmt-admin.

Sometimes I feel that people (including myself) may not fully understand what it means and what is changed by being added to a team. So, when we invite anyone to the team, we should also let them know:

• after joining the team, they will have write/maintainance/admin permission, and they can do things like "working in the pygmt repo instead of a fork"
• they should be more responsible as they have more permissions
• they should be more cautious about their operations
• we will ping them by @python-contributors when we want their comments or help and they will be notified

Great. More permissions, more responsibility. Should be more cautious. I think we should let all the contributors/maintenance/administration know it.

[weiji14]

I thought the idea was that there could be people in the 'pygmt' umbrella team with 'triage' permissions only (but they won't belong in the other contributors/maintainers/core teams)? I.e. the base set of permissions is 'triage' in team pygmt, and @core-man would be in pygmt-contributors with 'write' permissions, but most others previously in pygmt-contributors would just stay in the pygmt team?

[maxrjones]

OK, mostly wanted to check that I understand who should be in pygmt versus pygmt-contributors. Functionally, it seems that python-contributors will become pygmt since that is the triage team. I will update accordingly.

[weiji14]

Just to be clear, this is probably the structure we want (correct me if I'm wrong):

└── pygmt-team - The PyGMT umbrella team (triage)
      ├── pygmt-contributors - (write)
      |  └── pygmt-maintainers - (maintain)
      └── pygmt-admin - (admin)

[maxrjones]

Just to be clear, this is probably the structure we want (correct me if I'm wrong):

└── pygmt-team - The PyGMT umbrella team (triage)
      ├── pygmt-contributors - (write)
      |  └── pygmt-maintainers - (maintain)
      └── pygmt-admin - (admin)

OK.

[maxrjones]

Ping @GenericMappingTools/pygmt-contributors

[maxrjones]

The current team structure for PyGMT has worked well in my opinion. I will include a discussion about applying the same structure for GMT teams on the agenda for the next community meeting. For reference, here is the PyGMT team structure:

└── pygmt-team - The PyGMT umbrella team (triage)
      ├── pygmt-contributors - (write)
      |  └── pygmt-maintainers - (maintain)
      └── pygmt-admin - (admin)