From: Jonathan Nieder <jrnieder@gmail.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: Git and GSoC 2013
Date: Wed, 27 Mar 2013 11:52:48 -0700 [thread overview]
Message-ID: <20130327185248.GE28148@google.com> (raw)
In-Reply-To: <20130327183410.GA26066@sigill.intra.peff.net>
Jeff King wrote:
> There was a big thread about a month ago on whether Git should do Google
> Summer of Code this year[1].
[...]
> In my opinion, a lot of the issues come down to project selection;
Let me throw in some other issues. :)
* I think the git project has been very disorganized in vetting
candidate students. Other organizations have formal requirements
(for example, "must submit at least one properly formatted patch to
qualify") but we seem to rely on a candidate's good sense,
independence, and general sense of trustworthiness without
providing guidance beyond that.
At first glance that wouldn't seem to be a problem --- the accepted
students have been very good anyway --- but I think that if we
could communicate more clearly what we need, we might find there
are more qualified students that we have been missing, and
promising students might end up working a little in advance of
GSoC to adapt themselves to the project.
* Similarly, we are not very good at making clear the expectations
for students during the program and making sure they are met. At
least I know I was lousy about this as a mentor.
For example, students delay too long before posting patches
on-list and do not ask for help quickly when they are stuck. By
the end of the summer they may start to get a sense of the usual
contribution workflow when they could have been more effective
by following it from the start.
Some organizations require (as a non-negotiable rule) regular blog
posts from their students, as a way of advertising to others what
work they are doing and how to help them out. That could help
here.
* We didn't plan in advance for "What happens when summer ends and
the students don't have free time any more?"
* We don't advertise any good recourse available to students if a
mentor is unexpectedly too busy or hard to contact. I don't know
if that's happened in practice.
Matthieu Moy's summer projects worked better in all these respects, I
think.
I don't think we should apply. Better to take a break and prepare for
next time.
My two cents,
Jonathan
next prev parent reply other threads:[~2013-03-27 18:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-27 18:34 Git and GSoC 2013 Jeff King
2013-03-27 18:52 ` Jonathan Nieder [this message]
2013-03-27 22:15 ` Christian Couder
2013-03-28 16:45 ` Junio C Hamano
2013-03-28 17:07 ` Jeff King
2013-03-28 20:39 ` Christian Couder
2013-03-29 4:57 ` Junio C Hamano
2013-03-28 15:17 ` Ramkumar Ramachandra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130327185248.GE28148@google.com \
--to=jrnieder@gmail.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).