[Python-Dev] Appeal for reviews

[Stephen J. Turnbull]

On 14 Apr 2014 08:42, "R. David Murray" <rdmurray at bitdance.com> wrote:

 >> Or to put it another way, I'd like to encourage contributors who
 >> want to get commit access to focus just as much on doing good
 >> reviews as they do on writing new patches.  Currently the focus is
 >> all on getting patches accepted.

 >Huh, I hadn't thought of it that way before, but it's a very good
 >point.

AFAICS Python already does very well at getting people to do reviewing
by comparison to most projects, though.  And it's *not* all about
getting patches accepted -- newer people seem to do a lot of work on
PEPs and testing compared to most projects I've seen, and not just
because Python-Dev insists on them before getting code approved.

I've always really liked MvL's 5-reviews-to-get-1 approach.  In the
context of this thread it has a number of nice properties.  First, it
makes it explicit that cooperative work (even if it's expressed as
out-and-out horse-trading, it's still working together) is central to
python-dev.  Second, it makes that work visible if people post their
requests to either python-dev or core-mentorship.[1][2]  Third, it
emphasizes reviewing as a good thing and an important contribution.
People tend to think of reviews as "criticism", or even us-against-
them.  Again, the activity and the idea that it is a Good Thing is (or
can be) visible to the contributors in general.

The only thing I don't like about it[3] is that it puts an explicit
price on core developer time ("my time is worth 5x as much as
yours").  I fear that it may be a little off-putting.

In this vein, I wonder if a slot for "new comments on old issues" in
the tracker report might not be useful.  (Yeah, I know, the tracker
reporting function is free software. :)  Maybe a "most active issues"
report, too.

This isn't to deprecate the "50% core developer" idea at all -- it's
great!  I just don't know enough bosses in the field to know how to
sell that one.


Footnotes: 
[1]  Bazaar had a "patch pilot" program where an experienced developer
was detailed to clean the patch queue by shepherding newer developers
through their rather detailed process.  But it had two disadvantages:
first, it really was all about getting patches accepted, and second,
the actual piloting tended to be done off-list.

[2]  I know some people don't like core-mentorship because it's
somewhat less visible than python-dev.  Let's not discuss that now,
it's just an example.

[3]  Well, actually, when wearing my economist hat I like it a lot. :-)