Add maintainers file

[afrittoli]

Changes

Add maintainers file with the existing members of the spec-maintainers team

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

• Has the primer doc been updated if a design decision is involved
• Have the JSON schemas been updated if the specification changed
• Has spec version and event versions been updated according to the versioning policy
• Meets the CDEvents contributor standards

[e-backmark-ericsson]

I'm not sure how this file relates to the built-in support for a CODEOWNERS.md file. They might be mutually exclusive, and the CODEOWNERS file could refer to a GitHub team and therefore there is no need to explicitly specify the individual names in it.

[afrittoli]

I'm not sure how this file relates to the built-in support for a CODEOWNERS.md file. They might be mutually exclusive, and the CODEOWNERS file could refer to a GitHub team and therefore there is no need to explicitly specify the individual names in it.

In my understanding CODEOWNERS is used for automatic selection of reviewers based on changes in repo files and folders. I was looking for a native file based way to assign roles to users but I didn't find one, or at least it didn't seem to me that code owners would do that.

The mechanism I proposed in the other PR involves both changing this file and adding the user to a team, the first part allows us to have a PR that tracks the changes, the latter actually grants roles and permissions.

[afrittoli]

I'm not sure how this file relates to the built-in support for a CODEOWNERS.md file. They might be mutually exclusive, and the CODEOWNERS file could refer to a GitHub team and therefore there is no need to explicitly specify the individual names in it.

In my understanding CODEOWNERS is used for automatic selection of reviewers based on changes in repo files and folders. I was looking for a native file based way to assign roles to users but I didn't find one, or at least it didn't seem to me that code owners would do that.

The mechanism I proposed in the other PR involves both changing this file and adding the user to a team, the first part allows us to have a PR that tracks the changes, the latter actually grants roles and permissions.

I'm happy to add a CODEOWNERS file nonetheless. I removed maintainers.md and added the extra info in the in comments inside CODEOWNERS.

[e-backmark-ericsson]

In Eiffel we handle this solely through GitHub teams. Our CODEOWNERS files only point out the GitHub team and then maintainers are added/removed from the repo by updating the team only. Yes, we loose the tracking/review of PRs to update maintainers, but to me that is fine. Emeritus maintainers would then need to be handled in a separate file (or still as comment in CODEOWNERS if we like).

Example: https://github.com/eiffel-community/eiffel/blob/master/CODEOWNERS

[afrittoli]

We could add the team to the CODEOWNERS file, but I like the idea of having an auditable record of the change being approved.
We could also use a GitHub issue instead of a PR, if you prefer to have teams in the CODEOWNERS files

[e-backmark-ericsson]

I'm slightly concerned that we will need to update the same information in multiple places (CODEOWNERS file and GitHub team). I'm pro centralizing such operations as much as possible. But I see the point of having PRs (or issues) to track it as well.
I don't have a strong opinion on this so we could let today's meeting decide :)

[afrittoli]

I'm slightly concerned that we will need to update the same information in multiple places (CODEOWNERS file and GitHub team). I'm pro centralizing such operations as much as possible. But I see the point of having PRs (or issues) to track it as well.

Thank you @e-backmark-ericsson - as discussed during the WG, I switched the automation part to the team, and kept the table in the comment to make it easier for people to discover the list of maintainers.