From 4f5368781cb5b7d6d42c40375e3aa300e0141d89 Mon Sep 17 00:00:00 2001
From: Daniel James <daniel@calamity.org.uk>
Date: Fri, 7 Dec 2007 01:12:02 +0000
Subject: [PATCH] Merge from trunk, finally.
[SVN r41817]
---
boost_soc_06_overview.html | 820 -------------------------------------
formal_review_process.htm | 350 ----------------
2 files changed, 1170 deletions(-)
delete mode 100644 boost_soc_06_overview.html
delete mode 100644 formal_review_process.htm
diff --git a/boost_soc_06_overview.html b/boost_soc_06_overview.html
deleted file mode 100644
index f8d6770..0000000
--- a/boost_soc_06_overview.html
+++ /dev/null
@@ -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>
diff --git a/formal_review_process.htm b/formal_review_process.htm
deleted file mode 100644
index 8cc7835..0000000
--- a/formal_review_process.htm
+++ /dev/null
@@ -1,350 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-
-<html>
- <head>
- <meta name="generator" content=
- "Microsoft FrontPage 5.0">
- <meta http-equiv="Content-Type" content=
- "text/html; charset=windows-1252">
- <meta name="GENERATOR" content="Microsoft FrontPage 5.0">
- <meta name="ProgId" content="FrontPage.Editor.Document">
-
- <title>Boost Formal Review Process</title>
-<style type="text/css">
-@import ../boost.css
-.first {
- margin-top: 0 }
-.last {
- margin-bottom: 0 }
-div.attention, div.caution, div.danger, div.error, div.hint,
-div.important, div.note, div.tip, div.warning, div.admonition {
- margin: 2em ;
- border: medium outset ;
- padding: 1em }
-div.attention p.admonition-title, div.caution p.admonition-title,
-div.danger p.admonition-title, div.error p.admonition-title,
-div.warning p.admonition-title {
- color: red ;
- font-weight: bold ;
- font-family: sans-serif }
-div.hint p.admonition-title, div.important p.admonition-title,
-div.note p.admonition-title, div.tip p.admonition-title,
-div.admonition p.admonition-title {
- font-weight: bold ;
- font-family: sans-serif }
-</style>
-</head>
-
-<body bgcolor="#FFFFFF" text="#000000">
- <table border="1" bgcolor="#007F7F" cellpadding="2">
- <tr>
- <td bgcolor="#FFFFFF"><img src="../boost.png" alt=
- "boost.png (6897 bytes)" width="277" height="86"></td>
-
- <td><a href="../index.htm"><font face="Arial" color=
- "#FFFFFF"><big>Home</big></font></a></td>
-
- <td><a href="../libs/libraries.htm"><font face="Arial" color=
- "#FFFFFF"><big>Libraries</big></font></a></td>
-
- <td><a href="http://beta.boost.org/users/people.html"><font face="Arial" color=
- "#FFFFFF"><big>People</big></font></a></td>
-
- <td><a href="faq.htm"><font face="Arial" color=
- "#FFFFFF"><big>FAQ</big></font></a></td>
-
- <td><a href="index.htm"><font face="Arial" color=
- "#FFFFFF"><big>More</big></font></a></td>
- </tr>
- </table>
-
- <h1>Boost Formal Review Process</h1>
- <div class="admonition-note admonition">
- <p class="first admonition-title">Before Requesting a Formal Review</p>
- <p class="last"><b>Read and follow the Boost <a href=
- "submission_process.htm">submission process</a>.</b> There are at
- least four steps a library author must take before a formal review is
- requested.</p>
- </div>
-
- <p><a href="#Introduction">Introduction</a><br>
- <a href="#Comments">What to include in Review Comments</a><br>
- <a href="#Results">Results</a><br>
- <a href="#Review_Manager">Notes for Review Managers</a><br>
- <a href="#Submitters">Notes for Library Submitters</a><br>
- <a href="#Wizard">Review Wizard</a><br>
- <a href="#Fast-Track">Fast Track Reviews</a></p>
-
- <h2><a name="Introduction" id="Introduction">Introduction</a></h2>
-
- <p>Proposed libraries are accepted into Boost only after undergoing a
- formal review, where Boost mailing list members comment on their evaluation
- of the library.</p>
-
- <p>The final "accept" or "reject" decision is made by the <a href=
- "#Review_Manager">Review Manager</a>, based on the review comments received
- from boost mailing list members.</p>
-
- <p>Boost mailing list members are encouraged to submit Formal Review
- comments:</p>
-
- <blockquote>
- <ul>
- <li>Publicly on the mailing list.</li>
-
- <li>Privately to the Review Manager.</li>
- </ul>
- </blockquote>
-
- <p>Private comments to a library submitter may be helpful to her or him,
- but won't help the Review Manager reach a decision, so the other forms are
- preferred.</p>
-
- <h2>What to include in Review <a name="Comments" id=
- "Comments">Comments</a></h2>
-
- <p>Your comments may be brief or lengthy, but basically the Review Manager
- needs your evaluation of the library. If you identify problems along
- the way, please note if they are minor, serious, or showstoppers.</p>
-
- <p>The goal of a Boost library review is to improve the library through
- constructive criticism, and at the end a decision must be made: is the
- library good enough at this point to accept into Boost? If not, we hope to
- have provided enough constructive criticism for it to be improved and
- accepted at a later time. The Serialization library is a good example of how
- constructive criticism resulted in revisions resulting in an excellent
- library that was accepted in its second review.</p>
-
- <p>Here are some questions you might want to answer in your review:</p>
-
- <ul>
- <li>What is your evaluation of the design?<br></li>
-
- <li>What is your evaluation of the implementation?<br></li>
-
- <li>What is your evaluation of the documentation?<br></li>
-
- <li>What is your evaluation of the potential usefulness of the
- library?<br></li>
-
- <li>Did you try to use the library? With what compiler? Did
- you have any problems?<br></li>
-
- <li>How much effort did you put into your evaluation? A glance? A quick
- reading? In-depth study?<br></li>
-
- <li>Are you knowledgeable about the problem domain?</li>
- </ul>
-
- <p>And finally, every review should answer this question:<br></p>
-
- <ul>
- <li>Do you think the library should be accepted as a Boost library?
- Be sure to say this explicitly so that your other comments don't obscure
- your overall opinion.</li>
- </ul>
-
- <p>Many reviews include questions for library authors. Authors are
- interested in defending their library against your criticisms; otherwise
- they would not have brought their library up for review. If you don't get a
- response to your question quickly, be patient; if it takes too long or you
- don't get an answer you feel is sufficient, ask again or try to rephrase the
- question. Do remember that English is not the native language for many
- Boosters, and that can cause misunderstandings.<br>
- <br>
- E-mail is a poor communication medium, and even if messages rarely get lost
- in transmission, they often get drowned in the deluge of other messages.
- Don't assume that an unanswered message means you're being ignored. Given
- constructively, criticism will be taken better and have more positive
- effects, and you'll get the answers you want.</p>
-
- <h2><a name="Results">Results</a></h2>
-
- <p>At the conclusion of the comment period, the Review Manager will post a
- message to the mailing list saying if the library has been accepted or
- rejected. A rationale is also helpful, but its extent is up to the
- Review Manager. If there are suggestions, or conditions that must be met
- before final inclusion, they should be stated.</p>
-
- <h2>Notes for <a name="Review_Manager" id="Review_Manager">Review
- Manager</a>s</h2>
-
- <p>Before a library can be scheduled for formal review, an active boost
- member not connected with the library submission must volunteer to be the
- "Review Manager" for the library.</p>
-
- <p>The Review Manager:</p>
-
- <ul>
- <li>Checks the submission to make sure it really is complete enough to
- warrant formal review. See the <a href="lib_guide.htm">Boost
- Library Requirements and Guidelines</a>. If necessary, work with
- the submitter to verify the code compiles and runs correctly on several
- compilers and platforms.</li>
-
- <li>Finalizes the schedule with the <a href="#Wizard">Review Wizard</a>
- and the submitter .</li>
-
- <li>Posts a notice of the review schedule on the regular <b><a href=
- "mailto:boost@lists.boost.org">boost</a></b> mailing list, the
- <b><a href="mailto:boost-users@lists.boost.org">boost-users</a></b>
- mailing list, and the <b><a href=
- "mailto:boost-announce@lists.boost.org">boost-announce</a></b> mailing
- list.
-
- <ul>
- <li>The notice should include a brief description of the library and
- what it does, to let readers know if the library is one they are
- interested in reviewing.</li>
-
- <li>If the library is known to fail with certain compilers, please
- mention them in the review notice so reviewers with those compilers
- won't waste time diagnosing known problems.</li>
- </ul>
- </li>
-
- <li>Inspects the Boost <a href="../libs/libraries.htm">library
- catalogue</a> for libraries which may interact with the new submission.
- These potential interactions should be pointed out in the review
- announcement, and the author(s) of these libraries should be privately
- notified and urged to participate in the review.</li>
-
- <li>Urges people to do reviews if they aren't forthcoming.</li>
-
- <li>Follows review discussions regarding the library, moderating or
- answering questions as needed.</li>
-
- <li>Asks the <a href="#Wizard">review wizard</a> for permission
- to extend the review schedule if it appears that too few reviews will
- be submitted during the review period.</li>
-
- <li>Decides if there is consensus to accept the library, and if there
- are any conditions attached.</li>
-
- <li>Decides if there is consensus to accept the library, and if there are
- any conditions attached.</li>
-
- <li>Posts a notice of the <a href="#Results">review results</a> on the
- regular <b><a href="mailto:boost@lists.boost.org">boost</a></b> mailing
- list, the <b><a href=
- "mailto:boost-users@lists.boost.org">boost-users</a></b> mailing list,
- and the <b><a href=
- "mailto:boost-announce@lists.boost.org">boost-announce</a></b> mailing
- list.</li>
- </ul>
-
- <p>In other words, it is the Review Manager's responsibility to make sure
- the review process works smoothly.</p>
-
- <h2>Notes for Library <a name="Submitters" id=
- "Submitters">Submitters</a></h2>
-
- <p>See <a href="submission_process.htm">Submission Process</a> for a
- description of the steps a library developer goes through to get a library
- accepted by Boost.</p>
-
- <p>A proposed library should remain stable during the review period; it
- will just confuse and irritate reviewers if there are numerous
- changes. It is, however, useful to upload fixes for serious bugs
- right away, particularly those which prevent reviewers from fully
- evaluating the library. Post a notice of such fixes on the mailing
- list.</p>
-
- <p>Library improvements suggested by reviewers should normally be held
- until after the completion of review period. If the suggested changes
- might affect reviewer's judgments, post a notice of the pending change
- on the mailing list.</p>
-
- <h2>Review <a name="Wizard" id="Wizard">Wizard</a></h2>
-
- <p>The Review Wizard coordinates the formal review schedule:</p>
-
- <ul>
- <li>Maintains a list of review manager volunteers, in the form of a
- queue, so that volunteers who least recently managed reviews become the
- prime candidates for upcoming reviews.</li>
-
- <li>When a formal review is requested for a library:</li>
-
- <li style="list-style: none">
-
- <ul>
- <li>Assign a review manager and suggests a schedule, after checking
- (via private email) availability of the volunteers at the top of
- review manager queue.</li>
-
- <li>Finalize the schedule, once the review manager verifies the
- library is actually ready for review.</li>
-
- <li>Resolve schedule slips or other issues with review managers and
- submitters.</li>
- </ul>
- </li>
-
- <li>Monitors the general review process, and makes minor adjustments as
- needed, or queries the list about possible major adjustments.</li>
- </ul>
- The role of Boost Review Wizard is currently played by John
- Phillips (phillips at mps dot ohio-state dot edu) and Ronald
- Garcia (garcia at cs dot indiana dot edu).
-
- <li>Resolves questions from review managers and library submitters, who
- sometimes want a third opinion on questions such as "Should we extend the
- review period because ...?"</li>
-
- <li>Monitors the general review process, and makes minor adjustments as
- needed, or queries the list about possible major adjustments.</li>
- </ul>The role of Boost Review Wizard is currently played by <a href=
- "mailto:reportbase@yahoo.com">Tom Brinkman</a> and Ronald Garcia (garcia at
- cs dot indiana dot edu).
-
- <p>Revised
- <!--webbot bot="Timestamp" s-type="EDITED" s-format="%d %B, %Y" startspan -->10 October, 2006<!--webbot bot="Timestamp" endspan i-checksum="38930" --></p>
-
- <p>To qualify for fast track review:</p>
-
- <ul>
- <li>The component must be small.</li>
-
- <li>The technique must be already in use in Boost libraries and the new
- component provides a common implementation.</li>
-
- <li>A full Boost-conformant implementation is available in the
- sandbox.</li>
-
- <li>The Review Wizard determines that the proposal qualifies for fast
- track review.</li>
- </ul>
-
- <p>Procedure:</p>
-
- <ul>
- <li>The Boost Review Wizard posts a review announcement to the main Boost
- developer's list. The review period will normally last for 5 days. No two
- fast track reviews will run in parallel. Fast track reviews may run
- during full reviews, though generally this is to be avoided.</li>
-
- <li>After the review period ends, the submitter will post a review
- summary containing proposed changes to the reviewed implementation.</li>
-
- <li>The Review Wizard will accept or reject the proposed library and
- proposed changes.</li>
-
- <li>After applying the proposed changes, the component is checked into
- CVS like any other library.<br>
- </li>
- </ul>
- <hr>
-
- <p>Revised
- <!--webbot bot="Timestamp" s-type="EDITED" s-format="%d %B, %Y" startspan -->15
- October, 2003<!--webbot bot="Timestamp" endspan i-checksum="38556" --></p>
-
- <p>© Copyright Beman Dawes 2000</p>
-
- <p>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>