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

Kendall Nelson kennelson11 at gmail.com
Tue Jun 12 08:38:53 UTC 2018


Thanks for the patch Zane :)

-Kendall (diablo_rojo)

On Mon, Jun 11, 2018 at 3:50 PM Zane Bitter <zbitter at redhat.com> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180612/792000fb/attachment.html>


More information about the OpenStack-dev mailing list