Open Stack

Hi all,
Title change since I'm all about positivity. :)

I've been at an internal dev conference this week and started asking around
to hear what other teams do about review quality - how to improve it. I
find that sometimes I only have time to pick nits or only mark edits to our
conventions. I'd rather do technical reviews and ensure consistency and
quality, of course.

I'm also looking at our 30-day [1] and 90-day stats[2],  and what's
interesting is there's a bit of an imbalance for some people in number of
reviews being high and number of commits being low. What this might be
setting up is a feeling of more criticism than collaborative patching,
which I think we're all feeling. I'm personally committing more to just
patching a patch when OpenStack is spelled Openstack, ya know? But since
I'm already a core member and others may be trying to become core, I want
to find more ways to enable that goal (more great reviewers on core).

So I've got a couple of ideas, not policy exactly but what do you think
about these ideas:

- The first day a patch is up, let newer reviewers do the reviews. The
second day, more experienced reviewers can step in after a first review is
done. This approach trains more reviewers in creating higher-quality
reviews.
- Try to pair with another reviewer, and I can help with this, where the
more experienced docs writers and reviewers give guidance on any patch.
- If you only have small suggestions (that you know are still technically
accurate), patch the patch. Never merge a patch until the original author
has a chance to re-review your changes, however.

Do you think we can try these ideas?

Thanks,
Anne


1. http://stackalytics.com/report/contribution/documentation-group/30
2. http://stackalytics.com/report/contribution/documentation-group/90
-- 
Anne Gentle
annegentle at justwriteclick.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20150225/60ebf0d8/attachment.html>