On Wed, Mar 2, 2011 at 11:10 PM, Mark Smith <mark.sm...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
