Thanks for the patch Zane :) -Kendall (diablo_rojo)
On Mon, Jun 11, 2018 at 3:50 PM Zane Bitter <[email protected]> wrote: > On 04/06/18 10:13, Zane Bitter wrote: > > On 31/05/18 14:35, Julia Kreger wrote: > >> Back to the topic of nitpicking! > >> > >> I virtually sat down with Doug today and we hammered out the positive > >> aspects that we feel like are the things that we as a community want > >> to see as part of reviews coming out of this effort. The principles > >> change[1] in governance has been updated as a result. > >> > >> I think we are at a point where we have to state high level > >> principles, and then also update guidelines or other context providing > >> documentation to re-enforce some of items covered in this > >> discussion... not just to educate new contributors, but to serve as a > >> checkpoint for existing reviewers when making the decision as to how > >> to vote change set. The question then becomes where would such > >> guidelines or documentation best fit? > > > > I think the contributor guide is the logical place for it. Kendall > > pointed out this existing section: > > > > > https://docs.openstack.org/contributors/code-and-documentation/using-gerrit.html#reviewing-changes > > > > > > It could go in there, or perhaps we separate out the parts about when to > > use which review scores into a separate page from the mechanics of how > > to use Gerrit. > > > >> Should we explicitly detail the > >> cause/effect that occurs? Should we convey contributor perceptions, or > >> maybe even just link to this thread as there has been a massive amount > >> of feedback raising valid cases, points, and frustrations. > >> > >> Personally, I'd lean towards a blended approach, but the question of > >> where is one I'm unsure of. Thoughts? > > > > Let's crowdsource a set of heuristics that reviewers and contributors > > should keep in mind when they're reviewing or having their changes > > reviewed. I made a start on collecting ideas from this and past threads, > > as well as my own reviewing experience, into a document that I've > > presumptuously titled "How to Review Changes the OpenStack Way" (but > > might be more accurately called "The Frank Sinatra Guide to Code Review" > > at the moment): > > > > https://etherpad.openstack.org/p/review-the-openstack-way > > > > It's in an etherpad to make it easier for everyone to add their > > suggestions and comments (folks in #openstack-tc have made some tweaks > > already). After a suitable interval has passed to collect feedback, I'll > > turn this into a contributor guide change. > > It's had a week to percolate (and I've seen quite a few people viewing > the etherpad), so here is the review: > > https://review.openstack.org/574479 > > - ZB > > > Have at it! > > > > cheers, > > Zane. > > > >> -Julia > >> > >> [1]: https://review.openstack.org/#/c/570940/ > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
