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.
Have at it!
cheers,
Zane.
-Julia
[1]: https://review.openstack.org/#/c/570940/
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
