Tech Blog

Python Community Observations Retort

Python Community Observations Retort

Recently updated on

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.

Comments

Comments are closed.