Add Plugin Development Team to CODEOWNERS

[sghill-rewrite]

Hi!

This change adds a CODEOWNERS file (docs) to ensure folks on the development team are notified about new contributions.

Newly generated plugins automatically get this configuration.

Use this link to re-run the recipe: https://app.moderne.io/recipes/org.openrewrite.jenkins.github.AddTeamToCodeowners

[sghill]

This team is currently lacking write access to the repository. I can update to a better team name if preferred.

[olamy]

GH is displaying an error

[sghill]

Thanks @olamy! Are you able to add write access to the team? I could change it to another team if you'd prefer, or if there is none I can close this out.

[olamy]

no access to add team.

[NotMyFault]

I added the repository team, the CODEOWNERS file is now green:

[olamy]

TBH, I don't see any added value with such a change.
Looking at the team members https://github.com/orgs/jenkinsci/teams/maven-plugin-developers
and last contributions. I'm pretty sure 99% of those people are NOT interested in receiving any notifications.
That will be horrible spam for them

[sghill]

Thanks for your thoughts @olamy!

I'll add maven-plugin to the exclude list so the recipe doesn't open this one again.

Would be curious to hear if you object to the concept of code ownership by teams, or this particular implementation is falling short. I don't have any abilities to create teams, but I'm interested in the difficult problem of how to identify maintainers/owners and I do think the Jenkins project is striking a nice balance here.

[olamy]

In the opensource world, people contribute then stop then eventually comes back.
Some may have turn off notifications on purpose and this option may reactivate it.
So frankly I consider a bad idea to force them to receive notifications which they will consider as spam.
Participating to opensource is a volunteer process you cannot force people to anything.

[sghill]

All good points. I would have thought this is more a question of team composition. Ideally the development team is composed of folks who have a vested interest in actively maintaining. Certainly that interest changes over time, so it also seems reasonable to have a low-friction way to leave and join the team.

I've excluded this plugin, so this same automated PR won't be opened again in the future.

[olamy]

All good points. I would have thought this is more a question of team composition. Ideally the development team is composed of folks who have a vested interest in actively maintaining. Certainly that interest changes over time, so it also seems reasonable to have a low-friction way to leave and join the team.

I've excluded this plugin, so this same automated PR won't be opened again in the future.

TBH this will be potentially the case for a lot of plugins here!!

[jtnord]

valid points - probably worth a discussion on the mailing list. without a CODEOWNERS users without write permissions can generate PRs but it may be that no one is notified (not even an active developer) and this causes things to languish, so there are both pros and cons to this. Perhaps something else should change, or that the change and RPU should add individuals that are added in an PRU change, not the group (and add/remove users when they are added/removed in RPU - so that an individual can remove themselves from the CODEOWNERS for a give repo should they wish)?

[jglick]

Please consider reopening; this is standard format for all plugin repos. (https://github.com/jenkinsci/archetypes/blob/d8a3ec6d5728ecf29da958dc8ea7a1ec2f05f09a/common-files/.github/CODEOWNERS) Clearly https://github.com/orgs/jenkinsci/teams/maven-plugin-developers is bloated and should be trimmed. File an update to https://github.com/jenkins-infra/repository-permissions-updater/blob/2e8a9a260120bec293114b62a33a7580860855a0/permissions/plugin-maven-plugin.yml#L9-L16 (for example kohsuke, stephenc, and abayer do not even work on Jenkins any more) and ask the merger to run the bot command to ensure that the team list is refreshed to match RPU. This is not currently automatic, for what I guess are historical reasons.

[olamy]

AGAIN I don't minf adding this file. But I don't like we will potentially send notifications to people who don't want it as they are not participating in it anymore.
Sorry, but I don't have time to manually go to every plugins I'm participating in and modify all team members.
There is a bot creating those PRs so if we want to accept those PRs, we should have an automatic process pruning team members list as well.
BUT this should be discussed by the whole community (mailing list) and discussed/approved as it has side effects to every plugin such as this kind of PR on every plugin...

cc @MarkEWaite

[olamy]

this team list must be pruned before.

[MarkEWaite]

AGAIN I don't mind adding this file. But I don't like we will potentially send notifications to people who don't want it as they are not participating in it anymore.

I think that non-participants are already filtering notifications. If they are not, they can either choose to explicitly remove themselves as participants or they can adjust their notification settings. In either case, I don't think that should delay this change.

Sorry, but I don't have time to manually go to every plugins I'm participating in and modify all team members. There is a bot creating those PRs so if we want to accept those PRs, we should have an automatic process pruning team members list as well. BUT this should be discussed by the whole community (mailing list) and discussed/approved as it has side effects to every plugin such as this kind of PR on every plugin...

I agree that if we are going to automate the pruning of team members, that should be discussed more widely before it is implemented.

I very much like the development team to be included in the CODEOWNERS file. I think it may prompt individual repository maintainers to reconsider the maintainer list for that repository. I think it increases the chances of additional reviews of pull requests.

[jglick]

Standard practice is to merge these; any org-wide policy changes can be discussed elsewhere.

[MarkEWaite]

I think that this should be labeled "maintenance" so that it is categorized correctly in the changelog.