The code owner feature in Github requests reviews from code owners when a PR is opened. This both notifies the responsible team when they have a PR to review and also makes it clear who should be reviewing a particular PR so that the PR author can follow up with those people.
David On Tue, Aug 14, 2018 at 10:36 AM Bryan Kearney <bkear...@redhat.com> wrote: > On 08/13/2018 05:29 PM, David Davis wrote: > > > > > > # Problem Statement > > > > For Pulp's review process, there are several areas we could improve: > > > > 1. It’s not always clear who should review files. Over time we have > > developed subject matter experts for different areas of the codebase, > > but these are not codified anywhere. It would be useful for us to define > > teams need to review projects using code owners. > > > > 2. PRs go unnoticed. Github has a request-review feature, but only > > members of the github organization can click 'request review' button. It > > would be great if when a PR is opened people automatically received PR > > review requests. > > > > > > # Team Examples > > > > Functional Tests - The QE Team should be code owners of functional tests > > that test core or core-maintained plugins > > The Tasking System - bmbouter, daviddavis, and dalley are the SME in > > this area > > > > > > # Solution > > > > 1. Configure the code-owners feature of Github > > (https://blog.github.com/2017-07-06-introducing-code-owners/). It will > > allow a team of 2 or more people to be notified and asked for review > > when a PR modifies a file within a certain area of the code. > > > > 2. Require code-owner review to merge. This is described in this > > section: > > > https://blog.github.com/2017-07-06-introducing-code-owners/#an-extra-layer-of-code-security > > > > > > # Process > > > > The code owner role is not related to the commit bit. It's designed to > > get better reviews. Well reviewed work can be confidently merged by > > anyone with the commit bit. > > > > To make a change to code owners, open a PR with the changes, and call > > for a lazy consensus vote by mailing list. Similar to the PUP decision > > making process, voting must be open for 10 days, and the committers of > > the respective repository are voting. > > > > The code owners file itself should be owned by the core committers of > > the repository. > > > If the problem statement is a slowdown in PRs, how does limiting who can > do the review/merge solve the issue? > > -- bk > > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev