On Tue, Mar 10, 2009 at 09:37:16AM -0500, Hyrum K. Wright wrote:
> On Mar 10, 2009, at 9:18 AM, C. Michael Pilato wrote:
>
> > http://google-code-updates.blogspot.com/2009/03/now-accepting-applications-for-google.html
> >
> > Google is now accepting apps for projects wishing to participate in
> > the
> > Summer of Code program for 2009. What's your pleasure?
>
> (FYI, project applications are due Friday at noon.)
>
> I'd like to see us participate, but we've got to handle the program
> better than we have in past years. We typically throw together a
> bunch of candidate projects, get a couple of good applications and
> many mediocre ones, accept a couple of students, give them branches in
> the repo, and hope they succeed. That's not a recipe for success.
>
> How could we improve? I don't know the answer just yet, but I do know
> we're lacking in several areas. We aren't:
> * attracting quality students
Well, they all use git ;)
> * providing sufficient mentoring to those students
I'd say we need at least two or three mentors per student,
or even more.
This would reduce turn-around time for mentors, because they
may not always be able to react in a timely fashion. E.g. Karl
last year was constanly busy and patches by his student were
lying on the list for ages, with no one else looking at them
because, well, it was "Karl's student". Being able to quickly
pass the ball would be nice for mentors. A +1 from any mentor
will do.
And it would also reduce turn-around time for gsoc students, and
involve them in the project more closely. Rather than being proxied
by their mentor, gsoc students should be encouraged to participate
directly in the community just like everyone else, and not just
talk to a single mentor.
I'd happily mentor something related to tree-conflicts, but not on
my own. Maybe Julian, Neels and Steve would also help to mentor such
a project?
> * using the resulting code in a timely manner
Let them commit reviewed patches to trunk then, incrementally
working on their feature/bugfix/whatever.
If we pick projects that we know need to be done anyway one way
or another, and have enough mentors reviewing patches from gsoc
students before they enter trunk, this might turn out to work well.
It also give gsoc students more exposure, because their work
will not be hidden away on a branch.
> * retaining students as developers after SoC ends
Again, more mentors makes this more likely.
This is a social problem, not a technical one.
If people feel welcome and valued in a community, they tend to stay.
A proxy-type mentor model does not achieve that effect.
Stefan
Received on 2009-03-10 15:57:58 CET