|
|
Boost-Commit : |
From: grafikrobot_at_[hidden]
Date: 2007-12-02 12:03:44
Author: grafik
Date: 2007-12-02 12:03:43 EST (Sun, 02 Dec 2007)
New Revision: 41587
URL: http://svn.boost.org/trac/boost/changeset/41587
Log:
Obsolete.
Removed:
trunk/more/boost_soc_06_overview.html
Deleted: trunk/more/boost_soc_06_overview.html
Boost-Commit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk
==============================================================================
--- trunk/more/boost_soc_06_overview.html 2007-12-02 12:03:43 EST (Sun, 02 Dec 2007)
+++ (empty file)
@@ -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
-Summer of Code™ 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>How the program works
- <ul>
- <li>2006 figures</li>
- </ul>
- </li>
- <li>Boost participation
- <ul>
- <li><a href="#application_and_process_selection">Application and
- process selection</a></li>
- <li>Accepted projects</li>
- <li>Development</li>
- <li>Results</li>
- </ul>
- </li>
- <li>Analysis
- <ul>
- <li>Boost appeal</li>
- <li>Opportunities lost?</li>
- <li>Projects startup</li>
- <li>Ongoing development</li>
- <li><a href="#public_communication_issues">Public communication
- issues</a></li>
- <li>Scope of projects</li>
- </ul>
- </li>
- <li>Suggestions for improvement
- <ul>
- <li>Preparation</li>
- <li>Public communication</li>
- <li>Project management</li>
- </ul>
- </li>
- <li>Conclusions</li>
- <li>Acknowledgements</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>)
-</p>
-
-</body>
-</html>