On Wed, Oct 30, 2013 at 9:31 AM, Daniel P. Berrange <berra...@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@lists.openstack.org > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack