[Python-Dev] Our failure at handling GSoC students (original) (raw)

Stephen J. Turnbull stephen at xemacs.org
Wed Aug 7 07:06:23 CEST 2013

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.

More information about the Python-Dev mailing list