From 60db50f5d7941fa1edc201ae1f326764a4ac537b Mon Sep 17 00:00:00 2001 From: Daniel James Date: Thu, 6 Dec 2007 07:47:43 +0000 Subject: [PATCH 1/2] Update/fix a load of links, add a missing jamfile. [SVN r41777] --- formal_review_process.htm | 2 +- getting_started/detail/conclusion.rst | 4 ++-- getting_started/unix-variants.html | 10 ++++----- getting_started/unix-variants.rst | 2 +- getting_started/windows.html | 8 +++---- index.htm | 6 +++--- writingdoc/design.html | 2 +- writingdoc/template/index.html | 30 +++++++++++++-------------- 8 files changed, 32 insertions(+), 32 deletions(-) diff --git a/formal_review_process.htm b/formal_review_process.htm index ca9ae11..8cc7835 100644 --- a/formal_review_process.htm +++ b/formal_review_process.htm @@ -47,7 +47,7 @@ div.admonition p.admonition-title { Libraries - People use in the Boost.Build documentation. If that isn't your problem or the user-config.jam file doesn't work for you, please address questions about configuring Boost for your compiler to the -Boost.Build mailing list.

+Boost.Build mailing list.

@@ -695,13 +695,13 @@ surely a few additional points you'll wish we had covered. One day we may have a “Book 2 in the Getting Started series” that addresses them. Until then, we suggest you pursue the following resources. If you can't find what you need, or there's anything we can do to -make this document clearer, please post it to the Boost Users' +make this document clearer, please post it to the Boost Users' mailing list.

@@ -719,7 +719,7 @@ mailing list.

[1]

If developers of Boost packages would like to work with us to make sure these instructions can be used with their packages, we'd be glad to help. Please make your interest known -to the Boost developers' list.

+to the Boost developers' list.

diff --git a/getting_started/unix-variants.rst b/getting_started/unix-variants.rst index ca9a3d0..1adfa1f 100644 --- a/getting_started/unix-variants.rst +++ b/getting_started/unix-variants.rst @@ -225,7 +225,7 @@ Spoil Rock Hunter?” packages, we'd be glad to help. Please make your interest known to the `Boost developers' list`_. - .. _Boost developers' list: ../../more/mailing_lists.htm#main + .. _Boost developers' list: http://beta.boost.org/community/groups.html#main .. [#lowercase-l] That option is a dash followed by a lowercase “L” character, which looks very much like a numeral 1 in some fonts. diff --git a/getting_started/windows.html b/getting_started/windows.html index 38a57eb..f413973 100644 --- a/getting_started/windows.html +++ b/getting_started/windows.html @@ -560,7 +560,7 @@ linker, consider setting up a use in the Boost.Build documentation. If that isn't your problem or the user-config.jam file doesn't work for you, please address questions about configuring Boost for your compiler to the -Boost.Build mailing list.

+Boost.Build mailing list.

@@ -766,13 +766,13 @@ surely a few additional points you'll wish we had covered. One day we may have a “Book 2 in the Getting Started series” that addresses them. Until then, we suggest you pursue the following resources. If you can't find what you need, or there's anything we can do to -make this document clearer, please post it to the Boost Users' +make this document clearer, please post it to the Boost Users' mailing list.

diff --git a/index.htm b/index.htm index 47d3db8..de1c855 100644 --- a/index.htm +++ b/index.htm @@ -14,7 +14,7 @@ boost.png (6897 bytes) Home Libraries - People + People FAQ More @@ -53,9 +53,9 @@ about the Boost Software License.

Bibliography  Print and online publications relating to Boost and Boost libraries.

-

Who's Using Boost?   +

Who's Using Boost?   Products and organisations that are using Boost.

-

Compiler Status  Describes +

Compiler Status  Describes what library works with which compiler.

Links  Links of special interest to Boost users.

diff --git a/writingdoc/design.html b/writingdoc/design.html index 7e95a63..d1f1a5f 100644 --- a/writingdoc/design.html +++ b/writingdoc/design.html @@ -225,7 +225,7 @@ understand why a library was designed the way it was and may reduce the frequency of a number of frequently asked questions. For a better description of why rationale is important see the Rationale rationale + "http://beta.boost.org/development/requirements.html#Rationale">Rationale rationale in the general submission guidelines.

Like most content pages, the Rationale page should include a

-
{{header}}
+
{{header}}
-
Macros
+
Macros
-
{{macro name}}
+
{{macro name}}
-
Values
+
Values
-
{{value name}}
+
{{value name}}
-
Types
+
Types
-
{{type name}}
+
{{type name}}
-
Classes
+
Classes
-
{{class name}}
+
{{class name}}
-
Functions
+
Functions
-
{{function +
{{function name}}
-
Objects
+
Objects
-
{{object name}}
+
{{object name}}
@@ -99,9 +99,9 @@
Definitions
-
Frequently Asked Questions (FAQs)
+
Frequently Asked Questions (FAQs)
-
Bibliography
+
Bibliography
Acknowledgments
From 4f5368781cb5b7d6d42c40375e3aa300e0141d89 Mon Sep 17 00:00:00 2001 From: Daniel James Date: Fri, 7 Dec 2007 01:12:02 +0000 Subject: [PATCH 2/2] 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 @@ - - - - - -An overview of Boost participation in -Google Summer of Code™ 2006 - - - - - -boost.png (6308 bytes) -

An overview of Boost participation in -Google Summer of Code™ 2006

- -
- -

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

- -

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

- -

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

- -

Contents

- - - - -

How the program works

- -

-There are three types of participants in Google Summer of Code: -

    -
  • Google itself acts as the funding partner and conducts the overall - program.
    • -
  • The open source organizations accepted into the program must designate - people inside the organization who will act as project mentors.
    • -
  • 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.
    • -
-The program goes through the following stages: -
    -
  • 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.
    • -
  • 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.
    • -
  • 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.
    • -
  • 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.
    • -
-

- -

2006 figures

- -

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

- -

Boost participation

- -

Application and -process selection

- -

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

- -

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

- -

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

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

- -

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

- -

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

- -

Accepted projects

- -

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

- -
-C++ Coroutine Library -
-Giovanni Piero Deretta, mentored by Eric Niebler. -
-Library for the management through a modern C++ interface of OS-provided -coroutine facilities. -
- -
-Concurrency Library -
-Matthew Calabrese, mentored by David Abrahams. -
-STL-inspired generic framework for high-level specification and execution of -parallelizable algorithms. -
- -
-TR1 Math Special Functions -
-Xiaogang Zhang, mentored by John Maddock. -
-Implementation of the 23 special mathematical functions specified in C++ -standard library extension proposal TR1. -
- -
-The Boost.Process library -
-Julio M. Merino Vidal, mentored by Jeff Garland. -
-Portable library for process launching and basic management. -
- -
-Out-of-Core Graphs and Graph Algorithms -
-Stéphane Zampelli, mentored by Jeremy Siek. -
-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. -
- -
-MISC (M)ulti (I)ndex (S)pecialized (C)ontainers -
-Matías Capeletto, mentored by Joaquín M López Muñoz. -
-Families of specialized containers internally based on Boost.MultiIndex. -
- -
-Generic Tree Container -
-Bernhard Reiter, mentored by René Rivera. -
-Design and implementation of a family of STL-compatible tree containers. -
- -
-Viewer utility for FSMs -
-Ioana Tibuleac, mentored by Andreas Huber Dönni. -
-Utility program for the visualization of finite state machines (FSMs) specified -with Boost.Statechart. -
- -
-Modular C++ preprocessor, using Boost.Spirit -
-Hermanpreet 'Lally' Singh, mentored by Joel de Guzman. -
-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++. -
- -
-Implementing a state of the art Mincut/Maxflow algorithm. -
-Stephan Diederich, mentored by Douglas Gregor. -
-Implementation of a fast mincut/maxflow routine for the Boost Graph Library -based on a new algorithm devised by Vladimir Kolmogorov. -
- -

Development

- -

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

- -

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

- -

Results

- -

-By the date the development period was officially closed, the status of the -different projects was as follows: -

    -
  • 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.
    • -
  • Two projects did not reach the planned goals, but nevertheless produced - useful material that could be expanded outside of the Summer of Code - program.
    • -
  • One project was abandoned shortly after the midterm review. The reasons - for the abandonment are unknown.
    • -
-The results of all the projects can be consulted online at the dedicated -Trac -site. -

- -

Analysis

- -

-We examine the various stages of Boost participation in Summer of Code, with an -emphasis on discovering opportunities for improvement. -

- -

Boost appeal

- -

-In a mid project -presentation at OSCON -2006, Chris DiBona from Google provided some data about the organizations -which received the most applications: -

- -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
OrganizationNo of applications
KDE244
Ubuntu & Bazaar236
Python Software Foundation212
GNOME199
Apache Software Foundation190
Boost174
Gaim152
The GNU Project148
Drupal146
-

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

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

- -

Opportunities lost?

- -

-If we look at the number of funded projects with respect to the applications received, -figures are not so favorable to Boost.

- -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
OrganizationNo of projectsProject/app ratio
KDE249.8 %
Ubuntu & Bazaar229.3 %
Python Software Foundation2310.8 %
GNOME199.5 %
Apache Software Foundation2714.2 %
Boost105.7 %
Gaim85.3 %
The GNU Project106.8 %
Drupal149.6 %
-

- -

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

- -

Projects startup

- -

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

- -

-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 bjam and Quickbook. Each -student overcome the startup difficulties on their own or resorting to their -mentors (see the section on public -communication issues). -

- -

Ongoing development

- -

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

- -

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

- -

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

- -

Public communication -issues

- -

-Students and mentors had at their disposal three different forums for the public -interchange of information and support: -

    -
  • Boost public lists, especially the developers and users lists.
    • -
  • A dedicated mailing list reaching all students and mentors working at - Summer of Code in Boost.
    • -
  • 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.
    • -
-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: -
    -
  • Doubts were deemed too technical or specific to be worth raising in - public.
    • -
  • A crave for perfectionism detracted students from asking or submitting work - in progress until they felt their material looked good enough.
    • -
  • Shyness: some students probably lacked previous experience communicating in - public, and most are not English native speakers, which could also be a - limiting factor.
    • -
-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. -

- -

Scope of projects

- -

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

- -

-These scope issues are very dependent on the particular type of project. We can -classify the Boost projects for Summer of Code as follows: -

    -
  • Full-fledged libraries,
    • -
  • additions to existing Boost libraries,
    • -
  • utilities and tool projects using Boost.
    • -
-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. -

- -

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

- -

Suggestions for improvement

- -

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

- -

Preparation

- -

-Much work can be done before the actual program begins. The following preparation -activities can already be launched: -

- -

-Create a pool of ideas for projects. 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. -

- -

-Create a student pool. 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. -

- -

-Create a mentor pool. 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. -

- -

-Prepare a startup package. 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. -

- -

Public communication

- -

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

- -

-Mandate (bi)weekly reports. 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. -

- -

-Conduct student-mentor exclusively through public channels. 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. -

- -

Project management

- -

-The two most important issues to improve upon with respect to the management are: -

    -
  • Project scope must be kept under control,
    • -
  • The progress has to be publicly visible, so that problems of scope, - design and/or schedule can be more easily detected.
    • -
-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. -

- -

-Create a best practices document. 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. -

- -

-Mandate a design phase. 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. -

- -

-Maintain code, docs and tests in parallel. 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. -

- -

-Encourage the KISS principle. It is much better to finish a simpler library -and then iteratively evolve it, once it has been exposed to public scrutiny and -usage. -

- -

-More Trac updates. 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. -

- -

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

- -

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

- -

Conclusions

- -

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

- -

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

- -

Acknowledgements

- -

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

- -
- -

Revised October 17th 2006

- -

© Copyright 2006 Joaquín M López Muñoz. -Distributed under the Boost Software -License, Version 1.0. (See accompanying file -LICENSE_1_0.txt or copy at -http://www.boost.org/LICENSE_1_0.txt) -

- - - 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 @@ - - - - - - - - - - Boost Formal Review Process - - - - - - - - - - - - - - - - - - -
-HomeLibrariesPeopleFAQMore
- -

Boost Formal Review Process

-
-

Before Requesting a Formal Review

-

Read and follow the Boost submission process.  There are at - least four steps a library author must take before a formal review is - requested.

-
- -

Introduction
- What to include in Review Comments
- Results
- Notes for Review Managers
- Notes for Library Submitters
- Review Wizard
- Fast Track Reviews

- -

Introduction

- -

Proposed libraries are accepted into Boost only after undergoing a - formal review, where Boost mailing list members comment on their evaluation - of the library.

- -

The final "accept" or "reject" decision is made by the Review Manager, based on the review comments received - from boost mailing list members.

- -

Boost mailing list members are encouraged to submit Formal Review - comments:

- -
-
    -
  • Publicly on the mailing list.
    • - -
  • Privately to the Review Manager.
    • -
-
- -

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.

- -

What to include in Review Comments

- -

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.

- -

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.

- -

Here are some questions you might want to answer in your review:

- -
    -
  • What is your evaluation of the design?
    • - -
  • What is your evaluation of the implementation?
    • - -
  • What is your evaluation of the documentation?
    • - -
  • What is your evaluation of the potential usefulness of the - library?
    • - -
  • Did you try to use the library?  With what compiler?  Did - you have any problems?
    • - -
  • How much effort did you put into your evaluation? A glance? A quick - reading? In-depth study?
    • - -
  • Are you knowledgeable about the problem domain?
    • -
- -

And finally, every review should answer this question:

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

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

- -

Results

- -

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.

- -

Notes for Review - Managers

- -

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.

- -

The Review Manager:

- -
    -
  • Checks the submission to make sure it really is complete enough to - warrant formal review.  See the Boost - Library Requirements and Guidelines.  If necessary, work with - the submitter to verify the code compiles and runs correctly on several - compilers and platforms.
    • - -
  • Finalizes the schedule with the Review Wizard - and the submitter .
    • - -
  • Posts a notice of the review schedule on the regular boost mailing list, the - boost-users - mailing list, and the boost-announce mailing - list. - -
      -
    • 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.
      • - -
    • 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.
      • -
    -
    • - -
  • Inspects the Boost library - catalogue 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.
    • - -
  • Urges people to do reviews if they aren't forthcoming.
    • - -
  • Follows review discussions regarding the library, moderating or - answering questions as needed.
    • - -
  • Asks the review wizard for permission - to extend the review schedule if it appears that too few reviews will - be submitted during the review period.
    • - -
  • Decides if there is consensus to accept the library, and if there - are any conditions attached.
    • - -
  • Decides if there is consensus to accept the library, and if there are - any conditions attached.
    • - -
  • Posts a notice of the review results on the - regular boost mailing - list, the boost-users mailing list, - and the boost-announce mailing - list.
    • -
- -

In other words, it is the Review Manager's responsibility to make sure - the review process works smoothly.

- -

Notes for Library Submitters

- -

See Submission Process for a - description of the steps a library developer goes through to get a library - accepted by Boost.

- -

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.

- -

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.

- -

Review Wizard

- -

The Review Wizard coordinates the formal review schedule:

- -
    -
  • 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.
    • - -
  • When a formal review is requested for a library:
    • - -
  •   - -
      -
    • Assign a review manager and suggests a schedule, after checking - (via private email) availability of the volunteers at the top of - review manager queue.
      • - -
    • Finalize the schedule, once the review manager verifies the - library is actually ready for review.
      • - -
    • Resolve schedule slips or other issues with review managers and - submitters.
      • -
    -
    • - -
  • Monitors the general review process, and makes minor adjustments as - needed, or queries the list about possible major adjustments.
    • -
- 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). - -
  • 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 ...?"
    • - -
  • Monitors the general review process, and makes minor adjustments as - needed, or queries the list about possible major adjustments.
    • - The role of Boost Review Wizard is currently played by Tom Brinkman and Ronald Garcia (garcia at - cs dot indiana dot edu). - -

    Revised - 10 October, 2006

    - -

    To qualify for fast track review:

    - -
      -
    • The component must be small.
      • - -
    • The technique must be already in use in Boost libraries and the new - component provides a common implementation.
      • - -
    • A full Boost-conformant implementation is available in the - sandbox.
      • - -
    • The Review Wizard determines that the proposal qualifies for fast - track review.
      • -
    - -

    Procedure:

    - -
      -
    • 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.
      • - -
    • After the review period ends, the submitter will post a review - summary containing proposed changes to the reviewed implementation.
      • - -
    • The Review Wizard will accept or reject the proposed library and - proposed changes.
      • - -
    • After applying the proposed changes, the component is checked into - CVS like any other library.
      -  
      • -
    -
    - -

    Revised - 15 - October, 2003

    - -

    © Copyright Beman Dawes 2000

    - -

    Distributed under the Boost Software License, Version 1.0. (See - accompanying file LICENSE_1_0.txt or copy - at http://www.boost.org/LICENSE_1_0.txt)

    - -