Patch Pilot report

[Stephen J. Turnbull]

Martin Pool writes:

 > The theory underneath this is that many people (on any project,
 > however welcoming) are just going to send one patch and then go about
 > their business, and even the nicest teaching of how to add tests is a
 > waste of everyone's time.

Then just asking "do you expect to contribute again in the near
future, and if so, would you like to invest some time in learning
about our system?" is very cheap.  They say "no" within a day or so,
and the same thing happens as did with Andrew's policy.  The
interesting case is if they say "yes".

 > If people are interested in writing tests or are going to do
 > multiple patches then it's worth them learning how that works.

I agree, but I think Andrew's opinion would be more valuable than mine
here. :-)

 > >  > Also, I deliberately chose patches from new contributors over
 > >  > regulars.
 > >
 > > I'm not sure I like the sound of that.  My understanding was that the
 > > patch pilot was supposed to help less experienced and/or one-off
 > > contributors to deal with the relatively technical aspects (proper
 > > docs and tests, for example).  That may be a misunderstanding, but you
 > > see where I'm going: if one is needed to get regulars past the
 > > Charybdis of PQM and the Scylla of committers too busy to review,
 > > there's a constricted bottleneck that needs shattering.
 > 
 > Maybe you're misunderstanding?  He meant he he was helping new
 > contributors, which seems to be what you want.

That is indeed my preference.  My point is that if the patch pilot
needs to make such a choice, then there seems to be a serious
bottleneck for "regulars," too.  Streamlining the process for people
who are doing everything right but aren't yet committers is important
-- they're the last people you want to deflate by making them suffer
delays in processing.