Re: [boost] Bug-fix volunteers: risks, downsides?

Subject: Re: [boost] Bug-fix volunteers: risks, downsides?
From: Jim Bell (Jim_at_[hidden])
Date: 2010-10-31 21:30:44

On 1:59 PM, David Abrahams wrote:
> At Sun, 31 Oct 2010 00:22:25 +0530,
> Arindam Mukherjee wrote:
>> I am one of those hopefuls who responded on the thread that proposed
>> the idea for volunteers. I have always wanted to understand and
>> contribute to the Boost libraries because I felt that it would give me
>> an insight into the design and implementation of Boost (and perhaps
>> the C++ standard libraries themselves) to an extent that I lack today.
>> And I am certain greater participation can only mean good thing,
>> provided we have answers to the following questions (or at least know
>> where to start in trying to answer):
>>
>> a. What are the concrete criteria for admitting a volunteer - where do
>> you set the bar. These must be verifiable objective criteria.
> I don't think we can really come up with objective criteria.  Each
> library maintainer has his own set of values and his own style, and—at
> least if the maintainers are going to be involved in the
> decision—contributions mustn't clash too badly with that style and set
> of values.  Therefore, criteria for accepting contributions, if not
> contributors, will be, to some extent, subjective.

I agree. I think a volunteer's own motivation will carry him farther
than anything.

I think it will start out largely self-study: studying a library's
documentation and regression tests to understand it. Hopefully there
would be two or three such volunteers per library, and they can ask
questions of each other.

Learning how to (a) identify a spurious Ticket and diplomatically
dispose of it, or (b) adapt it into a legitimate regression test or
extension to an existing test, possibly with (c) a minimal-impact patch
... that alone will sharpen the volunteers skills a lot, and get the
attention of the library's maintainer(s) in terms of mentoring.

>> b. Do we have a process in place which makes the induction of
>> volunteers easy - how easily can a new recruit get down to the
>> business of fixing the bugs? Part of it depends on the bar you set in
>> (a) and part of it depends on the process you set. For example, the
>> volunteers at the least need to know the bug-fixing process that is in
>> place today including tools, reviews, etc. How quickly can this
>> knowledge be imparted.

I think self-study will rule the day here, too.

Where the most instruction is needed is in building and running the
regression tests in isolation. My method might be a bit unorthodox: hack
run.py, then regression.py, and operate things just like a regression
test, but without uploading data. (More detail later.)

Anyone can add comments to a ticket, though I think a more clear
explanation of some things like severities 'showstopper' and
'regression' would be helpful.  But navigating a ticket is one way to
get to know it.

>> c. As somebody already mentioned, to what extent can you provide
>> mentoring and who does it.

>> d. Finally, would someone assign tickets to volunteers - I feel this
>> would be a better idea than letting people pick and choose when the
>> volunteers start off. The process could get eased off as a volunteers
>> spends more time with the code base and therefore gets more familiar.

If one volunteer has more advanced experience, he could assign tickets.
If a maintainer has just stepped out in front of a bus, though, there
may not be anyone to do this.

>> I am sure the questions are easy to ask and there are logistical
>> hurdles to take into account in trying to answer any of these
>> questions.

The bain to boost's quality is thinking someone else is taking care of it.