Imaginary Landscape Blog

Python Community Observations Retort

I recently read an article by Steve Holden, chairman of the Python Software Foundation, titled Comments or Not? Public or Private? Relevant or Irrelevant?. It's a rather interesting read that I definitely recommend that covers the heated PyPi comments debate, issue tracking, and the surrounding Python community. There are also a number of insightful comments on this blog post, but I personally felt a lengthier blog post to be more fitting than a comment in retort.

First off, commenting on PyPi has stirred up quite a bit of debate. I personally feel that the pros are outweighed by the cons overall, but that doesn't necessarily matter. If 1000 people want ketchup on their hot dogs and 500 people want to see ketchup on hot dogs become illegal then it doesn't really matter what cons the 500 people come up with for their argument. They're still, simply put, overruled by the majority. I felt that the poll was inherently broken to some degree though. Instead of simply allowing for two options, "Comments and Ratings" and "No Comments or Ratings", there were instead five potential options (along with results):

  • Allow ratings and comments on all packages (status quo): 223
  • Allow package owners to disallow comments (ratings unmodified): 137
  • Allow comments, but only send them to package owners (ratings unmodified): 33
  • Disallow comments (ratings unmodified): 24
  • Disallow ratings and comments (status three months ago): 88

This gives way to a situation where one option technically gets the majority, while the other four options outweigh the single majority. Going with the "majority" in the sense of the option that received the most votes, will displease the actual majority of the voters. An all or nothing poll would have polarized the debate more, sure, but it would have given us a more precise picture of where the community stands. From there, we could discuss options such as allowing maintainers to disallow comments and so on. Instead we're stuck with this awkward outcome where unhappiness is really the only step forward. Unfortunately, I don't have any amazing answers as to how to make everyone happy. I do, however, know that maintainers are not pleased and that new PyPi creations are in the works within the community. All I can hope is that this doesn't result in some sort of bizarre fork war.

In his article Steve also mentions the matter of the Python issue tracker. From what I understand, Python leverages Roundup. We actually use that here in the office and, overall, it's a decent issue tracker. I feel it has some inherent limitations and drawbacks which inspired me to craft my own Django based issue tracker, but either way Roundup typically handles the majority of issue tracker use cases. That being said, I've generally found it more for developers than for users. It's just a bit on the clunky side and not typically easy on the eyes. Sort of like Bugzilla, it does a great job and it's easy to use when you're savvy, but when you're a user with a critical bug to report it can be troublesome.

Steve's thought for a solution however, seems strangely archaic. He proposes allowing people to email human beings who then translate the email into an issue to be placed in the issue tracker. I know humans are still useful Steve, but I don't trust them with trivial, repetitive tasks. Also I would worry about handlers interpreting, rather than strictly copying and pasting, issues. I don't want what the handler interpreted the complaint as, I want the user's exact words for everyone to see to help reduce potential misinterpretation (more eyes are better). The overall workflow just sounds messy. I think the real solution is obtaining a stronger issue tracker, but this is where I seem to find a flaw in the Python community. It seems we're too often running software strictly because it's Python based. The best issue tracker around isn't Python based, I'm sorry, it just isn't. Considering the PSF is open source based, they should have a number of strong issue trackers to choose from, since many companies like to donate software to open source/not for profit organizations.

Finally, the article concludes on the idea that we in the Python community don't do a very good job of pointing out our faults. I'm not sure that's necessarily true. We've been ranting about setuptools for months and the PyPi situation has sparked intense debate, so I think we at least have a fairly vocal minority in our ranks. Yes, there are things that are a bit strange, off-putting, or non-intuitive in our community that need to be fixed. Overall though I think that the issue tracker is functional, PyCon has great turnouts and talks, PyPi serves its most important use case, and the community produces a lot of great output. I feel we'll continue to see Python grow in the future as more industries see its uses, such as more system administrators picking it up instead of Perl (sorry, Perl!). It's not all doom and gloom in the land of Pythons and Ponies, in fact, blog posts like Steve's, this one here, debates on the mailing lists and so on are all signs that we're a healthy community. People don't debate, blog, and rant if they don't care.


Updated 12/02/09 @ 02:00PM CST by markr

Bookmark and Share

Categories: Python

Tags: community pypi python


Comments

Paul Boddie
On the subject of issue trackers, although there was enthusiasm in some circles for JIRA (and yet I hear horror stories about it from those who have no choice about using it), the arguments for using Roundup included it having a reasonable level of usability (it is nicer to use than Bugzilla), it being a "poster child" application for Python (related to the much publicised Software Carpentry competition), and it being Free Software (and hence customisable by anyone). Although people may say that a proprietary solution could have been donated and even some customisation carried out by the corporate entity involved, it's easy to get into a situation where only certain people have the keys to the building, or even a BitKeeper-style situation (http://lwn.net/Articles/12120/). A fair number of Python people don't seem to care that much about Free Software - witness the enthusiasm for various Google services - but adopting and improving such software has a positive feedback for Python and Free Software in general. Running a community project with large amounts of "proprietary plating" can undermine the credibility of the project because people do then wonder whether community projects are sustainable or whether they need to be propped up by corporate products. I've argued against using Python stuff for the sake of it quite recently, perhaps to the irritation of those concerned (why write a blogging solution when people are already using WordPress?), mostly because in a project with limited resources, you should focus on the things which need most improvement, but I can see the need to customise something like a bug tracker and that the people doing the work would rather hack on Python and not PHP, Perl or Java. Indeed, high-profile Bugzilla instances are frequently customised: take a look at KDE's tracker for an example. The way forward for the tracker is arguably an interface that makes it easier for users to understand and file bugs, very much in the fashion of KDE's front-end to Bugzilla. In addition, some kind of single sign-on to python.org services would be advisable, extending to OpenID support. Since MoinMoin supports OpenID, and Apache can be made to support it, it's just a question of having the time and inclination to put it all together, and then the existing services will all be better. What would be damaging is lobbying for just sweeping everything off the table and having a "clean slate" - that definitely deters anyone from committing their time to improving what's already there.

Michael Foord
"This gives way to a situation where one option technically gets the majority, while the other four options outweigh the single majority." You keep using that word, ("majority") I'm not sure it means what you think it means... Anyway - the second option was picked as a compromise (often a good term for communities). Assuming the second is *acceptable* (if not preferred) by those who picked the first option then a large *majority* are happy. It leaves comments on unless the author switches them off...

Leave a Comment

Optional

Captchacaptcha

The design of our "Leave a Comment" form was inspired by Jacob Kaplan-Moss. Because his is very cool.
pony