Add date someone became a maintainer

[nate-double-u]

In the maintainer record, can we add another field: Date the contributor became a maintainer for any project they're a maintainer for?

[RobertKielty]

EventTime Data for Maintainer Lifecycle Events

Implemented right now in the maintainer-d database via GORM, a go-native ORM tool that creates database tables from go structs, our problem-domain objects, such as Project, Maintainer, FoundationOfficer, defined as struct definitions in model/main.go, the includsion of gorm.Model in those structs results in the creation of the following row-level fields in the generated database:

• created_at
• updated_at
• deleted_at

Additionally, (and more relevantly for this feature request) on the table maintainer_projects where we associate a Maintainer with a Project we have at joined_at timestamp field. Important because we have Maintainers who work on multiple Projects.

For new Maintainers onboarded via maintainer-d this data should be recorded naturally. We will need to test that assertion and to do that I can bubble that data up into the UI to make that at least manually checkable.

The challenge here is sourcing accurate Maintainer Lifecycle Event-time data for data retrieved from legacy sources.

Sourcing accurate Maintainer Lifecycle Event-time Data

We have three channels of incoming data:

1. Maintainer data imported from the CNCF Internal Worksheet

Maintainer lifecycle events were not recorded in the internal worksheet so we would need to write code to source Maintainer lifecycle event data. We could look are processing the output of a git blame for the addition of the Maintainer to our maintainer.csv file to retrieve an indicative joined_at time for when a Maintainer joined a project.

2. Data created using maintainer-d

This should naturally capture the addion of new Maintainers to the Foundations's Maintainership. Testing needed as per above comment.

3. Data retrieved from .project repos

As .project repos are adopted, for lifecycle event data only, they will initially have a similar importation issues as the old internal worksheet. The naturally recorded time data from a .project repo lift and shift would be the date of the lift and shift.

We could code around this much more easily and also look at using work done on git blame / git log file inspection on maintainers.csv

Once a .project repo is taken on in favor of a Project's Legacy Maintainer File, changes to a Maintainer's status to the .project repo could be naturally recorded by maintainer-d.

[RobertKielty]

@nate-double-u @riaankleinhans @krook

Could/should we mine the git logs of maintainers.csv to calculate the date a maintainer onboarded?

[krook]

Do we have enough data in the archive? I assume it's truncated. Maybe capture going forward?

[nate-double-u]

For my records, I've been using a combination of git logs:

• https://github.com/cncf/foundation/blob/main/project-maintainers.csv
• individual owners files in relevant repos

The project-maintainers.csv file usually lags a bit, but it gives me an approximate time I can use to search the projects own files.