Boost logo

Boost :

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

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. -
-- rrivera/ (msn) - grafik/
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

Boost list run by bdawes at, gregod at, cpdaniel at, john at