I think that changes to the public API would be under more scrutiny and hopefully a consensus could be reached. I don't think we have hard and fast rules for our API conventions.
> On June 5, 2017 at 11:19 AM Tony Kurc <trk...@gmail.com> wrote: > > > 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) > >
