Adopt a Plugin

We’re looking for new maintainers of existing plugins!

This page addresses cases when there is no active maintainer of a plugin:

  • Adopting plugins marked for adoption. Plugin maintainers can mark plugins for adoption if they do not plan to maintain their plugins anymore. In such case we have a low-barrier process for taking over plugins.

  • Adopting abandoned plugins. Sometimes plugin maintainers move on without marking plugins for adoption, due to various reasons. In such case we can transfer ownership for plugins being hosted within the jenkinsci GitHub organization. Such transfer may take a while. If a plugin has no maintainers listed then it follows the adoption process.

Plugins marked for adoption

The procedure is two-fold:

Announce your adoption intention by mail

Send the notification email to the Jenkins Developers mailing list. Be sure to provide the following information:

  • Link to a plugin you want to adopt

  • The status of the plugin (for adoption or abandoned)

  • Link(s) to pull requests you want to deliver, if applicable

  • Your GitHub username/id (e.g. oleg-nenashev for https://github.com/oleg-nenashev/)

  • Your Jenkins infrastructure account id. Create your account if you don’t have one.

  • The link to the "Repository Permission Updater" PR described below

An example request can look like this:

Hi,
I would like to adopt a plugin:

    Link: https://github.com/jenkinsci/<REPO>
    Pull requests (optional): https://github.com/jenkinsci/<REPO>/pull/42
    Status: for adoption
    GitHub Username: <YOUR GitHub USERNAME>
    Jenkins Infrastructure ID: <YOUR Jenkins Infra ID>
    Repository Permission Updater PR: https://github.com/jenkins-infra/repository-permissions-updater/pull/3758

<Describe briefly what you plan to do>

Best regards,

Submit a PR on the "Repository Permission Updater" repository

File a pull request against Repository Permissions Updater (RPU) to be able to deploy releases for your plugin. You need to update the plugin’s definition yaml file located in the permission directory. Add your Jenkins infrastructure account under the developer section. Refer to the Readme for detailed guidance.

Ping the current registered developers on the PR to inform them of your initiative (just in case they miss the notification on the Jenkins Dev List).

Once you have access to the plugin’s GitHub repository, be sure to remove the adopt-this-plugin label. This can be done by clicking on the gear wheel near the "About":

change for adoption

Note: Membership of the jenkinsci github organization is required. If this is not the case yet, you will receive an invitation sent to your GitHub email account. You can also accept it at https://github.com/jenkinsci if you can’t find the invite. Note that the invitation is valid for 7 days only.

If you need a new invitation because you missed it, replying on the RPU pull request is the easiest way. You can also create an INFRA helpdesk ticket or email the jenkinsci-dev mailing list.

Abandoned plugins

For abandoned plugins, you are expected to try and reach out to existing maintainer(s) using a best effort. The typical way to do that is to ping in GitHub and to add her/his/their email addresses in CC (hint: Git commits should have this information). We typically wait for about 2 weeks in normal work periods before proceeding, so please be patient. Hence, if you can prove the existing maintainer already agrees, and you explicitly asked about taking over (e.g. in a PR discussion), the process can be faster.

Once the situation is clarified, proceed as for an "adoptable" plugins (see above). On the notification email, add information about the steps taken to contact the existing maintainers.

If there are no maintainers listed in the "Repository Permission Updater" repository then there is no need to wait 2 weeks and it can proceed immediately.

FAQ

A plugin I’m (planning on) using shows up as looking for a maintainer. Does that mean I shouldn’t use it?

No. Jenkins is designed with backward compatibility in mind, so it’s rare that a plugin stops working. And even then there’s often someone who can fix the bug and release a new version even if they wouldn’t be considered a maintainer of the plugin. So if you’re happy with what a plugin is offering, there’s no reason not to use it just because it’s up for adoption.

I want to help! How can I find a plugin to maintain?

Check out the list of plugins up for adoption at the bottom of this page. If you see a plugin you like, visit its wiki page as it may contain additional information about the adoption request.

I know which plugin I want to help with, what should I do now?

Once you’ve chosen a plugin, review the documentation on plugin maintainership in the Jenkins project. This is especially important if you’re not currently a plugin developer.

First, make sure the plugin is not being actively maintained. Even in actively maintained plugins, there may be periods of lower developer activity. Don’t misinterpret failures to respond to questions or requests as the plugin being unmaintained!

As a new maintainer of a new plugin, you’ll inherit its existing users, so be careful with breaking changes. We value data compatibility highly, so any new releases should remain compatible with previous data and upgrade smoothly. If you need help with this, don’t hesitate to ask other Jenkins developers for help. And if all else fails, you can mark a new version as being incompatible with older releases to warn users before they update.

How can I mark a plugin for adoption?

Before marking a plugin for adoption, we recommend to announce the incoming change in the Jenkins Developer Mailing list or in other appropriate channels. It may help you find new maintainers and, ideally, to establish a transition and knowledge transfer process.

  1. Add the adopt-this-plugin label to the plugin. A plugin is marked for adoption in one of two ways:

    • Put an adopt-this-plugin topic in the plugin’s GitHub repository. If multiple plugins are maintained inside a single repository, the repository topic marks all of them for adoption. This is the preferred method because the maintainer directly controls the topics assigned to the plugin repository

    • Add an adopt-this-plugin label to the plugin entry in the Update Center’s label-definitions.properties file If multiple plugins are maintained inside a single repository, an update center entry can mark a subset of the plugins for adoption. This is not the preferred method because the maintainer does not directly control the Update Center file

  2. Optional: If you want to explain why you’re marking that plugin as up for adoption, add a section to the plugin’s documentation. You can also document your vision for the plugin there so that new maintainers can take it into account.

I’m a plugin maintainer and my plugin shows as up for adoption, why?

This status is based on the adopt-this-plugin or jenkins-adopt-this-plugin label in the update center. Such labels can come from the topics in the plugin’s GitHub repository or from the Update Center’s label-definitions.properties file. If you remove these topics/labels, the adoption notice will disappear after the repo synchronization.

Which plugins are currently up for adoption?

See the list of plugin pages with the adopt-this-plugin label.

References