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

Subject: Re: [boost] Bug-fix volunteers: risks, downsides?
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2010-10-30 23:15:30

As a general comment.. I think having a pool of bug-fixers is a 
wonderful idea. And is frankly, one of the requirements of Boost staying 
afloat.

On 10/30/2010 3:05 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 mostly ;-) Like regular reviews for library submissions, and 
also for GSoC students, I think we can use similar criteria for what 
makes a good volunteer. I.e. we can have a vetting process for 
volunteers and their contributions.

IIRC for libraries we only really require that people test their code on 
two toolsets locally. And of course we do reviews of the library as a 
whole before initial inclusion.

The GSoC guidelines are a bit more fluid.. I expect some demonstrable 
knowledge of the problem domain and of C++. I have seen other 
participant organizations require some form of contribution to the 
project before considering a student. And something like that I would 
think is possible in this case.

So here's an initial set of criteria / process for this:

For volunteers to get SVN write access:

1. Must submit some minimum number of patches to Trac.

2. Some minimum number of patches to existing tickets must be accepted, 
reviewed, applied, and tested. I.e. a new volunteer would turn bug 
tickets into patch tickets to get this started.

3. A single patch must be reviewed by some minimum number of existing 
contributors. And either blessed or not for application.

4. Patches must be locally tested on some minimal number of toolsets. 
Either multiple toolsets on one operating system, or preferably multiple 
toolsets on multiple OSs. It would be up to the reviewers to decide if 
the tested toolsets are sufficient in the context of the particular patch.

Any regular maintainer, including existing volunteers, can help with the 
above. The hope being that we can start small and have this grow itself 
without increasing the burden on current contributors too much. Some 
possible numbers for the above: (1) five submitted patches, (2) three 
applied patches, (3) two reviewers for a patch, with high, preference 
for the library maintainer to be a reviewer but not required, and (4) 
two toolsets.

After volunteers have write access we would want to still monitor their 
patches so we would want to keep the review of their patches. So perhaps 
after some number of closed tickets we would remove the review portion 
with the expectation that they would be responsible enough at this time 
to seek out reviews for non-trivial, or non-controversial, patches.

>> 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.

Well, as you might have guessed there really isn't a process for bug 
fixing other than what is required for release management. Essentially 
it's mostly up to the individual maintainers to deal with it as they 
like. Hence my suggestion above for the process :-) As far as tools go 
though, we do have a rather fixed set of requirements for the testing 
part of this. And it's fairly easy to explain.

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

I think we can at minimum have the same set of contributors that we have 
for GSoC help out with the mentoring of this as they (a) tend to have 
the desire to help out, and (b) they tend to be the most broadly 
knowledgeable of Boost Libraries. Which I think roughly means 15 or so 
people to mentor at the start.

>> 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.

Assigning tickets might be a hard task for contributors to do initially 
as it might take a considerable amount of time to actively find tickets. 
And also would make it harder on volunteers as the particular domain 
might be out of their realm. Perhaps it might be better to have 
contributors mark tickets as candidates for volunteers to take on. 
Immediately what comes to mind are tickets for platforms that 
maintainers don't usually have access to as good candidates for this 
ticket pool.

>> 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.
>
> Can you suggest some answers, even as straw men?  We need a place to
> start.

Hopefully the above is a good place to start. Note, I wrote the above 
with the background of spending a few release cycles years ago doing 
nothing but fixing test failures.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org (msn) - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail