mirror of
https://github.com/boostorg/more.git
synced 2025-02-06 06:10:07 +08:00
Obsolete.
[SVN r41587]
This commit is contained in:
Rene Rivera
parent
2875bd4eda
commit
afd10faf21
@ -1,820 +0,0 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0.1 Transitional//EN">
|
||||
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
|
||||
<title>An overview of Boost participation in
|
||||
Google Summer of Code™ 2006</title>
|
||||
<link rel="stylesheet" href="../boost.css" type="text/css">
|
||||
<style type="text/css">
|
||||
<!--
|
||||
table{
|
||||
PADDING-RIGHT: 2pt;
|
||||
BORDER-TOP: gray 1pt solid;
|
||||
DISPLAY: block;
|
||||
PADDING-LEFT: 2pt;
|
||||
PADDING-BOTTOM: 2pt;
|
||||
BORDER-LEFT: gray 1pt solid;
|
||||
MARGIN-RIGHT: 32pt;
|
||||
PADDING-TOP: 2pt;
|
||||
background-color: #EEEEEE;
|
||||
}
|
||||
td{
|
||||
BORDER-STYLE: solid;
|
||||
BORDER-WIDTH: 1pt;
|
||||
BORDER-LEFT: ;
|
||||
BORDER-RIGHT: gray 1pt solid;
|
||||
BORDER-TOP: ;
|
||||
BORDER-BOTTOM: gray 1pt solid;
|
||||
}
|
||||
th{color: #ffffff; background-color: #000000;}
|
||||
.odd_tr{background-color: #ffffff;}
|
||||
-->
|
||||
</style>
|
||||
</head>
|
||||
|
||||
<body>
|
||||
<img src="../boost.png" alt="boost.png (6308 bytes)" align="middle" width="277" height="86">
|
||||
<h1>An overview of Boost participation in
|
||||
Google Summer of Code™ 2006</h1>
|
||||
|
||||
<hr>
|
||||
|
||||
<p>
|
||||
For the second consecutive year, Google has conducted its
|
||||
<a href="http://code.google.com/soc/">Summer of Code™</a> initiative,
|
||||
a program by which student developers are sponsored for their contributions
|
||||
within open source organizations willing to mentor the participants. The 2006
|
||||
campaign has run between April and September, with active development work
|
||||
taking place between May 23 and August 21.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Around mid April, when the program had just started, some Boost members began
|
||||
considering the possibility to enter Summer of Code as a mentoring
|
||||
organization. Despite the lack of time and the fact that most of us were
|
||||
completely new to this initiative, Boost managed to successfully apply for
|
||||
the program. As a result ten projects were selected and mentored, most of
|
||||
which are expected to become full contributions to Boost in the near future.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
We give here a summary report of this experience, along with a short analysis
|
||||
of the main problems we found, so that we can work at solving them and do
|
||||
better next year.
|
||||
</p>
|
||||
|
||||
<h2>Contents</h2>
|
||||
|
||||
<ul>
|
||||
<li><a href="#how_the_program_works">How the program works</a>
|
||||
<ul>
|
||||
<li><a href="#2006_figures">2006 figures</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a href="#boost_participation">Boost participation</a>
|
||||
<ul>
|
||||
<li><a href="#application_and_process_selection">Application and
|
||||
process selection</a></li>
|
||||
<li><a href="#accepted_projects">Accepted projects</a></li>
|
||||
<li><a href="#development">Development</a></li>
|
||||
<li><a href="#results">Results</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a href="#analysis">Analysis</a>
|
||||
<ul>
|
||||
<li><a href="#boost_appeal">Boost appeal</a></li>
|
||||
<li><a href="#opportunities_lost">Opportunities lost?</a></li>
|
||||
<li><a href="#projects_startup">Projects startup</a></li>
|
||||
<li><a href="#ongoing_development">Ongoing development</a></li>
|
||||
<li><a href="#public_communication_issues">Public communication
|
||||
issues</a></li>
|
||||
<li><a href="#scope_of_projects">Scope of projects</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a href="#suggestions_for_improvement">Suggestions for improvement</a>
|
||||
<ul>
|
||||
<li><a href="#preparation">Preparation</a></li>
|
||||
<li><a href="#public_communication">Public communication</a></li>
|
||||
<li><a href="#project_management">Project management</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a href="#conclusions">Conclusions</a></li>
|
||||
<li><a href="#acknowledgements">Acknowledgements</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
<h2><a name="how_the_program_works">How the program works</a></h2>
|
||||
|
||||
<p>
|
||||
There are three types of participants in Google Summer of Code:
|
||||
<ul>
|
||||
<li>Google itself acts as the funding partner and conducts the overall
|
||||
program.</li>
|
||||
<li>The open source organizations accepted into the program must designate
|
||||
people inside the organization who will act as project mentors.</li>
|
||||
<li>Students submit their project ideas and, if selected, work in
|
||||
collaboration with one of the mentoring organizations; upon successful
|
||||
completion of the project, students receive the full stipend for the
|
||||
program.</li>
|
||||
</ul>
|
||||
The program goes through the following stages:
|
||||
<ul>
|
||||
<li>Organization selection: those open source organizations willing to
|
||||
enter Summer of Code submit an expression of interest to Google, along
|
||||
with information Google uses for qualifying purposes. Selected organizations
|
||||
are publicly announced and each organization is expected to provide a pool
|
||||
of project ideas.</li>
|
||||
<li>Student selection: students willing to participate submit one or more
|
||||
project proposals, typically expanding on some of the ideas previously
|
||||
provided by the mentoring organizations. A student can apply several times
|
||||
and for different organizations, but ultimately can only be chosen for just
|
||||
one project. These proposals are routed by Google to the appropriate
|
||||
organizations, which must analyze them, rank them, and assign mentors to the
|
||||
most promising applications. Based on the information provided by mentoring
|
||||
organizations, Google issues the final list of accepted projects.</li>
|
||||
<li>Development: Students, guided by their assigned mentors, are expected to
|
||||
complete the projects in a period of three months. Google asks mentors for a
|
||||
mid-program review upon which continuation of the project depends.</li>
|
||||
<li>Final review: Once the development period is over, mentors are requested
|
||||
to inform Google on the results of the project, and determine whether students
|
||||
qualify to receive the full stipend.</li>
|
||||
</ul>
|
||||
</p>
|
||||
|
||||
<h3><a name="2006_figures">2006 figures</a></h3>
|
||||
|
||||
<p>
|
||||
The 2006 campaign of Google Summer of Code took place between April 14 and
|
||||
September 25. A total of 102 mentoring organizations participated. Of the 6,338
|
||||
applications submitted by 3,044 students around the globe, 630 were finally
|
||||
selected and funded. Google has spent more than US$3 million in student stipends
|
||||
and compensations to the mentoring organizations.
|
||||
</p>
|
||||
|
||||
<h2><a name="#boost_participation">Boost participation</a></h2>
|
||||
|
||||
<h3><a name="#application_and_process_selection">Application and
|
||||
process selection</a></h3>
|
||||
|
||||
<p>
|
||||
On April 14, the same day Google Summer of Code started, Julio M. Merino Vidal
|
||||
(later to become one of the selected students) sent a message encouraging Boost
|
||||
members to participate in this program as a mentoring organization. This call
|
||||
sparked the interest of the community; although time was already short for doing
|
||||
all the preparation labors, Boost moderators put rapidly themselves to work and
|
||||
conducted the preliminary registration steps. In the meantime, a Wiki page was
|
||||
grown with project ideas provided by Boost members, totalling more than twenty
|
||||
proposals.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
By the beginning of May Boost was officially accepted into the program and Boost
|
||||
moderators set out to form a group of mentors, selected on an invitation basis.
|
||||
As student selection is a delicate process, involving the assessment of individuals
|
||||
on their technical skills, all subsequent discussions were conducted by the
|
||||
selected mentors on a private mail list established for their collaboration.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
We were not prepared for the avalanche of student applications that followed. On
|
||||
day two after the application period was open, we had received three proposals;
|
||||
next day it was 14, and within a week the count exceeded 50. By the end of the
|
||||
application period the total number of proposals received was 174, which forced
|
||||
us to go through a very intensive ranking process and recruit additional mentors.
|
||||
Two rules were followed so as rationalize the process of selection among dozens
|
||||
of different proposals:
|
||||
<ul>
|
||||
<li>Where there were competing applications for the same project idea, only
|
||||
one were to be ultimately selected; so, no two projects with the same or very
|
||||
similar goals were accepted.</li>
|
||||
<li>Some of the applications built on a given Boost library (for instance, the
|
||||
Boost Graph Library is a frequent target for the addition of algorithms.) We
|
||||
limited the applications to a maximum of two per Boost library.</li>
|
||||
</ul>
|
||||
These rules have the combined effect of greatly reducing the number of eligible
|
||||
applications while at the same time distributing the accepted projects evenly
|
||||
across the space of ideas. Moreover, students with unique proposals, i.e. project
|
||||
ideas not coming from the pool originally presented by Boost, are at a
|
||||
competitive advantage.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The different proposals were classified according to its related technological
|
||||
area so that each cluster could be handled by an appointed mentor with the
|
||||
required expertise on the subject. Mentors submitted then "focus reports"
|
||||
summarizing the applications under their responsibility; these reports served as
|
||||
a first filter to help reduce the number of final applications to be evaluated
|
||||
jointly. Along the process, students with the most promising proposals were asked
|
||||
to refine their ideas and provide further information.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Although not enforced by the official rules, we agreed upon a one-to-one ratio
|
||||
of mentors to students, which ultimately marked a hard limit on the maximum number
|
||||
of eligible projects.
|
||||
</p>
|
||||
|
||||
<h3><a name="accepted_projects">Accepted projects</a></h3>
|
||||
|
||||
<p>
|
||||
Google accepted and funded the ten top-ranked projects endorsed by Boost. Of
|
||||
these, eight projects are libraries or library components targeted for future
|
||||
inclusion into Boost, while the remaining two consist of utility programs
|
||||
heavily relying on Boost.
|
||||
</p>
|
||||
|
||||
<blockquote>
|
||||
<b>C++ Coroutine Library</b>
|
||||
<br>
|
||||
Giovanni Piero Deretta, mentored by Eric Niebler.
|
||||
<br>
|
||||
Library for the management through a modern C++ interface of OS-provided
|
||||
coroutine facilities.
|
||||
</blockquote>
|
||||
|
||||
<blockquote>
|
||||
<b>Concurrency Library</b>
|
||||
<br>
|
||||
Matthew Calabrese, mentored by David Abrahams.
|
||||
<br>
|
||||
STL-inspired generic framework for high-level specification and execution of
|
||||
parallelizable algorithms.
|
||||
</blockquote>
|
||||
|
||||
<blockquote>
|
||||
<b>TR1 Math Special Functions</b>
|
||||
<br>
|
||||
Xiaogang Zhang, mentored by John Maddock.
|
||||
<br>
|
||||
Implementation of the 23 special mathematical functions specified in C++
|
||||
standard library extension proposal TR1.
|
||||
</blockquote>
|
||||
|
||||
<blockquote>
|
||||
<b>The Boost.Process library</b>
|
||||
<br>
|
||||
Julio M. Merino Vidal, mentored by Jeff Garland.
|
||||
<br>
|
||||
Portable library for process launching and basic management.
|
||||
</blockquote>
|
||||
|
||||
<blockquote>
|
||||
<b>Out-of-Core Graphs and Graph Algorithms</b>
|
||||
<br>
|
||||
Stéphane Zampelli, mentored by Jeremy Siek.
|
||||
<br>
|
||||
Extension of the Boost Graph Library to deal with out-of-core structures,
|
||||
i.e. data sets too large to be kept in main memory at once.
|
||||
</blockquote>
|
||||
|
||||
<blockquote>
|
||||
<b>MISC (M)ulti (I)ndex (S)pecialized (C)ontainers</b>
|
||||
<br>
|
||||
Matías Capeletto, mentored by Joaquín M López Muñoz.
|
||||
<br>
|
||||
Families of specialized containers internally based on Boost.MultiIndex.
|
||||
</blockquote>
|
||||
|
||||
<blockquote>
|
||||
<b>Generic Tree Container</b>
|
||||
<br>
|
||||
Bernhard Reiter, mentored by René Rivera.
|
||||
<br>
|
||||
Design and implementation of a family of STL-compatible tree containers.
|
||||
</blockquote>
|
||||
|
||||
<blockquote>
|
||||
<b>Viewer utility for FSMs</b>
|
||||
<br>
|
||||
Ioana Tibuleac, mentored by Andreas Huber Dönni.
|
||||
<br>
|
||||
Utility program for the visualization of finite state machines (FSMs) specified
|
||||
with Boost.Statechart.
|
||||
</blockquote>
|
||||
|
||||
<blockquote>
|
||||
<b>Modular C++ preprocessor, using Boost.Spirit</b>
|
||||
<br>
|
||||
Hermanpreet 'Lally' Singh, mentored by Joel de Guzman.
|
||||
<br>
|
||||
Implementation with Boost.Spirit and Boost.Wave of a front-end translator
|
||||
from Modular C++ (as specified in a proposal to add modules to C++ by Daveed
|
||||
Vandevoorde) to standard C++.
|
||||
</blockquote>
|
||||
|
||||
<blockquote>
|
||||
<b>Implementing a state of the art Mincut/Maxflow algorithm.</b>
|
||||
<br>
|
||||
Stephan Diederich, mentored by Douglas Gregor.
|
||||
<br>
|
||||
Implementation of a fast mincut/maxflow routine for the Boost Graph Library
|
||||
based on a new algorithm devised by Vladimir Kolmogorov.
|
||||
</blockquote>
|
||||
|
||||
<h3><a name="development">Development</a></h3>
|
||||
|
||||
<p>
|
||||
Two main facilities were set up to assist students and mentors during the
|
||||
development phase: a mailing list and a Trac/SVN project management system
|
||||
with separate directories for each project. One of the students, Matías
|
||||
Capeletto, out of personal initiative registered a Google Group aimed at giving
|
||||
students with Boost a place for informal interaction and discussion of common
|
||||
problems.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
After the initial warm-up period, each student-mentor pair performed development
|
||||
work mostly privately. The usage of the Boost mailing lists was scarce, and
|
||||
only by the end of the program did some students publicly announced their results.
|
||||
</p>
|
||||
|
||||
<h3><a name="results">Results</a></h3>
|
||||
|
||||
<p>
|
||||
By the date the development period was officially closed, the status of the
|
||||
different projects was as follows:
|
||||
<ul>
|
||||
<li>Seven projects were completed or nearly completed and the students are
|
||||
expected to ask for a formal review within 2006 or early 2007. Four of these
|
||||
projects necessitated a goal reorientation during development, basically
|
||||
because the original plan was too ambitious for three months. Most of the
|
||||
projects are still in active development during the months following the
|
||||
Summer of Code program.</li>
|
||||
<li>Two projects did not reach the planned goals, but nevertheless produced
|
||||
useful material that could be expanded outside of the Summer of Code
|
||||
program.</li>
|
||||
<li>One project was abandoned shortly after the midterm review. The reasons
|
||||
for the abandonment are unknown.</li>
|
||||
</ul>
|
||||
The results of all the projects can be consulted online at the dedicated
|
||||
<a href="https://www.boost-consulting.com:8443/trac/soc/browser/boost/soc/2006">Trac
|
||||
site</a>.
|
||||
</p>
|
||||
|
||||
<h2><a name="analysis">Analysis</a></h2>
|
||||
|
||||
<p>
|
||||
We examine the various stages of Boost participation in Summer of Code, with an
|
||||
emphasis on discovering opportunities for improvement.
|
||||
</p>
|
||||
|
||||
<h3><a name="boost_appeal">Boost appeal</a></h3>
|
||||
|
||||
<p>
|
||||
In a mid project
|
||||
<a href="http://code.google.com/soc/GSoC2006Statistics.pdf">presentation at OSCON
|
||||
2006</a>, Chris DiBona from Google provided some data about the organizations
|
||||
which received the most applications:
|
||||
</p>
|
||||
|
||||
<p align="center">
|
||||
<table cellspacing="0">
|
||||
<tr>
|
||||
<th align="left">Organization</th>
|
||||
<th>No of applications</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>KDE</td>
|
||||
<td align="center">244</td>
|
||||
</tr>
|
||||
<tr class="odd_tr">
|
||||
<td>Ubuntu & Bazaar</td>
|
||||
<td align="center">236</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Python Software Foundation</td>
|
||||
<td align="center">212</td>
|
||||
</tr>
|
||||
<tr class="odd_tr">
|
||||
<td>GNOME</td>
|
||||
<td align="center">199</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Apache Software Foundation</td>
|
||||
<td align="center">190</td>
|
||||
</tr>
|
||||
<tr class="odd_tr">
|
||||
<td><b>Boost</b></td>
|
||||
<td align="center"><b>174</b></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Gaim</td>
|
||||
<td align="center">152</td>
|
||||
</tr>
|
||||
<tr class="odd_tr">
|
||||
<td>The GNU Project</td>
|
||||
<td align="center">148</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Drupal</td>
|
||||
<td align="center">146</td>
|
||||
</tr>
|
||||
</table>
|
||||
</p>
|
||||
<blockquote style="FONT-SIZE: 75%;">
|
||||
The numbers shown here have been estimated from a chart included in the
|
||||
presentation slides. This chart contains an additional column labeled "Google"
|
||||
which actually accounts for the applications dismissed because of their low
|
||||
quality.
|
||||
</blockquote>
|
||||
|
||||
<p>
|
||||
The fact that Boost is ranked the sixth most attractive organization out of a
|
||||
total of 102 was entirely unexpected, especially considering the wide popularity
|
||||
of the rest of top-rated organizations. There is a more or less implicit
|
||||
consensus among Boost members that ours is a relatively niche project, known for
|
||||
its quality standards by seasoned C++ practitioners, but with a limited penetration
|
||||
among entry level programmers: maybe the figures above should make us reconsider
|
||||
this assumption. A cursory examination of the applications submitted to Boost reveals
|
||||
that most applicants were regular users of Boost: many cite the Boost status among
|
||||
the C++ community as an appealing factor in order to apply.
|
||||
</p>
|
||||
|
||||
<h3><a name="opportunities_lost">Opportunities lost?</a></h3>
|
||||
|
||||
<p>
|
||||
If we look at the number of funded projects with respect to the applications received,
|
||||
figures are not so favorable to Boost.</p>
|
||||
|
||||
<p align="center">
|
||||
<table cellspacing="0">
|
||||
<tr>
|
||||
<th align="left">Organization</th>
|
||||
<th>No of projects</th>
|
||||
<th>Project/app ratio</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>KDE</td>
|
||||
<td align="center">24</td>
|
||||
<td align="center">9.8 %</td>
|
||||
</tr>
|
||||
<tr class="odd_tr">
|
||||
<td>Ubuntu & Bazaar</td>
|
||||
<td align="center">22</td>
|
||||
<td align="center">9.3 %</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Python Software Foundation</td>
|
||||
<td align="center">23</td>
|
||||
<td align="center">10.8 %</td>
|
||||
</tr>
|
||||
<tr class="odd_tr">
|
||||
<td>GNOME</td>
|
||||
<td align="center">19</td>
|
||||
<td align="center">9.5 %</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Apache Software Foundation</td>
|
||||
<td align="center">27</td>
|
||||
<td align="center">14.2 %</td>
|
||||
</tr>
|
||||
<tr class="odd_tr">
|
||||
<td><b>Boost</b></td>
|
||||
<td align="center"><b>10</b></td>
|
||||
<td align="center"><b>5.7 %</b></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Gaim</td>
|
||||
<td align="center">8</td>
|
||||
<td align="center">5.3 %</td>
|
||||
</tr>
|
||||
<tr class="odd_tr">
|
||||
<td>The GNU Project</td>
|
||||
<td align="center">10</td>
|
||||
<td align="center">6.8 %</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Drupal</td>
|
||||
<td align="center">14</td>
|
||||
<td align="center">9.6 %</td>
|
||||
</tr>
|
||||
</table>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
It turns out that the project/application ratio for almost any other organization
|
||||
among the top nine is considerably higher than that of Boost. As it happens, Google
|
||||
initially requested that organizations submitted the maximum number of projects they
|
||||
felt they could cope with, and we got funding for exactly what we aimed for, so the
|
||||
limiting factor lies entirely on Boost's side.
|
||||
</p>
|
||||
|
||||
<h3><a name="projects_startup">Projects startup</a></h3>
|
||||
|
||||
<p>
|
||||
Contributing to Boost relies on a fair number of guidelines and protocols for
|
||||
coding, documentation, testing and maintenance. Many of the required tools are
|
||||
exclusively used within Boost, and some of them are not trivial, like for instance
|
||||
Boost.Build. Although the Boost web site contains information about all these tools
|
||||
and procedures, this intelligence is scattered through unrelated pages and sometimes
|
||||
is very hard to come by.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
So, there is a good deal of expertise required to begin working at Boost. Some
|
||||
students have reported on startup difficulties getting to know these details and
|
||||
familiarizing themselves with the tools, most notably <code>bjam</code> and Quickbook. Each
|
||||
student overcome the startup difficulties on their own or resorting to their
|
||||
mentors (see the section on <a href="#public_communication_issues">public
|
||||
communication issues</a>).
|
||||
</p>
|
||||
|
||||
<h3><a name="ongoing_development">Ongoing development</a></h3>
|
||||
|
||||
<p>
|
||||
Once students got past the startup stage, most projects advanced without serious
|
||||
complications. In the majority of cases, it was realized at some point during
|
||||
the development that there was no time to complete it. Some participants had to
|
||||
redefine the goals in an effort to keep the project within schedule, while others
|
||||
simply decided that they would continue working after the official deadline of
|
||||
Summer of Code.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The information flow between each student and their mentor was usually reported
|
||||
by both parties to be satisfactory. The projects suffering from lack of
|
||||
communication have been precisely those yielding the poorest results. In general,
|
||||
mentors have not felt overwhelmed by requests from their students, and even in a
|
||||
couple of cases the projects were run practically unattendedly. This fact is
|
||||
witness to the high competence of the students recruited into the program.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The degree of usage of the Trac/SVN system has varied. Some students did frequent
|
||||
updates, while others have just used the repository to dump the final results for
|
||||
the official submission to Google.
|
||||
</p>
|
||||
|
||||
<h3><a name="public_communication_issues">Public communication
|
||||
issues</a></h3>
|
||||
|
||||
<p>
|
||||
Students and mentors had at their disposal three different forums for the public
|
||||
interchange of information and support:
|
||||
<ul>
|
||||
<li>Boost public lists, especially the developers and users lists.</li>
|
||||
<li>A dedicated mailing list reaching all students and mentors working at
|
||||
Summer of Code in Boost.</li>
|
||||
<li>A more casual Google Group, set up by one of the students, aimed at
|
||||
providing the participants with a place for socializing and resolution of
|
||||
common problems.</li>
|
||||
</ul>
|
||||
Despite this abundance of resources, there was an almost complete lack of group
|
||||
communication among all the parties involved and between these and the larger
|
||||
Boost community. Seemingly, students were satisfied to pursue their activities by
|
||||
relying on support from their mentors alone. This circumstance has prevented
|
||||
Boost members from enriching the initiative by offering their experience and
|
||||
insight, and has possibly led students to the false impression that contributing
|
||||
to Boost proceeds in a predictable linear path from requisites to completion of
|
||||
the work. When asked about their not engaging in public communication, the students
|
||||
gave vague justifications that can be classified into the following:
|
||||
<ul>
|
||||
<li>Doubts were deemed too technical or specific to be worth raising in
|
||||
public.</li>
|
||||
<li>A crave for perfectionism detracted students from asking or submitting work
|
||||
in progress until they felt their material looked good enough.</li>
|
||||
<li>Shyness: some students probably lacked previous experience communicating in
|
||||
public, and most are not English native speakers, which could also be a
|
||||
limiting factor.</li>
|
||||
</ul>
|
||||
Although students did not identify the following as a reason not to go public, it
|
||||
is likely that many of them did not feel the need given the readily access to their
|
||||
mentors they enjoyed. It is easy to grow used to such a dedicated source of support
|
||||
and neglect resorting to other resources. Mentors should have encouraged their
|
||||
students to pursue the public discussion of projects, which constitutes one of the
|
||||
pillars of Boost renowned quality.
|
||||
</p>
|
||||
|
||||
<h3><a name="scope_of_projects">Scope of projects</a></h3>
|
||||
|
||||
<p>
|
||||
In hindsight, it has become apparent that most projects were too ambitious to be
|
||||
completed within the three months of duration of the program, and even those that
|
||||
were considered a success will need weeks or months of polishing up before the
|
||||
material is ready for a formal review. In contrast with other organizations
|
||||
participating in the Summer of Code program, Boost has as of this writing included
|
||||
no results into its code base. No formal review for any project has been requested
|
||||
yet, either.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
These scope issues are very dependent on the particular type of project. We can
|
||||
classify the Boost projects for Summer of Code as follows:
|
||||
<ul>
|
||||
<li>Full-fledged libraries,</li>
|
||||
<li>additions to existing Boost libraries,</li>
|
||||
<li>utilities and tool projects using Boost.</li>
|
||||
</ul>
|
||||
Of these, additions (like for instance the mincut/maxflow algorithm for BGL by
|
||||
Stephan Diederich) are the most suitable for completion in a short period of time:
|
||||
most of the preparation work is already done, and the student has clear guides as
|
||||
to what coding and documentation standards to follow. Also, these projects need
|
||||
not undergo a formal review, since it is the responsibility of the hosting library
|
||||
author to review the code and include it within her discretion. Utility projects
|
||||
seem also suitable for small timeframes, though most project proposals and requests
|
||||
are naturally oriented to contributions of actual code to the Boost project.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
As for those projects involving the design and realization of full-fledged
|
||||
libraries, there is little hope that the goals and scope can be kept modest enough
|
||||
for a three-month schedule. Boost candidate libraries developed by professional
|
||||
authors usually take much longer than three months to be accepted; some libraries
|
||||
have been evolving through several <i>years</i> before being included into Boost.
|
||||
So, the best we can hope for if we are to support the realization of library projects
|
||||
for Boost inside Summer of Code is that the results by the end of the program can
|
||||
be evaluated to constitute a viable <i>potential</i> contribution to Boost. When this is
|
||||
the case, it is crucial that the student commits to further working on the project
|
||||
up to completion and formal review. Perhaps more important than getting libraries
|
||||
coded is to engage new authors into a long-term relationship with the Boost project.
|
||||
</p>
|
||||
|
||||
<h2><a name="suggestions_for_improvement">Suggestions for improvement</a></h2>
|
||||
|
||||
<p>
|
||||
The following proposals aim to alleviate some of the problems we have identified
|
||||
during the development of Summer of Code within Boost. These action points are
|
||||
related only to the issues found in connection with Boost: we are not addressing
|
||||
other areas of improvement associated to the Summer of Code program itself.
|
||||
</p>
|
||||
|
||||
<h3><a name="preparation">Preparation</a></h3>
|
||||
|
||||
<p>
|
||||
Much work can be done before the actual program begins. The following preparation
|
||||
activities can already be launched:
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Create a pool of ideas for projects.</b> This action will provide valuable extra
|
||||
time for evaluation and refining of ideas before the Summer of Code begins.
|
||||
The experience has shown that those projects with more preparation work, especially
|
||||
in the area of design, were ultimately more successful. The pool can also be used
|
||||
to retain interesting ideas that arise at the mailing lists and very often are
|
||||
not given proper attention and become abandoned.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Create a student pool.</b> Prior involvement with Boost is clearly an advantage
|
||||
both in the selection phase and later during project development. Those students
|
||||
with a serious interest in participating in Summer of Code with Boost can enter
|
||||
the pool and begin exploring ideas and interacting with the community well in
|
||||
advance of the summer, so as to put themselves in a favorable position for the
|
||||
selection. Advertisement for the student pool can be initiated in the beginning of
|
||||
2007 through the usual channels (web site and mailing lists): additionally, Boost
|
||||
members involved with the University can spread this information locally and help
|
||||
raise the interest of students in their environment.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Create a mentor pool.</b> Given the rush with which Boost entered the 2006
|
||||
Summer of Code campaign, the invitation of mentors has to be done on an on-demand
|
||||
basis as it became all too evident that the task was growing bigger and bigger.
|
||||
It is important that the organization is better prepared next year so that a
|
||||
number of people with the ability and will to participate as Boost mentors are
|
||||
identified in advance.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Prepare a startup package.</b> In order to facilitate the initial period of
|
||||
getting familiarized with the various Boost guidelines, protocols and tools, it
|
||||
would be extremely useful to prepare a compilation of startup material for
|
||||
students. This package can consist of a single document gathering the currently
|
||||
dispersed information, or go beyond this and provide some bundle of documentation
|
||||
and pre-built tools, an approach that one of the students is currently working on.
|
||||
</p>
|
||||
|
||||
<h3><a name="public_communication">Public communication</a></h3>
|
||||
|
||||
<p>
|
||||
It is crucial that students get involved with the community as soon as possible
|
||||
and grow to appreciate the advantages of public development with respect to
|
||||
solitary coding.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Mandate (bi)weekly reports.</b> These reports should be directed to the public
|
||||
mailing lists so as to give all Boost members an opportunity to follow the work
|
||||
in progress and contribute. Reporting has the extra benefit for students of
|
||||
forcing them to reflect on their own work periodically and struggle with the
|
||||
often difficult task of presenting their ideas to others.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Conduct student-mentor exclusively through public channels.</b> This might be
|
||||
too drastic a policy, as some matters need privacy, and depending on the amount
|
||||
of information exchanged flooding problems may arise. Less severe variations
|
||||
involve allowing for some private interchange at the mentors' discretion and
|
||||
moving this kind of communication to a dedicated public mailing list different
|
||||
from the general ones.
|
||||
</p>
|
||||
|
||||
<h3><a name="project_management">Project management</a></h3>
|
||||
|
||||
<p>
|
||||
The two most important issues to improve upon with respect to the management are:
|
||||
<ul>
|
||||
<li>Project scope must be kept under control,</li>
|
||||
<li>The progress has to be publicly visible, so that problems of scope,
|
||||
design and/or schedule can be more easily detected.</li>
|
||||
</ul>
|
||||
Some of the proposals in this section are not to be regarded as strict rules,
|
||||
but rather as general guidelines to be kept in mind by students and encouraged
|
||||
by mentors.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Create a best practices document.</b> This document can serve as a guideline
|
||||
for project management, an area in which Boost traditionally imposes no
|
||||
requirements. Students might lack the expertise in this area that is usually
|
||||
taken for granted in the traditional model where contributions to Boost are
|
||||
made by professional programmers.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Mandate a design phase.</b> Having a concrete design set up and clearly
|
||||
described early in the project will help estimate the necessary effort for
|
||||
completion of the work. This is also an opportunity for public discussion.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Maintain code, docs and tests in parallel.</b> All too often, novice
|
||||
programmers do the coding in one fell swoop and only then move to testing and
|
||||
documenting their work. This is unacceptable by all current methodology
|
||||
standards, and can result in serious underestimations of the time to
|
||||
completion.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Encourage the KISS principle.</b> It is much better to finish a simpler library
|
||||
and then iteratively evolve it, once it has been exposed to public scrutiny and
|
||||
usage.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>More Trac updates.</b> The repository should be viewed as an everyday work
|
||||
tool, not only as the place into which to dump the final results. Updating often
|
||||
leads to more visibility of the work by the mentor and the public in general.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Informal reviews.</b> The typical Summer of Code Boost project will not be
|
||||
completed by the official deadline, as have been discussed earlier. To somehow
|
||||
officialize the work done within the Summer of Code proper, and also to allow
|
||||
the students to reach some sort of psychological milestone, informal reviews can
|
||||
be instituted where Boost members evaluate the work done at then end of Summer
|
||||
of Code.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Engage students.</b> This experience has shown that it is possible to guide
|
||||
willing and bright students to the competence levels required for contributing
|
||||
to Boost. The best possible outcome of Summer of Code campaigns are the
|
||||
incorporation of new people into the circle of Boost active contributors. Strive
|
||||
to make the students commit to Boost.
|
||||
</p>
|
||||
|
||||
<h2><a name="conclusions">Conclusions</a></h2>
|
||||
|
||||
<p>
|
||||
Despite the lack of previous experience in Boost, our participation in Google
|
||||
Summer of Code has been extremely fruitful: much useful material has been produced,
|
||||
and, perhaps more importantly, some of the students are likely to commit on a
|
||||
long-term basis and grow to be regular Boost contributors. Traditionally, becoming
|
||||
a productive Boost author has a very high entry barrier due to the extreme quality
|
||||
standards, lack of public support and the very specific culture of the project.
|
||||
The appeal of Summer of Code itself and the possibility of being gently mentored
|
||||
into the world of Boost have most likely been key factors in lowering this entry
|
||||
barrier.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The process has not been without some difficulties, either, as it was expected of
|
||||
a newcomer organization as Boost. We have tried to identify in this paper the
|
||||
areas of improvement and suggest specific actions so that the upcoming Google
|
||||
Summer of Code 2007 can be an even more rewarding experience.
|
||||
</p>
|
||||
|
||||
<h2><a name="acknowledgements">Acknowledgements</a></h2>
|
||||
|
||||
<p>
|
||||
This paper couldn't have been written without the numerous reports and contributions
|
||||
kindly provided by Boost students and mentors: Many thanks to all the participants
|
||||
for sharing their experiences with me. Thank you also to the people at Google who
|
||||
have promoted and conducted the Summer of Code initiative.
|
||||
</p>
|
||||
|
||||
<hr>
|
||||
|
||||
<p>Revised October 17th 2006</p>
|
||||
|
||||
<p>© Copyright 2006 Joaquín M López Muñoz.
|
||||
Distributed under the Boost Software
|
||||
License, Version 1.0. (See accompanying file <a href="../LICENSE_1_0.txt">
|
||||
LICENSE_1_0.txt</a> or copy at <a href="http://www.boost.org/LICENSE_1_0.txt">
|
||||
http://www.boost.org/LICENSE_1_0.txt</a>)
|
||||
</p>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
Loading…
Reference in New Issue
Block a user