[Phylobase-devl] Phyloinformatics Summer of Code 2008
hlapp at duke.edu
Wed Feb 27 19:47:14 CET 2008
Hi folks -
I thought this would be particularly appropriate to invite you as a
mentoring 'group', or as a few among you to conceive and mentor a
project for a remote summer student. I can easily imagine that
there's more than one project you can carve out, and there's probably
a number of grad students (or even undergrads) who'd be eager to hack
away on the future data or IO or plotting or subsetting or <insert
here> standard for phylo packages in R.
BTW just in case this isn't obvious, this isn't a government program,
and hence in no way tied to US residents, neither for students nor
for mentors. (There are some international restrictions, but only for
residents of those countries the US has trade embargoes with, b/c
Google is a US company.)
Cheers, and please don't hesitate to ask any questions. I'm looking
forward to your ideas!
as you may have noted, on Monday Google announced that the Google
Summer of Code is on again for 2008: http://code.google.com/soc/2008
Program FAQs are at http://code.google.com/soc/2008/faqs.html, and a
program calendar is at http://www.google.com/calendar/hosted/
As NESCent's first-time participation in 2007 was not only hugely
successful but also wildly enjoyable beyond expectations (see http://
www.nescent.org/news/newsletter_10_07.php#google) we will be applying
as a mentoring organization again this year.
It is our mentors, and the project ideas they propose, who are at the
center of our potential value and attractiveness for students, and
competitiveness among other applying organizations. If you have an
idea for carving out a summer coding project for a student, and/or
can fancy yourself mentoring a student, or are simply enthusiastic
about helping out, for example as a backup mentor, please let me
know. Any and all ideas are welcome, as is feedback and help.
Attached below is some additional information about our participation
last year, an overview of the Summer of Code program procedure, and
some guidelines for our expectations from our mentors. If you haven't
participated last year with us, you can find information about last
year's project ideas, accepted projects, and students at http://
Over the next one and a half weeks we will assemble our mentoring
organization application. In the course of that I will also create a
new project ideas page. If you have participated last year (as a
student or as a mentor), any feedback or suggestion as to what worked
or did not work well and what was missing from the ideas page is
appreciated, and if you have specific ideas or any other suggestions
for the format of that page those would be great to hear too.
I'll post the URL of the page as soon as a skeleton is in place and
open for adding/editing project ideas, should be within the next
days. In the meantime, don't wait thinking about what might be cool
Cheers, and on behalf of NESCent I hope you join us in feeling the
: Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org :
Guidelines for NESCent Mentors for Google Summer of Code
After participating for the first time in the Google Summer of Code
(GSoC) in 2007, NESCent will apply again to the program in 2008 as a
mentoring organization. This document lays out the key guidelines for
participating in NESCent as a GSoC mentor.
NESCent's 2007 first time ever GSoC participation turned out highly
successful, on many levels and in many respects. For example, we
received a much higher-than-average number of student applications,
and were allocated the highest number of projects among all academics-
based organizations. Some of our projects became part of larger open-
source projects, some got noticed and picked up by the research
community; some students started with knowing few or none of the
needed technical skills and finished not only accomplishing their
project goals but also being students empowered with ubiquitously
applicable programming skills; some students continue to this day to
work and expand on their SoC project, and some are in the process of
publishing their work in scholarly journals. The end-of-summer
gathering of students and mentors at (and co-sponsored by) NESCent
gave an impressive overview of the breadth of accomplishments and
skills gained among the students.
As will be no surprise, we also learned a number of lessons. For
example, in some cases student and mentor weren't matched as well as
they could have been, and some mentors had unrealistic expectations
what the needed time commitment would be. Some projects had to be
canceled after highly qualified students had applied, rather than
dropping them before students could apply. Last, but not least, it is
worth noting that Google will hold the mentoring organization
accountable for all of the actions (or lack thereof) of its mentors,
and for issues arising later from lack of preparation or diligence.
Thus, in a spirit of facilitating more of the strengths and potential
value of our participation while trying to prevent avoidable
mistakes, this document states our expectations from our mentors,
along with our mission and an overview of the procedure.
NESCent's mission in participating in the Google Sumer of Code as a
mentoring organization is to introduce future researchers in
comparative biology to open-source and open, collaborative
development of reusable, interoperable, and standards-supporting
software that enables new and increasingly complex scientific
questions to be addressed.
NESCent is particularly interested in training future researchers to
not only have awareness and understanding of the value of open-source
and collabaratively developed software, but also to gain the
programming and remote collaboration skills needed to successfully
contribute to such projects.
Overview of the SoC procedure
GSoC 2008 consists roughly of the following steps.
1. Mentoring organizations apply between March 3-12. Assembling the
application includes recruiting tentative mentors, accumulating and
documenting project ideas in outline format, and writing the
application itself. In 2007 the acceptance rate of organizations was
around 35%, with more than 300 organizations applying, and is
becoming increasingly competitive with each year. Only accepted
organizations proceed to the next step.
2. After, and given, acceptance (announced March 17), in theory there
is a week to shore up project idea descriptions and to reach out to
possible student communities to call for applications. However, given
the short period for students to submit applications, students will
typically start exploring project ideas or post project suggestions
during this week already, so any fleshing out and changes should be
made ASAP after acceptance.
3. Students have one week (March 24-31) to apply for their project(s)
idea of choice (or they may suggest their own project). Though in
principle students are allowed to apply to as many projects as they
like, in practice high-quality applications take significant time and
generally involve communication with the prospective mentor. Projects
canceled after a student applied to them can jeopardize the student's
ability to get accepted into GSoC at all.
4. After the student application period closes, mentoring
organizations have 11 days (April 1-11) to rank the applications they
received (by scoring them), and to assign mentors to high-ranking
students. Mentors can request additional information from students
during this period. Typically prospective mentors also interview
students during this time, using email, chat, IRC, or phone.
5. Google allocates a certain number of projects to each
organization, using a secret formula essentially based on an
organization's previous GSoC history and on the number of
applications they received. The number of highest ranking students
for each organization that is equal to its allocation is accepted by
Google. One should keep in mind that students without a mentor cannot
be accepted regardless of their rank (or score), and a student can
only be accepted for one project.
6. Google allows for a 'community-bonding period' after student
acceptance until the official start of coding, which is on May 26.
Students receive a small program payment upfront ($500). The total
coding time is 12 weeks.
7. Mentors evaluate their students at mid-term, which during July
7-14. In 2007, this included a survey for both the mentors and the
students. Students failing the mid-term evaluation will not receive
any further program payment. Passing students receive about half of
their stipend ($2000). It is absolutely critical that mentors turn in
the evaluations and surveys in time.
8. Official 'pencils down' is on August 18, followed by an end-term
evaluation of students by their mentors (with deadline Sep 1).
Students failing the end-term evaluation will not receive the
remaining program payment ($2000) nor the (much prized) T-shirt. In
2007, this was also coupled with a survey for both mentors and
students. Again, it is absolutely critical that mentors turn in the
evaluations and surveys in time.
How to participate as a mentor
* Indicate your interest to Hilmar Lapp (hlapp at nescent.org), who
will also be the organization administrator for NESCent.
* Conceive a suitable and well-scoped project ideas.
* Keep in mind that the problem should be scoped so that it is
tractable by a student (who may not know all the technologies yet)
over a period of 12 weeks.
* Students will be working remotely the entire time. Project
ideas requiring face-to-face contact or a nearby office with the
student are unsuitable as GSoC project ideas (although such projects
may arise, and are acceptable, as applications from the local grad
* Google's guideline is that the project be about programming
(and not documentation, or wet-lab experiments, for example). Also,
the code to be written as well as the software project that is the
context need to be open-source licensed (with an OSI-approved
license), and its source code needs to be publicly downloadable (or,
better yet, already in a publicly accessible source code repository).
* Team up with others who may be interested in co-mentoring a
student on your project idea. Empirical evidence from other
organizations suggests that at least 2 mentors per student are best.
We will eventually need someone to be designated as the primary
mentor among a group of co-mentors, but this need not be decided
until the stage in which student applications are ranked.
* Enter and maintain your project idea on the wiki page
designated for this purpose (we will disseminate the URLs) before the
mentoring organization application is submitted. Details may be added
only after NESCent's application has been accepted, but keep in mind
that the project ideas page plays an important role in the review of
the organization's application.
* You need not be a primary mentor to participate; you can help
out with one or more project(s) at different levels, such as helping
with the project idea conceptualization, reviewing student
applications for the project(s), or serving as a secondary mentor
throughout the summer. Having backup mentors makes an organization's
Guidelines for Mentors
1. By the time the student application period opens,
project ideas need to be fleshed out to a degree sufficient to
attract the best qualified students. They also need to have at least
one fully committed primary mentor at that time. We reserve the right
to modify or remove project ideas that we deem unlikely to succeed,
at risk of not having enough committed mentoring time, or outside of
our mission as a participating organization. We will notify in
advance the proposed mentors of projects we consider removing, and we
will give advice about what we perceive as the issues that need
2. Although the requirements of project ideas at the
time of submitting the mentoring organization application are more
liberal, a project ideas page that conveys creativity, prior thought,
and clear plans on the side of the mentoring organization is a key
factor towards acceptance.¬† We encourage each mentor to focus on at
most one well-conceived and well-scoped project idea. We reserve the
right to modify or remove project ideas in order to craft a
competitive application for a mentoring organization. Given the
increasingly competitive nature of the program, we expect to need as
much help as possible from prospective mentors in assembling a strong
3. Empirical evidence suggests that prospective mentors
should expect to spend at least 5 hrs per week with their student,
and sometimes more. This assumes that there is also a community, or
secondary mentors, behind a project that can help out occasionally.
If there is only a single mentor, a bigger time commitment may be
needed. Obviously, this also depends much on the student. Hence,
mentors should exercise particular diligence when scoring student
applications, and are strongly encouraged to interview students
during the application period, especially if there is no backup help
on their project. Prospective mentors should let us know as early on
as possible if they anticipate to need help with recruiting
additional backup mentors.
4. We expect at least the primary mentors to review at
least all student applications for their project idea and to score
them. We will provide scoring guidelines in time before the review
and scoring period starts. We encourage all mentors to also score
applications for projects other than their own, so that reviewer
consensus (or lack thereof) becomes apparent. We also encourage all
mentors to interview (over phone, chat, or IRC) the top-ranking
students for their project to get a better feel for their
communication abilities, their expectations, and check that mentor
and student personalities aren't misaligned. As NESCent will
ultimately be held accountable for the student (and project)
selection, we reserve overriding the ranking resulting from mentors'
scores if we deem other applicants a better fit than the one ranked
highest for a project by its mentor(s). We may also override the
ranking to better align the breadth a topics with our mission as an
5. For students to work productively and focused over
the short coding period it is critical that they have a project plan
with milestones and deliverables at least one week in advance of the
start date. We expect the mentor to guide the student through
developing this plan (not to write it for them) in time, and to guide
the student through continuously revising the plan as the project
6. The idea of the program timetable is that students
are ready to start writing code at the start of the coding period. It
is therefore highly advisable to start working on a project plan soon
after the student is accepted, as the emerging plan will help guide
the student in what technologies she needs to prepare herself in,
which software needs to be installed, and what administrative work
may need to be done (such as subscribing to a mailing list, checking
out codebases, acquiring cvs or svn accounts, etc).
7. If the project is situated within a community (such
as a larger research collaboration, or an open-source project with a
developer community), we expect mentors to gently guide their student
to introduce themselves to and become an accepted and valued part of
that community. Even though we will try to facilitate this as much as
possible from the organization's end, the mentor is pivotal in
achieving this. Empirical evidence collected by Google shows that for
a variety of reasons this is one of the most difficult obstacles for
students to overcome, but once overcome also one of the best
predictors of a student's sustained future involvement in the project.
8. Students and mentors will likely have differences in
personal, work, and communication style. Despite the best efforts to
match students and mentors, sometimes these differences lead to
issues and frustrations between the mentor and the student that
persist or even escalate. The organization administrator is there to
mediate in such cases to the extent possible. However, in order to do
so we must know that issues exist. We expect mentors to inform the
organization administrator (hlapp at nescent.org) as early as possible
about any issues affecting the success of the student's project,
including issues with the student or issues affecting your own role
9. It occasionally happens that a student, despite
careful review, turns out to be a free rider. We expect mentors who
suspect their student is not contributing their share of the work to
let the organization administrator know as early as possible so we
can take action. Spending your mentoring time, or Google's money, on
a student who doesn't do their share is a waste of both. A mentoring
organization can ask Google to drop students even before the mid-term
evaluation, if justified.
10. We expect mentors to turn in the mid-term and end-of-
term evaluations of their students sufficiently far in advance of the
Google-set deadline that we can review the evaluation with the mentor
in case there are disputes. Mentors who are unavailable during part
of or the entire evaluation period need to notify us in advance so we
can find an alternative way of submitting the evaluation.
Last but not least, the overwhelming majority of our mentors in 2007
thoroughly enjoyed the experience, and learned a lot themselves. We
will do the best from our end to ensure that this will be no
different this year.
More information about the Phylobase-devl