At Sat, 30 Oct 2010 22:15:30 -0500, Rene Rivera wrote:
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.
That's a good idea; would weed out lots of the non-serious submissions.
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.
This all sounds great to me.
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.
Wow, that's a huge number, compared to my expectation! That would be wonderful.
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.
Not sure who you're referring to as "contributors" in this section. Could you clarify?
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.
I like it!! Can you (co-)implement it? -- Dave Abrahams BoostPro Computing http://www.boostpro.com