Thoughts on “Why aren’t you contributing…?”

Jesse Noller’s just published an article entitled “Why aren’t you contributing (to Python)?“. It’s trying to work out what the barriers are to someone who comes along with a bug, an improvement or an idea which could contribute to Python in some way. As you might expect it’s generated a fair few comments, the vast majority thoughtfully and candidly expressed. I thought about replying over there, but realised I couldn’t possibly be concise enough :) so I’ll jot some thoughts down over here.

The common complaints — it’s too much of a hurdle to report things; they just lie around anyway without any attention; when they do get looked at there’s just a lot of talk and further demands on my time; it takes ages to format the code correctly — are all familiar. Some could be addressed: you can email a report to bugs@python.org; the tracker accepts OpenID & Google logins; someone more familiar could reformat the code. But some are part of the nature of things: even a straightforward fix which finds a champion among the committers still needs tests and docs and may well need more discussion than the originator had thought about for his particular needs. Someone’s got to do the work.

I like the idea of lieutenants (as long they’re pronounced correctly, of course ;) ). I’d certainly step up to be part of a group around Windows bugs / features etc. There are, let us say, political obstacles even for committers: different people have different ideas of what should go into the stdlib and whether it’s worth introducing a particular change merely for the sake of consistency and tidiness, and so on. You can’t just commit-and-run. No surprise for anyone who’s worked on a coding project of any size.

My particular area, of course, is Windows and I’d like to consider the additional barrier to contribution for Windows users of Python. I imagine (always worth imagining in the absence of any credible data) that Windows users, even developers, are less likely to have Visual Studio (or Mingw or cygwin) installed. And even less likely to be using Subversion or Mercurial. Let alone the secondary toolsets needed to do a full rebuild of Python. What this means in practice is that, if a user says: here’s a bug; and I reply: here’s a fix, does it work? they’re less likely to be able to patch the code (or pull the update) and rebuild and test. This doesn’t stop me or someone else testing, but it does disengage the OP from the problem he’s reported. In addition, if he’s a Windows user he’s probably hoping for the next MSI to become available. Which won’t be for a while.

All this is imaginary. I’ve seen no reports of Windows users crying themselves to sleep because they couldn’t reinstall a patched version of Python which fixes a problem. But what is real is that Windows developers are very slightly further removed from the Python development process by the difference in development setup.

So that’s my challenge: to try to improve matters within Python development so that it’s at least as easy for Windows users to get started, to report and test problems, to help to fix things. What will this involve? I don’t know. Maybe returning to automated overnight MSI builds. Maybe streamlining the download / setup / build process on Windows. Maybe getting my act together and documenting things better. Maybe putting a bundle together which makes things easier, as sort of DIY Python Starter Pack. I’ve got the motivation; all I need is the time.