Interesting to see this posted, as this wasn't particularly widely used even at Red Hat. And the timestamps for revision history show you that it's of a certain era.<p>What I would recommend is something like the MailChimp style guide: <a href="http://styleguide.mailchimp.com/" rel="nofollow">http://styleguide.mailchimp.com/</a><p>The upside here is that those teams are small and centralised and obsessive over the tone of their product. The same goes for other SaaS companies like Intercom (Elizabeth is an amazing content strategist). They have to be.<p>For context, I'm an alumni of the Red Hat content team, which I joined from a corporate background and was frustrated to see the team relied on the IBM Style Guide. I pushed for Red Hat to make a canonical open source style guide, as I researched common patterns across engineering and tech writing that can create disparity in UIs or APIs if one group ends up writing one way, and another the other.<p>For various reasons this wasn't a feasible project so my team focused on tooling instead (creating the PressGang CCMS internally, and then I took funding from one of the Red Hat founders to launch Corilla, a collaborative publishing tool for technical writers considered "the GitHub for content teams").<p>This style guide here is at best a reference for the kinds of things you might want to consider if you're building one for open source. In my era this guide was pretty useless though, as the content team voted for a strange hierarchy of style guides going from the IBM, then the CMoS, then the American Heritage dictionary, and then this guide. Or maybe some variation - nobody paid attention and we all just used the IBM and had opinions.<p>This is why the smaller SaaS companies make the best style guides (and the MailChimp one is not only creative commons so you can use it too, but not stuck in the awful DocBook XML format!).
This will be incredibly useful, thanks for posting. Now I need to learn what the GNU Free Documentation License allows, how/if it can be reused or derived.<p>Certainly, in my experience and where I currently am, most of the texts that are published externally receives good editing, but many communications and documents are not, and 90% of the documentation is for internal purposes. This guide might just make the documentation a bit improved and more fun.<p>Also I appreciate the details about appropriate use of "$" or "#" for prompts, to name one. That is the way one would expect since at least the days with Bourne shell in the 80s, but I have not seen it spelled out.