[Long] GSoC: Status Check before Submitting Application
Randy Kramer
rhkramer at gmail.com
Sun Mar 9 20:50:56 CET 2008
I am generally pleased with the progress that's been made on the ideas list.
There might be some more things we can do, including possibly ordering the
list with the "best" projects at the top.
By best I don't necessarily mean the ones that provide the most gain for
NEdit, but instead those that are most likely to provide a good experience
for both a student who takes them on as well as us in learning how to be a
mentoring organization for GSoC.
However, I'm still wrestling with whether to submit our application, for
various reasons:
* So far we have one volunteer for mentoring (Bert Wesarg), and one
volunteer to serve as administrator (me). Somewhere (in the last document
from which I've copied snippets), it suggests that a mentor should be
prepared to spend 30 to 60 minutes per day dealing with his student, plus
several extra hours a week. They also suggest that we should have a backup
mentor, just in case (of whatever).
* So far, the only backup mentoring plan I've come up with is to take that
on myself, but I lack the real knowledge and expertise to do it, so would
anticipate taking questions to the devel mailing list for discussion.
(Discussion of some or all of the mentoring questions on a mailing list could
be a good thing in any case, both to develop possibly better answers as well
as to develop experience so that next year we might have more volunteer
mentors.)
* ATM, I'm spending more time than I can afford on this effort--hopefully
sometime about 2 months from now I should be able to spend more time.
I don't think we're in a position to handle more than one student at this
point (especially not this year, and especially with only one volunteer
mentor). On the other hand, accepting one student this year (and doing a
good job for all concerned, that is, the student, Google, and NEdit) might
put us in a better position next year to get and handle more students.
However, if we don't think we can do a stellar job for all concerned, I think
we would be better off to put our application off a year.
If we do submit an application, I'll probably tell Google that we only want
(can only handle) one student this year.
Here are selected quotes from various GSoC related links that, I think, are
appropriate to review before making a decision. (Actually, some of this
became sort of a miscellany of things I thought we should try to remember or
keep in mind, but I didn't capture everything of that nature.)
* Snippets from the [[http://code.google.com/soc/2008/faqs.html][FAQ]]:
'
2. What are the goals of this program?
Google Summer of Code has several goals:
* Get more open source code created and released for the benefit of all;
* Inspire young developers to begin participating in open source
development;
* Help open source projects identify and bring in new developers and
committers;
* Provide students in Computer Science and related fields the opportunity
to do work related to their academic pursuits during the summer (think "flip
bits, not burgers");
* Give students more exposure to real-world software development scenarios
(e.g., distributed development, software licensing questions, mailing-list
etiquette).
'
'
7. How does the program work?
Here are the steps:
1. Open source projects who'd like to participate in Google Summer of Code in
2008 should choose an organization administrator(s) to represent them;
2. Organization administrators will submit the project's application for
participation online;
3. Google will notify the organization administrators of acceptance, and an
account for the organization will be created in the Google Summer of Code web
app;
4. Students submit project proposals online to work with particular mentoring
organizations;
5. Mentoring organizations rank student proposals and perform any other due
diligence on their potential mentees; student proposals are matched with a
mentor;
6. Google allocates a particular number of student slots to each organization;
7. Students are notified of acceptance;
8. Students begin learning more about their mentoring organization and its
community before coding work starts;
9. Students begin coding work at the official start of the program, provided
they've interacted well with their community up until the program start date;
10. Mentors and students provide mid-term progress evaluations;
11. Mentors provide a final evaluation of student progress at close of
program; students submit a final review of their mentor and the program;
12. Student uploads completed code to code.google.com/hosting.
'
'
8. How do evaluations work?
Google will pre-publish the evaluation questions for both students and
mentors. Mentors will fill out mid-term and final evaluations for their
students using the Google Summer of Code web app. These evaluations will be
visible in the system to the mentor and the mentoring organization's
administrator(s). Students will fill out a mid-term and final evaluation of
their mentors online as well, and their evaluations will only be visible in
the system to the mentoring organization's administrator(s). Program
administrators from Google will have access to all evaluation data.
In almost all cases, students will never see their mentor's evaluation of
their progress, nor will a mentor see a student's evaluation of her/his
mentorship. However, in the case where the mentoring organization's
administrator and a student's mentor are one and the same, the student's
evaluation will be shared with the mentor. Organization administrators are
expected to review mid-term and final evaluations and to provide course
corrections where necessary.
In some cases, Google's program administrators may need to share the results
of evaluations with the student and mentor, such as to arbitrate when payment
should not be made; should this need arise, all parties will be notified in
advance.
'
'
3. What is an "Ideas" list?
An "Ideas" list should be a list of suggested student projects. This list is
meant to introduce contributors to your project's needs and to provide
inspiration to would-be student applicants. It is useful to classify each
idea as specifically as possible, e.g. "must know Python" or "easier project;
good for a student with more limited experience with C++." If your
organization plans to provide an application template, it would be good to
include it on your Ideas list.
Keep in mind that your Ideas list should be a starting point for student
applications; we've heard from past mentoring organization participants that
some of their best student projects are those that greatly expanded on a
proposed idea or were blue-sky proposals not mentioned on the Ideas list at
all.
'
'
9. Can a student work on more than one project?
No, each participant is only eligible for one stipend.
10. Can a group apply for and work on a single proposal?
No, only an individual may work on a given project. Of course, students should
feel free to collaborate with others to accomplish their project goals.
11. What happens if two students are accepted to work on the same project,
e.g. from an organization's "Ideas" list?
That's fine, a little duplication is par for the course in open source.
'
'
2. What is the role of a mentoring organization?
Each mentoring organization is expected to provide:
1. A pool of project ideas for students to choose from, publicly published by
the mentoring organization as an "Ideas" list;
2. An organization administrator to act as the project's main point of contact
for Google;
3. A person or group responsible for review and ranking of student
applications, both those proposals which tie into the organization's "Ideas"
list and "blue-sky" proposals;
4. A person or group of people responsible for monitoring the progress of each
accepted student and to mentor her/him as the project progresses;
5. A person or group responsible for taking over for a student's assigned
mentor in the event they are unable to continue mentoring, e.g. take a
vacation, have a family emergency;
6. A written evaluation of each student participant, including how s/he worked
with the group, whether s/he should be invited back should we do another
Google Summer of Code, etc.
In addition to these responsibilities, a mentoring organization should
actively encourage each student developer to participate in the project's
community in whichever way makes the most sense for the project, be it
development mailing lists, idling in the project's IRC channel, participating
in the project's forum, etc. A truly successful mentoring organization will
work diligently to ensure that as many of their students as possible remain
active project participants long after the conclusion of the program.
'
'
4. Can a mentoring organization have more than one administrator?
Yes, but it's not strictly necessary. It's good to have a backup administrator
identified who can cover for your administrator should s/he go out of town,
etc. If your backup administrator becomes the primary administrator, make
sure to notify Google's program administrators.
5. What kind of mentoring organizations should apply?
As you can see from the lists of our mentoring organizations for 2005, 2006
and 2007 many different types of open source projects participate in Google
Summer of Code. As long as your project can provide mentors and is releasing
code under an Open Source Initiative approved license, you are welcome and
encouraged to apply. Unfortunately, there are far more great open source
projects than we can work with, so if your project is highly niche or has
very few users, chances are that your application will not be accepted.
You may also find our
[[http://groups.google.com/group/google-summer-of-code-announce/web/notes-on-organization-selection-criteria]
[Notes on Organization Selection Criteria]] helpful.
'
Some schedule information (ignoring the applications and evaluation
processes):
'
April 14:
* accepted student proposals announced at code.google.com/soc/ (~12 noon
PDT/19:00 UTC).
Community Bonding Period: students get to know mentors, read documentation,
get up to speed to begin working on their projects. <rhk: probably while
still attending classes and preparing for final exams>
May 26:
* Students begin coding for their GSoC projects;
* Google begins issuing initial student payments provided tax forms are on
file and students are in good standing with their communities.
Interim Period: Mentors give students a helping hand and guidance on their
projects.
July 7:
* Mentors and students can begin submitting mid-term evaluations (~12 noon
PDT/19:00 UTC).
July 14:
* Mid-term evaluations deadline at 12 noon PDT/19:00 UTC;
* Google begins issuing mid-term student payments provided passing student
survey is on file.
Interim Period: Mentors give students a helping hand and guidance on their
projects.
August 11:
* Suggested 'pencils down' date. Take a week to scrub code, write tests,
improve documentation, etc.
August 18:
* Firm 'pencils down' date. Mentors, students and organization
administrators can being submitting final evaluations to Google (~12 noon
PDT/19:00 UTC).
September 1:
* Final evaluation deadline 12 noon PDT/19:00 UTC;
* Google begins issuing student and mentoring organization payments
provided forms and evaluations are on file.
September 3:
* Students can begin submitting required code samples to Google
'
* Snippets from
[[http://groups.google.com/group/google-summer-of-code-announce/web/notes-on-organization-selection-criteria]
[Notes on Organizations Selection Criteria]]
'
We don't have any hard and fast rules for selecting organizations - there are
many organizations that apply and many more than apply who we'd like to help
with their open source efforts. In the end, we have to make many tough
decisions about which organizations to accept. Here's a bit about our
thought process:
...
2) Do the projects on your ideas list look feasible for student developers?
Is your ideas list thorough and well-organized? Your ideas list is the first
place that student participants are going to look to get information on
participating in GSoC, so putting a lot of effort into this list is a good
thing(tm). One thing we noticed and really appreciated this year was how
some organizations classified their ideas by easy, medium and difficult, and
specifically listed the skills and background required to complete a given
task. It might also be cool to expand on each idea with some places to get
started research-wise (pointers to documentation or specific bugs), as well
as the impact finishing a given idea will have for the organization.
3) Did it look like you spent a decent amount of time on your application? Do
we have a good sense of who you are and what you intend to accomplish in GSoC
after reading it? Just as with an organization reviewing student
applications, a thorough and well-written org application piques our
interest. If it looks like you only spent ten minutes on the application,
er, not so much. Particularly when the application questions were published
weeks in advance of the application period.
...
A final note, an organization may fulfill some (or all?) of these criteria and
still not be accepted. We simply can't accept every organization that
applies.
'
* Snippets from
[[http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators]
[Guide to the Google Summer of CodeTM Web App for Mentors and Organization
Administrators]]
<later--more relevant if we apply and get accepted as a mentoring
organization>
* Snippets from
[[http://code.google.com/p/google-summer-of-code/wiki/WikiStart][Welcome to
the GSoC Knowledge Base Wiki]]
<later, maybe>
* Snippets from
[[http://code.google.com/p/google-summer-of-code/wiki/AdviceforMentors]
[Welcome to the Advice for GSoC Mentors Page]]
Good stuff--anybody interested in mentoring should read this page, but note
also this:
'
For this benefit to be fully realised it is important to ensure that your
whole project community are on board with the mentoring task. Just because an
individual is named as the mentor, it doesn't mean that they are the only one
who deals with the mentees issues. The mentee is just a member of the
community, like any other. Of course the mentor has a few added
responsibilities. It is them who has to ensure that the mentee is comfortable
and that they are able to get the most from the community.
'
There was another good page I found on mentoring, but I've misplaced that at
the moment. Oh, wait, here are links to some from the page above:
'
More Resources
Federico Mena-Quintero, GNOME mentor for GSoC 2006, has posted a great
[[http://primates.ximian.com/~federico/docs/summer-of-code-mentoring-howto/index.html]
[mentoring how-to document]].
Sean Morrison, BZFlag mentor and org admin for GSoC 2007, has posted an
[[http://my.bzflag.org/gsoc/bzflag_gsoc2007_post_mortem.pdf][overview of
their participation in the program]]. Good reading for first time mentors.
Warning: huge PDF, ~ 15 MB. You can also check out more notes on their
[[http://my.bzflag.org/w/Google_Summer_of_Code/][project's wiki]].
Jan Schauman, mentor and org admin for mutiple GSoCs with the NetBSD project,
did an [[http://arstechnica.com/articles/culture/netbsd4-interview.ars/8]
[interview with Ars Technica on NetBSD's repeat performances in Summer of
Code]], amongst other topics.
'
* Snippets from
[[http://www.gnome.org/~federico/docs/summer-of-code-mentoring-howto/index.html]
[Summer of Code Mentoring HOWTO]]
'
First, you need time. Be prepared to dedicate at least 30 to 60 minutes every
day to your mentoring. There will be exceptions, such as days when your
student is not online. But in general, you need to be able to dedicate a
relatively large amount of time to your student. You will be communicating
with her, clarifying doubts, making plans, checking her work, reviewing
patches, communicating to other people about your student's work, or just
chit-chatting.
Second, you need to dedicate a good extra two hours every week to test your
student's code or otherwise evaluate her work. Nothing is more demoralizing
than a mentor who talks to you but doesn't actually see the fruit of your
work in front of him.
Third, you'll be mentoring on behalf of a project, or part of a project ("the
file manager in GNOME"). You must know the code for this project or
sub-project really well. Your student has probably never had to do anything
with that code. You are the person who will answer her questions about where
in the code something happens, or how the code is supposed to work in the
grand scheme of things. Remember the first time you had to modify a big
program: that's exactly how your student will feel, so you have to be
prepared to answer questions about the actual code.
Fourth, you must have a clear vision of what your student wants to accomplish.
If you cannot see the finished "product" in your mind, you won't be able to
communicate clearly with your student. This automatically rules out projects
that are too experimental or imagined by architecture astronauts.
...
Keeping yourself and your student organized
You have your daily work, hobbies, and personal things to do. On top of that,
now you have to coordinate and manage another person: your student. What do
you do?
Keep a journal or log of what your student does and of what you ask him to do.
You don't need anything fancy to do this: maintaining a text file,
~/summer-of-code/student.txt is enough. The following is an actual sample of
the log I kept for one of my students:
---< example log entries >----
Care and feeding of students
IRC and IM are fine for day-to-day chatting with your student. In this modern
age you may even be able to set up Ekiga or some other VOIP software — but
don't waste too much time setting it up if it doesn't work at first. See the
section called “Starting the project” below for how to pick a good time to
chat with your student.
Use email for detailed technical explanations; it is much better for that than
IRC/IM, and it will be much easier for both you and your student to keep
those emails around for reference.
Your student knows few people in your project's community, and she is not used
to all the informal or formal processes which that community has defined. You
must take care of all the bureaucratic little details for your student. For
example, if your project requires your student to wait for a sysadmin to
create a CVS or Subversion account for her, then you should ask the sysadmin
to do so as soon as possible. In general, help your student so she doesn't
have to waste time waiting for administrative things to happen.
Guide your student through the code. You have been working with it for years,
while your student is probably looking at the code for the first time. Teach
her all the little debugging tricks that you have amassed over the years.
Your student wants and deserves recognition. Advertise your student's work
far and wide! Every time she reaches an important milestone, do whatever it
will take for people to notice: blog about it, send a screenshot to your
project's mailing list, etc. People will get interested and they will contact
your student; your student will feel appreciated as a result.
Make sure your student uses a revision control system for the code.
CVS/Subversion/Git are all fine. Also, teach your student the basics of
Bugzilla or your project's bug tracking system if appropriate.
Very important: if your project uses a nontrivial build system, a sandbox
environment, or anything similar (for example, jhbuild for the GNOME
project), teach your student how to use it and make sure she can get the code
compiled and running very early in the project. This is in the same spirit as
helping your student with silly administrative details: you don't want your
student to waste time getting the code to compile; help her out!
When your student gets stuck, help her to think laterally. Why do you think
the problem is happening? Can you solve it in a non-traditional way? Tell her
key places in the code to put debugging printf()s. Tell her the little tricks
you use in your debugger. Only if she gets *really* stuck, solve that little
part of the problem for her, but in general try to help your student solve
the problem herself.
---< lots more good stuff--every potential mentor should read this >---
'
Randy Kramer
More information about the Develop
mailing list