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

On 2010-02-19 at 14:18:45 [+0100], Michael Zucchi <notzed@xxxxxxxxx> wrote:
> 
> Hope you don't mind me butting in here.

Not at all.

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

Well, while that sounds reasonable, I believe it simply doesn't apply. The 
IMO in most cases incorrect assumption is that there actually are other 
developers who want to review a patch, have the time to do so, and possess 
the necessary familiarity with the concerned code base.

Usually reviewing patches is not fun. At least not for me, and given how 
long patches are sometimes pending in Trac I don't seem to be alone. That 
mainly depends on the quality of the patch and the complexity and own 
familiarity with the touched code. Reading through a 1000 lines patch may 
take as little as 10 minutes when it is well-crafted and the code isn't 
particularly complex, while thoroughly commenting on a complex one with 
issues can easily take several hours (I might just be exceptionally slow, 
though).

Which raises the time question. People work on Haiku in their spare time. 
As a paid developer in a commercial project it's easy to make one or two 
hours for reviewing a patch. In usually rather limited spare time, when one 
may rather want to do something fun, that's an issue, though.

Finally, regarding sufficient familiarity with the code base: Most of 
Haiku's developers (maybe with Axel being the exception) have worked only 
on a few components, and the total number of active developers isn't 
particularly high. So for most components there are at best only a few 
initiated who could do a review without first needing to familiarize 
themselves with the concerned code. Usually one of those is the mentor 
anyway (and maybe another the backup mentor).

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

Given that the students are possibly completely new to open source and may 
not even have experience in contributing to any kind of large project, one 
of purposes of a closed list was to decrease the communication barrier for 
them. From the experience of the last years that didn't work too well, so 
that I don't think it will work any better to use haiku-development. It may 
not work any worse either, though.

Having only the stakeholders on the list would improve the signal to noise 
ratio and facilitate the collaborative atmosphere of a small team (i.e. 
mentors helping also the other students, students interacting with each 
other). At least that was the idea. Since most students primarily 
communicated only with their mentors via private mail, that worked only to 
a small degree. Again, it might work just as good/bad on haiku-development.

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

I believe that's what we're already doing anyway.

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

Well, anybody with commit access who has experience with the concerned 
code. Which usually leaves only a few people who are probably involved 
anyway.

> I guess the
> GSOC process gives reasonably well defined targets anyway - something
> we didn't have.
[...]
> 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 ...

Actually I believe that unless the student is exceptionally self-reliant 
and flexible, mentoring is bound to take more time than implementing the 
project yourself. I also don't see any way around that. Investing less time 
in code review will just get us substandard code. Which helps no one. 
Dropping all students that after a short time turn out not to be 
exceptionally good would be an option, but that would probably result in 
90% failed projects.

> which
> kind of defeats the purpose unless they are going to stick around.

This is exactly our goal -- gaining new contributors that is (not defeating 
the purpose ;-)).

CU, Ingo

Other related posts: