I'd like to put in my two cents' worth on the matter of documentation. I'm not an expert like Carla Schroder or Bruce Byfield, the two who brought up the topic, but I'm the very sort of person who needs it most, still pretty much of a newbie, but one who learns best by reading. It's a good thing reading is my preferred mode of learning, because as it happens I've not personally met a real live human who is a Linux expert, one who could give me over-the-shoulder instructions as I muddle through.

Other Stories on LinuxPlanet Fixing Strange and Peculiar Filenames in Linux Mastering Characters Sets in Linux (Weird Characters, part 2) Configuring Strong Wi-fi (802.1x) Authentication in Linux Character Sets in Linux or: Why do I See Those Weird Characters? Linux Bug #1: Bad Documentation (part 2)

It occurs to me that there must be a whole lot of people out in the real world who are not unlike me. They have used their PCs long enough that they're familiar with all the processes they usually use, but they suspect there's a lot more stuff they could do if only they knew how. After a few tentative experiments with what they've been using, they learn that the motto of Windows is You Can't Get There From Here.

Books!

That's where documentation gets dicey. Sure, you can do as instructed, but that's no different from “click on this, click on that”. It's an instruction, telling you HOW but not WHY. Real documentation should give something more, not necessarily a full account of every detail, but at least an overview of what processes are involved and how they operate. I remember lurking on user forums long before I ever attempted an installation, trying to get some background. I soon learned that there were just a few really helpful gurus who would put their instructions in the form “What you use is (command), and what that does is (operation) on the (target) to make it (result). The way you type that into the terminal is...”

Why and How

Next: Not Clueless, but Not Confident »