[openstack-dev] [tc][all] A culture change (nitpicking)

Rochelle Grober rochelle.grober at huawei.com
Tue Jun 5 01:27:01 UTC 2018


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.

I offer the suggestion that there are some real examples of Good/Not Good in the document or maybe an addendum.  Since we have many non-native speakers in our community, examples are like pictures -- worth a thousand foreign words;-)

Maybe Zhipeng has a few favorites to supply.  I would suggest both score and comment to go with score.  In some cases, the example would show how to score and avoid nitpicking, in others, valid scores, but comments that are reasonable or not for the score.

--Rocky
 
> Have at it!
> 
> cheers,
> Zane.
> 
> > -Julia
> >
> > [1]: https://review.openstack.org/#/c/570940/
> 
> __________________________________________________________
> ________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


More information about the OpenStack-dev mailing list