I like the idea in general. It's could help with individual momentum for new contributors. The idea to me says, we create a sense of belonging and a path to learning more step by step. <div><br></div><div>If we committed to pushing patches faster, and then created more bugs, then I would say that each bug creating patch would need to be owned by the patch approver and the patch contributor. The patch approver in the role of a mentor. </div><div><br></div><div>This scales and lines up new people with experienced ones. Ideas on how it could be automated?<br><br>On Monday, February 23, 2015, Lana Brindley <<a href="mailto:openstack@lanabrindley.com">openstack@lanabrindley.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 24/02/15 09:00, Nick Chase wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On 2/23/2015 1:52 PM, Andreas Jaeger wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks for bringing it up. We do have guidelines<br>
here: <a href="https://wiki.openstack.org/wiki/Documentation/ReviewGuidelines" target="_blank">https://wiki.openstack.org/<u></u>wiki/Documentation/<u></u>ReviewGuidelines</a> so<br>
feel free to enhance those to help solve the problem.<br>
Before we do this, I suggest that we experiment a bit with the workflow.<br>
Nick, could you show us a few examples how this would work, please?<br>
</blockquote>
<br>
Basically, as far as the ReviewGuidelines, we would add a new type of<br>
change, making the three possibilities "Objective", "Subjective", and<br>
"Cosmetic/Convention".  So for a (probably silly, but demonstrative)<br>
example:<br>
<br>
-- You submit a change that adds a new section talking about how to add,<br>
say, a new driver for Cinder, and everywhere you should have "OpenStack<br>
Block Storage" you just say "cinder".  You a<br>
-- I review your change, and I see that everything is fine, except for<br>
those 17 instances of "cinder".<br>
-- From here it can go one of three ways:<br>
-- 1) I comment that I'm going to fix it (so you don't spend time on<br>
it), then correct them and submit a patch, and +1.<br>
-- 2) I mark them, and you fix them and resubmit.  I +1.<br>
-- 3) I let you know that it needs to be fixed and:<br>
-- -- 3a) you submit a bug and drop it into comments, then I +1 or<br>
-- -- 3b) I submit a bug, then +1<br>
</blockquote>
<br>
So, this isn't totally insane. From where I'm sitting though, I'd vastly prefer to see 1 and 2 happen in 90%+ cases. I think we need to be having a broader discussion about review rigour in general, though, so we can better identify where a -1 isn't warranted, where a reviewer should do a quick fix on someone else's patchset, or where a new bug is a better way of fixing issues.<br>
<br>
I know when I started working on OpenStack docs, doing reviews was quite daunting, mostly because I didn't have a good idea what level of review rigour was expected. Here's some notes I wrote about that at the time:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A note on review rigour: There are very few guidelines about what consists of a successful patch, but the general approach seems to be that if it's technically accurate and better than the existing content, then it should be approved. The main things to look for:<br>
General spelling and grammar.<br>
Technical accuracy. Where possible, test commands on your own VM to make sure they're accurate. Check any related bugs, and the Disqus comments on the doc site to see if there's anything else you might need to take into account.<br>
The 'is it better than what we have already' test. Check the diff, or go look at the current document on the doc site, and determine if the changes are an improvement.<br>
Provide corrections in-line (double click on the offending line in the diff viewer to write your suggested changes) for the author to fix if there's more than a couple of errors. If there's just one or two really minor changes (or in a situation where the writer is either ESL or could be otherwise unable to improve the doc themselves), consider checking out the patch and editing it quickly yourself. Be nice.<br>
</blockquote>
<br>
Hopefully this can start a broader conversation about what is/isn't expected from reviewers :)<br>
<br>
L<br>
<br>
-- <br>
Lana Brindley<br>
Technical Writer<br>
Rackspace Cloud Builders Australia<br>
<a href="http://lanabrindley.com" target="_blank">http://lanabrindley.com</a><br>
<br>
______________________________<u></u>_________________<br>
OpenStack-docs mailing list<br>
<a>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/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-docs</a><br>
</blockquote></div><br><br>-- <br>~sean<br>