[RFH] SoC 2012 Guidelines

First, I'd like to thank Jeff King for creating and hosting GSoC wiki pages for Git. Without his initiative, and even more his volunteering to be GSoC Git organizator we (as the Git Development Community) wouldn't be in Google Summer of Code 2012.

The https://github.com/peff/git/wiki/ includes the following pages:

* "SoC 2012 Application", which should probably be renamed to
  "SoC 2012 Organization Application"; it was here to help (crowd)craft
  organization application.

* "SoC 2012 Template", which perhaps should be better named
  "SoC 2012 Student Application Template"; it is here for prospective
  (would-be) student to help craft better project application.

* "SoC 2012 Ideas", to gather ideas for GSoC project from Git developers
  and others, as _example_ ideas for students applications.

  We really should have more ideas, as it looks like students would be
  battling for a few projects (I think there are two would-be students 
  for any proposed project).  Well, too late now.

I'd really like to see blue-sky proposals not mentioned on ideas list, or at least greatly expanded on proposed ideas.

When students proposals would get accepted at April 23, there would be created "SoC 2012 Projects", listing accepted projects and hopefully tracking their status. I guess we would try to list git-related GSoC projects from other organizations, like in previous years.

What is lacking (for me) is something like "SoC 2012 Guidelines" wiki page, which would gather guidelines and suggestions both for mentors and for students.

One can find some information buried in GSoC FAQ:
 
http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2012/faqs

It would be nice however to have it extracted and make easier to find.

This page could also serve to gather organization-specific requirements, for example:

* That the discussion of GSoC project application ideas with mentoring
  organization (i.e. with us) should take place in the open, here on git
  mailing list, git@vger.kernel.org.

* That each student should examine relevant parts of existing git code,
  read SubmittingPatches and Coding Guidelines, and at least lurk (read)
  on git mailing list during the Community Bonding Period (e.g. via
  GMane; I don't think we should require subscribing to git mailing
  list).

* That for each project there should be created a public git repository
  on one of git hosting sites like repo.or.cz, Gitorious or GitHub.

* How often students (and/or mentors) should send updates about status
  of a project (once per week perhaps?), and what should those  
  announcements include.

And to gather help:

* There should be some information about what parts of discussion and
  work should take place in private communication between student and
  mentor, and how much should it take place in public, on git mailing
  list.

* How can and how should mentors help students.

* How to make use of comments on patches (or design ideas), while not
  getting bogged down in "bikeshed"-ding :-)

* Perhaps also some advice from successfull students to students,
  and from mentors to mentors.

[I was neither GSoC student, or GSoC mentor.]

Those are very good ideas and everyone should think about implementing these :).

On Sat, Mar 24, 2012 at 9:41 PM, Jakub Narebski <jnareb@gmail.com> wrote:

2012/3/25 Jakub Narebski <jnareb@gmail.com>:

Looking through the ideas page on the wiki, it's not that we don't have enough ideas, it's just that students are all "clustering" around a few proposals (or just one, to be exact).

I wonder if they are aware of this, given that they most probably aren't subscribed to the list and thus wouldn't see "competing" proposals.

On 03/25/2012 03:19 AM, Tay Ray Chuan 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?

Which proposal (or proposals) is that?

Yes, at least I'm aware :) But I think it would be good to everybody if we could manage to get us students to talk and pick one different proposal each, specially if there is a possibility to get more people to participate in GSoC for Git.

Cheers André

André Walker wrote:

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.
 

"Improving parallelism in various commands" (3-4 proposals), "Designing a faster index format" (2-3 proposals), "Remote helper for Subversion" (this has 1 proposal I think), "Modernizing and expanding Git.pm" (2 proposals), "Use JavaScript library / framework in gitweb" (2 proposals), 'Complete "Linus's ultimate content tracking tool"' (0.5 proposal).

That is from what I remember, and from public and not so public info
I have available.  There might be dragons^W errors.
 

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?

On 03/25/2012 12:45 PM, Jakub Narebski wrote:

Well... I hope Git gets more slots this year! :) Do you know whether there were so many proposals in previous GSoC's?

That's awesome! I didn't know about that.

On Mon, Mar 26, 2012 at 4:14 AM, André Walker <andre@andrewalker.net> wrote:

This is a good news. If this can actually happen there is no problem for student "clustering" on certain proposals. I think this is good for git. Take the "Designing a faster index format" as an example, students comes with different formats. Perhaps they may work better in various cases. This gives more options to git. And more chance for students to get involved for sure.

Regards, Elton

On Sun, Mar 25, 2012 at 12:45 PM, Jakub Narebski <jnareb@gmail.com> wrote:

This is possible, but it's not profitable for git having 6 students working on a proposal just one could complete. Also, if all proposals are for the same project, chances are that google will give less slots to git, since no one is really sure how they distribute the slots.

I have been thinking in an alternate proposal, but without success right now.

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

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.

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

Most people go for improving the index, some with parallelisation and one or two choose for js improvements for git web.

On Sun, Mar 25, 2012 at 11:58:14AM -0300, André Walker wrote:

On Sat, Mar 24, 2012 at 05:11:29PM +0100, Jakub Narebski wrote:

Good renaming suggestions; I just pushed this.

The template page was not well-advertised, so I linked to it from the ideas page.

Some of that (for the students) is at the ideas page, and on the application template page. To a large degree, the advice is: engage the community. Hopefully that results in interesting discussions and the students getting a sense of what is required for each project. But there is probably room to provide some more specific guidance.

For the mentor side, we have pretty much left the mentors alone to decide how to do their jobs, recognizing that every mentor and every student-mentor pair will be a little bit different.

All of what you said looks reasonable to me, and follows the practices we've had in years past. It's a wiki. Feel free to add a new page, or edit (or if you want to get feedback before changing the wiki, post patches).

Some of these things are discussed in more general terms on the GSoC mentors list. We don't have particular policies in git, though in general I would encourage mentors to integrate the students into the usual list workflow. So lots of communication and status reports, and as much as possible in the open and on the list.

-Peff