Skip to content

Why aren’t you contributing (To Python)?

Over the past year or two, I’ve been in a pile of discussions surrounding attempting to increase the number of contributions to Python (as a project and ecosystem) – specifically around bug fixes/patch reviews, filing bugs, pointing out documentation issues, website content, etc. Many of these conversations seem relatively insular (people already involved talking about how they get work done, and how easy it is) or relatively hand-wavy (“let’s make it better! *crickets*”).

We all know that the fact is that there are plenty of areas for anyone (both programmer and not) to contribute to the Python project/ecosystem, this is actually true for most, if not all, open source, and open communities out there. While I am looking at this through the myopic lens of Python-core, the same discussion could be applied anywhere.

In the discussions I’ve had on mailing lists, and in private conversations with people about why they don’t contribute, I’ve found a set of recurring issues cited by people who could be contributors, roughly speaking these are:

  • Don’t know how (documentation issue)
  • Don’t know where (site layout, organization issue)
  • Don’t want to fight/argue with the “but this is the way we’ve always done it” people (perception issue)
  • For many issues, see checkout (svn), build (learn a “new” build system), run tests/write tests, generate patch, file bug, defend bug as a “high bar” (process/tool issue)
  • Don’t feel that they’ll be valued (perception issue)
  • Can’t invest the time to learn the tool chain(s) (make, ReST, regrtest, svnmerge/svndiff, sphinx, etc) (I got nothin here)

And so on.

What interests me more than the things I’ve listed about (which is a distillation of months of discussions) is what, if anything, prevents you, my reader(s) from contributing to the following areas:

  • Filing bug reports (including the stdlib and documentation)
  • Filing patches for bugs/improvements (including the stdlib and documentation)
  • Fixing issues/sending patches on website content
  • Proposing new website or documentation content
  • Contributing to website maintenance
  • Contributing to the Documentation

And anything else you can think of. What I’m asking for, is for you to give me thoughts, ideas and feedback on how we can lower the bar and reduce the friction of any of this so that you too can help out. Everything is fair game, even “I find the method of arguing for PEPs to cause lower intestinal irritation” (although, I hope to get more constructive comments than that).

Here’s the reason I’m asking/reaching out – I firmly, and totally believe that every single person who uses Python today can become a contributor to the project and ecosystem beyond that of a user. While it is true that philosophically, everyone who uses Python is contributing, I would like to see if we can make it so that even the most “basic” user feels that they can file a bug, submit a patch, fix the documentation, fix/add website content, etc.

Much like I think anyone can, and should be empowered to contribute back to the “Python Project” – I believe the culture of “everyone contributes” is an important one. Citing the wonderful keynote from PyCon 2010 by Antonio Rodriguez (video here), I maintain this is should be a goal for everyone, not just companies – but open source projects as well.

There are lots of things we can change/fix/improve – but before we can do that, we have to be able to identify the “bugs” in what we have now. Do we need a giant flowchart with flashing text (I joke!) or do we need simplified “how do I…” text to the website? Everything’s fair game (except “just put it on github”).

So, do you have any thoughts? If you don’t feel comfortable airing them publicly, you can email comments to jnoller at (gmail.com|python.org) as you see fit. I promise not to share any identifiable information, but I reserve the right to share the feedback you provide, albeit anonymously. I also promise to ask meaningful questions so I can squirrel out more detail if needed.

  • Contributing takes skill and awareness of the value it creates.

    Developing that skill and awareness in people who don't have it requires learning to take place.

    Learning, in turn, requires motivation--of which there were classically two types: the carrot and the stick, opportunity and fear. Dan Pink's book, Drive, explains why this old view of motivation is wrong. Watch this animated video for an entertaining presentation of his point:

    http://comment.rsablogs.org.uk/videos/

    Pink points to our ability to "grow and develop" as the real motivators. Contributing to Python would be easier for more people if it was on a pathway--ideally a well-lit, well-paved pathway with a friendly greeter right at the start--to growing and developing into a better, more successful/skilled person.

    Now I just learned today that BackRub, the precursor to the Google search engine, used Python:

    http://en.wikipedia.org/wiki/History_of_Google

    More people should know that fact. Python can lead to great things!

    I'm trying to use Python in a similar way to give people new capabilities to learn from what others know or have discovered--and I'd like your help.

    Learning, for most people, involves a combination of having things explained and acting on the new information. A "contributing to Python sandbox" might be useful in this regard. Give people a safe place to make mistakes and learn from those mistakes painlessly.

    But I'm hoping to spark the development of something more ambitious: a new style of Skype-like interaction with the computer that would give Python the ability to "explain itself." We can put on a headset and connect a webcam to communicate with one another through the computer, so why not use that same hardware to interact directly with the computer -- instead of (or in addition to) the mouse and keyboard? Give the computer a script (that it can fetch from the web) and let it use text-to-speech to talk, voice recognition to listen and the webcam to watch for and respond to gestures. What you get is an interactive tutor.

    The open source project for this style of interface is called Open Allure DS ( http://openallureds.org or search for Open Allure on PyPI ) and it has a series of short proof-of-concept videos at

    http://bit.ly/openallure

    including the classic Python No Hands.

    You will find prototype Python code at Open Allure from a Python novice with documentation but no tests at this point (I wrote my first Python program less than 6 months ago), but amazingly the current version works well enough on Mac, Windows and Linux to demonstrate the idea. I'm committed to full-time development work on the project for at least the next 12 months--so if you don't look at it now, please look later.

    Bottom line, what I am suggesting is this:
    0/ people need help learning the skills and attitudes required to contribute to Python
    1/ build this new interface so the computer can verbally guide people through learning new things
    2/ create content for the interface which explains all about Python (including how to contribute to it and why that is a good thing to do) and then
    3/ watch as the magic of self-reference works as it did with the viral spread of "Show Source" HTML and the web

    A system that has the ability to self-explain can effectively reproduce and "grow and develop." If Dan Pink is right, such growth and development is not only what we want for Python, but what we are most motivated to seek for ourselves.
  • I don't know of any bugs that bother me, documentation is helpful and easy to find. There is a lot of other stuff out in the world that needs attention and fixing. Python works fine the way it is.
  • This video of the PyCon (2009 I think) talk "How Python is Developed." From my outsider's perspective, this seems like a good intro for anyone wanting to understand the process of contributing to core.

    http://pycon.blip.tv/file/1947394/
  • That's a great link, but I'm personally quite familiar with the process :)
  • Ha! I figured *you* are familiar Jesse. I linked it for the benefit of others like me, who are interested in. Best regards. :-)
  • Ilya
    One idea would be to to relax "5 for 1" idea to "3 for 1" or even "2 for 1"...

    (Finding 5 issues to help with may be quite non-trivial for an inexperienced contributor and many won't even try).

    Also, it might help to describe the "5 for 1" offer in a bit more detail: what qualifies as a review? Is applying someone else patch and testing it sufficient? Is pointing out a bug dup or pointing out a bug side effect sufficient? The problem for me with "5 for 1" is that even though I commented on a few issue (and in some cases my comments seem to have led to the resolution), I don't view my comments as reviews and I don't want to sound like a cheapskate by making a "5 for 1" request.. So clarifying the rules of the game might help.
  • After being using the Python for over a year as a graduate student in an applied sciences field I still have the impression of Python's being designed for computer science(s) people. I feel this way mostly because of the fact the Python ecosystem is a very complex environment. I think the attitude of "Python for computer geeks" should be more and more changed and emphasized to "Python for all." This mentality usually reflects why I don't contribute as much as I could (not directly to Python but I report bugs, suggest features, catch documentation errors, try to add some improvements through scientific Python tools.) Most likely only a few people in my vicinity use Python in their work and this takes away the natural feeling of making widely usable contributions to the ecosystem. Python is not like English/or my native language where everybody around you/me speaks. That's why I have said above that Python should be for all and this state-of-mind should be advertised in every possibility so that contributions go beyond "hacking/geek activity" to a natural state of sharing/improving a common language.
  • I don't follow - what gives you the impression it's only for compsci people?
  • Ilya
    The primary problem as far as I am concerned is that patches often sit in the tracker for many many months at best or many years at worst.,.

    Right now I'm waiting for two of my patches to pdb to get finally accepted/rejected (I already went through 3 rounds of reviews, added test cases, etc)...

    http://bugs.python.org/issue7245 and
    http://bugs.python.org/issue6719


    And, yes, there are a couple of other pdb bugs which I could fix, but probably won't bother until my current patches make it.
  • I personally don't believe in contributing small bits of code to a project.

    I know this is an unpopular opinion in the open source world, but this is the way I believe in.

    My approach is to devote a lot of effort to a very small number of projects, in contrast to devoting a little effort to a big number of projects.

    I think that this approach is superior, especially in the world of software where having one excellent project is better than having 3 good projects. (Generally speaking.)

    But of course, this approach might not suit everybody.
  • sdeibel
    Usually it's "If it ain't broke don't fix it". I've run into maybe 3-4 bugs I felt I needed to patch or report (and I did) in more than 10 years of intensive daily full time use of Python. Dunno, maybe I just write boring code.
  • optilude
    I've written a bit about similar things in the Plone community:

    http://www.martinaspeli.net/articles/the-dog-ate-my-contributor-agreement

    and, somewhat related:

    http://www.martinaspeli.net/articles/oh-how-we-love-to-hate-plone

    I think ultimately, contribution comes down to leadership. When you have people in the community who make sure that community is welcoming, people are more likely to emotionally commit to contributing. If those same people then support, mentor and encourage (rather than hand-wave, slap down and belittle) contributions, contributors are made.

    So, perhaps, it's less about what stops people contributing, and more about what's lacking in terms of support infrastructure to turn potential contributors into committed community members.
  • Anonymous
    Make the docs like a Wiki, except changes are queued for review instead of immediately applied. Make it one click from python.org, and allow anonymous access. If that works, do the same for the source.
  • Anonymous
    Put buttons on python.org for "Improve the docs" and "Fix the code".
  • Just two weeks ago I wrote a post called "Contributing to Python", covering the process of submitting a first patch. I think this is a terrific topic to discuss in order to strengthen the community, and I wrote a whole post as an answer, check it out.
  • Simon Cross
    Coders from my local PUG have been involved in various Python sprints we've all felt
    the contributing-to-Python pain. Mostly the trouble is that getting anything into Python core requires a fair amount of effort and that effort is often drawn out over many months.

    One of us started http://www.ctpug.org.za/wiki/CTPUGBugs just to keep track of which issues we've worked on are still open. Some of those issues are years old. I've recently seen a patch submitted by an ex-colleague finally get applied -- I think the original patch was submitted almost four years ago.

    My best suggestion is for Python to adopt a leiutenants (sp?) system similar to that used by the kernel. There need to be a few people dedicated to funnelling in other people's patches. The switch from Subversion to Mercurial (when it eventually happens) will probably make it easier but what we really need is to have two or three people paid to work on Python full time (at the moment we have half a Guido).
  • I have two comments: one general and one very specific. The general one is a perception that, if I contribute a patch or a bug report, it will sit there in the issue tracker for a long time until someday maybe someone will get around to fixing the bug or applying my patch (even if I strictly follow the rules for contributing). The problem definitely applies to any open-source project and not just Python, and it may be not that bad for Python right now (haven't checked), but the perception is still there.

    The specific comment comes from my participation in the Unladen Swallow sprint during this year's PyCon. I got a few things done, accepted and checked in, but at least two thirds of comments I got when I first sent my changes for review were related to spacing, indentation and line lengths. I had to spend quite a lot of time fixing the issues - and shoehorning code into 80-character lines, 48 of which are already used up by 8-space indents, is completely opposite to my idea of fun. Especially given that at work I don't have to spend any time at all thinking about code formatting - the line length limit is much less strict, and my IDE takes care of almost all the formatting for me automatically. I don't know what's the right solution for that, but the problem definitely exists for me. I understand why the rules are there, but I'd much rather work on something else where complying with rules wouldn't take that much effort.
  • Xie
    There are at least two kind of potential contributers:

    1. Normally they have a job and are working on some project using Python. They find python not satisfying in production and want something more. And they don't want to maintain their own fork.
    2. Normally they are students and they are looking for projects to contribute. Maybe they just want to kill time or maybe they are looking for challenge, cool stuff and a sense of achievement from contributing.

    For the first kind of people, there are already many good suggestions to make contributing easier. For the second kind of people, they need more guidance. Google Summer of Code is great, but why wait for summer? How about something like that every season for student(or everyone)?
  • Xie
    There are at least two kind of potential contributers:

    1. Normally they have a job and are working on some project using Python. They find python not satisfying in production and want something more. And they don't want to maintain their own fork.
    2. Normally they are students and they are looking for projects to contribute. Maybe they just want to kill time or maybe they are looking for challenge, cool stuff and a sense of achievement from contributing.

    For the first kind of people, there are already many good suggestions to make contributing easier. For the second kind of people, they need more guidance. Google Summer of Code is great, but why wait for summer? How about something like that every season for student(or everyone)?
  • .
    I do not contribute because Python is perfect and created by God. It is heresy to suggest it needs to be improved.
  • dbenamy
    My suggestion: Add a prominent "Help Improve Python" link on the home page.

    It should have intro text about how valuable contributions are, even small ones, although maybe with a disclaimer that changes can't always be accepted.

    It should have a section for each type of contribution each containing a screencast/tutorial showing how to contribute, text quick start guide, and links to relevant resources. For example the code video should show finding a simple bug, installing svn (or tortoise), checking out the code, fixing it, adding a test, submitting a patch...

    (I haven't read most of the comments so sorry if this has been talked about.)
  • Because I have to sign up for yet another account on Python's bugtracker.
    (Incidentally, I could use my Twitter or OpenID on this site.)
  • You can use OpenID in the Python bug tracker.
  • MW
    For me, I believe a lot of the resistance to commit to any open-source project is two-fold:

    1) The resistance of doing anything differently. "What we have is good enough", "You're new here, don't think you know better than the rest of us" or similar sentiments usually shuts down most of the initial enthusiasm and ideas coming from a new person.

    2) There's a long road to actually feel like you're belonging to the project. This might be because of the distributed nature of open source projects, but what I usually see is a tight group of people working well at the top, but for people just getting involved, it's usually all about sitting at home working alone at some patch, documentation change or whatever.

    On top of that, I would personally be more interested in a project that has a particular goal. I'd much prefer to work in a small group of people wanting to create the best documentation set that is available for any project, for instance, defining what that means, figuring out a plan to get there, and so forth, rather than just "we need people who do stuff. You don't have to have any skills whatsoever. Promise!" I don't know about you, but if someone was advertising an open job position like that, I'm pretty sure I wouldn't apply. Maybe creating task groups and "recruiting" for these specific tasks is a better approach for finding people?
  • Jason Whitlark
    I wonder if something like Ubuntu's "Quickly" project would be helpful for python. I've got the dev experience to fix bugs or whatever, but I have enough of setting up environments at work. If I could type: quickly fix_python_bug, and get a test version to work against, with the various commands, I'd be much more likely to do so.
  • I'm one of those who believe that submitting bug reports and proposing documentation enhancements should be as easy as possible. Needing to register an account is always an extra step and it would be great if it was possible to use some existing account instead. I loved how I could register using my Twitter account to submit this comment!

    For documentation it would be awesome to have system to add comments to every paragraph similarly as in e.g. in Hg Book <http: hgbook.red-bean.com="" preface.html="" read="">. Someone could periodically go through the comments and enhance documentation accordingly, but even the raw comments would help others looking for information.</http:>
  • You can already use OpenID in the bug tracker. We may experiment with allowing new bug reports to be made without an account and see how much spam we get or extra effort it is to monitor.
  • Cool, I didn't know that. Now that I checked also Google and Launchpad accounts seem to be supported. I'm pretty sure this wasn't the case when I last submitted an issue, but that was quite long time ago. As others have commented, things mostly work for a "normal" Python user.

    For smallish documentation enhancements I consider the tracker overkill anyway, and would love to see a possibility to comment the actual documentation.
  • Bug reports without the identity of the submitter are worthless, so we should at least require an email address.
  • If the bug is real and reproducible why is a report without an identity worthless? Better than no report at all, surely.
  • Sure, if it's reproducible. My experience has been if there's no effort to even provide an identity then the bug report isn't complete enough to be helpful.
  • Here are the hurdles for contributing to the main python.org website.

    Suppose "someone" did decide they wanted to help python.org by supplying a patch, this is roughly the set of steps they would have to go through:

    Go to http://python.org
    Click on "Help maintain the website" in the left sidebar: http://www.python.org/about/website/
    Click on website maintenance: http://www.python.org/dev/pydotorg/website [1]

    The instructions here are on how to checkout the repository from the command line with the svn tool. ( Please note that this repository contains several hundred megabytes.) This takes a looooooong time. :-( By default this gives you a directory called "beta.python.org". You then open a file build/README with instructions.

    The first step is to install the build system dependencies: mako, pyyaml, and docutils.

    The next step is running make, which if you are on Windows requires first installing Cygwin - another lengthy procedure.

    To actually make changes you need to know / learn ReStructured Text, a custom markup from pyramid and possibly yaml.

    If you don't have checkin rights you'll need to generate a patch (assuming you know how) - and then there is nowhere to post it (no issue tracker for the website), other than perhaps emailing it to webmaster@python.org.

    Anyone who doesn't think this constitutes a "high barrier to entry" is nuts (tm).
  • Jason
    I gotta say more than anything is the fact that a.) technical people don't want to help in non-technical ways (personal interest issue) and b.) to help with code requires learning the Python codebase, which could take even experienced hackers weeks. Whether this perception is reality or not, I believe it plays a large part in deterring would-be, could-be contributors (like me).
  • Casey Duncan
    Ok, so here's an example of me not contributing, when it seems like I should have. We use urlparse with lots of apache logs at work (and by lots I mean more than I care to count). The log processor was becoming too slow a few months ago so I profiled it. urlparse was one of the things that floated to the top as a bottleneck. I looked at the stdlib implementation, which is pure python, and didn't see any obvious way to make it significantly faster in Python. So, I rewrote it in C. The new version is about 15x faster, and though it isn't quite as general as the stdlib version, it could be improved to be with a bit more effort.

    I was immediately going to blog about it, but I didn't because its unit tests were tangled up in the larger project and I felt like it needed to be packaged better. Spewing C code on my blog didn't seem that helpful to folks without an easy way to install it.

    I thought about filing a patch, but I didn't. Because, this was done for Python 2.4, and this api moved to a different stdlib module and it has no C code already iirc. And I hadn't even breathed the words "Python 3" at that point. I figured this would need to be done for Py 3 anyhow.

    In my mind I saw two possible approaches to contribute this: Bring it up first on python-dev to see if it was generally considered valuable, or make a patch and put it in the tracker. I suspected the former would just lead to a request to do the latter, with requisite bikeshedding. I suspected the latter would lead nowhere, perhaps incorrectly, but the thought of going to all that work for nothing when I had other things to do with my time that was more interesting, made me lose all interest in contributing it. There was no technological reasoning here, I'm confortable with all of the tools, and writing tests and docs. I felt like the contribution was not good enough for me to spend my time pushing thought the system.

    And more generally I don't feel like there is a contribution I am ever going to come up with that will compel me to push it through. OTOH, releasing a library for Python has a much lower bar, so I am doing that. Then I can focus my attention on the problem, not the process. I fear that "improving" the stdlib is a lot like "reforming" the government. The grueling process makes it a worthwhile project for very few folks. The stdlib is not a meritocracy, and in many ways its where once good code goes to die. There is no technical reason for me to not dive in there and start helping, but the thought of the process drives all of my energy away.
  • ThomasWeigel
    Here are the hurdles to submit a single bug:

    0. Break yourself out of whatever project you were coding for.

    1. Find out where to go. (http://bugs.python.org) You will usually find this out from http://docs.python.org/bugs.html, which exhorts you to do research prior to submitting a bug: you know, make sure that it hasn't already been reported, make sure a fix isn't already in the pipeline in /dev, all the usual rigamarole that takes up your time. It also recommends reading up on best practices for submitting bugs, rather than getting back to work.

    2. So I try to bug search tool. My first few tries turn up all KINDS of crap, most of it completely unrelated. Why, oh why, did I have to find a bug in a two-letter-name module? I gamely fight through.

    3. I see a few that *might* be relevant. I open those links. On a casual read, I have NO IDEA if these are related or not. They might be? But they're big and nasty and long conversations about the module. And example: http://bugs.python.org/issue2636

    4. Then I realize I'm going to have to *register*, too, before I can even submit a bug report. I haven't even gotten to the bug report form yet (which at this point I am certain will be long and intimidating and involve choosing which portion of the inner Python parser it affects), and I'm already feeling put upon.

    5. Think to myself, "You know, maybe it's just a documentation error. It doesn't do what it says, but it might do what it was supposed to. The documentation in Python is a lot less intimidating than this, too."

    6. So I go to http://docs.python.org/documenting/index.html and see what's involved for just fixing a little... crap.

    There's a small book outline of what will be covered, a template language to learn, a style guide... Thankfully, it also says "If you’re interested in contributing to Python’s documentation, there’s no need to write reStructuredText if you’re not so inclined; plain text contributions are more than welcome as well." and "Please don’t let the material in this document stand between the documentation and your desire to help out!"

    7. Decide I'm going to just send in plain text. Look for the person I should send a plain text explanation of the documentation issue. No contacts are listed. No submission forms are provided.

    8. Check the FAQ. Nothing there, either.

    9. Realize that I am simply not man enough to submit a bug report *or* documentation correction to Python.
  • Thank you. This is good information.
  • I haven't ran into enough problems that needed fixing tbh. Most of the stuff I use python for works beautifully already (thanks to the community)
  • Jason
    When I run into a bug, I file it. Other than that, I don't contribute because of legal reasons. I am employed by a software company that makes development tools, so anything that I contribute would be in a legal gray-area at best. I could probably get permission to work on something orthogonal to what my employer does, but I'll admit I'm to lazy to go through that process when there are other open source projects that are so different that it is unnecessary.
  • I've filed a few bugs and commented here and there and whatnot, but I've not just dove in. I try to answer questions where I can (blogs, c.l.py, etc) as I actually enjoy that quite a bit and it's something that can be done in 15 minutes without a solid time commitment.

    I also did some volunteer work as a local for PyCon. That was wonderful as I was able to use Python as a way to learn about an area I had no knowledge of -- conference planning & all that goes into it.

    Quite honestly, there are a couple reasons I haven't done anything on a large scale from a code perspective.

    1. I feel as though the chance that I'll come into a bug or an improvement that needs to be included in (or fixed within) Python is closer to 0 than to 1. I, like most Python programmers I would assume, am not doing anything out of the ordinary that would trigger edge-case explosions. This requires me going out of my way to find something to fix and or address with the sole purpose of helping the community. This is great and I'd love to do this, but time gets in the way.

    2. Assuming I'm feeling largely helpful one day, where do I pull projects and fixes as detailed above? I generally resort to thinks marked as "easy" within the bug tracker as that equates to "quick." Though that's probably hit and miss, no? Of course, I don't expect a trickle of work fed to me with a spoon.

    The old PyBots project that Grig ran was great. It let me help out a bit, but I didn't have to spend a lot of time churning through bugs and implementing fixes and whatnot. I generally had to poke a BuildBot instance every couple of weeks when someone would reboot a server on me.

    There are a few areas that I've had ideas on, just haven't up and started.

    1. Documentation tends to be trivialized as a task for those that cannot program. I don't agree. Being able to convey knowledge to other users in a meaningful manner is a skill that not everyone has. Additionally, it requires a sound knowledge of the technology. How can you document it if you don't understand it on the whole? I'd love to write some stuff up on best practices for beginners. Most docs cover lists, dicts, and so on. But how does the newbie get into eggs, distribute, virtualenv, and so on? Why would they want to?

    2. From my point of view, the 2.x->3.x porting efforts have been lackluster. Go sort by version on the Cheese Shop. This is one area where I've always thought a solid effort would be appreciated and give aspiring Van Rossums a way to actually contribute real code back (while learning 3.0 at the same time). I'd love to see some global porting resource that keeps track of what's there, what needs help, and so on. I don't have the time to port EsotericProject-1.0r6172, but I have the time to help four other guys that volunteered update it.

    3. A "stable branch" Egg repository that's tested by a team of users before elements are added. Want to avoid version conflict hell. RHEL vs. Fedora, if you will.

    Of course, none of this is code-slinging-fujitsu, but it's all stuff that helps the community as a whole that most don't seem to be interested in.

    So, I guess I'm saying time. If I can find small, discrete tasks, I'll jump on them, though. In the interim, I've got a head full of ideas that I've not been able to crank out.

    Getting into the core development of anything is a huge undertaking. It's a second full-time job in a way. Consider the work required of multiprocessing. None of that stuff is trivial. Unfortunately, my desire to be part of the core community is trumped only by the fact that there's 24 hours in a day.
  • I think others have mentioned this frequently, but getting a patch through the tracker is a very slow, bureaucratic process. The expectation that the person providing the patch also provide test cases (where applicable), adheres 100% to PEP8, and writes it "perfectly" just as the committer would, is very intimidating. From a potential contributor's standpoint, there are a lot of other things we'd rather be doing (like contributing to infinitely more agile third party modules).

    On a documentation note, I wouldn't mind helping, but there is no clear place to start. The idea of some kind of orientation community would be great, with some examples on how to get started. Maybe walking through some basic fixes that happened in the past as introductory steps to contributing would be helpful. A contributor's tutorial of sorts.

    It's a whole different topic for discussion, but the "batteries included" approach causes a lot of bureaucratic poop we're talking about here, since there's so much under one umbrella. It requires a lot of core developers to maintain the language *AND* the library, so it gets to be pretty complicated to get things through the process. There's no clear go-to person in many cases.

    In summation, the biggest thing I have to suggest is an orientation site/community/tutorial that walks a potential documentation writer, python developer, or <insert here="" something=""> through a past patching/commit process, explaining what happened step-by-step, and providing some really simple real-world examples. </insert>
  • Skip Montanaro
    The requirement for "completeness" can be a high hurdle, but it's really required to improve the quality of the finished product.
  • Neil Muller
    While completeness is a good goal to strive for, combined with the often quite slow response from people in a position to comment on the patch, the process of evolving a patch to a point where it is acceptable ends up being extremely tedious. and the several hundred bugs tagged patch in the python bug tracker that haven't seen any activity for more than 6 months suggests that this is a serious problem with the current process.

    There are also a number of patches which have also stalled at stages where they look reasonable for no clear reason, and there's no obvious process for getting them unstalled (a trivial example is http://bugs.python.org/issue5610 ).
  • The current problem with requiring high quality patches is that too often the author of a patch receives comments too long after having posting the patch. By that time, the author has likely moved on to other things and is unlikely to invest additional time into it.

    My story: I have contributed, a bit, mainly to IDLE. Many of my patches weren't accepted, mostly because nobody bothered to review them or because they were reviewed and commented on several months after my posting them. Some, admittedly, weren't fit to be accepted, but having the discussion span months is horrible. After having put many hours of work into many patches, only to have a handful of them accepted over several *years*, I simply forked IDLE and haven't bothered with any patches lately.

    Today, if I had an idea for Python (something other than IDLE) I wouldn't bother with it unless I got significant backing from python-dev in advance; otherwise it wouldn't be worth the bother.

    I will note that I have posted one or two bug reports and have helped figure out a few posted by others, and in these cases things were usually moved forward in a matter of days. It's submitting patches for feature requests which I am avoiding.
  • I understand your frustration. We simply don't have an active maintainer for IDLE. :-(
  • apreche
    Two reasons.

    Reason number one is that I almost never modify anyone else's code. I just import other people's modules, and they work for me. I hardly ever run into bugs or problems. When I do, I work around them in my own code rather than patching some unknown code base.

    Why don't I patch the unknown code base? Many reasons. Sometimes the patch is already in the dev version, but I want to run the stable version. I don't want to have to start tracking someone else's code. I need the foundation under my own code to be stable. Also, I'm involved in enough communities. I don't want to make the huge investment of being involved in another one in order to change someone else's code that I don't care about.

    And that brings me to the second reason I don't contribute, and that is it is too much work. Let's say I do make a patch to some module I'm using. Everything is working on my end. Unless someone comes to take the patch from me, I have to do work to get it contributed.

    At the very least I have to send it to someone, probably by e-mail. Ok, I can deal with that. But most of the time that isn't nearly enough. I have to talk to people. Even if they are nice and love my patch, which is so rare as to be effectively 0% chance, I have to do more work on it. I have to write documentation and test cases an then possibly argue with somebody. Why? To make a change to code other people are using that I don't care about? Sorry, not worth my time.

    If you want more people to contribute, you have to make contribution the path of least resistance. Here is how you do it.

    First you have me, Mr. Lazy. I'm writing some Python, and I put my code on Github. I'm not in any communities, I don't talk to anyone, I'm just merrily coding my own stuff. You want my changes integrated? Here's what you do. First, come to Github and take them from me. There out there for the taking, so feel free. Next, you take care of test cases and documentation and all that stuff that I am not going to do. When you've got my patch all integrated, send me a thank you note. I'll feel pretty damn swell if I find out that people thought my code was so great they integrated it into their own project. Maybe it will make me feel good enough to want to help you out later and maybe stop being quite as lazy.

    Contribution must be the path of least resistance. Remove all road blocks.
  • Thank you for at least being honest. However, I think your final line "Contribution must be the path of least resistance. Remove all road blocks." is disingenuous when viewed in the context of the rest of your comment, which, in summary is "I just want to use your code, I don't care if it's improved (by me)".

    Don't worry - I'm not using that summary above pejoratively - that's how I am for some projects to be completely honest. However I will use that summary to counter your last line. Stating that the project owner(s), which, in this case, comprise around 150 developers, give or take, should find your patch (when they don't even know you use it) and pull it it, and thank you for it doesn't remove work except from you, it significantly increases the amount of work performed by those 150 developers.

    There has to be a way to convince you to at very least, file a bug with that patch. Even if you move on immediately, and never look at it again, you've contributed in some small way to the code you use. Heck, skip the patch - if you find a bug - even if you don't patch it, how could I/we convince you to at least file it?
  • apreche
    The only time I will file a bug usually is if I have no other choice. For example, I had a bug in cmemcached. I didn't file a bug, I just switched to python-memcached. If cmemcached were the only option, and I needed it to work, then I would have started to investigate patching it or filing a bug.

    If I do end up filing a bug, if you want me to keep filing them, all I need is to feel loved. Not really, but I do need to feel that my ticket is getting attention, and that someone else cares, and that effort I put into it will not be in vain.

    Take for example this bug I filed in Ubuntu in 2008.

    https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/227808

    I never forget this bug because I get e-mail notifications from it every few months when someone finds it on Google after experiencing the same problem. The fact that it got its priority set to low, nobody seems to be fixing it, and no one who is an authority at the project seems to notice or care has resulted in me not filing too many more Ubuntu bugs. It's a waste of my time if nothing is going to happen.

    I need to get my work done, and soon. I can't really have other people standing in my way or slowing me down. Patching and filing bugs is a path of last resort when all alternative solutions have been exhausted.
  • Lots of people (myself included) blog about how to get work done *with* Python, but I can't recall ever seeing a blog post about how to get work done *on* Python. So unless a post like this comes up on the planet or something, the notion of contributing just flies under the radar. There should be some videos posted like "Watch me file a bug in the issue tracker" and "Watch me make a new document on docs.python.org". If you can do either of these videos and use real life scenarios rather than example use cases, and displayed them prominently, and talked about them on blogs, podcasts, etc., and kept them updated as those processes changed, I'd be willing to bet it would help. Just because we're all developers here doesn't mean it's ok if things are hard. In the context of the larger "Python Core" world, we're all just end users.

    I contribute around the fringes in places where I feel my skill set is of best use with the least overhead in terms of time/commitment on my part. This basically means I help people on stackoverflow, irc, and wherever else I find people having issues, and I write documentation.

    The documentation I write is on my blog or in articles, not for docs.python.org, because when I looked into how that's done, the process seemed much more cumbersome, and required more time and commitment, than writing anywhere else. This is kind of a shame, because I'm kind of a documentation freak, and I have lots of issues with docs.python.org I'd love to have a hand in addressing.

    I don't file bugs. If filing bugs were easier (or someone changed my perception about it being hard), I might file bugs. As it stands, if I come across bugginess in a built-in module, I get a 3d-party module or write something myself. "Bug filing is hard" probably sounds like a cop-out, but if I have a deadline 3 days out and come across a bug, what's going to help me more, finding a way to work around it, or spending 3 hours figuring out how to use the issue tracker and then praying someone gets back to me while I still even remember the bug existed?

    The issues that keep me from contributing might all be perception-based: I view contributing to Python in *any* way to be clumsy and cumbersome. I already have more than a full time job, and although I'd love to contribute, it's not going to happen if I have to spend yet more time to do something that is simple in almost any other venue I've worked within. So... not only do I view it as cumbersome, but unnecessarily so, which is a turnoff that makes me less likely to look into contributing in the future.

    If I could find a way to get on a roll with documentation without spending a week of my life scratching my head, I'd do it in an instant.
  • travisbradshaw
    The most prominent reason that I don't contribute to Python is that I'm not particularly interested in language development. I love Python, I'm passionate about software development, and I'm extremely happy to have been able to make my career as a Python developer.

    But the problems I enjoy solving aren't those core to the language. I just love using the language to solve problems in other scopes.
  • Actually, I'm with you - I don't really care about the development of the syntax, but the standard library holds my interest like no other. If you consider that "python" is a language + the batteries, does contributing to the batteries interest you, or is that "just language" in your mind?
  • travisbradshaw
    No, I agree with you that the standard library has great potential. I also understand particularly how your work with multiprocessing, for instance, would be very rewarding.

    However, when considering the standard library in general, I think of this quote from Tarek Zaide shaped my thinking:

    > I had a twenty minutes meeting with Guido after the Summit to clarify the situation and he helped me understand why this was the right path and worked with me on what to do next in the stdlib front and outside the stdlib.
    >
    > Basically, a package that comes in the standard library has a foot in the grave (I am paraphrasing Guido here.). Its APIs is frozen, and people don’t really expect nothing from it, but small new features and bug fixes. Refactorings are dangerous, if not impossible.
    >

    APIs and refactoring are some of my very favorite development activities. I often take an equal joy in the elegant API and intuitive use cases than I would in any particular implementation. Optimization and refactors that make code more clear, smaller and remove anomalous/inconsistant behaviors are very fun.

    This just doesn't seem like the type of work that the standard library offers. My typical process involves using the standard library whenever possible. But when it's not possible, I quickly go to alternative libraries. When there's not a solution, my first consideration is to contribute to one of the alternative libraries, not consider a fix in the standard library.

    As another example as to why I'm not cut out for standard library work... if I "ruled the world," all standard libraries in Python 3.0 would have been PEP8 compliant. Not as pragmatic as the chosen solution, and I respect the chosen solution as more wise than myself, but I still wish it would have happened. :)
  • Though I'm only a marginal Python hacker and thus consider it unlikely that I could contribute at this point in my development to the code base, I've continued to be interested in things like outreach, particular improving the Python web site.

    The current Python website continues to be a terrible first stop for new-to-Python visitors, despite this very issue being discussed at length at recent PyCons. Compared to the excellent Git and Ruby sites, for instance, it's really second rate from a design, navigation and identity perspective.

    However I haven't pursued contributing to the site. Here's why:

    1. Contribute to the website options on Python.org seem limited to "bug fixes". The "SiteImprovements" page is a mess. The whole site design and identity is a bug, unfortunately.

    2. The stagnant design (only a marginal improvement over the previous iteration) implies that there is either a serious design-by-committee problem when it comes to the site or a serious lack of good-design-sense from whomever is actually running it.

    I'm not trying to be a grouch about this, but the site needs strong direction in terms of visual identity, navigation, presentation, etc., not just incremental fixes.

    I'll put my time/money where my mouth is on this. If there really is a chance to radically improve the site and contribute, I'm there. Point me in the right direction. If there is a roadblocker committee issue that needs to be sorted first.
  • This is something I've suggested before as well. If I had much html skill, I'd have offered to help. But as it turned out, everyone agreed that the site needed to be changed, but nothing ended up happening.
  • I'm not surprised that nothing happened, though it's unfortunate. I am not a big believer in site design by committee or community. I *am* a big believer in site *contribution* by community. Unfortunately, the two are often conflated and as a result nothing is achieved.

    For what it's worth, I would recommend that the initial goals of a python.org redesign should be:

    * Identify who the decision makers are on the project. Establish how the community is involved and to what degree. Ensure that decisions can in fact be made and that the process is designed so that good design is achievable.

    * Quickly establish a site redesign process/plan that has clearly achievable goals, deliverables and deadlines.


    Ideally, the redesign process would include:

    * Developing a fresh, comprehensive visual and design identity that encompasses, but potentially extends beyond, the website (i.e. should be adaptable to both the website and non web materials).

    * Clarify the site audience, intent, content (current and optimal), and from this redevelop the site architecture.
  • I'm going to put you contact with someone leading a project working towards a redesign of the site. Do you mind if I use your email (which I can get from the comment submission)?
  • Jesse, that's great, thanks. My public vCard is also available at http://ethanschoonover.com/card with full contact details.
  • As I mentioned on HN; I completely agree with you, and this is part of something I'm driving towards.
  • I've dealt with design inertia in massive site redesigns for Fortune 500 companies, but I suspect nothing beats the resistance-to-change of an open source design committee.

    If the first step is selling in the idea, I'm happy to contribute to that dialog as well.
  • Gigi
    Have a way to quickly file a bug report. Without having to register, without requiring email or name.

    I have found bugs in many pieces of software I use, but having to create a bugzilla/launchpad/sf account makes me give up reporting them.

    I will create an account if the bug affects me and I want it fixed. But I won't otherwise. Yes, maybe it would have been nice of me to take the time. But this thing happens like it or not.

    My suggestion: have a place on python.org with a text box in which you can put a bug, with optional name/email.

    Of course, somebody at python.org (maybe another volunteer you seek now to find?) will have to triage these bug reports and introduce them in the real Python bug tracker (perhaps even summarily investigating it).
  • Skip Montanaro
    Sending mail to bugs@python.org should work. Does it not?
  • I do contribute to Python. I just don't contribute to the Python project itself. If I just release the stuff I want to use as a library, then I get my own little island where I can make whatever software is useful to me and not have to quibble with other people or deal with bikeshed arguments on the mailing list somewhere.
  • And like I mentioned in the post; using it, and releasing libraries is great, and is contribution. But what would it take you to contribute to the core project? Even as something as simple as documentation. You cite bike shedding; is it just that you don't want to deal with that aspect?
  • I think it would take something to make it a lot less scary, and I'm not sure that's something that's possible. As Guido's mentioned in an interview, the programming language is at the very bottom of the technology stack. There are a *lot* of people that have a vested interest in Python and therefore they may not take changes lightly. I just don't have the kind of personality that can deal with a large environment like that.

    I might be more easily persuaded to help out if python were an organization of smaller groups with individual leaders given authority to make decisions. For instance, I may not want to deal with trying to have meaningful contributions for python-dev as a whole, but I may be more easily persuaded to help out in the context of say a multiprocessing group or a documentation group.

    And lastly, when is Python going to finish the move to Mercurial? I'd be infinitely more likely to contribute even if for no other reason than not having to deal with SVN. :-)
  • Well, if you want to be part of a multiprocessing group - Just say it, and we can start it right now (oh god I need the help) :)

    But I definitely see what you're saying. The lieutenant model is something I've thought about bringing up.
  • Good documentation isn't "simple".
  • Lots of good documentation isn't simple, but when I state simple in this context, I mean that it's a lower barrier/less conflict method of contributing then getting language or library features in. So, I don't mean to diminish the value.
  • lars
    from: http://www.python.org/dev/patches/
    "If you don't know how to generate context diffs, you're probably not qualified to produce high-quality patches anyway"

    Insulting people is not a good way to encourage participation.
  • I *completely* agree. This is going high up on my list - it's been so long since I read that doc, I never had the itch to fix it.
  • Mike
    This is a tough post. Why would people respond to this post if they already don't contribute to Python. However, I for one.. do not contribute. After thinking about it for a while, and thinking about other projects where I have opened a bug, or posted comments about a feature and realize this is why.

    Starting with Ubuntu: I opened bugs, and regularly read up on the forums, post on OMG Ubuntu about my opinion or help others solve problems in the forums, blogs, IRC, etc. Why do I do this? Because it's convenient! -- This is the big smoking gun for me. My original reason to goto the Ubuntu forums, talk on IRC, isn't because I *want* to help. Its because I am already there, looking up issues myself and get distracted.

    Ubuntu built a community that is both easy to join, and rewarding in nature because there are people asking questions across the whole spectrum of noobs -> experts. I might be on the forum looking for a bug or a new game, and then get distracted and decide to look at issues people have. If I notice something unanswered and I know the answer, I'll always respond.

    I never once went to the Python website to browse around. I go, click "Download" and moveon with my life. If I have an issue in Python, my immediate response is "Search Google". If the result is a Python.org website, it is never interactive. Generally I'll land on a docs page, or a PEP page, read my information and move on. I didn't ever look to file a bug report because my knowledge of the Python website is minimal, I never even knew bugs were there. Of course tho, I would never file a bug report, because I don't have an account. I won't create an account because it doesn't benefit me (There are no forums or anything else I get out of it).

    I love Ubuntu's Idea system they have. Post an idea, and people upvote / downvote on it. A quick, easy way to get more people involved.

    I guess for me, it comes down to reward and simplicity.
  • erichheine
    Seriously, ubuntu forums turn out to have piles of answer to my questions on a regular basis. Yet I don't use ubuntu... Perhaps forums.python.org would be a good idea.
  • reidkleckner
    I would also say that, I do plan to contribute! I want to solve the problems I mentioned previously about not having enough core developers going over bug reports. I'd like to help solve that problem. Hopefully I can do that in my free time this summer, because I will be working an internship instead of being a student whose responsibilities extend late into the night.
  • reidkleckner
    My personal perception is that the core developers of Python are all volunteers, and while this has it's positive sides, it means that developers frequently have to excuse themselves from doing things because they are too busy with the rest of their lives. I wish there existed a part of the core development team that was paid to work full time on reviewing patches, triaging bug reports, and making incremental improvements like the new GIL/scheduler. It seems like many people are paid to work part time on improving CPython, but they all work on different pieces at different times. Issues are triaged whenever a developer feels generous or needs his own code reviewed instead of as soon as they come in.

    I may be wrong, but that's my perception.
  • I wish there were developers paid to work on Python too, but whilst we're wishing maybe we should go for a unicorn instead... Bug triage is pretty good these days by the way - we have a good bunch of volunteers who are pretty quick to pounce on new bugs.
  • +1. I would love to contribute but I can barely poop without getting behind at work. Plus there are python projects that need to be maintained as well (what good is the snake without the batteries?). In my little spare time, I prefer to spend time contributing to python packages instead of core python. My perception as a developer/user of packages, true or not, is that those are what really need help. So maybe then it becomes a question of motivation - why would I take my free time to contribute to python instead of a package which has a more immediate impact on my day to day?
  • But then again; you probably use the standard library. I would argue, to an extent, that the standard library code, docs and tests probably need a lot of help. I can not disagree that helping third party libraries helps *everyone* as well, but what would help trigger you to contribute to core?
  • I look at the problem as related to management, rather than technology or documentation. No amount of documentation can take the place of a helpful person.

    The process isn't hugely complicated, but there are some vague areas where someone new is prone to stumble. For example, I have commit access, but do I need to have my changes reviewed before I commit to trunk, or will that happen after? What if I just want someone to sanity check the work? And which of the various branches do I need to merge a given change into? Georg helped me get going with a few minor doc changes a while back, and having him verify my answers to my questions gave me more confidence.

    We see more contributions from newcomers at & after the PyCon sprints because there are people on hand to help walk the contributor through their first few commits. If we want to increase the contributor base, someone has to be prepared to manage the integration of the new contributors on an ongoing basis. Anyone familiar with the process could do that work, even if their coding or writing skills weren't strong enough that they were contributing as much to the actual source.

    I suggest designating a small group of developers who are available for quick turn-around answers to questions from contributors (new, old, irregular, whatever). They would make up a sort of combination support team and welcome wagon. Over time, some of those new people may join the support team and let the initial crew move back over to just doing development work.

    Having every new contributor go straight to python-dev with questions isn't realistic, because there are too many people on the list without time and that results in brusque answers, a big turn-off if you're new to a group. The last time I asked to have a patch reviewed, the response was "first you have to go review 5 of ours". Huh? If I'm new, why do you care what I have to say about someone else's patch? If the existing group is too busy to review more submissions from new contributors, stop asking us to contribute. :-)
  • I agree very strongly with this. I have contributed to Python core once (submitted and had accepted a patch for http://bugs.python.org/issue6300). However, since I've not personally stubbed my toes on any bugs, I don't have any clear idea of what I "should" work on. Having a mentor to give me a bit of direction would help immensely.
  • One of the things that the Rails Bridge community has been doing is something they call BugMashes. The idea is to get a bunch of folks of all skills levels to be 'on-line' at the same time. Having live help and guidance seems to have worked pretty well for them. They don't wait for a conference or a convention to do a sprint, they have them on a fairly regular basis. (That's all I know about the details, having not participated).
  • We've had Python bug days before and they've been pretty effective. We should do it again. (Mainly coordinated over IRC.)
  • PHP dev here, but used Python (and want to use it even more).

    Similar thing for the Zend Framework - once in a month, for 2 days, there's a ZF Bug Hunt Days event thingy. There are even prizes for the top 3 contributors, altho no one is chasing those, all we want to do is close 'em bugs :)
    During those 2 days everyone is up on IRC, core devs are there so we contributors can "molest" them with our questions, to ask them to review patches and so on. So far I "attended" 2 of these events (out of 5 or 6 - the timing is real bad, always on Thursday and Friday, weekend would be better for me, but, well... Someone do have a life and family xD), with 3-4 patches so far. I feel like I gave back and the devs thanked me for that. When I don't have the time to participate, at least I try to retweet it on twitter to spread the word - maybe someone else can join.

    Maybe a similar event could be organized for Python? Prizes or not, it's much more fun to contribute when there's 10-20 or even more people out there at the same time doing the same thing - it's more friendly. Personally, I would find 30 minutes, one hour, at least to fix a typo in the docs or to provide more info on a bug that some random guy left. Don't have money for prizes? Give a "I contributed to Python" badge after the first accepted patch to put on my blog - I'd be back with more patches.

    Contributing with random ideas :)

    HTH :)

    P.S.: The points like "I ain't contributing cause I need to register" are, for me at least, not valid. For contributing to ZF, I had to register and to sign a Contributor License Agreement - print out an A4 paper, sign it by hand, scan it, email it, wait for approval. But a simple "thanks for the patch" from devs I respect was well worth it.
  • RonnyPfannschmidt
    every complete mess i find/want fixed is completely ignore, repeatedly

    the result being me still using many 3rd party libs just cause the equiv in the stdlib is broken for anything but toy use
  • Do you have any specific examples Ronny? I'm not being coy; I'm genuinely interested.
  • RonnyPfannschmidt
    one of the last straws is pickle in python3 doing massively wrong things when loading/storing anything with protocol <3

    other pains include inconsistent email apis for messages/maildirs
    "fscked" modules like cgi, simplecookie that are just broken

    and of course all those messes about fixing standards like wsgi to fit broken modules in the stdlib
  • Interesting. Do you have a link to the wsgi discussion w.r.t the broken modules they're working around?
  • RonnyPfannschmidt
    don't have a link any more, i lost all interest in dealing with wsgi directly at that point
  • Fair enough; but let me ask the logical question - I'm assuming http://bugs.python.org/issue6784 is yours (since you filed it) and the resolution seems reasonable (at least, to me), so I'm wondering why the seeming "strong dislike" or perception that it's being ignored. That's one bug report versus the list of broken modules you cited.

    Again; I'm trying to squirrel out things we can improve on, which is why I'm asking. What would it take to get you to make a PEP, file a patch, etc regarding the other issues you see? What would it take for you to possibly volunteer to help shepherd something like cgi or simplecookie?
  • In my humble opinion, this thread highlights one of the reasons why there is few active contributors to core Python—i.e., Python is a mature project. This means it is difficult to submit changes that doesn't imply backward-compatibility issues. Even bug fixes, as demonstrated by the pickle issue, can exhausts one's patience and resources quickly.

    In addition, it is not surprising for a Python maintainer to spend an hour, or two, just to commit a patch. This is partly due to the quality requirements we need to satisfy. One needs to go through a lengthy process that includes code review, running tests, writing documentation, and so on, before committing a change.

    Then, there is the high burden of maintaining multiple branches. So after you managed to commit your change, you are just halfway done. And, it certainly doesn't help us that svnmerge is sometime awfully slow (and I am generous here). On the bright side, the switch to Mercurial will hopefully mitigate some of the issue.

    Furthermore, most changes to Python are bug fixes and cleanups nowadays; and this is especially true with the moratorium in place. This makes Python unsexy to the eyes of many young developers (I know, I am one). With reason, most young developers rather like to spend their free time working on new and shiny projects.

    Working on Python might not be the most pleasant hobby, but I must confess that it is extremely rewarding to see my contributions be put to work. Plus, the Python community is just an amazing bunch of people. The time I spend on Python is nothing compared to the countless opportunities this community has brought me.
  • RonnyPfannschmidt
    as for that bug fixing pickle was kinda doable, fixing the c impl was beyond me

    we got a own serializer now

    as for the other modules, there are already way better working 3rd party modules

    and thats the general way i'm going now - correctly working 3rd party libs > rotten batteries

    and i certainly don't want any of those libs die the death of stdlib inclusion (thus no peps)

    the only way to interest me is an efford to kill the idea of the monolithic stdlib and go for ship a bundle of good libs as batteries (but currently that seems way too far-fetched)
  • Mat Lehmann
    I agree with the critic of the monolithic stdlib. As appealing as it is at first glance as hindering it becomes over time, when one has to realize, that the real best practice libs ad those with the best functionality are found elsewhere. And with systems like pip maturing, the whole value of this "batteries included" approach becomes questionable, I think. It would be more important to include something like pip, to give the user access to all the real "power-plants" of python libs out there.
  • The biggest reason I don't contribute (OK, actually I do contribute somewhat - but certainly why I don't contribute *more*) is possibly best defined as "lack of attention span". If I file a bug, or submit a patch, or whatever, there's often a long period before anyone on the core team will have time to look at it. That's not an issue in itself - they are volunteers and I don't expect them to drop everything for my minor issue - but often, by the time anyone responds to my report, I've moved on. Requests for further detail when I've no longer got the environment around to reproduce the bug, or comments on a patch when I've lost track of where I put the svn checkout with it in, leave me feeling that I've "not helped".

    Worse still is when I produce a patch, and it's OK, but it sits around for a while, and when someone looks at it, it no longer applies cleanly. Should I have kept it up to date with core changes? Is my contribution less useful because I didn't (after all, if I had, there'd be less work for a core developer to do to apply it). This one may be a perception thing, as I've no hard evidence that patches do go stale often enough to matter.

    On a related note, there's a question of what counts as "contributing". Clearly anything that eventually results in a core change counts, but the bottleneck there is, and always will be, the core committers' time. I'm assuming that a core developer is more interested in actually developing, than in administrative tasks like vetting and applying other people's patches. That's fine, but it does mean that non-committers are reliant on a very scarce resource (core committers' time and interest) to "contribute", if contributing means getting stuff into the core.

    Maybe a clearer message that contributions go wider than that, would help. Every bug report (even if the submitter immediately goes AWOL) is helpful, every feature request (no matter how daft) indicates that someone cares enough to ask, even just participating in discussions on the mailing lists is contributing. I'm not sure people get the impression that this is always true, though.

    Having said all that, f4nt's point is also very relevant - basically Python "just works", so there's very little in the way of contributions that I can make which are major to me (because I need something to work that isn't - scratching my own itch, in effect). So a lot of what I could contribute is more or less "nice to have" and so the motivation level to follow through is lower - and hence, it's easy to get discouraged by small obstacles.

    Sorry, that was a bit long, and didn't offer any solutions. Hopefully, it casts a slightly different light on some of your points, though.

    Paul.
  • Nope, it's good information. What about documentation enhancements, things like that which are not "core code" but valuable to the ecosystem?
  • Reason I'm not contributing? I rarely ever hit snags, and when I do I find that I hit a snag someone else found before me. I know that makes me kinda selfish to some degree, and I apologize for that. Generally though I start helping out a project I'm using when I find that there's something that doesn't work quite the way I want, or I stumble across something undocumented.

    Although, I will say that because of this blog post I've finally taken a closer look at the issue tracker and what not. Now I'm at least interested in contributing, whereas before it just wasn't something that had crossed my mind. That seems silly, considering I've contributed to other projects, and I constantly use Python, but when it "just works" most of the time it hasn't came up. For what it's worth I really enjoy Django's "How do I get involved" page, makes it pretty clear what you can/need to do.
blog comments powered by Disqus