Dave, on your not block acceptance #1 - where would something like ensuring consistent "look and feel" of APIs fit? I recently had a PR for another project and recommended a class name change to something more consistent with the rest of the project.
On Mon, Jun 5, 2017 at 11:08 AM, Dave Marion <dlmar...@comcast.net> wrote: > I propose that we define a set of guidelines to use when reviewing pull > requests. In doing so, contributors will be able to determine potential > issues in their code possibly reducing the number of changes that occur > before acceptance. Here's an example to start the discussion: > > > Items a reviewer should look for: > > 1. Adherence to code formatting rules (link to formatting rules) > > 2. Unit tests required > > 3. Threading issues > > 4. Performance implications > > > Items that should not block acceptance: > > 1. Stylistic changes that have no performance benefit > > 2. Addition of features outside the scope of the ticket (moving the goal > post, discussion should lead to ticket creation) >
