Defining specific problems and handwaving at solutions (was Re: What's Canonical thinking about Bazaar?)

[Neil Martinsen-Burrell]

I think that Matthew is addressing here one of the core issues (for 
existing users, that may leak out and affect adoption rates) of 
"community ownership" as defined by Stephen.  I've had my own 
experiences with trying to land patches and want to echo some of the 
points herein.

On 2009-11-07 03:22 , Matthew D. Fuller wrote:
> On Fri, Nov 06, 2009 at 06:46:03PM +0900 I heard the voice of
> Stephen J. Turnbull, and lo! it spake thus:
>>
>> Matt Fuller doesn't think it's fair in the sense of "unbiased" (my
>> reading is that he thinks it fair in the sense of "good
>> intentions").  He specifically said you need a Canonical employee as
>> champion to get a patch through the process.  (Obviously just his
>> opinion, some people have managed without, blah blah blah.)
>
> This is what I said, though the phrasing here could be read a bit more
> combative than I meant it.  You often need a _committer_ as champion.
> Yes, there are non-Canonical committers, but committers that range
> generally over the codebase (as opposed to cleaving rather closely to
> a few pieces where they're personally active, important though those
> may be) and are active?  Certainly I don't scrutinize every commit
> that comes across (and you can't really tell post facto who actually
> nudged PQM toward something), but I certainly feel that number comes
> awful close to 0.

That is certainly my perception as well.  As John said, the list of PQM 
committers is not public, nor is the organizational affiliation of those 
people always obvious.  (Does he work for Arbash-Meinel.com or is that 
just a nice email address?)  Since change discussions have moved 
off-list (and I haven't subscribed to get merge review emails on 
Launchpad) it is even less obvious who the relevant parties are for 
reviews and merges.  When I submitted my only nontrivial patch (and like 
Matthew, I won't soon do that again) the only people who I knew were 
involved were the people who wrote reviews: one positive and one with 
change suggestions.

>> Martin Pool writes:
>>   >  but it's sadly a historical fact that some people give up on
>>   >  their patches after being asked to write tests, and that these
>>   >  patches languish in the bug tracker or the mail archive.
>>
>> This is important.  At least in my experience, GNU/Debian types are
>> behind the curve when it comes to test-driven development.  They're
>> generally willing to put in effort, but writing tests when you're
>> not used to the testing framework can easily turn a 5 line patch
>> into a 2-day nightmare.  A couple of riffs on that theme:
>
> [also from earlier in the mail]
>
>> Especially if there are not enough contributors with the skills to
>> noodle a patch[1] through the process available to mentor newbies on
>> their early contributions.
>
>  From my perspective, these are very important points, and aim at a
> very important something I'm willing to point directly at as a
> deficiency in the Process.  To put it shortly and bluntly:
>
>      If you don't essentially FINISH your entire contribution yourself,
>      it will never become part of bzr.

This is accurate in my experience as well.  I am not a professional 
programmer.  I'm a math professor who thinks it is fun to write Python. 
  Bazaar is the first open source project where I have ever tried to 
contribute code.  Finishing a nontrivial contribution to an acceptable 
level is something that still needs lots of learning on my part.  Given 
a lack of time to volunteer, this leads to a very difficult process for 
Bazaar to gain a new contributor and a user who has an increased sense 
of community ownership.

> Lacking tests are probably the largest single block in this area, but
> I don't think that covers the majority of cases.  Patches get
> responses like "this is good, but X, Y, and Z", which may be
> capricious but certainly aren't always, or even usually.  But that's
> the END of it; the submitter either fixes it themselves, or it'll sit
> there until doomsday.  It's not the common case at all that somebody
> fixes part of a problem, or gets it working but rough, and that's
> taken and fixed up as necessary and dropped in.
>
> For people who are to become committers or heavy contributors, that's
> just peachy; they LEARN the expected standards for the code, and a
> feel for how it should be structured, yada yada.  But it's a *VERY*
> *BAD* thing for casual contributors, who wrote a patch to scratch an
> itch they had with bzr, rather than to improve bzr generally.  It's a
> great way to teach them "don't bother trying to give us patches, we're
> too busy with our own stuff", and they won't next time.  And while it
> doesn't really have anything to do with "Canonical ownership", it's a
> impression that dovetails very strongly with "bzr is a Canonical
> project" into a doubly whammy of demotivation.

I think it's important here that the commercial aspect of the "Canonical 
ownership" is less relevant to the casual contributor issue than is the 
issue of available committer time and energy for mentoring/finishing 
community contributions.

[snip very familiar-sounding story of patch review over many months]

> There are 3 positions people can have regarding bzr being a
> Canonical-owned project (whether it IS in fact, whatever that may
> mean, is irrelevant, only the perception, and I don't think it's
> arguable that the perception exists both among people who know nothing
> of bzr and those closely following it).  It can be a turn-on, a
> turn-off, or generally irrelevant.
>
> To me, it's not in and of itself too relevant.  I'm a BSD guy, not a
> GNU guy; we LIKE companies paying programmers  8-}.  But I very much
> think that, of the groups occupying the other two positions, the group
> for which it's a turn-off are *MUCH* more likely than those to whom
> it's a turn-on, to spawn people who become developers who can throw
> cycles into these holes.  THAT (to allude to the major point of the
> thread rather than straight hijacking it) is a way in which a
> perception of being a Canonical project rather than a community one is
> a serious ill in the long term.  And I think if we want to discuss
> whether it's a plus or minus, concentrating on that particular point
> is the most fruitful way to head in the rough direction of a
> conclusion.

Here are some less-handwaving thoughts on solutions:

1.  The tools are already very good.  Launchpad with Bazaar makes the 
process of contributing back to open source easy enough that it made me, 
a non-programmer, willing to try.  This is of course what Mark 
Shuttleworth has had in mind all along.  I think that the current state 
of Bazaar/LP is most of the way there.  I particularly think that ``bzr 
push lp:~my_username/project/my_fix; bzr lp-open; #make merge proposal`` 
is a real hit and could be improved even further.  If I could create a 
merge proposal from the command line, this would be a slam-dunk, 
particularly if it worked in tandem with --fixes to link the pushed 
branch to the given bug.

2.  Mentoring could help get more contributors and thus more sense of 
community ownership.  Mentoring has a multiplier effect where a small 
input of time from an experienced developer builds up another individual 
who can then make further contributions to the community far beyond the 
amount of time devoted by the developer.  Taking myself as an example, I 
am not a programmer, I'm a math professor.  But I'm fascinated by Python 
and version control and I've even begun to make use of Bazaar in my 
research. Down the road a few years, I could have a reasonable amount of 
my time that I devote to scholarship that I could choose to devote to 
Bazaar development.  As Stephen says, I aspire to someday write a whole 
plugin or host a wiki.  With effective mentoring (this doesn't have to 
be time-consuming, it is primarily a matter of designating a person for 
one-on-one contact) I would be much more likely to make that allotment 
of time in the future.

3.  Patch review for community members should be different than patch 
review for core developers.  The comments in a patch review may be 
enough to help a core developer fix the problem in the right way or if 
not, the core developers generally have enough confidence in the 
techniques that they use to mount a defense.  For casual, especially 
first-time nontrivial contributors, my experience is that these comments 
are often not sufficient to lead to an adequate resolution.

4.  Review of contributions has at least two purposes that need to be 
balanced: maintain high quality code and increase the sense of community 
ownership.  The latter is important for all of the reasons that Stephen 
has mentioned.  Community members who feel ownership are important 
contributors of bug reports, bug fixes, blog posts, mailing list 
resonses, etc.  We should continue to be evaluating the merge review 
process in light of these (at least) two purposes.

5.  HACKING.txt is good but it is very, very large and hard for a casual 
contributor to work through and ensure that their submission meets the 
widely-scattered guidelines.  We've got "Bazaar in Five Minutes", why 
not "Bazaar Contribution in Five Minutes".  I would be willing to work 
on such a document if people were interested.

6.  While GSoC is a good way to boost community involvement and image, 
it reaches a relatively small group of people (students who can devote a 
summer to an approved project).  Canonical might have resources that 
could replicate on a much smaller scale this sort of focused mentoring 
program for feature development.  If Bazaar is to do GSoC, I think that 
we should focus on developing features that will have multiplier effects 
in making more future contributors feel welcome (IDE integration, API 
documentation, launchpad plugin improvements, etc.)

7.  The people involved are very good at this already.  I remember 
reading the Subversion-users list and being impressed that the infamous 
Karl Fogel was reading that list and encouraging regular users to report 
bugs, post patches, write feature specs, etc.  Martin Pool plays a 
similar role here and is very good at it.  Ian C. is also someone who 
regularly reaches out to new posters with further questions and 
assistance.  JAM, Robert Collins, and the rabble do fairly well at this too.

That's probably enough to chew on for now.

-Neil