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

Subject: Re: [boost] Bug-fix volunteers: risks, downsides?
From: David Abrahams (dave_at_[hidden])
Date: 2010-10-30 16:05:55

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.

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

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com