[Python-Dev] Our failure at handling GSoC students

[Stephen J. Turnbull]

Nick Coghlan writes:
 > On 7 August 2013 05:26, Antoine Pitrou <solipsis at pitrou.net> wrote:

 > > I would like to point out that we currently fail at handling GSoC
 > > projects and bringing them to completion.
 > 
 > Agreed.

I have no opinion on that statement, having not looked at the
projects.

 > > What didn't produce an alarm during Robin's work is that GSoC work is
 > > done in private.
 > 
 > This isn't the way GSoC is supposed to work.

Indeed.  I've seen this in one of the orgs I mentor for, and we may
ask that mentor to go elsewhere if we don't get a credible promise to
shape up.  (That's an indication of how seriously my orgs take "work
in public", not a suggestion for Python action in any case.)

 > or else a more general channel like core-mentorship or
 > python-ideas.

+1 for python-ideas if there is no better fit in a specialist list,
moving to python-dev as usual if the mentor judges the student
sufficiently mature.[1] If the student's posting becomes annoying on
python-ideas, the mentor should provide netiquette guidance.  IMO the
project-specific mentoring will become an annoyance on core-mentorship
since it continues for the whole summer, and changing "preliminary"
venues midstream doesn't seem like a great idea to me.

My orgs require (in only one case successfully :-) weekly progress
reports to the developers' list (per above, that would be
python-ideas, not python-dev).  In that successful case, GSoC is
essentially the only content posted to that dev list, though.  I'm not
sure if that matters.

 > Ideally (and this isn't going to be possible for every GSoC project),
 > mentors will be able to help break the project down into reviewable
 > chunks proposed as incremental issues, rather than producing one big
 > patch at the end of the summer.

GSoC suggests (at about the level of an RFC SHOULD) that students be
committing early and often to a publicly accessible branch.  I don't
see a good reason why that wouldn't work even for complex projects
that can't be merged until end of summer.  (I wonder whether such
projects should be used as GSoC tasks, as well, but as I haven't
actually looked at Python GSoC tasks, I'll leave that in parens.)


Footnotes: 
[1]  By that I mean that I often observe students mixing blue-sky
design with hard-core implementation details and necessary design
revision late in the summer.  If the project and student are "mature,"
that won't happen.