Open Stack

Zane,

Not sure it is to be honest.:)

Amy (spotz)

On Mon, Jun 4, 2018 at 7:29 AM, Zane Bitter <zbitter at redhat.com> wrote:

> 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-documentati
>> on/using-gerrit.html#reviewing-changes
>>     <https://docs.openstack.org/contributors/code-and-documentat
>> ion/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:unsubscrib
>> e
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180604/020d411e/attachment.html>