 is to try to persuade you to adopt a plugin. And adopting a plugin is a process that the Jenkins project uses to allow people to maintain plugins across the world. So what we've got here is individual maintainers, one or two or sometimes three are the ones who care for an individual plugin. And those maintainers release the plugin, they update it to use new versions, et cetera. Well, one of the things we need is more maintainers because we've got over a hundred that are ready to be adopted. Now, first challenge is we need to overcome your sense of imposter syndrome. Oh, I can't do that. Then we're gonna talk about how you can find which plugins you could adopt, then you send the request to adopt the plugin and you start improving it. It's actually a relatively lightweight process to do this. And some of these plugins are so lightweight that you could adopt them and only spend on the order of minutes or maybe an hour a week and still be a very successful plugin maintainer. So this is not a life commitment. This is not an, oh, I have to do a whole bunch of things. First, yes, go ahead, Dheeraj. So in the previous slide, if you can go back. Uh-huh. So there you mentioned that improve the plugin and release the improvements. Can you give me more examples on how we can improve a plugin? Absolutely, yes. So for instance, one of the things that I think it was actually Jonathan mentioned is he's been maintaining a plugin, just keeping it up to date. And one way to improve the plugin is to update it so that you're sure it runs with and depends on a modern Jenkins version. So you might update the palm file to use the most recent palm. You might update its dependencies to depend on more recent, more modern libraries. Those are very valuable improvements that help reduce the load on others and reduce the risks and the debt that exists for a project that has a nice long life like Jenkins does. So Dheeraj, did that answer your question? Yes, thank you. Super, and thank you for asking questions. That's exactly what we want. So one of the things that I wrestled with as I was considering becoming a plugin maintainer is imposter syndrome. This is a condition where people mistakenly downgrade or deprecate or deride their own skills and their own ability to learn. And I'm here to persuade you that you should stop doing that when it comes to adopting a plugin. If you're willing to learn, if you're willing to ask questions, if you're willing to seek answers, test your changes and help others, then you are ready to adopt a Jenkins plugin. There are plugins that you could adopt if you're willing to do basic, fundamental things like this. Now, if you say, oh, I can't do those things, all right, then maybe you shouldn't adopt a plugin, but most people with technology experience could benefit themselves and others by adopting a plugin and caring for it, spending 10 minutes, 15 minutes, 30 minutes, exploring it to understand how it might be improved just a little bit. So let's talk first about some of the plugins that are available for adoption. So there are API plugins. Now what an API plugin is in the adoption list is it's a plugin that is a Jenkins representation of an existing API component. For example, the Apache HTTP client is a released library that's shipped by others, but in order to make it convenient to use for a Jenkins developer, we have a Jenkins plugin whose whole job is to bundle that library. It's a pretty simple task to maintain the API plugin. You watch the API that it's bundling when it releases a new version, you update the plugin and release, test it and release a new version with that updated library. So Apache HTTP client right now is on version 4.13. You would watch and when 4.14 releases, you choose to update the Palm file, one line, build it, test it in your Jenkins instance and submit a release. And now you've released a new version of the plugin. Likewise, there are build utilities. One of these may be something you're already using where you say, oh, that matters to me. I use Timeout or, oh yeah, I use the configuration file provider. Or you know what, promoted build is important to me. Well, guess what? Adopting those is a way to serve your community, serve yourself and help others. Likewise, very popular are the SCM plugins. If you're a subversion user, there's a motivation to consider adopting the subversion plugin or maybe you're a CVS user or a TFS user or a clear case, any one of those plugins is looking for a maintainer. I maintain the Git plugin and the way I got there was I started by writing tests for the Git plugin, trying to avoid regressions. And after writing tests for a while, people said, hey, should we just give this guy commit permission because he keeps submitting all these tests? You could do that. Now there are more things, more plugins that could be adopted like on Windows, if you're a Windows user, there are Windows specific things that could help others and may help you as well. Maybe you use MS build and you need the MS build plugin or you use Wix to build your installer or you depend on the Windows management install, the WMI layer agents. All those are looking for adoption. Likewise, there are admin tools that you may use. Maybe you use one of the backup plugins or the job config history or maybe you're a cloud user and one of these cloud plugins that's up for adoption is a candidate that you should consider. Likewise, there are test tools that need to be put up that have been put up for adoption and are ready. So all of them give us a hint that there's lots that you could do if you were willing to adopt a plugin and help us. So now let's take a minute here and look at the process. And I've got a, whoops, I need to go back one. So this is what we do. We follow this page that gives us instructions on how to identify a plugin that's up for adoption and then adopt it. And it talks about, hey, you send an email to the Jenkins developer mailing list with a link to the plugin you want to adopt, a link to the pull request that you'd like to deliver, if any, your GitHub username and your Jenkins account. So now how do we find plugins that need adoption? Let's go back and let's locate them on the plugin site. Jenkins plugins. And if I remember correctly, what we do is we ask about adopt. No, that's not right. Let's see, it is, I think it's label equals. Okay, let's find CVS. We'll find it the easy way. Click here and I'm going to click this label, adopt this plugin. There we go. Come on. So when I refresh this page, we're going to see that list of 111 plugins that are up for adoption. Let me put this into the slide. That really belongs there. Because you need to know where to find the plugin to adopt. I guess that another way is that you could go to your Jenkins plugin section. And then if you are using a specific plugin that is requiring adoption, you will see on their install section. That's the more that it's a way to find it, right? Oh, that is Marcel. That is a brilliant way to find it. Thank you for highlighting that. That is absolutely. So did you catch what Marcel said? He noted your Jenkins installation will hint to you the things you might consider adopting. So what I did was I went to the Jenkins dashboard to manage Jenkins, manage plugins and under installed. Now look at these nice big boxes that tell me, oh, hey, the Apache HTTP Components Client 4.x API plugin is up for adoption. This is one that I was describing, right? So you see it here and this is a great candidate. Maybe you say, I'd like to know more about that plugin. So you open that link and here is all the discussion about that plugin. Oh, I'd like to see it's GitHub repository. There it is, ready to go. Okay, what kinds of changes have happened recently? All visible from here and waiting for you to get involved to adopt it. Excellent, Marcel. Thanks so much for pointing that out. So let's look at my installation to see just how many of the plugins that I actively use are up for adoption. So I've got Apache HTTP, authorize the BitBucket branch source, the build timeout plugin, conditional build step, config file provider. This one's actually quite valuable to me. I like that one. Configuration slicing, oh, I love this one. And I would love for somebody to adopt it because it lets me with one set of clicks modify the configurations of many, many jobs all at once. And gives you a good hint of the kinds of plugins that are up for adoption. Marcel, thanks again for pointing us that way. That's a great, let me put that in the slides is look at your own Jenkins instance. Manage plugins installed, excellent. So the process that was described there send an email to the Jenkins developers mailing list is pretty simple. It's not a very high bar. You can just ask, hey, I'd like to be made a maintainer. Now, with some of the plugins, they may ask that you first submit pull requests to show that you're interested. That's a fair thing. And okay, it's a great way to get involved. Any other questions so far? Hello, Mark. Hello, this is the ratio here. In context to the skill sets that is required actually to develop a plugin. Can you please tell me what specific Java skills do we need? Good question. So what specific Java skills are needed to maintain a plugin? So if it's okay, I'm gonna tell my story as a way to answer your question. So I was a manager, morning, morning manager, I said manager. I was a manager of a team of software developers. I had been managing for many years and therefore did not write code day to day. I did not. But I was interested because I wanted to be sure that the particular plugin that caught my interest was had more tests. So I started personally writing tests but I had not done active Java development. I had little or no experience in Java IDEs and I used my beginnings of adopting the plugin to learn those things. So if you're willing to learn about Java, if you're willing to learn about how to use Maven, I had never used Maven before starting work on the Jenkins Git plugin. I had all those things were brand new to me and I used this as a way to learn them. So in terms of the bar to actually do the work, it's quite low. Now, yes, if you don't have interest in it, if you say, no, I wanna do JavaScript, then you probably should not adopt a Jenkins plugin. It is Java development. Siddish, did that answer your question or would you like to explore it further? Thanks, Mark. Thanks for the answer. I'm satisfied. However, successive to this question, and I also have another question, like Jenkins extensions are sometimes built using Ruby as well. So is knowledge of Ruby also sufficient or is it only pure Java that we need? So generally a Jenkins plugin will not be built with Groovy. Many people use Groovy to create pipelines. They use Groovy in very interesting ways, but a plugin will generally be a Java component rather than a Groovy component. Given that Groovy and Java syntax are quite similar, I didn't find it difficult to learn Groovy when I needed it, but in my case, I had been a maintainer of a plugin for many, many years before I even did anything with Groovy. Sure, thanks, Mark. All right, and anything else along that line, Sudesh? Yeah, just a probably, go ahead. Probably, sorry, sorry, guys. Just a very novice question, basically, because I'm very, very new to this particular topic, but I'm very much interested in getting along because I have been using a lot of plugins. There has always been a kind of enthusiasm as to how the plugins are getting developed and I think this is the best platform that I can get to most of the knowledge. The question that I had actually, Mark, is initially, obviously, like you showed the materials as to how to get an adopt a plugin, basically, but there might be instances where, initially, we are specifically myself. I might need some kind of a hand-holding, but is it possible that I can reach to you or someone else to understand the process, basically? So once we get adopted to it, we can contribute more. There absolutely is, very good point. So if you have a question related to, hey, I'd like to adopt a plugin, you could either, so let's put a note on that, you could either, let's see, where would I best put that? Let's find, how about, how about we'll just put it right here? So one is the developer's mailing list or chat on newcomer contributors, Gitter Channel. So, and that is at this location. So I'm gonna go ahead and open it up and it's Jenkins, Gitter here, and here is the newcomer contributors channel. And what that is, is it's specifically dedicated to helping people who are brand new contributors. And so there you'll find folks. Now, if you've got a very specific development question, the Jenkins developer list is a great place to ask your question. If you're feeling like I did initially, if you're letting your imposter syndrome kick in and you say, I'm not sure I wanna ask a question in that big of a group, the newcomer contributors group is quite small and very comfortable. Thanks Mark, please, can you also share the slides across, so that you know, we can, we can get- Oh, yes, yes, absolutely. Oh, very good, thank you. I'm gonna paste the slides, the link to the slides in the chat, sorry about that. Slides for the session are here, there, very good. Now, Valentin, I believe you also had a question. Yes, I had a question. I have noticed that some plugins have forks on GitHub. I explain it, and this does confuse me. For example, I saw, as an example, I will name a SonarCube plugin, SonarCube plugin at Jenkins. It's a fork of Sonar scanner Jenkins. So if I wanna make a pull request or something like this, where should I start? Very good question. Okay, and I'm showing, I'm showing on my screen an example that's not the SonarCube example you did, but an example that I deal with. It's okay. So I think what you're highlighting is this text right here. Yes, yes. Right, it says, hey, wait a second. This thing is forked from some, and while that message is accurate, if we can open this up and we'll see just what that means. So yes, the Jenkins CI Git plugin repository accurately was forked from Nigel Magnaes, Magnaes Hudson Git plugin. But if we look at the commits to that one, what you'll see is the last commit to that plugin, to that plugin was 11 years ago. Yeah. So what this is, what you're seeing here, this forked from is just an artifact of the history of the plugin, who it's original author before they were ready to bring it into the Jenkins organization. So the simple answer is you can ignore the forked from. And in 99.99% of the cases, that is the exact right safe thing to do. So ignore the forked from and follow the contributing directions that you'll find for most plugins in their contributing file like this one, where it says, this is where you should contribute and this is how you should do it, those kind of things. Contributing, okay. Does every single plugin has this contributing notice? No, no, we hope most of them do, but that relies on the maintainer to have created the thing. Okay. Thanks. Did that address your question? Do you have further questions? Yes, sure, sure, for sure. Thank you. All right. Sorry for interrupt. Yes, Aki. Yeah, I have to go. So, see you later. No problem. And I'll see you on other drugs. See you. Thank you. Thanks very much. All right, so back to the idea that we want to encourage adoption of plugins. So you find the plugin you want to adopt and remember this is the part where you have to overcome the imposter syndrome thing. But I can't adopt a plugin that's much too popular, much too big or much too narrow. Stop making excuses and just acknowledge that it's a good thing to, yeah, okay, maybe I'll give a little bit of time and see how it goes. So, when you adopt the plugin, you might ask, and this was something that Dheeraj asked, what are some things that you might do initially to a plugin? And so, Jonathan, I'm going to sort of target your plugin as one example of this kind of thing because it's a valid question. Hey, I've got this plugin that I use, but what are the things that might benefit me to do it? And so, one is you can simplify your life dramatically. Now, I've got to be able to highlight. If you use Dependabot to track dependencies, this is a little bit of automation that will cause automated processes to run on GitHub periodically that look for new versions of your dependencies. I love this thing because what it does is it tells me when the plugin I maintain has a new update. So, as an example, let's look at one of the plugins I maintain is called the platform labeler. And I love what this thing tells me in terms of pull requests because I will get a pull request that says, let's look at closed pull requests. Oh, one of some of my tests depend on a Docker image and this bump the Amazon Linux Docker image was offered to me by Dependabot without me doing anything. I did absolutely nothing other than configure Dependabot and it has suggested, hey, Amazon upgraded their Docker image. Oh, Ubuntu upgraded their Docker image. Oh, Alpine upgraded their Docker image. Each of them with no effort on my part, Dependabot just helps. So, this is a great one. Dependabot is wonderful. And there's this entire video here on how you use Dependabot for Jenkins plugin development. So, first point for me is use Dependabot or enable Dependabot and that's if you say, oh, I'm not sure I'm ready to adopt a plugin. That's also a good first pull request because the maintainers should be delighted to see you suggesting that you use Dependabot. So, any questions on Dependabot or any experiences you'd like to share from your use of Dependabot. Okay, next thing that you can do to simplify your life as a developer is simplify the changelog maintenance with a release drafter. Okay, release drafter is again, a little piece of automation that watches the pull requests that you merge and proposes changes to the changelog so that other people can see it and automatically publish it so that you can automatically publish it when you're ready to release. Oh, just a minute, I'm getting pinged. Yeah, okay, that'll wait. All right, so have any of you had experience previously with release drafter? I'm gonna show you an example of release drafter and show you just why I am so pleased with it. Here's the experience that I have with release drafter. Notice this formatted, let's shrink it a little, oops. This list of what's changed in the Git plugin was all created for me automatically from the pull requests that I merged to the plugin. I didn't do anything to create this, what to me is a very attractive page. It assigned things to features and improvements to dependency updates, to documentation updates all through the magic of release drafter. So it's a great thing to do as a proposed change for a plugin you're adopting. Likewise, this one, use the Jenkins plugin bill of materials is a great way to simplify the maintenance of a plugin and simplifying is really a good thing. So this page talks about how you use this, how you add this little snippet right here and then you start taking away specific version numbers listed in your plugin and it's much, much better to maintain. So Jenkins bill of materials, track dependencies with dependabot and simplify your change log management with release drafter, all good things to do to contribute to a plugin. Likewise, you could move the documentation into the GitHub repository, many older plugins. So Jonathan, I would guess your plugin probably has documentation published to the wiki, right? If I think about where its documentation is, it's probably on the wiki or some or is that correct? No, I've been actually trying to find it. It appears to have fallen off. Right. So I can find it in GitHub but I can't find much of anything and most of the last stuff there is like five or six years old. And this video can guide you how you can convert so that you keep all the documentation in GitHub right next to the source code. So you revise the documentation as you release new versions of the plugin.