[haiku-development] Re: RFC: Idea for redefining our participation in Google Summer of Code

Hi guys,

Hope you don't mind me butting in here.

In the early-mid 2000's I was working full-time on Evolution Mail,
which was a sizeable code-base of a commercial product being used in
production environments and developed by a pretty small team.  And
although that pre-dates the whole GSOC of thing, we did have interns
or just interested parties, and I have some experiences that may be
helpful.

1. I think students should be exposed to the same process as any other
outsider.   What I mean is their patches should under-go the same
global scrutiny as any other patches.  Particularly in a 24-hour-world
(which we worked under every day with developers in every timezone
from +1000 to -0800) limiting patch review to a subset of developers
is something a small project simply cannot afford, and it saves one
individual being overwhelmed with details.   I do think the developers
should cut them a bit of slack to start with (to save any real
embarrassment)  - but this courtesy they should extend naturally to
all keen potential first-time contributors anyway.  Also, if they are
not exposed to proper `real world' criticism, they will not be able to
cope as well when it happens `for real'.  Any 'hidden' mailing list is
just a bad idea - just as it's a bad idea for core devs, it's a bad
idea for any contributors.  Obviously the rest of the team can't go
under-cutting the mentor's every goal ... but that shouldn't be too
difficult to manage.

2. Don't be so anally retarded about unimportant things like
formatting to start with.  Sure you need to mention it and try to get
them consistent, but we made a huge mistake of scaring people away
constantly with silly comments about completely unimportant things
like missing or extra white-space here and there.  It isn't that
difficult to fix it when you commit (most patched being pretty small),
and it's not that hard to do a bit of training and make sure they get
it right before you grant commit access (and keep an eye on it if you
do).  By the end, we just put stuff in and fixed these little problems
- we got free code, and they were happier not being treated like
idiots - it just wasn't worth the angst for anyone.

3. It is important they understand that this is a real-world
production-level code-base.  That means they can't be allowed to go
completely off on their own whims and ideas by themselves.  They will
definitely need some control - which is more where I see 'mentors'
fitting, rather than just the general patch review process - which
anybody experienced enough should be able to help with.  I guess the
GSOC process gives reasonably well defined targets anyway - something
we didn't have.

4. Manage expectations.  This is the hardest to do.  Even the most
interested, keen and dedicated individual may just not have what it
takes to produce production-level code for your project, or wont
produce something that fits with the over-all project direction.  This
is very hard to judge, since sometimes anything is better than
nothing.  But you also have to realise that sometimes the wrong thing
is actually worse than nothing.  Presumably these guys and girls are a
bit above the average, so it may not be an issue with GSOC.  Also,
treat them as real people - nobody likes being treated as idiots.

5. And finally, for the mentors/main contributors, realise that these
kids are just doing it for work experience.  Even the most motivated
may never work on the product ever again.  So help as much as you're
willing, but don't get so absorbed that you will regret the effort
later if they vanish - you're still the core people on the project
after-all and will still be around when others are not and you have to
look after your own well-being.  There's no use burning out for no
reason.  Sometimes it seemed like we were wasting more time reviewing
patches than we would've taken to simply write it ourselves ... which
kind of defeats the purpose unless they are going to stick around.

Anyway - not saying you should adopt these ideas, these are just some
things from my experience.

Regards.
 Michael Z

Other related posts: