<div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote">On Tue, Aug 14, 2018 at 4:36 PM, Bryan Kearney <<a href="mailto:bkearney@redhat.com" target="_blank">bkearney@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">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 > (<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 > 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: > <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> > > > # 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. > </div></div>If the problem statement is a slowdown in PRs, how does limiting who can do the review/merge solve the issue? </blockquote><div>hard unless the SME (and/or commit bit ownership) status is tied formally to review quality and rate.</div><div> </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> -- bk _______________________________________________ Pulp-dev mailing list <a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a> </blockquote></div> </div></div>