Why aren’t you contributing (To Python)?

April 22nd, 2010 § 93 comments

Over the past year or two, I’ve been in a pile of dis­cus­sions sur­round­ing attempt­ing to increase the num­ber of con­tri­bu­tions to Python (as a project and ecosys­tem) — specif­i­cally around bug fixes/patch reviews, fil­ing bugs, point­ing out doc­u­men­ta­tion issues, web­site con­tent, etc. Many of these con­ver­sa­tions seem rel­a­tively insu­lar (peo­ple already involved talk­ing about how they get work done, and how easy it is) or rel­a­tively hand-wavy (“let’s make it bet­ter! *crickets*”).

We all know that the fact is that there are plenty of areas for any­one (both pro­gram­mer and not) to con­tribute to the Python project/ecosystem, this is actu­ally true for most, if not all, open source, and open com­mu­ni­ties out there. While I am look­ing at this through the myopic lens of Python-core, the same dis­cus­sion could be applied anywhere.

In the dis­cus­sions I’ve had on mail­ing lists, and in pri­vate con­ver­sa­tions with peo­ple about why they don’t con­tribute, I’ve found a set of recur­ring issues cited by peo­ple who could be con­trib­u­tors, roughly speak­ing these are:

  • Don’t know how (doc­u­men­ta­tion issue)
  • Don’t know where (site lay­out, orga­ni­za­tion issue)
  • Don’t want to fight/argue with the “but this is the way we’ve always done it” peo­ple (per­cep­tion issue)
  • For many issues, see check­out (svn), build (learn a “new” build sys­tem), run tests/write tests, gen­er­ate patch, file bug, defend bug as a “high bar” (process/tool issue)
  • Don’t feel that they’ll be val­ued (per­cep­tion 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 inter­ests me more than the things I’ve listed about (which is a dis­til­la­tion of months of dis­cus­sions) is what, if any­thing, pre­vents you, my reader(s) from con­tribut­ing to the fol­low­ing areas:

  • Fil­ing bug reports (includ­ing the stdlib and documentation)
  • Fil­ing patches for bugs/improvements (includ­ing the stdlib and documentation)
  • Fix­ing issues/sending patches on web­site content
  • Propos­ing new web­site or doc­u­men­ta­tion content
  • Con­tribut­ing to web­site maintenance
  • Con­tribut­ing to the Documentation

And any­thing else you can think of. What I’m ask­ing for, is for you to give me thoughts, ideas and feed­back on how we can lower the bar and reduce the fric­tion of any of this so that you too can help out. Every­thing is fair game, even “I find the method of argu­ing for PEPs to cause lower intesti­nal irri­ta­tion” (although, I hope to get more con­struc­tive com­ments than that).

Here’s the rea­son I’m asking/reaching out — I firmly, and totally believe that every sin­gle per­son who uses Python today can become a con­trib­u­tor to the project and ecosys­tem beyond that of a user. While it is true that philo­soph­i­cally, every­one who uses Python is con­tribut­ing, I would like to see if we can make it so that even the most “basic” user feels that they can file a bug, sub­mit a patch, fix the doc­u­men­ta­tion, fix/add web­site con­tent, etc.

Much like I think any­one can, and should be empow­ered to con­tribute back to the “Python Project” — I believe the cul­ture of “every­one con­tributes” is an impor­tant one. Cit­ing the won­der­ful keynote from PyCon 2010 by Anto­nio Rodriguez (video here), I main­tain this is should be a goal for every­one, not just com­pa­nies — 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 iden­tify the “bugs” in what we have now. Do we need a giant flow­chart with flash­ing text (I joke!) or do we need sim­pli­fied “how do I…” text to the web­site? Everything’s fair game (except “just put it on github”).

So, do you have any thoughts? If you don’t feel com­fort­able air­ing them pub­licly, you can email com­ments to jnoller at (gmail.com|python.org) as you see fit. I promise not to share any iden­ti­fi­able infor­ma­tion, but I reserve the right to share the feed­back you pro­vide, albeit anony­mously. I also promise to ask mean­ing­ful ques­tions so I can squir­rel out more detail if needed.

← Older Comments
  • Casey Dun­can

    Ok, so here’s an exam­ple of me not con­tribut­ing, when it seems like I should have. We use url­parse with lots of apache logs at work (and by lots I mean more than I care to count). The log proces­sor was becom­ing too slow a few months ago so I pro­filed it. url­parse was one of the things that floated to the top as a bot­tle­neck. I looked at the stdlib imple­men­ta­tion, which is pure python, and didn’t see any obvi­ous way to make it sig­nif­i­cantly faster in Python. So, I rewrote it in C. The new ver­sion is about 15x faster, and though it isn’t quite as gen­eral as the stdlib ver­sion, it could be improved to be with a bit more effort.

    I was imme­di­ately going to blog about it, but I didn’t because its unit tests were tan­gled up in the larger project and I felt like it needed to be pack­aged bet­ter. Spew­ing C code on my blog didn’t seem that help­ful to folks with­out an easy way to install it.

    I thought about fil­ing a patch, but I didn’t. Because, this was done for Python 2.4, and this api moved to a dif­fer­ent stdlib mod­ule and it has no C code already iirc. And I hadn’t even breathed the words “Python 3″ at that point. I fig­ured this would need to be done for Py 3 anyhow.

    In my mind I saw two pos­si­ble approaches to con­tribute this: Bring it up first on python-dev to see if it was gen­er­ally con­sid­ered valu­able, or make a patch and put it in the tracker. I sus­pected the for­mer would just lead to a request to do the lat­ter, with req­ui­site bikeshed­ding. I sus­pected the lat­ter would lead nowhere, per­haps incor­rectly, but the thought of going to all that work for noth­ing when I had other things to do with my time that was more inter­est­ing, made me lose all inter­est in con­tribut­ing it. There was no tech­no­log­i­cal rea­son­ing here, I’m con­fort­able with all of the tools, and writ­ing tests and docs. I felt like the con­tri­bu­tion was not good enough for me to spend my time push­ing thought the system.

    And more gen­er­ally I don’t feel like there is a con­tri­bu­tion I am ever going to come up with that will com­pel me to push it through. OTOH, releas­ing a library for Python has a much lower bar, so I am doing that. Then I can focus my atten­tion on the prob­lem, not the process. I fear that “improv­ing” the stdlib is a lot like “reform­ing” the gov­ern­ment. The gru­el­ing process makes it a worth­while project for very few folks. The stdlib is not a mer­i­toc­racy, and in many ways its where once good code goes to die. There is no tech­ni­cal rea­son for me to not dive in there and start help­ing, but the thought of the process dri­ves all of my energy away.

  • Jason

    I gotta say more than any­thing is the fact that a.) tech­ni­cal peo­ple don’t want to help in non-technical ways (per­sonal inter­est issue) and b.) to help with code requires learn­ing the Python code­base, which could take even expe­ri­enced hack­ers weeks. Whether this per­cep­tion is real­ity or not, I believe it plays a large part in deter­ring would-be, could-be con­trib­u­tors (like me).

  • http://www.voidspace.org.uk/ Michael Foord

    Here are the hur­dles for con­tribut­ing to the main python.org website.

    Sup­pose “some­one” did decide they wanted to help python.org by sup­ply­ing a patch, this is roughly the set of steps they would have to go through:

    Go to http://python.org
    Click on “Help main­tain the web­site” in the left side­bar: http://www.python.org/about/website/
    Click on web­site main­te­nance: http://www.python.org/dev/pydotorg/website [1]

    The instruc­tions here are on how to check­out the repos­i­tory from the com­mand line with the svn tool. ( Please note that this repos­i­tory con­tains sev­eral hun­dred megabytes.) This takes a looooooong time. :-( By default this gives you a direc­tory called “beta.python.org”. You then open a file build/README with instructions.

    The first step is to install the build sys­tem depen­den­cies: mako, pyyaml, and docutils.

    The next step is run­ning make, which if you are on Win­dows requires first installing Cyg­win — another lengthy procedure.

    To actu­ally make changes you need to know / learn ReStruc­tured Text, a cus­tom markup from pyra­mid and pos­si­bly yaml.

    If you don’t have checkin rights you’ll need to gen­er­ate a patch (assum­ing you know how) — and then there is nowhere to post it (no issue tracker for the web­site), other than per­haps email­ing it to webmaster@python.org.

    Any­one who doesn’t think this con­sti­tutes a “high bar­rier to entry” is nuts ™.

  • http://twitter.com/pekkaklarck Pekka Klärck

    I’m one of those who believe that sub­mit­ting bug reports and propos­ing doc­u­men­ta­tion enhance­ments should be as easy as pos­si­ble. Need­ing to reg­is­ter an account is always an extra step and it would be great if it was pos­si­ble to use some exist­ing account instead. I loved how I could reg­is­ter using my Twit­ter account to sub­mit this comment!

    For doc­u­men­ta­tion it would be awe­some to have sys­tem to add com­ments to every para­graph sim­i­larly as in e.g. in Hg Book <http://hgbook.red-bean.com/read/preface.html>. Some­one could peri­od­i­cally go through the com­ments and enhance doc­u­men­ta­tion accord­ingly, but even the raw com­ments would help oth­ers look­ing for information.

  • Jason Whit­lark

    I won­der if some­thing like Ubuntu’s “Quickly” project would be help­ful for python. I’ve got the dev expe­ri­ence to fix bugs or what­ever, but I have enough of set­ting up envi­ron­ments at work. If I could type: quickly fix_python_bug, and get a test ver­sion to work against, with the var­i­ous com­mands, I’d be much more likely to do so.

  • https://www.google.com/accounts/o8/id?id=AItOawkk1DXqn7nmBMOlvQDg4w1zwpm4R7znKVg Jeff­Brad­berry

    I agree very strongly with this. I have con­tributed to Python core once (sub­mit­ted and had accepted a patch for http://bugs.python.org/issue6300). How­ever, since I’ve not per­son­ally stubbed my toes on any bugs, I don’t have any clear idea of what I “should” work on. Hav­ing a men­tor to give me a bit of direc­tion would help immensely.

  • MW

    For me, I believe a lot of the resis­tance to com­mit to any open-source project is two-fold:

    1) The resis­tance of doing any­thing dif­fer­ently. “What we have is good enough”, “You’re new here, don’t think you know bet­ter than the rest of us” or sim­i­lar sen­ti­ments usu­ally shuts down most of the ini­tial enthu­si­asm and ideas com­ing from a new person.

    2) There’s a long road to actu­ally feel like you’re belong­ing to the project. This might be because of the dis­trib­uted nature of open source projects, but what I usu­ally see is a tight group of peo­ple work­ing well at the top, but for peo­ple just get­ting involved, it’s usu­ally all about sit­ting at home work­ing alone at some patch, doc­u­men­ta­tion change or whatever.

    On top of that, I would per­son­ally be more inter­ested in a project that has a par­tic­u­lar goal. I’d much pre­fer to work in a small group of peo­ple want­ing to cre­ate the best doc­u­men­ta­tion set that is avail­able for any project, for instance, defin­ing what that means, fig­ur­ing out a plan to get there, and so forth, rather than just “we need peo­ple who do stuff. You don’t have to have any skills what­so­ever. Promise!” I don’t know about you, but if some­one was adver­tis­ing an open job posi­tion like that, I’m pretty sure I wouldn’t apply. Maybe cre­at­ing task groups and “recruit­ing” for these spe­cific tasks is a bet­ter approach for find­ing people?

  • http://blog.hellmage.info Xie

    There are at least two kind of poten­tial contributers:

    1. Nor­mally they have a job and are work­ing on some project using Python. They find python not sat­is­fy­ing in pro­duc­tion and want some­thing more. And they don’t want to main­tain their own fork.
    2. Nor­mally they are stu­dents and they are look­ing for projects to con­tribute. Maybe they just want to kill time or maybe they are look­ing for chal­lenge, cool stuff and a sense of achieve­ment from contributing.

    For the first kind of peo­ple, there are already many good sug­ges­tions to make con­tribut­ing eas­ier. For the sec­ond kind of peo­ple, they need more guid­ance. Google Sum­mer of Code is great, but why wait for sum­mer? How about some­thing like that every sea­son for student(or everyone)?

  • http://twitter.com/voltagex volt­age x

    Because I have to sign up for yet another account on Python’s bug­tracker.
    (Inci­den­tally, I could use my Twit­ter or OpenID on this site.)

  • dbe­namy

    My sug­ges­tion: Add a promi­nent “Help Improve Python” link on the home page.

    It should have intro text about how valu­able con­tri­bu­tions are, even small ones, although maybe with a dis­claimer that changes can’t always be accepted.

    It should have a sec­tion for each type of con­tri­bu­tion each con­tain­ing a screencast/tutorial show­ing how to con­tribute, text quick start guide, and links to rel­e­vant resources. For exam­ple the code video should show find­ing a sim­ple bug, installing svn (or tor­toise), check­ing out the code, fix­ing it, adding a test, sub­mit­ting a patch…

    (I haven’t read most of the com­ments so sorry if this has been talked about.)

  • .

    I do not con­tribute because Python is per­fect and cre­ated by God. It is heresy to sug­gest it needs to be improved.

  • http://taleinat.pip.verisignlabs.com/ taleinat

    The cur­rent prob­lem with requir­ing high qual­ity patches is that too often the author of a patch receives com­ments too long after hav­ing post­ing the patch. By that time, the author has likely moved on to other things and is unlikely to invest addi­tional time into it.

    My story: I have con­tributed, a bit, mainly to IDLE. Many of my patches weren’t accepted, mostly because nobody both­ered to review them or because they were reviewed and com­mented on sev­eral months after my post­ing them. Some, admit­tedly, weren’t fit to be accepted, but hav­ing the dis­cus­sion span months is hor­ri­ble. After hav­ing put many hours of work into many patches, only to have a hand­ful of them accepted over sev­eral *years*, I sim­ply forked IDLE and haven’t both­ered with any patches lately.

    Today, if I had an idea for Python (some­thing other than IDLE) I wouldn’t bother with it unless I got sig­nif­i­cant back­ing from python-dev in advance; oth­er­wise it wouldn’t be worth the bother.

    I will note that I have posted one or two bug reports and have helped fig­ure out a few posted by oth­ers, and in these cases things were usu­ally moved for­ward in a mat­ter of days. It’s sub­mit­ting patches for fea­ture requests which I am avoiding.

  • http://blog.hellmage.info Xie

    There are at least two kind of poten­tial contributers:

    1. Nor­mally they have a job and are work­ing on some project using Python. They find python not sat­is­fy­ing in pro­duc­tion and want some­thing more. And they don’t want to main­tain their own fork.
    2. Nor­mally they are stu­dents and they are look­ing for projects to con­tribute. Maybe they just want to kill time or maybe they are look­ing for chal­lenge, cool stuff and a sense of achieve­ment from contributing.

    For the first kind of peo­ple, there are already many good sug­ges­tions to make con­tribut­ing eas­ier. For the sec­ond kind of peo­ple, they need more guid­ance. Google Sum­mer of Code is great, but why wait for sum­mer? How about some­thing like that every sea­son for student(or everyone)?

  • matleh

    I agree with the critic of the mono­lithic stdlib. As appeal­ing as it is at first glance as hin­der­ing it becomes over time, when one has to real­ize, that the real best prac­tice libs ad those with the best func­tion­al­ity are found else­where. And with sys­tems like pip matur­ing, the whole value of this “bat­ter­ies included” approach becomes ques­tion­able, I think. It would be more impor­tant to include some­thing like pip, to give the user access to all the real “power-plants” of python libs out there.

  • http://yole.livejournal.com/ yole

    I have two com­ments: one gen­eral and one very spe­cific. The gen­eral one is a per­cep­tion that, if I con­tribute a patch or a bug report, it will sit there in the issue tracker for a long time until some­day maybe some­one will get around to fix­ing the bug or apply­ing my patch (even if I strictly fol­low the rules for con­tribut­ing). The prob­lem def­i­nitely 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 per­cep­tion is still there.

    The spe­cific com­ment comes from my par­tic­i­pa­tion in the Unladen Swal­low sprint dur­ing this year’s PyCon. I got a few things done, accepted and checked in, but at least two thirds of com­ments I got when I first sent my changes for review were related to spac­ing, inden­ta­tion and line lengths. I had to spend quite a lot of time fix­ing the issues — and shoe­horn­ing code into 80-character lines, 48 of which are already used up by 8-space indents, is com­pletely oppo­site to my idea of fun. Espe­cially given that at work I don’t have to spend any time at all think­ing about code for­mat­ting — the line length limit is much less strict, and my IDE takes care of almost all the for­mat­ting for me auto­mat­i­cally. I don’t know what’s the right solu­tion for that, but the prob­lem def­i­nitely exists for me. I under­stand why the rules are there, but I’d much rather work on some­thing else where com­ply­ing with rules wouldn’t take that much effort.

  • Simon Cross

    Coders from my local PUG have been involved in var­i­ous Python sprints we’ve all felt
    the contributing-to-Python pain. Mostly the trou­ble is that get­ting any­thing 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 sub­mit­ted by an ex-colleague finally get applied — I think the orig­i­nal patch was sub­mit­ted almost four years ago.

    My best sug­ges­tion is for Python to adopt a leiu­tenants (sp?) sys­tem sim­i­lar to that used by the ker­nel. There need to be a few peo­ple ded­i­cated to fun­nelling in other people’s patches. The switch from Sub­ver­sion to Mer­cu­r­ial (when it even­tu­ally hap­pens) will prob­a­bly make it eas­ier but what we really need is to have two or three peo­ple paid to work on Python full time (at the moment we have half a Guido).

  • Neil Muller

    While com­plete­ness is a good goal to strive for, com­bined with the often quite slow response from peo­ple in a posi­tion to com­ment on the patch, the process of evolv­ing a patch to a point where it is accept­able ends up being extremely tedious. and the sev­eral hun­dred bugs tagged patch in the python bug tracker that haven’t seen any activ­ity for more than 6 months sug­gests that this is a seri­ous prob­lem with the cur­rent process.

    There are also a num­ber of patches which have also stalled at stages where they look rea­son­able for no clear rea­son, and there’s no obvi­ous process for get­ting them unstalled (a triv­ial exam­ple is http://bugs.python.org/issue5610 ).

  • http://www.voidspace.org.uk/ Michael Foord

    You can use OpenID in the Python bug tracker.

  • http://www.voidspace.org.uk/ Michael Foord

    You can already use OpenID in the bug tracker. We may exper­i­ment with allow­ing new bug reports to be made with­out an account and see how much spam we get or extra effort it is to monitor.

  • http://tech.blog.aknin.name Yaniv Aknin

    Just two weeks ago I wrote a post called “Con­tribut­ing to Python”, cov­er­ing the process of sub­mit­ting a first patch. I think this is a ter­rific topic to dis­cuss in order to strengthen the com­mu­nity, and I wrote a whole post as an answer, check it out.

  • http://www.doughellmann.com/ Doug Hell­mann

    Bug reports with­out the iden­tity of the sub­mit­ter are worth­less, so we should at least require an email address.

  • Anony­mous

    Put but­tons on python.org for “Improve the docs” and “Fix the code”.

  • Anony­mous

    Make the docs like a Wiki, except changes are queued for review instead of imme­di­ately applied. Make it one click from python.org, and allow anony­mous access. If that works, do the same for the source.

  • http://timgolden.me.uk/ Tim Golden

    I’ve com­mented over there –> http://ramblings.timgolden.me.uk/2010/04/23/tho…

  • optilude

    I’ve writ­ten a bit about sim­i­lar things in the Plone community:

    http://www.martinaspeli.net/articles/the-dog-at…

    and, some­what related:

    http://www.martinaspeli.net/articles/oh-how-we-…

    I think ulti­mately, con­tri­bu­tion comes down to lead­er­ship. When you have peo­ple in the com­mu­nity who make sure that com­mu­nity is wel­com­ing, peo­ple are more likely to emo­tion­ally com­mit to con­tribut­ing. If those same peo­ple then sup­port, men­tor and encour­age (rather than hand-wave, slap down and belit­tle) con­tri­bu­tions, con­trib­u­tors are made.

    So, per­haps, it’s less about what stops peo­ple con­tribut­ing, and more about what’s lack­ing in terms of sup­port infra­struc­ture to turn poten­tial con­trib­u­tors into com­mit­ted com­mu­nity members.

  • sdeibel

    Usu­ally 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 inten­sive daily full time use of Python. Dunno, maybe I just write bor­ing code.

  • trav­is­brad­shaw

    No, I agree with you that the stan­dard library has great poten­tial. I also under­stand par­tic­u­larly how your work with mul­ti­pro­cess­ing, for instance, would be very rewarding.

    How­ever, when con­sid­er­ing the stan­dard library in gen­eral, I think of this quote from Tarek Zaide shaped my thinking:

    > I had a twenty min­utes meet­ing with Guido after the Sum­mit to clar­ify the sit­u­a­tion and he helped me under­stand why this was the right path and worked with me on what to do next in the stdlib front and out­side the stdlib.
    >
    > Basi­cally, a pack­age that comes in the stan­dard library has a foot in the grave (I am para­phras­ing Guido here.). Its APIs is frozen, and peo­ple don’t really expect noth­ing from it, but small new fea­tures and bug fixes. Refac­tor­ings are dan­ger­ous, if not impos­si­ble.
    >

    APIs and refac­tor­ing are some of my very favorite devel­op­ment activ­i­ties. I often take an equal joy in the ele­gant API and intu­itive use cases than I would in any par­tic­u­lar imple­men­ta­tion. Opti­miza­tion and refac­tors that make code more clear, smaller and remove anomalous/inconsistant behav­iors are very fun.

    This just doesn’t seem like the type of work that the stan­dard library offers. My typ­i­cal process involves using the stan­dard library when­ever pos­si­ble. But when it’s not pos­si­ble, I quickly go to alter­na­tive libraries. When there’s not a solu­tion, my first con­sid­er­a­tion is to con­tribute to one of the alter­na­tive libraries, not con­sider a fix in the stan­dard library.

    As another exam­ple as to why I’m not cut out for stan­dard library work… if I “ruled the world,” all stan­dard libraries in Python 3.0 would have been PEP8 com­pli­ant. Not as prag­matic as the cho­sen solu­tion, and I respect the cho­sen solu­tion as more wise than myself, but I still wish it would have happened. :)

  • http://www.voidspace.org.uk/ Michael Foord

    We’ve had Python bug days before and they’ve been pretty effec­tive. We should do it again. (Mainly coor­di­nated over IRC.)

  • http://www.voidspace.org.uk/ Michael Foord

    I wish there were devel­op­ers paid to work on Python too, but whilst we’re wish­ing maybe we should go for a uni­corn instead… Bug triage is pretty good these days by the way — we have a good bunch of vol­un­teers who are pretty quick to pounce on new bugs.

  • http://www.voidspace.org.uk/ Michael Foord

    I under­stand your frus­tra­tion. We sim­ply don’t have an active main­tainer for IDLE. :-(

  • http://www.voidspace.org.uk/ Michael Foord

    If the bug is real and repro­ducible why is a report with­out an iden­tity worth­less? Bet­ter than no report at all, surely.

  • http://www.doughellmann.com/ Doug Hell­mann

    Sure, if it’s repro­ducible. My expe­ri­ence has been if there’s no effort to even pro­vide an iden­tity then the bug report isn’t com­plete enough to be helpful.

  • http://twitter.com/pekkaklarck Pekka Klärck

    Cool, I didn’t know that. Now that I checked also Google and Launch­pad accounts seem to be sup­ported. I’m pretty sure this wasn’t the case when I last sub­mit­ted an issue, but that was quite long time ago. As oth­ers have com­mented, things mostly work for a “nor­mal” Python user.

    For small­ish doc­u­men­ta­tion enhance­ments I con­sider the tracker overkill any­way, and would love to see a pos­si­bil­ity to com­ment the actual documentation.

  • http://cool-rr.com/ cool-RR

    I per­son­ally don’t believe in con­tribut­ing small bits of code to a project.

    I know this is an unpop­u­lar opin­ion 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 num­ber of projects, in con­trast to devot­ing a lit­tle effort to a big num­ber of projects.

    I think that this approach is supe­rior, espe­cially in the world of soft­ware where hav­ing one excel­lent project is bet­ter than hav­ing 3 good projects. (Gen­er­ally speaking.)

    But of course, this approach might not suit everybody.

  • Ilya

    The pri­mary prob­lem as far as I am con­cerned is that patches often sit in the tracker for many many months at best or many years at worst.,.

    Right now I’m wait­ing 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 cou­ple of other pdb bugs which I could fix, but prob­a­bly won’t bother until my cur­rent patches make it.

  • http://pycloud.blogspot.com Gökhan Sever

    After being using the Python for over a year as a grad­u­ate stu­dent in an applied sci­ences field I still have the impres­sion of Python’s being designed for com­puter science(s) peo­ple. I feel this way mostly because of the fact the Python ecosys­tem is a very com­plex envi­ron­ment. I think the atti­tude of “Python for com­puter geeks” should be more and more changed and empha­sized to “Python for all.” This men­tal­ity usu­ally reflects why I don’t con­tribute as much as I could (not directly to Python but I report bugs, sug­gest fea­tures, catch doc­u­men­ta­tion errors, try to add some improve­ments through sci­en­tific Python tools.) Most likely only a few peo­ple in my vicin­ity use Python in their work and this takes away the nat­ural feel­ing of mak­ing widely usable con­tri­bu­tions to the ecosys­tem. Python is not like English/or my native lan­guage where every­body around you/me speaks. That’s why I have said above that Python should be for all and this state-of-mind should be adver­tised in every pos­si­bil­ity so that con­tri­bu­tions go beyond “hacking/geek activ­ity” to a nat­ural state of sharing/improving a com­mon language.

  • http://jessenoller.com jnoller

    I don’t fol­low — what gives you the impres­sion it’s only for comp­sci people?

  • Ilya

    One idea would be to to relax “5 for 1″ idea to “3 for 1″ or even “2 for 1″…

    (Find­ing 5 issues to help with may be quite non-trivial for an inex­pe­ri­enced con­trib­u­tor and many won’t even try).

    Also, it might help to describe the “5 for 1″ offer in a bit more detail: what qual­i­fies as a review? Is apply­ing some­one else patch and test­ing it suf­fi­cient? Is point­ing out a bug dup or point­ing out a bug side effect suf­fi­cient? The prob­lem for me with “5 for 1″ is that even though I com­mented on a few issue (and in some cases my com­ments seem to have led to the res­o­lu­tion), I don’t view my com­ments as reviews and I don’t want to sound like a cheap­skate by mak­ing a “5 for 1″ request.. So clar­i­fy­ing the rules of the game might help.

  • http://tartley.com Jonathan Hart­ley

    This video of the PyCon (2009 I think) talk “How Python is Devel­oped.” From my outsider’s per­spec­tive, this seems like a good intro for any­one want­ing to under­stand the process of con­tribut­ing to core.

    http://pycon.blip.tv/file/1947394/

  • http://jessenoller.com jnoller

    That’s a great link, but I’m per­son­ally quite famil­iar with the process :)

  • http://tartley.com/ Tart­ley

    Ha! I fig­ured *you* are famil­iar Jesse. I linked it for the ben­e­fit of oth­ers like me, who are inter­ested in. Best regards. :-)

  • http://petereisentraut.blogspot.com/ Peter Eisen­traut

    I don’t know of any bugs that bother me, doc­u­men­ta­tion is help­ful and easy to find. There is a lot of other stuff out in the world that needs atten­tion and fix­ing. Python works fine the way it is.

  • http://jgraves1141.myopenid.com/ John Graves

    Con­tribut­ing takes skill and aware­ness of the value it creates.

    Devel­op­ing that skill and aware­ness in peo­ple who don’t have it requires learn­ing to take place.

    Learn­ing, in turn, requires motivation–of which there were clas­si­cally two types: the car­rot and the stick, oppor­tu­nity and fear. Dan Pink’s book, Drive, explains why this old view of moti­va­tion is wrong. Watch this ani­mated video for an enter­tain­ing pre­sen­ta­tion of his point:

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

    Pink points to our abil­ity to “grow and develop” as the real moti­va­tors. Con­tribut­ing to Python would be eas­ier for more peo­ple if it was on a pathway–ideally a well-lit, well-paved path­way with a friendly greeter right at the start–to grow­ing and devel­op­ing into a bet­ter, more successful/skilled person.

    Now I just learned today that Back­Rub, the pre­cur­sor to the Google search engine, used Python:

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

    More peo­ple should know that fact. Python can lead to great things!

    I’m try­ing to use Python in a sim­i­lar way to give peo­ple new capa­bil­i­ties to learn from what oth­ers know or have discovered–and I’d like your help.

    Learn­ing, for most peo­ple, involves a com­bi­na­tion of hav­ing things explained and act­ing on the new infor­ma­tion. A “con­tribut­ing to Python sand­box” might be use­ful in this regard. Give peo­ple a safe place to make mis­takes and learn from those mis­takes painlessly.

    But I’m hop­ing to spark the devel­op­ment of some­thing more ambi­tious: a new style of Skype-like inter­ac­tion with the com­puter that would give Python the abil­ity to “explain itself.” We can put on a head­set and con­nect a web­cam to com­mu­ni­cate with one another through the com­puter, so why not use that same hard­ware to inter­act directly with the com­puter — instead of (or in addi­tion to) the mouse and key­board? Give the com­puter a script (that it can fetch from the web) and let it use text-to-speech to talk, voice recog­ni­tion to lis­ten and the web­cam to watch for and respond to ges­tures. What you get is an inter­ac­tive tutor.

    The open source project for this style of inter­face 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

    includ­ing the clas­sic Python No Hands.

    You will find pro­to­type Python code at Open Allure from a Python novice with doc­u­men­ta­tion but no tests at this point (I wrote my first Python pro­gram less than 6 months ago), but amaz­ingly the cur­rent ver­sion works well enough on Mac, Win­dows and Linux to demon­strate the idea. I’m com­mit­ted to full-time devel­op­ment work on the project for at least the next 12 months–so if you don’t look at it now, please look later.

    Bot­tom line, what I am sug­gest­ing is this:
    0/ peo­ple need help learn­ing the skills and atti­tudes required to con­tribute to Python
    1/ build this new inter­face so the com­puter can ver­bally guide peo­ple through learn­ing new things
    2/ cre­ate con­tent for the inter­face which explains all about Python (includ­ing how to con­tribute 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 sys­tem that has the abil­ity to self-explain can effec­tively repro­duce and “grow and develop.” If Dan Pink is right, such growth and devel­op­ment is not only what we want for Python, but what we are most moti­vated to seek for ourselves.

← Older Comments

What's this?

You are currently reading Why aren’t you contributing (To Python)? at jessenoller.com.

meta