Migrate project maintainer data over to cncf/people from maintainers.csv

[Robert Kielty]

Overview

Lift and shift maintainer data so that it can be used by cncf/sheriff to control access to repos in the CNCF GitHub Org.

Benefits: Maintainer Data will have a single source of truth for use in CNCF Process Automation.

Data

Source

https://github.com/cncf/foundation/blob/main/project-maintainers.csv

Destination

https://github.com/cncf/people/blob/main/people.json
and
https://github.com/cncf/people/blob/main/config.yaml

Approaches

Multiple ways we could do this. Here are two suggestions. Open to hearing others.

Big bang

Write a script to process the full project-maintainer.csv file so it updates the destination files in one go (we would have to merge the data so that there were no repeats) this would generate a single PR for cncf/people

Might be hard to review (will have to gauge the overlap between both datasets)

Create a PR for each Project in maintainers.csv

Write a script to create a per-Project/Team PR. This would allow Projects and the CNCF to review the changes on a per project basis offering the opportunity to review team membership as we work through those PRs.

[Amye Scavarda Perrin]

With 147 projects (and 3 in voting) - can we do both?

[Jeffrey Sica]

If we have already tooling in place to manage tooling access, it needs to be in one-go. Otherwise it'll diff against the existing entries in places like ServiceDesk and y'know. Delete them all.

Prefer we coordinate doing one big PR and then scrub references to old maintainers CSV(s).

The tooling work should happen in parallel to (or ideally before) this.

[Ry Jones]

We at Hyperledger are super interested in adopting this workflow

[Robert Kielty]

Met with @jeefy yesterday (March 9th) to design out how to integrate the maintainer data from the csv file into cncf/people.json

We went over three possible iterations and settled on the following for a initial pass at this.

Add a maintainer object to the person record in cncf/people.json as follows:

Maintainer with voting rights looks like this

"maintainer" : {
    "Kube-virt" : "true",   
}

-OR-

Maintainer with no voting rights looks like this

"maintainer" : {
     "Kubernetes" : {
         "voting-rights": "false",
      },
}

Notes:

1. Maintainers by default have voting rights unless explicitly excluded in the current project-maintainers.csv (Embedded in one of the field values) captures this as above for the no-voting exception.
2. Maintainer email addresses are stored in a separate CNCF-private file that should be used a data source to produce the mailing list of voters to facilitate community communications during voting procedures.
3. In addition to point 2. maintainer-based reports should be considered for @amye (chime in during review of this work!)
4. The existing Pull Request review process of the cncf/people.json that allows for human oversight of changes to the file is a key process requirement here and MUST remain in place as-is.
5. In cncf/people the Category field is like a Role
6. We talked about teams and the current absence of explicit Tool/Resource modelling in cncf/people which we will revisit on future tasks. Keywords: plugins, use team definitions keep people data dry allow teams to correlate to roles from a access-to-tools POV

[Robert Kielty]

Development notes

1. I went with Big Bang approach,
2. There were maintainers in the CSV file that were not present in cncf/people so I add them and log that as a creation event
3. I added a source field to indicate that the record came from the migration script,
4. I will report on new and updated voters and non-voters.

[Robert Kielty]

This came up in yesterday, @jeefy and I are working on a design to retire finally

https://github.com/cncf/foundation/blob/main/project-maintainers.csv

Will leave this open for now.