-
Notifications
You must be signed in to change notification settings - Fork 4
Description
The CNCF would like to improve the process whereby projects document their maintainer team to the CNCF.
@jeefy and @mrbobbytables have written up a design describing the format of the a project.yaml which will contain project meta-data focused on, but not limited to, maintainer line-up.
The maintainer-d database has all of the requisite data to generate these files on a per-project basis.
Tasks
- Write code to generate project meta data files - perhaps including it in the bootstrap process 1
- Write code to process updates to the files and have changes reflected in maintainer-d 2
- PR the generated project files so that project maintainers can access their files.
- Contact project maintainers on maintainer-circle/mailing lists, announce and describe the initiaive to start using project meta data files.
Footnotes
-
The bootstrap process ingests data from an internal Google worksheet that has project and maintainer data, this data seeds the maintainer-d database and runs in an initContainer each time maintainer-d is deployed.
As maintainer-d development matures we would like to retrieve maintainer and project data from a combination of LFX's http://openprofile.dev/ and https://lfx.linuxfoundation.org/tools/pcc/
The bootstrap process has been implemented as a separate component from the maintainer-d server process so that in the future re-writing boostrap to ingest data from the LFX platform will be a relatively easy task once LFX tools provide us with a per-project maintainer line-up and can associate multiple email addresses with a single maintainer on a per-service basis, where a service is a 3rd-party service such as, FOSSA, Snyk, etc. ↩ -
The maintainer-d server listens for events on github-events.cncf.io and is currently processing events on cncf/sandbox for on-boarding. One of the design considerations here will be ease of configuratoin wrt to where the project meta data files are located. Centralizing file locations on a single CNCF repo will make it easier to deploy but this will mean that we have to tell projects, go to this CNCF repo to update your maintainer line-up, distributing the meta data files out in the project orgs will mean that we have to ask projects to configure the maintainer-d webhook end-point on the GitHub settings on those repos. It will alss place a location tracking burden on maintainer-d. A decision for CNCF Project Teams leadership in consultation with the wider community needed here? ↩