Use a CODEOWNERS file to identify maintainers?

[brian-rose]

Following discussion at this week's Pythia Community Meeting, I'm looking into some easy steps we could take to have identified maintainers for each cookbook repo. The overarching idea is that when people contribute new cookbook content to the gallery, we're setting an expectation that someone will help keep an eye on its health.

Features that I think would be helpful to have:

1. specific individual users identified as having opted in to being maintainers for the cookbook content
2. Maintainers (along with the core Pythia team) have push access to the repo
3. Maintainers get tagged for PR reviews
4. Maintainers receiving notifications when health-testing builds are failing

Seems to me the simplest way to achieve at least goals 1 - 3 is just to include a .github/CODEOWNERS file in each cookbook repo. The content of that file can be as simple as

* @[maintainer1 username] 

or for multiple maintainers

* @[maintainer1 username] @[maintainer2 username] @[maintainer3 username] 

etc.

As part of the Cookbook review process, prior to accepting a new Cookbook into the gallery, reviewers can just check to see that maintainers have been specified in the CODEOWNERS file, and verify that those individuals have consented to this.

Future changes to the maintainer list would just take the form of PRs making changes to the CODEOWNERS file.

This seems like something simple enough that we can implement it very quickly, with an empty CODEOWNERS file here in the template, and a brief update to our Contributor's Guide explaining how to add names to a new cookbook.

The big advantage that I see to this approach is that it keeps things simple. We don't build any new automation that we need to then maintain. All the automation comes from GitHub itself, which will use the CODEOWNERS file to auto-tag maintainers for reviews of PRs.

[brian-rose]

An alternative is to create GitHub teams associated with each cookbook. Team members would be the identified maintainers. In this case, we would still have a CODEOWNERS file but it would look like

* @ProjectPythia/[name of the cookbook team]

and all maintainers would need to be members of the ProjectPythia organization (which is already our goal).

One advantage of this approach is it would let us ping the maintainers with an @ reference to the team rather than individually. But that doesn't seem like a big deal. There might be bigger advantages to setting up teams with respect to setting up automation in the future.

[brian-rose]

I've been looking at how this all works in conda-forge as a model, where individual feedstock repos have identified maintainers who are members of the broad organization but only have push access to the feedstock repos they maintain.

@dopplershift I have a question that you might be able to answer about how teams are used in feedstock repos.

For example, one of the feedstocks I maintain has this team:
https://github.com/orgs/conda-forge/teams/climlab
but it also has a CODEOWNERS file with the same individuals explicitly listed:
https://github.com/conda-forge/climlab-feedstock/blob/main/.github/CODEOWNERS

• Why does the CODEOWNERS file list individuals rather than listing the team? Does this apparent redundancy serve a purpose?
• Is the team used in some of the conda-forge automation in ways that might become useful for Project Pythia?
• Should we stick with the simple, explicit approach of just manually editing a CODEOWNERS file instead?

[dopplershift]

I'm not sure why the CODEOWNERS doesn't list a team, but I will say that the team roster is managed by a bot, and that the CODEOWNERS is automatically generated, all from the list of maintainers in the recipe.

Since teams are an organization-level concept, there are a few feedstocks that use the same team across multiple feedstocks. I believe most of the R ecosystem has this.

[brian-rose]

Maybe this is something the infrastructure team can discuss during next week's hackathon. I would love to have some minimal system in place after hackathon to keep track of maintainers.

[jukent]

One case to consider: We have Cookbooks written by a team of scientists, one of them does all of the work to push their final code to its Cookbook repo (or to take a tutorial they wrote together and translate it into a Cookbook). In this case there are authors that are manually added that aren't represented in the contributor's file. Should we still give them maintainer status?

[brian-rose]

One case to consider: We have Cookbooks written by a team of scientists, one of them does all of the work to push their final code to its Cookbook repo (or to take a tutorial they wrote together and translate it into a Cookbook). In this case there are authors that are manually added that aren't represented in the contributor's file. Should we still give them maintainer status?

That decision should be made by the author team, not us. We're looking for individuals who volunteer some interest in staying connected to the cookbook over time.