GSOC Idea? Maintainers Heartbeat

[Gavin Mogan]

Maintainer Heartbeat script

1) Update jenkins core to highlight plugins that have the adopt plugin label (either via github or directly in update center)
2) Every 3 months the bot will create a jira or github issue (based on what the preference is in RPU)
* If there is already a ticket open, add the adopt plugin label to github
* IF no ticket open, create a new ticket, and email all ldap accounts in RPU (i know we have some users with emails out of sync from jira, but thats an infra issue for now).

I have never put together a proposal for gsoc before so not sure if this is the right scale, or even a good idea. But we have lots of plugins with open PRs and users are frustrated. If we have security issues we want to make sure contact info is up to date. I think its a good idea.

What do you all think?

Gavin

[Daniel Beck]

> On 5. Feb 2021, at 06:05, 'Gavin Mogan' via Jenkins Developers <jenkin...@googlegroups.com> wrote:
>
> 1) Update jenkins core to highlight plugins that have the adopt plugin label (either via github or directly in update center)

This already exists on the plugin site and in Jenkins directly, or are you thinking about even more visible warnings? Since not being maintained can be a transient state (unlike deprecation), I'm not convinced highlighting it to the same degree (i.e. admin warnings) is useful.

> * If there is already a ticket open, add the adopt plugin label to github

A ton of plugins are clearly unmaintained but an earlier attempt to label them was blocked[1]; apparently the rules were rewritten to be far more restrictive about marking plugins as unmaintained when the process was migrated from the wiki to the site. You need to take into account that this needs re-re-writing of the adoption process rules.

> * IF no ticket open, create a new ticket, and email all ldap accounts in RPU (i know we have some users with emails out of sync from jira, but thats an infra issue for now).

A potential problem is the incredible wave of spam that maintainers of multiple (many) plugins are going to get every few months, especially in the case of plugins with several maintainers. Even if we deduplicate emails, ideally they watch repos/issue trackers and getting a dozen or two dozen notifications that way for "no reason" won't be great.

Some of this is implementation detail of course; I support the overall goal to better represent when plugins are unmaintained. I don't know whether this is a suitable GSOC project.


1: https://github.com/jenkins-infra/update-center2/pull/358

[Gavin Mogan]

> This already exists on the plugin site and in Jenkins directly, or are you thinking about even more visible warnings? Since not being maintained can be a transient state (unlike deprecation), I'm not convinced highlighting it to the same degree (i.e. admin warnings) is useful.

I was just thinking some sort of icon or labeling when listing plugins so people know what they are in for / suggest we need help

> A potential problem is the incredible wave of spam that maintainers of multiple (many) plugins are going to get every few months, especially in the case of plugins with several maintainers. Even if we deduplicate emails, ideally they watch repos/issue trackers and getting a dozen or two dozen notifications that way for "no reason" won't be great.

Yea, thats why i was thinking once in a while not all the time type thing. Could even be filtered to just look at any plugin that has open tickets/issues/etc, if you have nothing pending then it could assume active and ignore?

Just thinking out loud at this point.

Gavin

--
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/1988FF0F-F44E-4911-87DD-6A872CC0A56C%40beckweb.net.