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 <zbit...@redhat.com
<mailto:zbit...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
