Open Stack

On Wed, Oct 30, 2013 at 9:31 AM, Daniel P. Berrange <berrange at redhat.com>wrote:

> On Wed, Oct 30, 2013 at 10:08:03AM +1100, Tom Fifield wrote:
> > Hi all,
> >
> > Recently, I did something crazy and got into the "top 10" reviewers
> > for OpenStack in a 30/60 day window. Admittedly, this was for
> > documentation  - which is quite a bit different than code - but the
> > experience did give me a small window of insight into the challenge
> > faced by our venerable core reviewers. It's a really tough job!
> >
> > One of the aspects that I noticed in doing so many reviews is that a
> > review was much easier to perform if another reviewer had been
> > through it beforehand. That is, a patch had gone through a couple of
> > -1 iterations to finally get a +1 before I saw it.
> >
> > This made me think a little about how much emphasis we place as a
> > community on +2 reviews. It can seem at times like they're the only
> > reviews we care about. Hell, I've even heard song lyrics from a
> > community member that imply this :D
> >
> > I think it's time to bend that focus slightly, and promote the role
> > of the +1 reviewers. Every review that a non-core reviewer does
> > helps reduce the burden of core reviewers just that little bit.
>
> It absolutely does, and is much appreciated by us core team
> members.
>
> > Do you see this too? How can we help encourage more +1 reviews?
>
>

Perhaps we should try making the top non-core reviewers more visible.
 Maybe list and thank the top x non-core reviewers and companies in the
weekly OpenStack newsletter?


> It is a tough question. You don't want to put up strict rules since that
> is typically counterproductive. Perhaps the biggest carrot to encourage
> more +1 reviews, is that it is a stepping stone to becoming a core team
> member. eg if you find yourself in the top-10 reviewers on nova for an
> extended period of time you'll likely get an invitation to become a
> core team member from Russell.
>
> Looking at our wiki page
>
>
> https://wiki.openstack.org/wiki/How_To_Contribute#If_you.27re_a_developer
>
> it is very much focused around that idea that you have to write code or
> do code fixes to become involved. It isn't really mentioning contribution
> via reviews at all. It merely mentions "learn gerrit" and use it to sign
> the CLA.
>
> Similarly this page
>
>   https://wiki.openstack.org/wiki/Gerrit_Workflow
>
> only mentions review in the context of what happens to *your* patch.
>
> I think that both those pages could be extended/re-written to strongly
> encourage contributors to participate in reviewing other people's patches.
>

++


>
> The "How to Contribute" page should explicitly list "reviewing code
> changes" as a primary way to contribute, and mention that it is one
> way to get on a path towards gaining the reputation needed to become
> a core team reviewer/member.
>
>

++

Currently the limiting factor in our workflow is reviewers, not patches or
patch authors.


> The "Gerrit Workflow" page should say something like
>
>   "While you are waiting for review feedback on changes you have
>    submitted, you should browser other pending changes and provide
>    review on them. By helping out with other reviews you will be
>    decreasing the time delay for your own change to receive feedback"
>
> Daniel
> --
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/:|
> |: http://libvirt.org              -o-             http://virt-manager.org:|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/:|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc:|
>
> _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20131030/182fbc1a/attachment.html>