[Phylobase-devl] Phyloinformatics Summer of Code 2008
pdc at berkeley.edu
Thu Feb 28 23:08:24 CET 2008
On Feb 27, 2008, at 10:47 AM, Hilmar Lapp wrote:
> 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.
Heh, can I apply? ;)
Areas that come to mind for me would be:
* Optimizing basic operations, analyses on multitree objects are
likely to be memory intensive and slow.
* Non-ape or ade4 based plotting. Perhaps implemented in the grid
* Transitioning ape and ade4 code to code that operates directly on
All of these seem to me to be time consuming efforts that aren't
likely to happen before a 1.0 release, unless we get someone to really
devote some time. However, I'm also not sure how pressing these
issues are, we don't yet have enough users to know what the pertinent
> Cheers, and please don't hesitate to ask any questions. I'm looking
> forward to your ideas!
> 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/
> 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
> project ideas!
> 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
> 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
> 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
> 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.
> Phylobase-devl mailing list
> Phylobase-devl at lists.r-forge.r-project.org
More information about the Phylobase-devl