Experiences from last year's GSOC
Peter Arrenbrecht
peter.arrenbrecht at gmail.com
Mon Feb 23 07:59:27 CST 2009
On Tue, Feb 17, 2009 at 10:14 AM, Martin Geisler <mg at daimi.au.dk> wrote:
> Hello everybody,
>
> I'm glad to see the early interest in having Mercurial participate in
> the Google Summer of Code. I hope we will participate again this year
> with many good projects.
>
> But I'm wondering if the mentors from last year could tell us a bit
> about their thoughts as to why some of the projects failed?
>
> * Were the projects too ambitious?
>
> * Did the students have too little experience with Python?
>
> I hope we can improve the success rate by thinking about this when
> selecting projects and students.
Sorry, I was in hospital for a while. I mentored work on TortoiseHg.
Despite not having worked with TortoiseHg before. Yes, it was not a
good idea. The project narrowly passed, however (note I'm saying
"project", not "student", here as the blame is shared). I also took
over mentorship for another project (partial cloning) when its mentor
went AWOL. This one failed.
Here are a few quotes from my final feedback to Google:
2. If there was one thing you wish you had known before getting
started in Summer of Code, what would it be? (required)
The amount of guidance required. I underestimated how much it takes to
get some students to really participate and overcome their shyness (or
whatever it is that keeps them). Now, I could have known from reading
other GSoC writeups, but experiencing it myself was quite different
from just reading about it.
3. If there was one thing you wish your students had known before
getting started in Summer of Code, what would it be? (required)
Just how much FOSS development is about collaboration, not just coding
something up.
4. Given your experience this year, would you change your applicant
selection process should you participate in a future Summer of Code?
( ) Our selection process worked very well for us and we would not change it.
(x) We would do things differently next year.
Comments:
Only accept students where there is a mentor who is already proficient
in the area of the project in question. (The double load of getting up
to speed in the area as well as coaching the student was a bit much at
times.) Expect more involvement during the application submission
phase. (Hard as it may be for some students with little spare time
ahead of the programme.) Judge more by ability to fix easy bugs, for
instance. Select projects clearly focused on a single task. Less
chance for hopping between tasks, avoiding closure.
5. Please describe your applicant selection process. (required)
I looked over the proposals and judged them on: * reasonable scope *
reasonable definedness * desirability of the feature * qualification
of the student showing through * own interest in topic I then put this
into context with how active the students had already been on the
list/IRC. Finally, we all entered our ratings into the mentor app and
met on IRC to make final adjustments.
6. What would you do differently for future instances of Summer of
Code should you participate again? (required)
Not take on a project where I am not knowledgeable already. Not accept
proposals where the key people are rarely on IRC. Make sure the
project is not absorbed with something else during the final weeks (an
imminent release, for instance). Schedule regular IRC meetings from
the start. Then see how much of them are really needed after a while.
Assume I need to make contact regulary, rather than wait for the
student to come to me with problems. Insist more on priorities and
sticking with them, unless we both decide they ought to be changed.
Implies clearer planning. Insist more on seeing code or at least
thoughts and plans in written form early. Try to encourage students to
seek more feedback from the list/IRC.
7. What worked very well for your organization? (required)
Regular, scheduled IRC meetings. Making contact again and again,
rather than waiting for it. Encouraging students repeatedly to share,
despite current shortcomings of the work. Meeting students in person.
For the Google Zurich meet-up, I had one of the students (not mine -
Stefano) stay with me as I live close by. This was an excellent
opportunity to talk through some issues with his project, and also to
form a bit of a bond. This might help with keeping people with the
project, too. Buy-in from non-mentors on the team for supporting the
GSoC students helped those students who actively participated on the
list/IRC.
8. What advice would you give to future would-be Summer of Code
mentoring organizations? (required)
As above, expect to be on IRC regularly. Start with scheduled
meetings. Expect to have to guide. Expect to have to encourage and
allay fears (which may not even be clearly voiced). Get buy-in from
active non-mentors for supporting the students on IRC/list.
9. What advice would you give to future would-be Summer of Code
students who would like to work with your organization? (required)
This is about collaboration as much as it is about code. Don't be shy.
Let yourself be helped. Be on IRC. Share early. Be visible: it buys
goodwill, which buys help. If you get stuck, yell! If your code is
critized, don't hide - someone cares about it! We want you to succeed.
After all, we chose projects we really would like to see get done. But
do expect this to be work. With plans, priorities, unloved chores,
getting stuck, and a deadline. These are part of being successful in
the end.
-parren
More information about the Mercurial
mailing list