Where did you hear about... ?

I've served as PyCon's volunteer publicity chair the past two years. This year, at my request, the attendee survey had the question, "How did you hear about PyCon?"

Thanks to everybody who took the survey and answered that annoying question. Of course, most answers were along the lines of, "Duh, I've always known about PyCon!"

Basically, the answers helped to confirm that community buzz is what brings most people. (My favorite answer: "Birds.") Problem: not everybody is plugged into the buzz. I know lots of programmers who never read blogs or attend groups, and there are lots more that I don't know because they don't do blogs or groups, or otherwise plug themselves into the community.

What I most need is for everybody who didn't hear about PyCon to answer this question: "Why didn't you hear about PyCon? Where would you have seen a PyCon announcement?" The logistics of doing that survey are tricky, however.

How do you think word spreads among geeks, in this day and age?

Wanted: pictoral Field Guide to Nerds

My grandfather was an amazing man. He seemed to know every living soul in Duluth, Minnesota. He never forgot a face.

I didn't inherit that gene. Remembering faces and names is a huge challenge for me. "Very nice to meet you, Mrs. - wait, have we met before? Oh, Mom! I'm sorry." I can spend fifteen minutes in conversation with someone, and five minutes later be unable to bring their face into my mind. It's frustrating and humiliating. I need technological help.

I'd love a website full of labelled and indexed photos of the inhabitants of geekland, something I could brush up on before a conference, or study afterward to cement the new acquaintances into my memory.

Does something like this exist? Failing that, does anybody have some good ideas for how it could be made? At present, my best idea is for some sort of Flickr mashup.

documentation rant

Everybody knows that open-source software documentation sucks.

It doesn't, however, suck nearly as much as big-company proprietary software documentation, which Steve Holden characterizes as

Threep Nardling
To nardle threeps, select the Threep tab and check the Nardling checkbox.

... and so forth... a beautifully-typeset waste of electrons.

The questions we go to docs for are: Can I nardle a threep via SSH? I tried it, but my threep still isn't nardled. I got an "ERROR: Threep nardling failure" message. What now? If those questions aren't addressed, there's really no point.

These days, I do sometimes see open-source docs that address these questions. Most often, of course, you find answers to these questions in the user community.

Anyway, I suggest that, when users run into trouble, this is the preferable order of responses:

1. Change the program so that it acts as the users expected in the first place.
2. Use program interaction and informative error messages to guide users through problems without having to look outside the program.
3. Put the answer in the documentation - and make it easy to find or it doesn't count! Expecting users to comb painstakingly through 400 pages is not realistic.
4. Respond to individual questions via some sort of support process.

Small-to-medium FOSS projects are the best at responding in this order, probably because the same people - or at least people who know each other - are responsible for writing the program, documenting it, and answering user questions. At Big Software Corp., on the other hand, Support, Documentation, and Development are likely to be completely separate groups. The professionalization of documentation is deadly, because you get reams of nearly identical manuals that are pleasantly laid-out and nicely proofread, but completely unaware of realistic user problems. Support is painfully aware of user problems, but they have no process to tell Documentation and Development, "Hey, users keep getting confused here. Can we change the program and the docs to help them? Please? Because we'd really like to quit getting these questions?" (Perhaps some companies do have processes; I can only speculate, but I do know that I don't see evidence of it.)

Oracle, incidentally, only about halfway sucks in these matters, which is pretty good for a company so large. Their docs generally have some good, non-obvious substance, and sometimes - but, alas, only sometimes - troubleshooting information.

In short, I think you need users' pain to efficiently and accurately become developers' and documenters' pain, so that the causes will get fixed. Small FOSS projects have this kind of pain transfer built-in (when the authors publish their email addresses and invite questions). Everybody else should think about how to make it happen for their product.

managing installation requirements by Python version

I always feel guilty using this blog as my LazyWeb, but it works really well, so here we go again...

I'm trying out Oracle Enterprise Linux 5 - basically a clone of RHEL - and trying to get sqlpython installed on it. OEL5 comes with Python 2.4; sqlpython 1.6.5.1 needs Python 2.5. I could take out the 2.5 dependency in sqlpython, but it uses pyparsing. Pyparsing dropped 2.4 compatibility as of 1.5.2.

[EDIT: It turns out that pyparsing 1.5.2 still works on Python 2.4. It emits a scary error message, during easy_install under Python 2.4 -

except ParseException as err:
^
SyntaxError: invalid syntax

but it installs successfully nonetheless. Thanks to Paul McGuire to pointing that out. So my job in this case is simply to release a 2.4-compatible sqlpython 1.6.5.2.]

I could change install_requires=['pyparsing>=1.5.1'] to install_requires=['pyparsing==1.5.1'] in setup.py, but that locks everybody into an obsolete pyparsing whether they need it or not.

I'd like to install_requires=(['pyparsing>=1.5.1'] if python.version >= '2.5' else ['pyparsing==1.5.1']), but that's absolutely imaginary syntax.

Obviously, I could just download a newer Python and install it on my machine, but I'm trying to make sqlpython usable for DBAs who don't have that kind of authority, or who fear to muck around with their environment that way.

I wonder what the smart people do in situations like this?