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

Amy Marrich amy at demarco.com
Mon Jun 4 14:19:22 UTC 2018


Zane,

I'll read in more detail, but do we want to add rollcall-vote?

Amy (spotz)

On Mon, Jun 4, 2018 at 7:13 AM, Zane Bitter <zbitter at redhat.com> 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-documentati
> on/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-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/20180604/8f1b14b1/attachment.html>


More information about the OpenStack-dev mailing list