Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
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.
The closest thing to a "Fedora manual" that I have seen is a 900+ page book
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.
If only that were still feasible; I would love such a solution, but the volume has grown too large in recent years.
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.
We almost always do,
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...).
Why restrict this to Linux? The problem of different toolkits that do not integrate well with the OS is pretty universal.
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.
One of the reasons I avoid all this open source stuff is that most of it is badly documented
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 email@example.com 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.
Link to Original Source
Link to Original Source