2009-08-27

Prioritizing my Python development time

Python has been my hobby since mid 2002. If I were to add up the number of hours I put into various things I do regarding developing for Python I am sure it overshadows every other hobby I have. Having such a large, open-ended hobby like Python development means I can easily fill all of my free time with Python stuff of various types. It also means that, me being me, I tend to over-extend myself with more than I can reasonably take on at the moment. And then on top of everything else, I am lucky enough to be in some unique positions within the Python community, e.g. being a core developer. This leads me having to occasionally stop, take a deep breath, assess what I can and want to do for Python, and then prioritize those goals and projects to make sure the most important things get done in a more expedient fashion than the low priority stuff.

There are several groupings of things I can work on at any one point. One is fixing bugs in Python that I have discovered. As of late that has been incompatibilities in importlib but it can involve doc issues I come across, etc. Nice thing about these projects is that I know what needs fixing so the only hold-up is me generating a fix.

Another type of project is trying to fix bugs as reported by others at the Python issue tracker. This takes a bit more effort than fixing bugs I found as I have to report everything I do in the issue tracker as compared to just fixing the bug. It also requires working with someone else to help clarify what the bug is or debug issues if it happens to be on a platform that I am not on. There is also an issue of motivation; sometimes I honestly just don't find a bug interesting enough to want to work with it. Sometimes I am motivated to work on an issue but the turn-around time of getting help from the original poster (OP) can sometimes kill my desire to fix the bug. But being a core developer means I have intimate knowledge of how Python works, putting me in a unique position to know how to fix certain bugs that most people who have no clue how to start working on.

Sometimes I want to create new code. Importlib is a good example of this as I decided I wanted this to happen so I coded it up. This is a rarity since I can't just add every piece of code that I have thanks to standards for adding new features to Python.

Being a core developer means I can also approve patches. Python is lucky enough to have gained people over the years who are happy to help triage issues so that core developers like me can simply look for issues that are staged as needing a commit review or a patch review or has the needs review keyword. Or if I want to work on patches that are less vetted, I can look at issues that simply have a patch (as you can see we are still experimenting on how to handle the issue workflow). Working on pre-existing patches has the perk of (potentially) of being more productive as I don't have to write the code from scratch or come up with inspiration for a solution. There is also the hope that by approving someone's patch will inspire that person to want to contribute more and even potentially becoming a core developer themselves.

I can also work on easing the development of Python. Because being a part of python-dev has given me so much I am always trying to make it easier for people to get involved or at least give back to Python. Plus easing development helps core developers as well. These are the reasons I helped us make the switch to Roundup, making the decision that we should switch to hg, and that I maintain the dev docs.

I do try to evangelize Python when I can. I go to my local Python user group, I gives talks at PyCon, I answer emails people send python-dev, etc. Evangelism tends to just come up and not be under my direct control. I can't just decide to travel to every user group and give a talk (although I have received some talk invitations which I had to turn down as I can't take the time off to extensive travel until November).

There is also the political aspect of Python. I am the board of the Python Software Foundation which helps protect the Python intellectual property (IP) and dole out the sponsor money we get (which we can always use more of). Typically the stuff I do for the PSF is not fun for me as it's business-related and that is not my strong suit, but it needs to be done. Luckily it is a rare thing for me to deal with as my PSF board work has mostly been related to infrastructure stuff.

Before I go any further, I want to point out the amount of work that is suggested above and how this is all done in my (and others) spare time. There are some people out there who always forget that Python is a volunteer-driven project. The only people I know who get paid to work on anything close to Python itself are the lead implementors of Jython, IronPython, and Unladen Swallow. They are not paid to work on CPython or the language itself. That means bugs in the standard library, the CPython interpreter, docs, etc. are all done by volunteers. So please, if you ever feel the urge to complain about how some bug has been lying around for a while or your patch has not been reviewed yet, realize that there are not many of us (less then 30 active at a time) and we are lucky if we get a couple of hours a week to deal with any Python stuff.

Anyway, with that out of the way, let's discuss how I should best use what little time I have for the benefit of Python. First and foremost, I need to keep myself happy. If I end up resenting my Python work I will do it less or pull out all together. My position as a core developer should also be considered as that is a unique position for me to be in to help others and thus should not be frivolously ignored. And then there is the infrequency argument where something comes up so rarely it should get priority.

With all of that in mind, I think my Python development priorities should be:

  1. Evangelism (rare but fun)
  2. PSF (rare)
  3. Fix bugs I find (typically a fast fix and usually a rare thing)
  4. New code (fun)
  5. development of Python (helps core developers and new people wanting to contribute)
  6. Patch approval (higher fixes/hour than coming up w/ my own code, might get someone more involved)
  7. Fix bugs discovered by others (still squashes bugs in Python)
This list of priorities does differ from how I current do thing (and thus I need to change). One is that I should not write any new code until all known bugs to me have been squashed. Applying that to the present, that means I should not be fiddling with my sqlite3 importer until all importlib incompatibilities and the cProfile/profile merge have occurred. It also means that once I have done that I should help with the coding needed to get python-dev switched over to Mercurial. I should also get off my rear and write a doc on the types of communication used for developers of Python along with how to get a new module or language feature into Python. I should not troll the issue tracker for bugs to fix but instead look at patches already submitted by people to fix bugs. To me all of this seems reasonable for maximizing my Python development time for productivity and enjoyment.