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.