[Python-Dev] Our failure at handling GSoC students

[Antoine Pitrou]

On Tue, 6 Aug 2013 12:43:40 -0700
Eli Bendersky <eliben at gmail.com> wrote:
> On Tue, Aug 6, 2013 at 12:26 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> >
> > Hello,
> >
> > I would like to point out that we currently fail at handling GSoC
> > projects and bringing them to completion.
> >
> > One cruel example is the set of PEP 3121 / PEP 384 refactorings done by
> > Robin Schreiber:
> >
> > http://bugs.python.org/issue?%40columns=id%2Cactivity%2Ctitle%2Ccreator%2Cassignee%2Cstatus%2Ctype&%40sort=-activity&%40filter=status&%40action=searchid&ignore=file%3Acontent&%40search_text=pep+3121&submit=search&status=-1%2C1%2C3
> >
> > Robin has produced many patches that seem to reach the stated goal
> > (refactor C extension modules to take advantage of the latest PEPs
> > about module initialization and extension types definition).
> > Unfortunately, tackling both goals at the same time produces big
> > patches with a lot of churn; and it is also not obvious the PEP 384
> > refactoring is useful for the stdlib (while the PEP 3121 refactoring
> > definitely is).
> >
> > What didn't produce an alarm during Robin's work is that GSoC work is
> > done in private. Therefore, other core developers than the mentor don't
> > get to give an advice early, as would happen with any normal proposal
> > done publicly (on the mailing-list or on the bug tracker). It is also
> > likely that the mentor gets overworked after the GSoC period is over,
> > is unable to finalize the patch and push it, and other core devs have a
> > hard time catching up on the work and don't know what the shortcomings
> > are.
> >
> 
> I would like to point out something that stands out in this list of issues:
> such a method of producing dozens of patches simultaneously is extremely
> unwise, unless there's a crucial piece of history I'm missing. It is much
> more prudent to start with one or two exemplary modules, and if those fully
> pass code review, send out patches for others. The reason is obvious - code
> review may turn up problems or requests for change. Going backwards to
> modify 57 patches is not something anyone would want to do.

I definitely agree, but this is part of our failure too. A
beginner contributor isn't supposed to know the best way to contribute
if nobody tells him/her beforehand.

Regards

Antoine.