Maintainers for packages

[leouieda]

Right now, the maintenance roles across our packages are a bit fuzzy. I do a lot of the releasing and admin and @santisoler has been stepping up quite a bit in Harmonica and RockHound. It would be nice to have explicitly defined maintainers for each project (in a document here maybe and also in each project's README).

Maintainers would be responsible for:

1. Merging PRs (usually also reviewing but others are welcome take on the responsibility).
2. Making releases. Thanks to our automation, the major work here is compiling the changelog from git history and creating a Zenodo archive. A minor task is merging the PRs in the conda-forge feedstock.
3. Welcoming and recruiting new contributors to each project. This includes mentoring those who wish to contribute something. Of course, this is a shared responsibility but maintainers would be expected to be a role model.

Of course, this is just off the top of my head and open to debate and change.

To their jobs, maintainers would be granted administrator rights to:

1. The repository they maintain (meaning they will be added to the corresponding Github team)
2. PyPI (which is usually never really used since we deploy automatically)
3. CIs (to be able to start and stop jobs, edit configuration, secret variables, etc)
4. conda-forge (by being listed as a maintainer in the recipe)

Ideally, we should have at least 2 maintainers for each package to increase our bus factor.

To be a maintainer of a projects, it seems reasonable to require being active in the project and somewhat knowledgeable of the code base.

Maintainer roles can be changed at any time to accommodate personal/professional life and should not be seen as a permanent commitment.

What I would like to know from the community:

1. Are these reasonable responsibilities/expectations/requirements?
2. What could/should be changed to help preserve the well-being of maintainers?
3. Does anyone wish to volunteer?

Currently, me and @santisoler are maintainers for all packages. It would be great to add more people to share the burden.

[leouieda]

cc @fatiando/contributors

[andersy005]

I am happy to help out with pooch.

[leouieda]

@andersy005 thanks for volunteering! I really appreciate the help.

Do you have any experience with a process for assigning (and retiring) maintainers from your other projects? I'm wondering if we should have a process for this or if we can make it up as we go along.

[andersy005]

Do you have any experience with a process for assigning (and retiring) maintainers from your other projects?

Not really :)

I'm wondering if we should have a process for this or if we can make it up as we go along.

It looks like there is an existing list of teams under the fatiando org. Can we start with those and maybe re-purpose or define what kind of tasks to be carried out by different teams, and see how things go?

[leouieda]

Not really :)

Good to know we're all in the same boat :)

It looks like there is an existing list of teams under the fatiando org.

Yeah, those were my original attempt at delegating write access to the repositories. So the Github part of making someone a maintainer is just adding them to the team.

I'd like to have an indicator in the repository as well of who is a maintainer so that users can recognize the person coming in to respond/review.

[leouieda]

Hi @andersy005 and others, a follow-up after our first community call:

We decided to do this in a more relaxed way. Meaning that we'll start delegating PR review and other responsibilities as people manifest interest and available time. This can transition to managing releases etc. Though the release is actually not much work. We mostly need help replying to issues, reviewing PRs, coding, and documentation (more than code actually).

[andersy005]

Thank you for the update, @leouieda! Sorry I couldn't make it to the last community call. I got access to the meeting notes (https://hackmd.io/@fatiando/community-calls-2020) though -- thank you for putting these together.

We decided to do this in a more relaxed way. Meaning that we'll start delegating PR review and other responsibilities as people manifest interest and available time.

👍

This can transition to managing releases etc. Though the release is actually not much work.

Are folks interested in automating some parts of the release procedure (at least for PyPI)? I've been using Github actions for this, and I am happy to submit PRs if need be.

[leouieda]

Are folks interested in automating some parts of the release procedure (at least for PyPI)? I've been using Github actions for this, and I am happy to submit PRs if need be.

We already have the release parts automated (using Travis at the moment). Uploading to PyPI and pushing new docs is all automatic. The only parts that aren't automate are:

• Building the changelog (there is #15 for this but it would require better practices when naming PRs)
• Uploading to Zenodo (their automated deploy is a bit strange and we sometimes need to update the authors)

Both aren't that much trouble and we have guidance in MAINTENANCE.md.

That said, it would be nice to start moving those steps away from Travis and onto Github Actions. See https://github.com/fatiando/continuous-integration and #18