[Phylobase-devl] Phyloinformatics Summer of Code 2008

[Peter Cowan]

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  
system.
* Transitioning ape and ade4 code to code that operates directly on  
phylo4 objects

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

Peter

> 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.
>
> _______________________________________________
> Phylobase-devl mailing list
> Phylobase-devl at lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/phylobase-devl