I like that idea, and I agree having a clearer way to track ongoing requests, so that they're not forgotten would be great. It's especially important IMO since people requesting to become maintainers may often be somewhat newcomers that won't necessarily dare asking twice if we miss or forget the request.
I think using the HOSTING project kind of makes sense, but I'm not feeling strongly for the actual JIRA project to use for this. I think we want to get feedback from Slide (CCed) here as he's the now one clearly doing the heavy lifting on the HOSTING process, so if we're going to add /requests/ that will appear in his bucket, he should be aware before we do. And I think that we should have a JEP for this, yes. I think we somehow could have a global JEP for the hosting process, then have a part on adoption, but that would make this a much bigger task which likely would kill the effort. IMO let's just have a smaller process JEP, and we'll use the existing process to deprecate it once/if we include it some day in a bigger JEP to describe the whole hosting/plugin handling process. (BTW, might be something interesting to do during JW/DW. IIUC Daniel started to do this during FOSDEM, as of https://jenkins.io/doc/developer/publishing/requesting-hosting/ but I think it's not finished as I would imagine once fully done, we'd blank https://wiki.jenkins.io/display/JENKINS/Hosting+Plugins or add a link to jenkins.io). -- Baptiste Le mar. 21 août 2018 à 18:54, Craig Rodrigues <[email protected]> a écrit : > *PROBLEM* > > - Over time, Jenkins plugin maintainers need to change as the original > maintainer may need to move on to other work. > - https://wiki.jenkins.io/display/JENKINS/Adopt+a+Plugin outlines the > process for adopting a plugin. It mentions that the Jenkins developer > mailing list should be e-mailed to start the process. > - Due to the popularity of Jenkins, the mailing lists receive a lot of > messages. For casual Jenkins users who maintain plugins, it is easy to > miss these types of e-mails. > > > *PROPOSAL* > > - Plugins need to change owners and there needs to be a clear adoption > process which can be tracked. > - I propose that JIRA be used as the primary mechanism by which the > plugin adoption process is tracked, from proposal to adopt a plugin, all > the way to when the plugin is adopted. > - Email would be used as a secondary mechanism. If someone e-mails > the Jenkins mailing list, they should be directed to the Adopt+a+Plugin > JIRA page, which would instruct them to file a JIRA ticket. > > *DETAILS* > > - When someone wants to adopt a plugin, they should file a JIRA ticket. > - They should set the Component field to the name of the plugin > - In addition, they must set a tag in JIRA to something like "*adopt"* > - The current plugin maintainer will receive an e-mail from JIRA. If > there are multiple plugin maintainers, they should be mentioned via the "@" > mechanism in JIRA. > - If the plugin owner does not respond to the JIRA ticket within 3 > weeks (enough time to cover reasonable vacation time, sick time, > emergency), then the plugin can be adopted. > - Plugin authors are also able to file a JIRA ticket with the "*adopt*" > tag, and mention that they want to give up maintainership of the plugin > - By doing things in JIRA, it is easier for Jenkins administrators to > query the list of plugins which are up for adoption and there is a clear > audit trail of when a plugin was adopted. > > *POST ADOPTION TASKS* > > - new maintainer needs to be given write access to the git repository > with the plugin code. I believe that this can be done by sending special > commands to the bot on the IRC Freenode #jenkins channel. > - in JIRA, new maintainer should be made the default assignee for > tickets filed with Component set to that plugin > - in JIRA, all Unresolved tickets should be assigned to the new > maintainer > - new maintainer is responsible for updating the wiki page for the > plugin, and also for updating the pom.xml metadata for the plugin > indicating that they are the maintainer > > > This will hopefully reduce the amount of email going to the lists (by a > small amount), yet give a clear trackable process by which > plugins can change maintainershp. > > Thank you. > > -- > Craig > > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3DrPVdd81B73r0aMRcOWD%2B50HfTb3qh5asTnt44tD9XWNMq%3DQ%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3DrPVdd81B73r0aMRcOWD%2B50HfTb3qh5asTnt44tD9XWNMq%3DQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS6bJyk3JLbP0hEUzvKeEJ8VM3C0KsOTfXA9j5CLNy6qPg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
