Here's something novel: how about letting a (gasp!) computer do it - as in divide the geopolitical space into the appropriate number of areas, each of which has a minimum outline or area. The idea is to eliminate gerrymandering, biases (political, ethnic, social, etc), and so on.

Which administration gets the blame for that?

Most all of my stuff is low-power, so powering a metric buttload (1.2X an English buttload) of devices from a single outlet is no biggie. I invariably need more places to plug things in than the current capacity of the outlet can handle.

Keep in mind that a lot of micro-based electronics (e.g. microwaves, fridges) are using microcontrollers, versus microprocessors.

Read what I wrote again. Nowhere in there is any request for any kind of deadline; the only thing even approximating any kind of time constraint is the last - where I explicitly use "not even a hint" as a scale. Even something as vague as "three or four months, maybe", or "early next year" would be sufficient.

but too many sites make it too much of a PITA:

• I don't think I should have to jump through a bunch of hoops (Bugzilla/Redhat!) to tell someone there's a problem with their software;
• I don't want to be on the mailing list for all the messages that get passed around while they try to figure out who's supposed to fix it, and what the problem is;
• Getting an email back that cops an attitude, regardless of how polite I was;
• Trying to describe something that a simple screen capture shows;
• Want me to sign up for a mailing list to even report it;
• Projects that don't have any info on who to report bugs TO;
• Reporting a bug, only to be told that it's a problem with Redhat/KDE/whatever, and they don't (and never will) test on that combo;
• Reporting a bug, only to be told that the project has been handed off to someone, without saying who or how to reach them (it's not on the project site);
• Reporting a bug, only to be told "Yeah, we're gonna fix that in the new version" with not even a hint as to when that'll happen.

Roger that. Stereotypes happen precisely because of averaged observations. And before I get flamed, note that "averaged" bit.

It isn't just ONE thing, or even mostly one. It's varying permutations of varying degrees of all of the above, depending on the user, OS, risk(s), and solutions available.

True. But A) the user doesn't need to read the whole book to use the index to find references to X, and B) that doesn't apply to a half-dozen people working on SuperHandyUtility in their spare time.

Again, much of what you write is most appropriate for large projects, like an entire OS. My comments are directed toward those that are simply writing a single application. As for users reporting bugs, anything of the "my mouse stopped" without amplifying information goes to the bitbucket. Be nice and tell them that without more info (application, what they were doing, the usual suspects), nothing you can do. But don't make them register with Bugzilla and go through all the rigmarole to report (for example) that a dialog button is mostly covered by the label next to it.

Again, true enough for a distro. But I recently had some questions about an active application; when I emailed the author, what I got back was "Oh, somebody else has taken that over; I don't have anything to do with it any more", with no mention of who had picked it up or how they could be reached. Website was as old as the negligible documentation (i.e. about 3 major revs behind, which is ANOTHER peeve...).

I'm sorry to say that I was a Windows user from 2.0 until shortly after XP released, and while there were indeed some butt-ugly apps written with other toolkits, they still ran. I've had several cases where source code wouldn't compile because of hard-coded dependencies on a specific (obscure!) Gnome library (I use KDE). The author? "Oh, well, I don't use KDE, so I didn't bother testing it. Maybe someone else has ported it over...".

It doesn't take but one or two of the above experiences with an application for someone to say it isn't worth the bother, or that open source isn't any good.

THIS

IRC channels, wikis, blogs, mailing lists (and their archives), a set of web pages... none of these is a valid substitute for actual documentation that a user can actually find an answer in. Fine, if you feel the need to be high-tech, edgy, l33t, or whatever, make it a pdf or downloadable html pages. Do not force users to have to jump through any 'extra' hoops to try and get help with a problem they may be having. I'd also add:

• If you get some variation of the same question over and over again, you need to (better) explain it in the docs.
• If a user finds an actual bug, don't make them have to sign up for some service or other that they'll (hopefully) only need once (i.e. Bugzilla) to report it. Maybe have a bugs@myproject.org to triage.
• CLEARLY provide SOME way to contact SOMEBODY actively involved with the project. Keep this updated if you don't want to be getting annoyed emails five years from now.
• If it's a Linux app, it would be kinda nice if it worked/looked good under ANY desktop, not just your personal favorite.