Proposal: Emeritus maintainers

[Stephen Connolly]

Can we add a concept of emeritus maintainer... by just commenting out their username in the corresponding repository-permissions-updater yaml file?

An emeritus maintainer would be indicating that they are no longer active, but if they want to re-activate they do not need to wait for existing maintainers to approve... or in the case of unmaintained plugins they do not need to wait for the claim-ownership period.

If all maintainers of a plugin are emeritus and someone wants to claim ownership then the emeritus maintainers can short-circuit the transfer of ownership rather than having to wait out the full period.

My use case is that I currently wish to be marked emeritus for all plugins that I am a maintainer of *except*:

- gitea (until I get the gitea token auth implemented, then I'll be looking for someone to adopt it)

- impersonation (until I decide whether to release it or kill it)

- mock-load-builder (needed for work commitments)

- random-job-builder (needed for work commitments)

- metrics (needed for work commitments)

I may need to step back on the other plugins at shorter notice, so it would be annoying to have to go though recovering maintainer status... which is why I have not dropped those permissions.

I do think we need to be able to reflect better the case where maintainers are not actively maintaining but do not want to drop permissions because it could trigger the plugin as completely unmaintained and thus a lot harder to reclaim... yet by not dropping permissions it leaves others who might be interested in adopting the impression that the plugin is actively maintained

[Marky Jackson]

I like this idea so a +1 from me.

On Mar 2, 2020, at 3:02 AM, Stephen Connolly <stephen.al...@gmail.com> wrote:



--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMw0XFtd1PR00yuhJJ-q8B0s6LqHK%3DResjH8P%3Di%3DJ%2B-MTw%40mail.gmail.com.

[Oleg Nenashev]

I think it would be a great improvement to the current process. Maybe it is better to add a new list to repository-permissions-updater files so that we can somehow credit the emeritus maintainers on the plugin site once https://issues.jenkins-ci.org/browse/WEBSITE-658 is implemented ("Use Repository Permission Updater as a source of the maintainer info").

In my case I also have several plugins which I de-facto maintain as "emeritus maintainer" (read as: "I step in when something is really broken there, but do not maintain it on a regular basis").

Maybe it is a use-case for emeritus maintainers retaining their release permissions.

P.S: It might be also good to explicitly mark plugins for adoption. Now it can be done by just setting a GitHub topic: https://jenkins.io/doc/developer/plugin-governance/adopt-a-plugin/

BR, Oleg

On Monday, March 2, 2020 at 12:06:21 PM UTC+1, Marky Jackson wrote:

I like this idea so a +1 from me.

On Mar 2, 2020, at 3:02 AM, Stephen Connolly <stephen.a...@gmail.com> wrote:



Can we add a concept of emeritus maintainer... by just commenting out their username in the corresponding repository-permissions-updater yaml file?

An emeritus maintainer would be indicating that they are no longer active, but if they want to re-activate they do not need to wait for existing maintainers to approve... or in the case of unmaintained plugins they do not need to wait for the claim-ownership period.

If all maintainers of a plugin are emeritus and someone wants to claim ownership then the emeritus maintainers can short-circuit the transfer of ownership rather than having to wait out the full period.

My use case is that I currently wish to be marked emeritus for all plugins that I am a maintainer of *except*:

- gitea (until I get the gitea token auth implemented, then I'll be looking for someone to adopt it)

- impersonation (until I decide whether to release it or kill it)

- mock-load-builder (needed for work commitments)

- random-job-builder (needed for work commitments)

- metrics (needed for work commitments)

I may need to step back on the other plugins at shorter notice, so it would be annoying to have to go though recovering maintainer status... which is why I have not dropped those permissions.

I do think we need to be able to reflect better the case where maintainers are not actively maintaining but do not want to drop permissions because it could trigger the plugin as completely unmaintained and thus a lot harder to reclaim... yet by not dropping permissions it leaves others who might be interested in adopting the impression that the plugin is actively maintained

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.com.

[Stephen Connolly]

On Monday, 2 March 2020 11:10:23 UTC, Oleg Nenashev wrote:

I think it would be a great improvement to the current process. Maybe it is better to add a new list to repository-permissions-updater files so that we can somehow credit the emeritus maintainers on the plugin site once https://issues.jenkins-ci.org/browse/WEBSITE-658 is implemented ("Use Repository Permission Updater as a source of the maintainer info").

Seems fine by me, though my proposal was limited to not actually requiring code changes so that it could be implemented quickly for my use case :-P

In my case I also have several plugins which I de-facto maintain as "emeritus maintainer" (read as: "I step in when something is really broken there, but do not maintain it on a regular basis").

Maybe it is a use-case for emeritus maintainers retaining their release permissions.

I am fine with retaining release permissions as emeritus, *at least for the case where all maintainers are emeritus* but I think it would be better for the active maintainers that they not have to worry about emeritus maintainers coming in and releaseing stuff that they are not actively tracking.

To me, it is more about tracking that you can help if necessary, while signalling the intent to step back.

[Daniel Beck]

On Mon, Mar 2, 2020 at 12:02 PM Stephen Connolly <stephen.al...@gmail.com> wrote:

If all maintainers of a plugin are emeritus and someone wants to claim ownership then the emeritus maintainers can short-circuit the transfer of ownership rather than having to wait out the full period.

Seems like this can trivially be accomplished by amending the usual adoption process (2 week timeout) to special-case "I used to maintain this". We've actually done that already in the past, when the last release pre-dated the cutoff date I used to initialize the permission files: The requester told us they maintained the plugin back 2012, they'd like to get permissions back. Nobody else was around to tell us "no" (i.e. no other co-maintainers recorded), so it was just done.

My main question here is how this would impact plugins with active maintainers. If you remove yourself from credentials plugin, it is currently considered to be maintained jointly by seven people. Do you expect to get permissions back without any approval from any of them, if you decide to?

[Stephen Connolly]

On Monday, 2 March 2020 11:19:07 UTC, Daniel Beck wrote:

If there are active maintainers, they can veto within a fixed period of time (say 72h or 1 week or whatever people want), but I think it would have to be a veto not an approval.

[Baptiste Mathus]

Overall +1 with a strong concern from my side on the 'new and active maintainers' respect aspect.

I think this is fine to move into a fast-forwardable veto system, however only taking in account a duration.

E.g. such "emeritus" maintainers would be able to get access back in a fast-track way only if they can show an activity in the last 12 months.

IOW I do not think someone who was not active in the last, say, 2 years should be able to get access back in less than the default timeout of 2 weeks.

 

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/cb6de16c-7621-4244-a373-12dbbb62cd4c%40googlegroups.com.

[Stephen Connolly]

On Monday, 2 March 2020 12:44:37 UTC, Baptiste Mathus wrote:

Le lun. 2 mars 2020 à 13:40, Stephen Connolly <scon...@cloudbees.com> a écrit :

On Monday, 2 March 2020 11:19:07 UTC, Daniel Beck wrote:

On Mon, Mar 2, 2020 at 12:02 PM Stephen Connolly <stephen.a...@gmail.com> wrote:

If all maintainers of a plugin are emeritus and someone wants to claim ownership then the emeritus maintainers can short-circuit the transfer of ownership rather than having to wait out the full period.

Seems like this can trivially be accomplished by amending the usual adoption process (2 week timeout) to special-case "I used to maintain this". We've actually done that already in the past, when the last release pre-dated the cutoff date I used to initialize the permission files: The requester told us they maintained the plugin back 2012, they'd like to get permissions back. Nobody else was around to tell us "no" (i.e. no other co-maintainers recorded), so it was just done.

My main question here is how this would impact plugins with active maintainers. If you remove yourself from credentials plugin, it is currently considered to be maintained jointly by seven people. Do you expect to get permissions back without any approval from any of them, if you decide to?

If there are active maintainers, they can veto within a fixed period of time (say 72h or 1 week or whatever people want), but I think it would have to be a veto not an approval.

Overall +1 with a strong concern from my side on the 'new and active maintainers' respect aspect.

I think this is fine to move into a fast-forwardable veto system, however only taking in account a duration.

E.g. such "emeritus" maintainers would be able to get access back in a fast-track way only if they can show an activity in the last 12 months.

IOW I do not think someone who was not active in the last, say, 2 years should be able to get access back in less than the default timeout of 2 weeks.

If that is scoped to actively maintained plugins, fine.

If the plugin is unmaintained an an emeritus maintainer steps up, they should be back in action as soon as they request it IMHO

 

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.com.

[Stephen Connolly]

On Monday, 2 March 2020 12:47:35 UTC, Stephen Connolly wrote:

On Monday, 2 March 2020 12:44:37 UTC, Baptiste Mathus wrote:

Le lun. 2 mars 2020 à 13:40, Stephen Connolly <scon...@cloudbees.com> a écrit :

On Monday, 2 March 2020 11:19:07 UTC, Daniel Beck wrote:

On Mon, Mar 2, 2020 at 12:02 PM Stephen Connolly <stephen.a...@gmail.com> wrote:

If all maintainers of a plugin are emeritus and someone wants to claim ownership then the emeritus maintainers can short-circuit the transfer of ownership rather than having to wait out the full period.

Seems like this can trivially be accomplished by amending the usual adoption process (2 week timeout) to special-case "I used to maintain this". We've actually done that already in the past, when the last release pre-dated the cutoff date I used to initialize the permission files: The requester told us they maintained the plugin back 2012, they'd like to get permissions back. Nobody else was around to tell us "no" (i.e. no other co-maintainers recorded), so it was just done.

My main question here is how this would impact plugins with active maintainers. If you remove yourself from credentials plugin, it is currently considered to be maintained jointly by seven people. Do you expect to get permissions back without any approval from any of them, if you decide to?

If there are active maintainers, they can veto within a fixed period of time (say 72h or 1 week or whatever people want), but I think it would have to be a veto not an approval.

Overall +1 with a strong concern from my side on the 'new and active maintainers' respect aspect.

I think this is fine to move into a fast-forwardable veto system, however only taking in account a duration.

E.g. such "emeritus" maintainers would be able to get access back in a fast-track way only if they can show an activity in the last 12 months.

IOW I do not think someone who was not active in the last, say, 2 years should be able to get access back in less than the default timeout of 2 weeks.

If that is scoped to actively maintained plugins, fine.

Similarly, if I come back in 2 years and see that Bob who adopted the foobar plugin from me has done nothing with it in the past year... should I need to wait for bob's timeout of two weeks to pick up the plugin?

For sure if Bob is maintaining the plugin actively and has commits etc then Bob should be respected... but if Bob is don;t nothing and hasn't moved himself to Emeritus, should he be entitled to block me from picking the plugin back up?\

[Daniel Beck]

On Mon, Mar 2, 2020 at 1:50 PM Stephen Connolly <scon...@cloudbees.com> wrote:

Similarly, if I come back in 2 years and see that Bob who adopted the foobar plugin from me has done nothing with it in the past year... should I need to wait for bob's timeout of two weeks to pick up the plugin?

For sure if Bob is maintaining the plugin actively and has commits etc then Bob should be respected... but if Bob is don;t nothing and hasn't moved himself to Emeritus, should he be entitled to block me from picking the plugin back up?\

This all makes sense in a way, but then we get to choose between a really complex decision tree (what even counts as actively maintained?), or just improvising every time (i.e. have a vaguely defined judgment call in there somewhere).

[Oliver Gondža]

I tend to agree this is getting way to complex given the limited value I
can see in this.

What is an effective difference for such a one-year-restricted
fast-track-reintroduced emeritus maintainer and a "real" maintainer that
just not commit in a while? I mean, it appears simpleer to just keep
being a maintainer...

--
oliver

[Stephen Connolly]

I'm fine with "have a vaguely defined judgment call in there somewhere" for whether Emeritus gets fast track or not in the presence of active maintainers.

The important part for me is that I don't have to worry in the case that the plugin is not actively maintained