[Python-Dev] contributors survey?

[Nick Coghlan]

On Wed, Mar 2, 2011 at 11:10 PM, Mark Smith
<mark.smith at practicalpoetry.co.uk> wrote:
> The following is going to sound bitter...
> I was fired with enthusiasm for working on Python after the sprints at
> EuroPython last year. I submitted 3 (I think) patches for pulldom - a test
> suite (it has 0% code coverage at present), documentation for the module
> (there isn't any at present), and a patch deprecating a function that is
> broken. They're all still open, and the patches are getting staler by the
> month.
> The point of this level of detail is: I was new to the project; I submitted
> some relatively uncomplicated patches that trivially, visibly, and (mostly)
> uncontroversially improve Python - one of them was a /documentation/ patch.
> Then nothing happened, apart from the odd comment from people who commented
> on the tickets - and I responded to their queries. So now I'm of the opinion
> that it's not worth submitting patches to the Python project at all, because
> they'll never be accepted. I'll dedicate my time to something else instead.
> Mercurial /will/ make it easier to contribute code, but if it doesn't get
> accepted into a release branch, then that makes no real difference to me.
> Seriously guys - fix the issue lifecycle; I'll come back.

I think a key point in your experience there is that contributing on
orphaned modules can be *really* hard, because it is difficult to find
a committer that feels qualified to accept it. That's a serious
chicken-and-egg problem, because someone needs to contribute in order
for the existing core developers to gain confidence in their
abilities, but if the components they're interested in are
comparatively unmaintained, their contributions may not be accepted
due to a lack of a capable reviewer...

I know there's a patch that has been sitting on the tracker for ages
that gave the mimetools module some love, and was generally a positive
change, but needed someone with the expertise to really pick it apart
and figure out which elements were acceptable from a backwards
compatibility point of view, and which needed to be dropped and/or
turned into feature requests. I was able to highlight a few problem
areas, but it really needed a fresh set of eyes that was more familiar
with mimetools than I am, but also more familiar with the standard
library development life cycle than the patch contributor.

In contrast, particularly with the triage folks on the tracker doing
such good work, patches to actively maintained modules are far more
likely to get some decent consideration from the relevant maintainer.
There have been a few cases of folks being granted commit access to
work on previously orphaned modules (e.g. Lars with tarfile), but I'm
not sure what we can do about that problem more generally.

So perhaps a question we should be focusing on is how we might go
about getting better module coverage in the first table at
http://docs.python.org/devguide/experts

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia