Can this idea of SME as code owner be used *only* for notification so that we don't get flooded with them for every PR across the codebase and *not* as a requirement for merging so other still can get things rolling, this just covers the scenarios where a PR fell between the cracks unnoticed?
--Dana Dana Walker Associate Software Engineer Red Hat <https://www.redhat.com> <https://red.ht/sig> On Tue, Aug 14, 2018 at 11:05 AM, David Davis <davidda...@redhat.com> wrote: > 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 > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
