[Phylobase-devl] Phyloinformatics Summer of Code 2008

[Hilmar Lapp]

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!

	-hilmar

Hi all,

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/ 
google.com/embed?src=gsummerofcode%40gmail.com&ctz=America/Los_Angeles.

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:// 
hackathon.nescent.org/Phyloinformatics_Summer_of_Code_2007.

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  
project ideas!

Cheers, and on behalf of NESCent I hope you join us in feeling the  
summer!

	-hilmar
-- 
===========================================================
: 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.

Preamble

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.

Mission

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  
student community).
       * 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  
application stronger.


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

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

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

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

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

             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.