Slashdot Mirror
A Publication Style Guide for Linux?
Saqib Ali asks: "Apple, publishes the Apple Publications Style Guide, which codifies the way in which Apple documentation uses language. This publication contains information about the specific terms that are used to describe interface elements. It also defines style and usage issues such as how certain terms are used and the preferred capitalization, spelling, and hyphenation of those terms. Some parts of the style guide are excerpted in this chapter to provide quick reference for key elements of the user interface. Whenever you are constructing a language for your application, you can consult the Apple Publications Style Guide to help you to create consistent and usable one. Is there a similar Style Guide for Linux Publications? If not, why not?"
"My interest in this stems from the fact that there is lot of Linux Documentation (including mine) that are not consistent in the style and terminology. So, I would like to propose a creation of a Style Guide for Linux Technical Publication. I think a wiki would be the perfect tool to create this Guide collaboratively. I am willing to host a Wiki @ http://tools.tldp.org (The Linux Documentation Project development server). Is this a good idea? Are people interested in seeing something of this sort?"
Why shouldn't someone make a style guide for everyone? Because Unix doesn't work that way. Let me explain.
The Unix culture loves standards. Standards are yummy. Unix eats standards for between-meal snacks. But what the Unix culture abhores is standards created from whole cloth and handed down from on high.
Why? Is it just because we're just cranky? Well, we can be cranky, but it's not just that.
It's because standards created from whole cloth and handed down from on high are invariably awful. When someone sits down to write a standard, they have the luxury of ignoring vast tracts of difficult territory, of hand-waving away little details like implementation.
That's why the Unix culture prefers its standards to evolve from existing, successful practice. That's why successful RFC's don't create a standard out of nothing, but rather codify something that's already been done. They turn research into production, but the research has to be there first. It has to be something that people see is good, something that with a few tweaks could be a good standard for wider use.
If Unix were to somehow get a unified style guide, it would happen because one of the many excellent existing styles gained the acceptance of the community in general. Then and only then would that style guide be turned into a standard.