Adopt a plugin!

With more than a thousand public plugins in the Jenkins community now, it should come as no surprise that some of them are no longer actively maintained. Plugin authors move on when they change jobs, or lose interest in the plugin, and that's fine. Plugins are hosted on the Jenkins project infrastructure after all, and when a maintainer moves on, others can continue their work.

The major problem of course is that it's often difficult to tell whether a plugin is still maintained (and there's just not a lot going on), or whether its maintainer has lost interest. Most plugins don't get released every few weeks, or even every few months, and still do their job just fine.

To connect plugins that aren't actively maintained with potential maintainers, we recently implemented the "Adopt-a-plugin" initiative: We built a list of plugins that are up for "adoption", and display a prominent message on the plugins' wiki pages. Anyone interested in taking over as a plugin maintainer can then contact us, and we'll set you up.

Are you interested in becoming a plugin maintainer? Maybe one of your favorite plugins isn't actively maintained right now. Check out the Adopt a Plugin wiki page for more details on this program, and a list of plugins that would benefit from your help.

Jenkins 2.0 Proposal: Improved "Out of the box" user experience

This week we have featured a number of proposals for what we would like to see in "Jenkins 2.0", the vision of which is to make Jenkins users more efficient, productive and happy. We started with some more internally facing changes and have slowly progressed from the "inside-out" to today's topic: improving the out of the box user experience.

Jenkins 2.0 Proposal: UX Improvements (Part One)

We have been featuring a few proposals this week for what "Jenkins 2.0" is going to include. Today we'll be diving into the most noticeable changes being proposed for Jenkins 2.0: the User Experience (UX) improvements

Thus far in this blog series we have reviewed proposals covering:

The UX improvements being proposed aren't necessarily as uniform as the proposals from earlier in the week but represent a large amount of prototype and exploratory work done by folks like Tom Fennelly, Gus Reiber and a few others. Those following the dev list may have already seen some of these proposals in some of the "mega threads" that we have had discussing potential UI/UX improvements previously.

The improvements proposed for 2.0 can be found under JENKINS-31156.

Jenkins 2.0 Proposal: Pipeline as Code front and center

We have been featuring a few proposals this week for what "Jenkins 2.0" is going to include, today we're discussing my personal favorite, which I believe will have a tremendously positive impact for years to come (not to be too biased!): moving the "Pipeline as Code" support in Jenkins to the front and center.

Thus far in this blog series we have reviewed proposals covering:

Today's proposal comes from project founder Kohsuke Kawaguchi titled "Pipeline as code front and center" and represents perhaps the most important and dramatic shift we hope to make in Jenkins 2.0.

This functionality has existed through the workflow plugin, which we have discussed at various Jenkins events before but if you're not aware of some of the power behind it, check out this presentation from Jesse Glick:

Jenkins 2.0 Proposal: Split Groovy out of "core"

As I mentioned in yesterday's post, there's been a lot of discussion recently about what "Jenkins 2.0" means. In a recent "Office Hours" session, Kohsuke Kawaguchi presented his vision for Jenkins 2.0 in a office hours session, the slides for which can be found in this Google Presentation. Roughly paraphrasing Kohsuke's vision, 2.0 is primarily about making things better for the thousands of users out there.

This week, we'll be reviewing some key areas of the "Jenkins 2.0" proposal. Asking you, the user community, to provide feedback on these proposals, going from Jenkins internals to user interface.

Thus far we've covered:

Today's post involves a proposal originally from community member Jesse Glick who has proposed in JENKINS-29068 that Groovy be split out from the "core" Jenkins distribution.