Proposal: Expanding the Jenkins Core maintainers team

[Oleg Nenashev]

Dear all,

TL;DR: I propose to expand the Jenkins Core maintainers team by inviting the most active code reviewers to the team. 

As you probably know, Jenkins core maintainers capacity has been a long-standing issue which was impacting the velocity of the Jenkins core and, in some case, leading to regressions due to missed issues during reviews. In September 2019 we created a new Core Pull Request Reviewers team in order to onboard more reviewers and provide a clear path to join the Jenkins Core team (aka "Jenkins core maintainers"). Currently the reviewers team includes 10 members including me and Mark Waite. Mark was added to the Jenkins Core team in November 2019 as per this discussion.

The "onboard more reviewers " part was a huge success IMHO. We largely increased number of reviews in the Jenkins core. Below you can find some stats and I extracted from DevStats. Please take them with a grain of salt, because there are some artifacts I see in other repositories:

• Last quarter we got to almost 700 reviews. Before the change we had 400 reviews in the previous quarter. (query). Quarters are counted till Dec 31, 2019.
• During the last quarter the newcomer reviewers team members did more than 150 reviews (query). This number is lower than the one above, but apparently it  ignores re-reviews
• We went from 2.5 to 4 reviews on average in pull requests. Number of incoming pull requests was quite stable over past quarters (query). Note that the review numbers IIUC includes re-reviews. Before introducing the team we used to merge a lot of PRs with just one review, but it does not happen anymore
• Time to engagement slightly improved, but no drastic improvements there (query)

IMHO it is time to proceed with the second part, "provide a clear path to join the Jenkins Core team". Based on the data, I suggest we expand the core team by inviting the most active code reviewers to it. Effectively it means granting merge permissions. I suggest the following:

• 5 most active reviewers are invited to join the Jenkins Core maintainers team: Raihaan Shouhell, Matt Sicker, Tim Jacomb, Ramon Leon, Evaristo Gutiérrez  
  
• All maintainers will need to sign individual CLA (and company CLA if needed) before getting permissions
• The team provides access to 32 repositories: Jenkins modules, libraries and core developer tools like Parent POMs. I will probably clean it up a bit
• We ensure that there is a knowledge transfer process established to help new maintainers
• We start doing regular office hours with Q&A and joint PR grooming/review sessions, e.g. every 2 weeks. I am ready to run such sessions
• Maintainer guidelines and best practices are documented in the Jenkins core repo. We will gradually create this documentation together during KT sessions  
• TBD - we create a new public chat for core maintainers so that conversations can happen outside highly populated #jenkins and jeninsci/jenkins channels in IRC and Gitter. Maybe YAGNI?
• We encourage more contributors to join the reviewers team. Having more contributors is always great!

What do you think?

Best regards,

Oleg Nenashev

Reviews by Core PR reviewers team in this quarter (Oleg and Mark are excluded):

Jenkins Core code reviews by quarter:

Jenkins core pull request by quarter:

[Manuel Ramón León Jiménez]

It would be an honor.

[Mark Waite]

+1 from me.  Thanks very much for the data that you've collected!

--
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/692f773f-629c-4d25-b919-3f1784245d3c%40googlegroups.com.

--

Thanks!

Mark Waite

[Tim Jacomb]

Sounds good to me,

Possibly instead of a core or in addition it might be good to have a jenkins-developer / dev channel. 

Separate to the Jenkins channels which have a lot of user questions

Thanks

Tim 

--
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/CAPfivLCLjPCiveK_PLJ99MG3RuEtrfE4%3DjcxXyfAAtcr5TgdAQ%40mail.gmail.com.

[Matt Sicker]

I'd be happy to help out!

For chat, if we need a more focused channel, can we use the CDF slack or something?

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BicQQqGt40b2gTOhamUO0kRZo3vvC%3Dr33m0LvgLXsiZcjQ%40mail.gmail.com.

--

Matt Sicker
Senior Software Engineer, CloudBees

[Arnaud Héritier]

+1

it makes sense to me

--
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/CAPfivLCLjPCiveK_PLJ99MG3RuEtrfE4%3DjcxXyfAAtcr5TgdAQ%40mail.gmail.com.

--

-----

Arnaud Héritier

http://aheritier.net

Mail/GTalk: aheritier AT gmail DOT com

Twitter/Skype : aheritier

[Marky Jackson]

+1 from me

<image.png>

Jenkins Core code reviews by quarter:

<image.png>

Jenkins core pull request by quarter:

<image.png>

--
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/CAPfivLCLjPCiveK_PLJ99MG3RuEtrfE4%3DjcxXyfAAtcr5TgdAQ%40mail.gmail.com.

--

-----

Arnaud Héritier

http://aheritier.net

Mail/GTalk: aheritier AT gmail DOT com

Twitter/Skype : aheritier

--
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/CAFNCU-8E5kx_45mJvZtPzqP0%3D-Ba_P4zzWvzq9KbYDKSzUk8RQ%40mail.gmail.com.

[Victor Martinez]

+1 

This is really great news!! Thanks for moving forward <3

[Raihaan Shouhell]

Sounds good to me

On Wed, 22 Jan 2020, 5:59 AM Victor Martinez, <victormar...@gmail.com> wrote:

+1 

This is really great news!! Thanks for moving forward <3

--

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/74dd129f-eca3-4eea-9385-e0a9cd6ecb16%40googlegroups.com.

[Daniel Beck]

> On 21. Jan 2020, at 13:01, Oleg Nenashev <o.v.ne...@gmail.com> wrote:
>
> TL;DR: I propose to expand the Jenkins Core maintainers team by inviting the most active code reviewers to the team.
>

I'm all for adding more active maintainers, so +1. It's been nice actually getting reviews for submissions (and with this change they will even be green, not grey!).

I wonder about the methodology used here though. The data is objective, but do these numbers actually tell us something useful, other than that Gavin's recent (awesome) contributions to the project are elsewhere? This seems akin to counting lines of code changed as a proxy for productivity.


> • We ensure that there is a knowledge transfer process established to help new maintainers

> • We start doing regular office hours with Q&A and joint PR grooming/review sessions, e.g. every 2 weeks. I am ready to run such sessions
> • Maintainer guidelines and best practices are documented in the Jenkins core repo. We will gradually create this documentation together during KT sessions

I'd also like to recommend that we emphasize the need to evaluate the usefulness of contributions in the maintainer guidelines. Not all contributions make sense to merge, and even useful contributions might result in weird inconsistencies or even problems across the whole of Jenkins if accepted as submitted. There's some subjectivity here, but even if you tend to be lenient on such matters, please still consider these issues and don't simply focus on whether the code works in isolation; that's not how it's going to affect users.

[Oleg Nenashev]

One thing to mention is that I will be traveling on Jan 29 ... Feb 08: FOSDEM and then a business trip. This time my time will be really limited, and it is safe to assume that I will not be available to review and merge pull requests. On the other hand, I also will unlikely be available for timely Q&A. After considering options, my preference was to add more maintainers and to do the best efforts on the documentation fronts before I go off.

Regarding the permissions, I am waiting for the Weekly release with regression patches and for ICLA submission from Raihaan

I wonder about the methodology used here though. The data is objective, but do these numbers actually tell us something useful, other than that Gavin's recent (awesome) contributions to the project are elsewhere? This seems akin to counting lines of code changed as a proxy for productivity.

Be sure I recognize and hugely appreciate Gavin's contributions. At the moment they just do not go into the Jenkins core, and hence Gavin was not in my list for Core maintainers. If others would like to add Gavin to the core maintainers team, I would be happy to support it. Regarding my methodology, I just used the existing queries, they do not represent quality of the reviews and other factors. If anyone wants to introduce better metrics and to reconsider the list, be my guest :)

I'd also like to recommend that we emphasize the need to evaluate the usefulness of contributions in the maintainer guidelines. Not all contributions make sense to merge, and even useful contributions might result in weird inconsistencies or even problems across the whole of Jenkins if accepted as submitted. There's some subjectivity here, but even if you tend to be lenient on such matters, please still consider these issues and don't simply focus on whether the code works in isolation; that's not how it's going to affect users.

Duly noted, I will add it explicitly to the maintainer docs

 

BR, Oleg

On Saturday, January 25, 2020 at 11:44:10 PM UTC+1, Daniel Beck wrote:

[Gavin Mogan]

I love all the love, but not interested in any serious help with core. Java is not my strength and rather just randomly help where I can.

--
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/70fe676f-cf7b-4d77-b929-6e84baa7dcae%40googlegroups.com.

[Raihaan Shouhell]

I was under the impression that a CCLA has to be filed first, is my assumption wrong?

I'm currently in the process of getting that sorted out

[Oleg Nenashev]

Hi Raihaan,

Yes, at least it is what our documentation says: "If you work on Jenkins core on behalf of your employer, your company needs to have CCLA in place. Have CCLA printed, signed, scanned back to PDF, then send it to jenkin...@googlegroups.com along with your account on Jenkins.".  https://github.com/jenkinsci/infra-cla#corporate-cla

So, if you work on the Jenkins core as your wok responsibilities, it would need CCLA.

If you do it during your spare time, it is not needed. Our ICLA covers the end responsibility of a contributor to ensure the permissive license anyway anyway in (4): "You represent that you are legally entitled to grant the above license. If your employer(s) has rights to intellectual property that you create that includes your Contributions, you represent that you have received permission to make Contributions on behalf of that employer, that your employer has waived such rights for your Contributions to the Project, or that your employer has executed a separate Corporate CLA with the Project.". There is "OR" in the end here.

BR, Oleg

[Oleg Nenashev]

Created a draft pull request with maintainer guidelines here: https://github.com/jenkinsci/jenkins/pull/4472
Would appreciate feedback

[Oleg Nenashev]

Hi all,

Thanks to everyone who contributed to the maintainer guide!

It is still under review in https://github.com/jenkinsci/jenkins/pull/4472, but I believe the most critical feedback was addressed there.

Is everyone is fine, I would like to proceed and to finally grant permissions as it was suggested in the original email.

Is anyone opposed to it?

Best regards,

Oleg

[Oleg Nenashev]

I have added Raihaan Shouhell, Matt Sicker, Tim Jacomb, Ramon Leon and Evaristo Gutiérrez  to the core maintainers team.

Welcome aboard!