Re: [RFH] SoC 2012 Guidelines

From: Jeff King <peff@peff.net>
Date: Mar 27, 2012, 05:41 UTC
Message-ID: <20120327054120.GA24170@sigill.intra.peff.net>
In-Reply-To: <201203251745.48858.jnareb@gmail.com>

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

Show 8 quoted lines

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