Open Stack

Hi,

Le 2015-02-25 15:42, Anne Gentle a écrit :
> 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.

Making patches is also more time consuming, and people who want to 
contribute, but don't have much time (like myself) might find it more 
efficient to help other people's patches get in, instead of "loosing 
time" writing a couple low-hanging-fruit bug fixes.
And these bugs are easy targets for newcomers!


> 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.

This means that in the little time I have, I first have to do some 
triaging to see where I can help. Hence even less time to do the actual 
reviews.
I think we already had a discussion about giving some time before 
reviewing, although in another context. IIRC the problem with this is 
that some patches that could get in very quickly would have to wait. I'm 
not against the idea at all, but this might also have an opposite effect 
on contributors, and maybe bring frustration.

> - 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.

I like this idea. Some kind of mentoring?

> - 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.

+1. But I think it has to be made very clear to contributors that this 
might (will?) happen.

Gauvain


> 
> Do you think we can try these ideas?
> 
> Thanks,
> Anne
> 
> 1. http://stackalytics.com/report/contribution/documentation-group/30 
> [1]
> 2. http://stackalytics.com/report/contribution/documentation-group/90 
> [2]--
> 
> Anne Gentle
> annegentle at justwriteclick.com
> 
> Links:
> ------
> [1] http://stackalytics.com/report/contribution/documentation-group/30
> [2] http://stackalytics.com/report/contribution/documentation-group/90
> 
> _______________________________________________
> OpenStack-docs mailing list
> OpenStack-docs at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs

Gauvain Pocentek

Objectif Libre - Infrastructure et Formations Linux
http://www.objectif-libre.com