1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
|
<!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>
|
