Open Stack

On 04/06/18 10:19, Amy Marrich wrote:
> Zane,
> 
> I'll read in more detail, but do we want to add rollcall-vote?

Is it used anywhere other than in the governance repo? We certainly 
could add it, but it didn't seem like a top priority.

- ZB

> Amy (spotz)
> 
> On Mon, Jun 4, 2018 at 7:13 AM, Zane Bitter <zbitter at redhat.com 
> <mailto: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-documentation/using-gerrit.html#reviewing-changes
>     <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
>     <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/
>         <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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> 
> 
> 
> __________________________________________________________________________
> 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
>