<div dir="ltr">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.<div><div><div><div><div dir="ltr" class="m_-4544786066920661112m_5940815626755237823gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 14, 2018 at 10:36 AM Bryan Kearney <<a href="mailto:bkearney@redhat.com" target="_blank">bkearney@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 08/13/2018 05:29 PM, David Davis wrote:<br>
> <br>
> <br>
> # Problem Statement<br>
> <br>
> For Pulp's review process, there are several areas we could improve:<br>
> <br>
> 1. It’s not always clear who should review files. Over time we have<br>
> developed subject matter experts for different areas of the codebase,<br>
> but these are not codified anywhere. It would be useful for us to define<br>
> teams need to review projects using code owners.<br>
> <br>
> 2. PRs go unnoticed. Github has a request-review feature, but only<br>
> members of the github organization can click 'request review' button. It<br>
> would be great if when a PR is opened people automatically received PR<br>
> review requests.<br>
> <br>
> <br>
> # Team Examples<br>
> <br>
> Functional Tests - The QE Team should be code owners of functional tests<br>
> that test core or core-maintained plugins<br>
> The Tasking System  - bmbouter, daviddavis, and dalley are the SME in<br>
> this area<br>
> <br>
> <br>
> # Solution<br>
> <br>
> 1. Configure the code-owners feature of Github<br>
> (<a href="https://blog.github.com/2017-07-06-introducing-code-owners/" rel="noreferrer" target="_blank">https://blog.github.com/2017-07-06-introducing-code-owners/</a>). It will<br>
> allow a team of 2 or more people to be notified and asked for review<br>
> when a PR modifies a file within a certain area of the code.<br>
> <br>
> 2. Require code-owner review to merge. This is described in this<br>
> section:<br>
> <a href="https://blog.github.com/2017-07-06-introducing-code-owners/#an-extra-layer-of-code-security" rel="noreferrer" target="_blank">https://blog.github.com/2017-07-06-introducing-code-owners/#an-extra-layer-of-code-security</a><br>
> <br>
> <br>
> # Process<br>
> <br>
> The code owner role is not related to the commit bit. It's designed to<br>
> get better reviews. Well reviewed work can be confidently merged by<br>
> anyone with the commit bit.<br>
> <br>
> To make a change to code owners, open a PR with the changes, and call<br>
> for a lazy consensus vote by mailing list. Similar to the PUP decision<br>
> making process, voting must be open for 10 days, and the committers of<br>
> the respective repository are voting.<br>
> <br>
> The code owners file itself should be owned by the core committers of<br>
> the repository.<br>
> <br>
If the problem statement is a slowdown in PRs, how does limiting who can<br>
do the review/merge solve the issue?<br>
<br>
-- bk<br>
<br>
<br>
</blockquote></div>