Re: [RFH] SoC 2012 Guidelines

[Jeff King <peff@peff.net>]

On Sun, Mar 25, 2012 at 04:45:47PM +0100, Jakub Narebski wrote:

> > Right. But would there be room for every student anyhow? Or, at least, 
> > would there be room for more students if there were more ideas / projects?
> 
> I don't know the details of how decision is made on how many project
> slots a GSoC organization will get, but in earlier GSoC (see Git Wiki)
> we get 2 to 6 projects (IIRC).
> 
> One limitation is number of possible mentors.

The decision is made by Google, taking into account how many slots we
ask for and how many slots other organizations ask for. The number of
slots we ask for depends on how many projects we have a good candidate
for. And also taking into account that mentor time is limited, so a
mentor who volunteers for two projects will probably only get one
selected.

Students should keep in mind, too, that items on the "ideas" page are
not the only potential projects. We have considered and sometimes
accepted projects that were totally of students' creation. Obviously
it's a bit harder to make such a proposal, since the student really
needs to be familiar with git.

> BTW. according to Google Summer of Code FAQ there can be more than one
> student working on the same project.  Though IIRC it never happened in
> history of Git participation in GSoC, isn't it?

Sort of. Students cannot work together, and are evaluated independently.
This being open source, of course, we expect people to communicate and
collaborate. But each student does his or her own project, and the goals
of that project are to be met by the student. So you can have two
students work in the same area, but you must do one of:

  1. Break the project into two independent pieces, and assign a student
     to each piece.

  2. Have the students compete, and pick the best implementation or
     approach at the end.

We haven't done either in the past, for a few reasons.  In the first
case, it can be very difficult to evaluate the students independently,
because even if one student completes their half, it may be hard to see
how good it is without the other student's half. In the second case,
evaluations can also be hard. We usually try to have a concrete
goal for success, like getting code accepted upstream; but with
competing students, that is unnecessarily harsh, since even good work
may not be taken. And in both cases, it is creating extra load on the
mentor, who has to spend twice as much time.

So while nothing is definite at this point, I would generally expect to
see at most one student per project area. And many projects will
probably not get picked at all, either because there isn't a strong
proposal, or because the proposed mentor ends up with another student.

-Peff