Proposal: Expanding the Jenkins Core maintainers team

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

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 LeonEvaristo 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):
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLCLjPCiveK_PLJ99MG3RuEtrfE4%3DjcxXyfAAtcr5TgdAQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Expanding the Jenkins Core maintainers team

Manuel Ramón León Jiménez
It would be an honor.

On Tuesday, January 21, 2020 at 1:01:58 PM UTC+1, Oleg Nenashev wrote:
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 <a href="https://groups.google.com/forum/#!msg/jenkinsci-dev/0sdrcSOQW64/tD-IKDTsBQAJ" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/forum/#!msg/jenkinsci-dev/0sdrcSOQW64/tD-IKDTsBQAJ&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/forum/#!msg/jenkinsci-dev/0sdrcSOQW64/tD-IKDTsBQAJ&#39;;return true;">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 <a href="https://github.com/orgs/jenkinsci/teams/core-pr-reviewers/members" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Forgs%2Fjenkinsci%2Fteams%2Fcore-pr-reviewers%2Fmembers\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH9Pf7UFZOMmNXNqMGA1TqkuabNOg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Forgs%2Fjenkinsci%2Fteams%2Fcore-pr-reviewers%2Fmembers\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH9Pf7UFZOMmNXNqMGA1TqkuabNOg&#39;;return true;">the reviewers team includes 10 members including me and Mark Waite. Mark was added to the Jenkins Core team in November 2019 as per <a href="https://groups.google.com/forum/#!msg/jenkinsci-dev/oDlAVOtHSCo/WCY7s-hHBwAJ" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/forum/#!msg/jenkinsci-dev/oDlAVOtHSCo/WCY7s-hHBwAJ&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/forum/#!msg/jenkinsci-dev/oDlAVOtHSCo/WCY7s-hHBwAJ&#39;;return true;">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 <a href="https://devstats.cd.foundation/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdevstats.cd.foundation%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHQyXau9ODKdbs-qB5Hv-XN0l5xCg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdevstats.cd.foundation%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHQyXau9ODKdbs-qB5Hv-XN0l5xCg&#39;;return true;">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. (<a href="https://jenkins.devstats.cd.foundation/d/46/pr-reviews-by-contributor?orgId=1&amp;from=now-2y&amp;to=now&amp;var-period=q&amp;var-repo_name=jenkinsci%2Fjenkins" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fjenkins.devstats.cd.foundation%2Fd%2F46%2Fpr-reviews-by-contributor%3ForgId%3D1%26from%3Dnow-2y%26to%3Dnow%26var-period%3Dq%26var-repo_name%3Djenkinsci%252Fjenkins\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH5TP9hE6Pwfxu-E3h3lDnLOfO_Gg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fjenkins.devstats.cd.foundation%2Fd%2F46%2Fpr-reviews-by-contributor%3ForgId%3D1%26from%3Dnow-2y%26to%3Dnow%26var-period%3Dq%26var-repo_name%3Djenkinsci%252Fjenkins\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH5TP9hE6Pwfxu-E3h3lDnLOfO_Gg&#39;;return true;">query). Quarters are counted till Dec 31, 2019.
  • During the last quarter the newcomer reviewers team members did more than 150 reviews (<a href="https://jenkins.devstats.cd.foundation/d/46/pr-reviews-by-contributor?orgId=1&amp;from=now-6M&amp;to=now&amp;var-period=q&amp;var-repo_name=jenkinsci%2Fjenkins&amp;var-reviewers=%22timja%22&amp;var-reviewers=%22varyvol%22&amp;var-reviewers=%22halkeye%22&amp;var-reviewers=%22jvz%22&amp;var-reviewers=%22res0nance%22&amp;var-reviewers=%22MRamonLeon%22&amp;var-reviewers=%22alecharp%22&amp;var-reviewers=%22fcojfernandez%22" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fjenkins.devstats.cd.foundation%2Fd%2F46%2Fpr-reviews-by-contributor%3ForgId%3D1%26from%3Dnow-6M%26to%3Dnow%26var-period%3Dq%26var-repo_name%3Djenkinsci%252Fjenkins%26var-reviewers%3D%2522timja%2522%26var-reviewers%3D%2522varyvol%2522%26var-reviewers%3D%2522halkeye%2522%26var-reviewers%3D%2522jvz%2522%26var-reviewers%3D%2522res0nance%2522%26var-reviewers%3D%2522MRamonLeon%2522%26var-reviewers%3D%2522alecharp%2522%26var-reviewers%3D%2522fcojfernandez%2522\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFBm5JIzlyVwhJhBiBNu3sju8ycbA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fjenkins.devstats.cd.foundation%2Fd%2F46%2Fpr-reviews-by-contributor%3ForgId%3D1%26from%3Dnow-6M%26to%3Dnow%26var-period%3Dq%26var-repo_name%3Djenkinsci%252Fjenkins%26var-reviewers%3D%2522timja%2522%26var-reviewers%3D%2522varyvol%2522%26var-reviewers%3D%2522halkeye%2522%26var-reviewers%3D%2522jvz%2522%26var-reviewers%3D%2522res0nance%2522%26var-reviewers%3D%2522MRamonLeon%2522%26var-reviewers%3D%2522alecharp%2522%26var-reviewers%3D%2522fcojfernandez%2522\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFBm5JIzlyVwhJhBiBNu3sju8ycbA&#39;;return true;">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 (<a href="https://jenkins.devstats.cd.foundation/d/15/new-prs-in-repository-groups?orgId=1&amp;from=now-2y&amp;to=now&amp;var-period=q&amp;var-repogroup_name=jenkinsci%2Fjenkins" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fjenkins.devstats.cd.foundation%2Fd%2F15%2Fnew-prs-in-repository-groups%3ForgId%3D1%26from%3Dnow-2y%26to%3Dnow%26var-period%3Dq%26var-repogroup_name%3Djenkinsci%252Fjenkins\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHpJZLcJbR66TG_pYPKGoR6H9p1xg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fjenkins.devstats.cd.foundation%2Fd%2F15%2Fnew-prs-in-repository-groups%3ForgId%3D1%26from%3Dnow-2y%26to%3Dnow%26var-period%3Dq%26var-repogroup_name%3Djenkinsci%252Fjenkins\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHpJZLcJbR66TG_pYPKGoR6H9p1xg&#39;;return true;">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 (<a href="https://jenkins.devstats.cd.foundation/d/10/pr-time-to-engagement?orgId=1&amp;from=now-1y&amp;to=now&amp;var-period=q&amp;var-repogroup_name=jenkinsci%2Fjenkins" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fjenkins.devstats.cd.foundation%2Fd%2F10%2Fpr-time-to-engagement%3ForgId%3D1%26from%3Dnow-1y%26to%3Dnow%26var-period%3Dq%26var-repogroup_name%3Djenkinsci%252Fjenkins\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFmxNECImljiReWvTn8w_xT6_eWBw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fjenkins.devstats.cd.foundation%2Fd%2F10%2Fpr-time-to-engagement%3ForgId%3D1%26from%3Dnow-1y%26to%3Dnow%26var-period%3Dq%26var-repogroup_name%3Djenkinsci%252Fjenkins\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFmxNECImljiReWvTn8w_xT6_eWBw&#39;;return true;">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 <a href="https://github.com/orgs/jenkinsci/teams/core" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Forgs%2Fjenkinsci%2Fteams%2Fcore\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFFEyZ3qrTHX-webFIhYq8G201oWQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Forgs%2Fjenkinsci%2Fteams%2Fcore\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFFEyZ3qrTHX-webFIhYq8G201oWQ&#39;;return true;">Jenkins Core maintainers team: <a href="https://github.com/res0nance" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fres0nance\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFITkwbrq-pRt4gZKD8i9FkPLwR2A&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fres0nance\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFITkwbrq-pRt4gZKD8i9FkPLwR2A&#39;;return true;">Raihaan Shouhell, <a href="https://github.com/jvz" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjvz\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHPme269H0E6Ia_VPAUUOjoN-oX5g&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjvz\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHPme269H0E6Ia_VPAUUOjoN-oX5g&#39;;return true;">Matt Sicker, <a href="https://github.com/timja" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Ftimja\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHsA2sPxTUboRwFCZoO0SIss8WkzA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Ftimja\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHsA2sPxTUboRwFCZoO0SIss8WkzA&#39;;return true;">Tim Jacomb, <a href="https://github.com/MRamonLeon" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FMRamonLeon\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFNbHulMDnA3LFgv1L9xN6tmzPGoQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FMRamonLeon\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFNbHulMDnA3LFgv1L9xN6tmzPGoQ&#39;;return true;">Ramon Leon, <a href="https://github.com/varyvol" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fvaryvol\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGCcstErF2zzVpl_Po6SjWH0h3d6A&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fvaryvol\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGCcstErF2zzVpl_Po6SjWH0h3d6A&#39;;return true;">Evaristo Gutiérrez  
    • All maintainers will need to sign <a href="https://github.com/jenkinsci/infra-cla" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Finfra-cla\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNErL8cSV6qDWKKBVf_FwdFknRBkaA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Finfra-cla\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNErL8cSV6qDWKKBVf_FwdFknRBkaA&#39;;return true;">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):
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/692f773f-629c-4d25-b919-3f1784245d3c%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Expanding the Jenkins Core maintainers team

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

On Tue, Jan 21, 2020 at 5:12 AM Manuel Ramón León Jiménez <[hidden email]> wrote:
It would be an honor.

On Tuesday, January 21, 2020 at 1:01:58 PM UTC+1, Oleg Nenashev wrote:
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 LeonEvaristo 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):
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 [hidden email].
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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtFVLH92Wx8rBeGykM2j13jNfV%3DEjqZdw-3R9sxB0dzqdg%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Expanding the Jenkins Core maintainers team

Tim Jacomb
In reply to this post by Oleg Nenashev
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 

On Tue, 21 Jan 2020 at 12:01, Oleg Nenashev <[hidden email]> wrote:
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 LeonEvaristo 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):
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLCLjPCiveK_PLJ99MG3RuEtrfE4%3DjcxXyfAAtcr5TgdAQ%40mail.gmail.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BicQQqGt40b2gTOhamUO0kRZo3vvC%3Dr33m0LvgLXsiZcjQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Expanding the Jenkins Core maintainers team

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?

On Tue, Jan 21, 2020 at 6:35 AM Tim Jacomb <[hidden email]> wrote:
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 

On Tue, 21 Jan 2020 at 12:01, Oleg Nenashev <[hidden email]> wrote:
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 LeonEvaristo 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):
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLCLjPCiveK_PLJ99MG3RuEtrfE4%3DjcxXyfAAtcr5TgdAQ%40mail.gmail.com.

--
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 [hidden email].
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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4owb8Zd6fiiBHg2sm5cbUTvVDpxdrZgeF%2Baazy0ESYL4%2BA%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Expanding the Jenkins Core maintainers team

Arnaud Héritier
In reply to this post by Oleg Nenashev
+1
it makes sense to me

On Tue, Jan 21, 2020 at 1:01 PM Oleg Nenashev <[hidden email]> wrote:
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 LeonEvaristo 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):
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 [hidden email].
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
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 [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Expanding the Jenkins Core maintainers team

Marky Jackson
+1 from me

On Jan 21, 2020, at 8:40 AM, Arnaud Héritier <[hidden email]> wrote:

+1
it makes sense to me

On Tue, Jan 21, 2020 at 1:01 PM Oleg Nenashev <[hidden email]> wrote:
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 LeonEvaristo 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):
<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 [hidden email].
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
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 [hidden email].
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.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA0C3FAC-4E2C-40B5-AC04-8CDE315F7324%40gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Expanding the Jenkins Core maintainers team

Victor Martinez
In reply to this post by Oleg Nenashev
+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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/74dd129f-eca3-4eea-9385-e0a9cd6ecb16%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Expanding the Jenkins Core maintainers team

Raihaan Shouhell
Sounds good to me

On Wed, 22 Jan 2020, 5:59 AM Victor Martinez, <[hidden email]> 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/74dd129f-eca3-4eea-9385-e0a9cd6ecb16%40googlegroups.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFoxvgy6MN2SPsrg_yDhWRwJrsgPAv0q5bD-ZjRnrV_Y-_MieQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Expanding the Jenkins Core maintainers team

Daniel Beck
In reply to this post by Oleg Nenashev


> On 21. Jan 2020, at 13:01, Oleg Nenashev <[hidden email]> 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.


--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/54999555-8C64-4AFF-9BA3-B07EB1CC0DD3%40beckweb.net.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Expanding the Jenkins Core maintainers team

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:


> On 21. Jan 2020, at 13:01, Oleg Nenashev <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="sJ2ufauYEgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">o.v.n...@...> 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.


--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/70fe676f-cf7b-4d77-b929-6e84baa7dcae%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Expanding the Jenkins Core maintainers team

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.

On Sun., Jan. 26, 2020, 12:31 p.m. Oleg Nenashev, <[hidden email]> wrote:
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:


> On 21. Jan 2020, at 13:01, Oleg Nenashev <[hidden email]> 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.


--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/70fe676f-cf7b-4d77-b929-6e84baa7dcae%40googlegroups.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_Duucuev3eQhncamJyWx1aUZhwZ2k%3DEOJO5Q80vWdQB7qbw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Expanding the Jenkins Core maintainers team

Raihaan Shouhell
In reply to this post by Oleg Nenashev
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

On Monday, 27 January 2020 04:31:06 UTC+8, Oleg Nenashev wrote:
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:


> On 21. Jan 2020, at 13:01, Oleg Nenashev <[hidden email]> 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.


--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/bb477d30-4251-43e5-8f0a-a27bcbed7b35%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Expanding the Jenkins Core maintainers team

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 [hidden email] 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

On Monday, January 27, 2020 at 5:11:04 PM UTC+1, Raihaan Shouhell wrote:
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

On Monday, 27 January 2020 04:31:06 UTC+8, Oleg Nenashev wrote:
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:


> On 21. Jan 2020, at 13:01, Oleg Nenashev <[hidden email]> 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.


--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/667197a7-00ee-42d9-8eab-f73830adb357%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Expanding the Jenkins Core maintainers team

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

On Tuesday, January 28, 2020 at 11:02:58 AM UTC+1, Oleg Nenashev wrote:
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 [hidden email] along with <a href="https://jenkins-ci.org/account" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fjenkins-ci.org%2Faccount\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEwgw7cJ4IS9_zVUhZZe_Wkf1MPBg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fjenkins-ci.org%2Faccount\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEwgw7cJ4IS9_zVUhZZe_Wkf1MPBg&#39;;return true;">your account on Jenkins.".  <a href="https://github.com/jenkinsci/infra-cla#corporate-cla" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Finfra-cla%23corporate-cla\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHXa4d2shCx5waWIpebC5eEyewh8w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Finfra-cla%23corporate-cla\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHXa4d2shCx5waWIpebC5eEyewh8w&#39;;return true;">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

On Monday, January 27, 2020 at 5:11:04 PM UTC+1, Raihaan Shouhell wrote:
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

On Monday, 27 January 2020 04:31:06 UTC+8, Oleg Nenashev wrote:
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:


> On 21. Jan 2020, at 13:01, Oleg Nenashev <[hidden email]> 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.


--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/86eed7e6-cd04-4d20-9fd0-f728ab7b59ee%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Expanding the Jenkins Core maintainers team

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


On Tuesday, February 4, 2020 at 1:59:25 AM UTC+1, Oleg Nenashev wrote:
Created a draft pull request with maintainer guidelines here: <a href="https://github.com/jenkinsci/jenkins/pull/4472" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjenkins%2Fpull%2F4472\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGgZDkKBTdSN27e7IU1KFI32Hu0iQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjenkins%2Fpull%2F4472\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGgZDkKBTdSN27e7IU1KFI32Hu0iQ&#39;;return true;">https://github.com/jenkinsci/jenkins/pull/4472
Would appreciate feedback

On Tuesday, January 28, 2020 at 11:02:58 AM UTC+1, Oleg Nenashev wrote:
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 [hidden email] along with <a href="https://jenkins-ci.org/account" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fjenkins-ci.org%2Faccount\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEwgw7cJ4IS9_zVUhZZe_Wkf1MPBg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fjenkins-ci.org%2Faccount\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEwgw7cJ4IS9_zVUhZZe_Wkf1MPBg&#39;;return true;">your account on Jenkins.".  <a href="https://github.com/jenkinsci/infra-cla#corporate-cla" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Finfra-cla%23corporate-cla\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHXa4d2shCx5waWIpebC5eEyewh8w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Finfra-cla%23corporate-cla\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHXa4d2shCx5waWIpebC5eEyewh8w&#39;;return true;">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

On Monday, January 27, 2020 at 5:11:04 PM UTC+1, Raihaan Shouhell wrote:
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

On Monday, 27 January 2020 04:31:06 UTC+8, Oleg Nenashev wrote:
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:


> On 21. Jan 2020, at 13:01, Oleg Nenashev <[hidden email]> 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.


--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/54c26dc1-7e4a-444d-a698-ee09397ca44a%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Expanding the Jenkins Core maintainers team

Oleg Nenashev
I have added Raihaan ShouhellMatt SickerTim JacombRamon Leon and Evaristo Gutiérrez  to the core maintainers team.
Welcome aboard!

On Wednesday, February 12, 2020 at 12:44:34 PM UTC+1, Oleg Nenashev wrote:
Hi all,

Thanks to everyone who contributed to the maintainer guide!
It is still under review in <a href="https://github.com/jenkinsci/jenkins/pull/4472" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjenkins%2Fpull%2F4472\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGgZDkKBTdSN27e7IU1KFI32Hu0iQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjenkins%2Fpull%2F4472\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGgZDkKBTdSN27e7IU1KFI32Hu0iQ&#39;;return true;">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


On Tuesday, February 4, 2020 at 1:59:25 AM UTC+1, Oleg Nenashev wrote:
Created a draft pull request with maintainer guidelines here: <a href="https://github.com/jenkinsci/jenkins/pull/4472" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjenkins%2Fpull%2F4472\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGgZDkKBTdSN27e7IU1KFI32Hu0iQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjenkins%2Fpull%2F4472\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGgZDkKBTdSN27e7IU1KFI32Hu0iQ&#39;;return true;">https://github.com/jenkinsci/jenkins/pull/4472
Would appreciate feedback

On Tuesday, January 28, 2020 at 11:02:58 AM UTC+1, Oleg Nenashev wrote:
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 [hidden email] along with <a href="https://jenkins-ci.org/account" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fjenkins-ci.org%2Faccount\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEwgw7cJ4IS9_zVUhZZe_Wkf1MPBg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fjenkins-ci.org%2Faccount\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEwgw7cJ4IS9_zVUhZZe_Wkf1MPBg&#39;;return true;">your account on Jenkins.".  <a href="https://github.com/jenkinsci/infra-cla#corporate-cla" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Finfra-cla%23corporate-cla\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHXa4d2shCx5waWIpebC5eEyewh8w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Finfra-cla%23corporate-cla\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHXa4d2shCx5waWIpebC5eEyewh8w&#39;;return true;">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

On Monday, January 27, 2020 at 5:11:04 PM UTC+1, Raihaan Shouhell wrote:
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

On Monday, 27 January 2020 04:31:06 UTC+8, Oleg Nenashev wrote:
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:


> On 21. Jan 2020, at 13:01, Oleg Nenashev <[hidden email]> 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.


--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/96cb414b-aa22-4b36-93fa-68c1d97fc861%40googlegroups.com.