<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 21, 2013 at 10:45 AM, Lorin Hochstein <span dir="ltr"><<a href="mailto:lorin@nimbisservices.com" target="_blank">lorin@nimbisservices.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi Anne:<div><br></div><div>Since you're updating the review policy, can you add the following? <br>
<div><br></div><div>For core members: they should only click Approve if they've given a +2? There's been some confusion in the past among newer core members who have given +1 (looks good to me but someone else must approve) and also an "approve". (Note: this has happened to multiple people).</div>
<div><br></div></div></div></blockquote><div><br></div><div>Good point, will add.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div><div></div><div><br></div><div>(This one isn't strictly about review policy...)</div><div>For submitters amending their patch: the updated commit log message shouldn't break down the changes by individual patchset (i.e., shouldn't put "patch set 2, added foo" in an amended commit message) since only the final commit will be visible in the git history after it's accepted. (This is the policy with the other OpenStack projects, and it's in the wiki *somewhere*, but I wasn't able to find it after a cursory search).</div>
</div></div></blockquote><div><br></div><div>Oh yes, I'm guilty of "patchset does this" in my subsequent commit messages. And yes, the infra team has told me not to do it. :) I'm happy to adopt the same overall policy for commit messages. The devs rules are sooo strict though that I avoid that particular debate. Still, consistency is good. This is the policy:</div>
<div><br></div><div><a href="https://wiki.openstack.org/wiki/GitCommitMessages">https://wiki.openstack.org/wiki/GitCommitMessages</a><br></div><div><br></div><div>If you're a reviewer and want to see what has changed between patch sets, use the drop-down next to Old Version History: to compare 2 patch sets.<br>
<br>Anne</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>
<div><br></div><div>Lorin</div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Wed, Aug 21, 2013 at 11:25 AM, Anne Gentle <span dir="ltr"><<a href="mailto:anne@openstack.org" target="_blank">anne@openstack.org</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">Hi all, <div>
I'm updating the Documentation/HowTo wiki page with the following description of our review policy. Please let me know if there are any questions. I'll definitely update the wiki page as we refine our policy. </div>
<div>---</div><div><div>All community members can review doc patches and give them +1 or -1. Documentation Core members can give +2 or -2 votes and also click Approve so that the doc goes live, published to <a href="http://docs.openstack.org" target="_blank">docs.openstack.org</a> or <a href="http://api.openstack.org" target="_blank">api.openstack.org</a>, based on the branch the patch is applied to. </div>
<div><br></div><div>Because the Docs team is small, core members have the choice when reviewing and must use best judgement before publishing. Generally speaking, core members will wait for one other core member to +2 a doc patch. However if the change is small and the build works, a doc core member can +2 and Approve a change without waiting for another reviewer. This is a judgement call so docs core people should exercise judgement when using this option. </div>
<div><br></div><div>Once two community members approve a doc patch, a doc core member can also review it and push it through without waiting for a second core member.</div></div><div>---</div><div><br></div><div>Hopefully this helps all of us keep pushing through patches with a high accuracy level. Test instructions, build locally, then approve. </div>
<div><br></div><div>Thanks,</div><div>Anne</div></div>
<br></div></div>_______________________________________________<br>
Openstack-docs mailing list<br>
<a href="mailto:Openstack-docs@lists.openstack.org" target="_blank">Openstack-docs@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs</a><br>
<br></blockquote></div><span class=""><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Lorin Hochstein<br><div>Lead Architect - Cloud Services</div><div>Nimbis Services, Inc.</div><div><a href="http://www.nimbisservices.com" target="_blank">www.nimbisservices.com</a></div>
</div>
</font></span></div>
</blockquote></div><br></div></div>