\o/ --- -> gpg --keyserver keys.gnupg.net --recv-key 52210D3D ---
On Fri, Sep 20, 2019, at 11:23 AM, Raihaan Shouhell wrote: > I'd be keen on this +1 > > On Thursday, 19 September 2019 19:26:46 UTC+8, Oleg Nenashev 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 >> <https://github.com/jenkinsci/jenkins/pulls>, 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 >> <https://help.github.com/en/articles/repository-permission-levels-for-an-organization#permission-levels-for-repositories-owned-by-an-organization> >> 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 <https://github.com/alecharp>, varyvol >> <https://github.com/varyvol>, MarkEWaite <https://github.com/MarkEWaite>, >> res0nance <https://github.com/res0nance>, jvz <https://github.com/jvz>, >> MRamonLeon <http://mramonleon/>, halkeye <https://github.com/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/191d48e2-1898-4266-8c39-0b2465bef2d9%40googlegroups.com > > <https://groups.google.com/d/msgid/jenkinsci-dev/191d48e2-1898-4266-8c39-0b2465bef2d9%40googlegroups.com?utm_medium=email&utm_source=footer>. -- 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/3f07d55f-dc0e-4c1d-8fee-3a8016ef7d03%40www.fastmail.com.
