My advice for GSoC applicants

Hi,

Based on my experience so far as a first-time Google Summer of Code mentor, I just wrote a blog article containing some hopefully useful advice for students applying to the program. Please note that this is my personal opinion only and doesn't necessarily reflect the views of the Git/libgit2 projects as a whole.

    My secret tip for GSoC success

http://softwareswirl.blogspot.com/2014/03/my-secret-tip-for-gsoc-success.html

Michael

From: "Michael Haggerty" <mhagger@alum.mit.edu>
Cc: "Dmitry Dolzhenko" <dmitrys.dolzhenko@yandex.ru>; "Sun He"
<sunheehnus@gmail.com>; "Brian Gesiak" <modocache@gmail.com>; "Tanay
Abhra" <tanayabh@gmail.com>; "Kyriakos Georgiou"
<kyriakos.a.georgiou@gmail.com>; "Siddharth Goel"
<siddharth98391@gmail.com>; "Guanglin Xu" <mzguanglin@gmail.com>;
"Karthik Nayak" <karthik.188@gmail.com>; "Alberto Corona"
<albcoron@gmail.com>; "Jacopo Notarstefano"
<jacopo.notarstefano@gmail.com>

In particular I liked : " If the documentation is unclear, it is OK to ask for a clarification, but then _fix the documentation_ so that your mentor never has to answer the same question again."

So the rhetorical question(s) for students would be :-

- was the Git documentation useful - did you see the README?, did it
lead, easily, to the useful places [1]? How could the wording/layout be
improved for the first time reader?

- which points of clarification were most useful and are they in the
documentation? Where should they be included?

- which points needed repeating often, and why? Where was the
disconnect?

- what would a patch look like...

Philip Oakley

[1] README; INSTALL; Documentation/SubmittingPatches; Documentation/CodingGuidelines;

On Mon, Mar 3, 2014 at 5:45 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:

I enjoyed reading that BLOG post. I daresay some of the points you raise are pertinent for any new contributor to any open-source code base.

Michael Haggerty <mhagger@alum.mit.edu> writes:

Thanks for writing this.

Also thanks for the MicroProject approach to introduce potential students and the community.

Multiple students seem to be hitting the same microprojects (aka "we are running out of micros"), which might be a bit unfortunate. I think the original plan might have been that for a student candidate to pass, his-or-her patch must hit my tree and queued somewhere, but with these duplicates I do not think it is fair to disqualify those who interacted with reviewers well but solved an already solved micro.

Even with the duplicates I think we are learning how well each student respond to reviews (better ones even seem to pick up lessons from reviews on others' threads that tackle micros different from their own) and what his-or-her general cognitive ability is.

On 03/03/2014 11:29 PM, Junio C Hamano wrote:

So far the list contains 10 microprojects, and as of yesterday I had seen 10 students attempt them. If I had made it clear from the beginning that each student should pick only one project, then we wouldn't be in all that bad a situation.

I might have time today to look for some more microprojects for the list and to mark the ones that have already been attempted. But other list regulars should FEEL ENCOURAGED to submit microprojects to add to the list. (Either submit them as a pull request to the GitHub repository that contains the text [1] or to the mailing list with CC to me.) I was hoping that writing the text and adding the first batch of microprojects would be enough to get the ball rolling, but I'm not sure I have enough time to be the one and only microproject muse.

On the other hand I've been very happy and grateful that other people have taken a lot of time to interact with the students and give them feedback on the mailing list. I definitely think the students are getting a realistic taste of how our community works.

Michael

[1] https://github.com/git/git.github.io