I like this idea, too.

On Thu, Sep 19, 2019 at 7:09 AM Mark Waite <[email protected]> wrote:
>
> I like the idea very much.  GitHub triage looks like a really nice addition 
> without granting more permissions than necessary.
>
> On Thu, Sep 19, 2019 at 5:58 AM Tim Jacomb <[email protected]> wrote:
>>
>> Sounds good to me
>>
>> On Thu, 19 Sep 2019 at 12:26, Oleg Nenashev <[email protected]> wrote:
>>>
>>> Hi all,
>>>
>>> I would like to make a proposal w.r.t the Jenkins Core review process.
>>>
>>> As you may see from the pull requests, currently we have a pretty heavy 
>>> process which includes multiple reviews, labeling PRs for automatic 
>>> changelog drafts, and so on. This process helps us to maintain high quality 
>>> of weekly releases. Over the last year we have had many contributors who 
>>> helped to review core pull requests on a regular basis. These contributors 
>>> do not have WRITE permission in the repo, and they had no way no assign 
>>> labels, request reviews, re-trigger CI, and so on. Only jenkinsci/Core 
>>> members have permission to do that, and it is a serious overhead since we 
>>> do not have many active core maintainers in jenkinsci/Core looking at PRs.
>>>
>>> Few months ago GitHub introduced a new TRIAGE permission for the repository 
>>> which basically gives permissions to manage issues/pull requests without 
>>> being actually able to merge them. IMO it gives us a great opportunity to 
>>> expand the core reviewers bandwidth and at the same time to offer a path 
>>> for onboarding new core maintainers (contributor => Triage => Write 
>>> permissions).
>>>
>>> What I suggest to do:
>>>
>>> Introduce a new jenkinsci/core-pr-reviewers team
>>> Grant the team TRIAGE permission in  https://github.com/jenkinsci/jenkins
>>> Maybe?: Add CODEOWNERS to GitHub to automatically request reviews from the 
>>> new team for new pull requests
>>> Invite contributors who regularly review Jenkins core pull requests: 
>>> alecharp, varyvol, MarkEWaite, res0nance, jvz, MRamonLeon, halkeye (sorry 
>>> if I missed anyone!)
>>>
>>> If the approach works well, later we can expand it to components which are 
>>> a part of the Jenkins core (libraries, modules, etc.).
>>>
>>> What do you think?
>>>
>>> Best regards,
>>> Oleg
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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 [email protected].
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLAypnU_vnh3GB3_DVDD5R2vZePjzvsuGtpvXEQTsyOrjQ%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 [email protected].
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifMF%2B8X%3D8wG4Pbh4Q8cguSzx2j-RmtUmORmw10MsB7aLw%40mail.gmail.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 [email protected].
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtHVQq%2BdciSsHU0w5jVhrJ%3DYemzUqeERV7-6sCRYASfyuQ%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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4oy%2BOUkozcYzErMpUqexxexX9OMx6aYRKaiFzCQcd5dJ9Q%40mail.gmail.com.

Reply via email to