<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>Articles&gt;Writing&gt;Style Guides</title>	<link>http://tc.eserver.org/dir/Articles/Writing/Style-Guides</link>
	<description>A listing of the most recently indexed works about Articles and Writing and Style Guides in the field of technical communication (and technical writing).</description>
	<language>en-us</language>
	<copyright>Copyright (c) 2005-08 by the EServer. All rights reserved.</copyright>
	<managingEditor>tclib-editorial@eserver.org (TC Library Editorial Board)</managingEditor>
	<webMaster>webmaster@eserver.org (Geoffrey Sauer)</webMaster>
	<image>
		<url>http://tc.eserver.org/images/newlogo.gif</url>
		<title>Articles&gt;Writing&gt;Style Guides</title>
		<link>http://tc.eserver.org/dir/Articles/Writing/Style-Guides</link>
	</image>
	<item>
		<title>What’s More Important, Content or Process?</title>
		<link>http://tc.eserver.org/35825.html</link>
		<guid>http://tc.eserver.org/35825.html</guid>
		<description>While style guidelines can be useful for maintaining consistency across a set (or several sets) of documentation, the editors that I worked with viewed the style guidelines as sacrosanct. Any deviation, no matter how small, was punishable by a nasty email and a sharply worded note to the offending writer’s manager.</description>
	</item>
	<item>
		<title>Sometimes, You&apos;ve Got to Break the Rules</title>
		<link>http://tc.eserver.org/35788.html</link>
		<guid>http://tc.eserver.org/35788.html</guid>
		<description>Sometimes, you don’t need documentation made up of perfectly-chosen words and phrases. Instead, you need something that can be easily scanned, easily understood, and easily digested. Documentation that distills the main points quickly.</description>
	</item>
	<item>
		<title>Writing Great Documentation: Technical Style</title>
		<link>http://tc.eserver.org/35709.html</link>
		<guid>http://tc.eserver.org/35709.html</guid>
		<description>Now that I’ve discussed what kinds of technical documentation to write, I can move on to the question of how to actually develop a writing style that produces great technical documentation. So how do you learn to write (anything) well? There’s only one answer: you’ll learn to write well if you write. A lot.</description>
	</item>
	<item>
		<title>Style Manuals: The Politics of Selection</title>
		<link>http://tc.eserver.org/35518.html</link>
		<guid>http://tc.eserver.org/35518.html</guid>
		<description>Bette Frick and Betsy Frick discuss how a style manual can save time and money, how to select the proper style manual and get buy-in, and how to create a style guide to use in conjunction with a style manual.</description>
	</item>
	<item>
		<title>Do I Really Need a Style Guide?</title>
		<link>http://tc.eserver.org/35211.html</link>
		<guid>http://tc.eserver.org/35211.html</guid>
		<description>Style guides recommend certain styles. In the domain of technical communication, we refer to guides for writing style, presentation of content in user documentation and technical documents, and graphical user interface of software and web sites.</description>
	</item>
	<item>
		<title>The Missing Manual Authors’ Guide</title>
		<link>http://tc.eserver.org/35126.html</link>
		<guid>http://tc.eserver.org/35126.html</guid>
		<description>This Authors’ Guide tells you everything you need to know to write Missing Manual. It starts out by giving you a brief introduction to the Missing Manual way of explaining things and then takes you through the nitty gritty of style guidelines, figure formatting, and so on.</description>
	</item>
	<item>
		<title>Do I Really Need a Style Guide?</title>
		<link>http://tc.eserver.org/34443.html</link>
		<guid>http://tc.eserver.org/34443.html</guid>
		<description>So, after all, I must follow those infernal style guides. I am straight-jacketed. Am I not?</description>
	</item>
	<item>
		<title>How to Use the Bulleted Lists Properly in Your Technical Document?</title>
		<link>http://tc.eserver.org/34039.html</link>
		<guid>http://tc.eserver.org/34039.html</guid>
		<description>Bulleted lists are important in technical writing. They summarize information in a manner that is easy to read and absorb. Use them whenever you can to get your information across quickly. Bullets are ideal for things-to-do, equipment, sets, collections, cooking ingredients, and all kinds of other lists.</description>
	</item>
	<item>
		<title>One Space Or Two Spaces?</title>
		<link>http://tc.eserver.org/33450.html</link>
		<guid>http://tc.eserver.org/33450.html</guid>
		<description>When I began writing technical documentation and courseware for Guru Labs, I asked a question during training about whether we should be putting two spaces after a period, colon, question mark and exclamation point, or one. The answer shocked me, as I was hoping for the standard answer as a means of teaching the rest of my colleagues. The answer was ONE space, not two. Then, I listened to the argument.</description>
	</item>
	<item>
		<title>Style Guides? Dictionaries? Who Cares?</title>
		<link>http://tc.eserver.org/31331.html</link>
		<guid>http://tc.eserver.org/31331.html</guid>
		<description>You should! Whether you&apos;re a corporate or a freelance communicator, a style guide and a dictionary are among your most important tools. And all the departments in your company or your client&apos;s company should be using the same ones, designated by their communication departments.</description>
	</item>
	<item>
		<title>Intelligent Terminology Management</title>
		<link>http://tc.eserver.org/27272.html</link>
		<guid>http://tc.eserver.org/27272.html</guid>
		<description>Using multiple terms to refer to the same concepts can be a major cause of confusion. Ray explains how to implement a process to consolidate the terminology used by your organization.</description>
	</item>
	<item>
		<title>Social Rules for Creating a Style Guide</title>
		<link>http://tc.eserver.org/26744.html</link>
		<guid>http://tc.eserver.org/26744.html</guid>
		<description>Creating a style guide may initially seem like a terminology affair (&apos;option button&apos; or &apos;radio button&apos; - pick one), but the real challenge lies in persuading the department to adopt new style principles. Some writers will feel threatened by change, and respond in bizarre and unpredictable ways. Whisper campaigns and ambushes may lie in wait for you. Beware, innovative editor! Before you even think about the literary details of style, prepare to do battle with the true Goliaths and Grendyls: the department itself. By following these five rules below, you can avoid an unexpected apocalypse when you reveal the new guide.</description>
	</item>
	<item>
		<title>Keep Spelling Consistent With a Style Sheet</title>
		<link>http://tc.eserver.org/26152.html</link>
		<guid>http://tc.eserver.org/26152.html</guid>
		<description>Consistent spelling and punctuation increases your website&apos;s credibility. Often it&apos;s your decision: &apos;inhouse&apos; or &apos;in-house&apos;, for instance? Either one is correct, but you must use the same punctuation throughout.</description>
	</item>
	<item>
		<title>Standards for Online Content Authors</title>
		<link>http://tc.eserver.org/26128.html</link>
		<guid>http://tc.eserver.org/26128.html</guid>
		<description>The standards on this page include non-technical standards relevant to all web authors and technical standards relevant to some web authors.</description>
	</item>
	<item>
		<title>Microsoft Manual of Style for Technical Publications</title>
		<link>http://tc.eserver.org/26068.html</link>
		<guid>http://tc.eserver.org/26068.html</guid>
		<description>Microsoft is one of the largest software companies in the world. Thus, with their rich experience in documentation it is only natural that they share it with the rest of the IT industry. The Microsoft Manual of Style for Technical Publications, Third Edition (MSTP) is the latest step in this direction and takes care of latest technologies and technical terms.</description>
	</item>
	<item>
		<title>Five FAQs About Business Writing</title>
		<link>http://tc.eserver.org/25785.html</link>
		<guid>http://tc.eserver.org/25785.html</guid>
		<description>A few style guide tips for novice business writers.</description>
	</item>
	<item>
		<title>Necessary Transition</title>
		<link>http://tc.eserver.org/24042.html</link>
		<guid>http://tc.eserver.org/24042.html</guid>
		<description>As writers and editors, we understand instinctively that readers need transitions, but we also work at getting rid of unnecessary words.</description>
	</item>
	<item>
		<title>Verbs with -ize: Efficient or to Be ... Ostracized?</title>
		<link>http://tc.eserver.org/24032.html</link>
		<guid>http://tc.eserver.org/24032.html</guid>
		<description>A discussion of whether neologisms such as &apos;prioritize&apos; have &apos;arrived&apos; yet.</description>
	</item>
	<item>
		<title>Do Technical Writers Need an International Standard for English-Language Spelling?</title>
		<link>http://tc.eserver.org/23501.html</link>
		<guid>http://tc.eserver.org/23501.html</guid>
		<description>He demonstrates how ministers of state who speak different languages often choose English as the most convenient language of communication. He cites the 11-nation European Central Bank in Frankfurt as a typical organization that works only in English. And he notes that many of the journals published by respected international organizations such as the Pasteur Institute also are published in English. TC-Forum is another example.</description>
	</item>
	<item>
		<title>Writing Processes</title>
		<link>http://tc.eserver.org/22230.html</link>
		<guid>http://tc.eserver.org/22230.html</guid>
		<description>Our Writing Guides help you locate information quickly on specific topics. These guides focus on a range of composing processes as well as issues related to the situations in which writers find themselves.</description>
	</item>
	<item>
		<title>Terminology and Spelling for Web-Related Concepts</title>
		<link>http://tc.eserver.org/22135.html</link>
		<guid>http://tc.eserver.org/22135.html</guid>
		<description>Generally speaking, &apos;Web&apos; as a short form of &apos;World Wide Web&apos; is capitalized, with one exception (webmaster). However, your company style may prefer the lower-case version.</description>
	</item>
	<item>
		<title>Use of Hyphens</title>
		<link>http://tc.eserver.org/22134.html</link>
		<guid>http://tc.eserver.org/22134.html</guid>
		<description>This page collects a series of notes from readers of my newsletter, and my responses to those notes, arising from an article in &lt;A HREF=&quot;http://www.jeanweber.com/news/tenews60.htm&quot;&gt;issue 60, 13 May 2002&lt;/A&gt;. I thank those who took the time to write and explain &lt;i&gt;why&lt;/i&gt; some hyphen usage is considered to be correct or incorrect.</description>
	</item>
	<item>
		<title>Choosing the Right Style Manual(s)</title>
		<link>http://tc.eserver.org/20798.html</link>
		<guid>http://tc.eserver.org/20798.html</guid>
		<description>Editors should consider at least four points in selecting, or reevaluating, primary and secondary manuals.</description>
	</item>
	<item>
		<title>Look at Common Style Differences in Choosing Manuals</title>
		<link>http://tc.eserver.org/20797.html</link>
		<guid>http://tc.eserver.org/20797.html</guid>
		<description>Style manuals often differ on important points, and one way to choose a manual is to compare them on some of those points.</description>
	</item>
	<item>
		<title>Appearing for Sentence</title>
		<link>http://tc.eserver.org/20465.html</link>
		<guid>http://tc.eserver.org/20465.html</guid>
		<description>Commas, semi-colons and colons are the sentence tidiers. Used correctly, they&apos;ll give your written language the &apos;punctuation&apos; that pauses, voice modulations and gestures provide when you speak.</description>
	</item>
	<item>
		<title>Are We Agreed?</title>
		<link>http://tc.eserver.org/20469.html</link>
		<guid>http://tc.eserver.org/20469.html</guid>
		<description>&apos;Agreement&apos; refers to elements in a sentence having the same number, gender, case or person. In English, it&apos;s probably an issue only for number (that is, singular vs plural) and case (that is, &apos;I&apos; vs &apos;me&apos;, &apos;he&apos; vs &apos;him&apos; and so on).</description>
	</item>
	<item>
		<title>Capital Punishment</title>
		<link>http://tc.eserver.org/20466.html</link>
		<guid>http://tc.eserver.org/20466.html</guid>
		<description>Many documents suffer from over-capitalisation. The writer sprinkles capitals everywhere in an attempt to make words stand out - with the result that nothing stands out. Here are some simple rules to help you avoid this capital offence.</description>
	</item>
	<item>
		<title>Caught in the Active</title>
		<link>http://tc.eserver.org/20471.html</link>
		<guid>http://tc.eserver.org/20471.html</guid>
		<description>Have you been told, perhaps by your computerised grammar checker, that too many of your sentences are passive? Have you heard the rule of thumb that at least 80 percent of the sentences in any passage should be active? If you&apos;ve had the problem or heard the rule, and wonder what the terms active and passive mean, and why one is good and the other frowned on, this article is for you.</description>
	</item>
	<item>
		<title>The Elusive Apostrophe</title>
		<link>http://tc.eserver.org/20464.html</link>
		<guid>http://tc.eserver.org/20464.html</guid>
		<description>Like teenagers and salespeople, apostrophes are frequently there when they&apos;re not wanted, and not to be seen when they&apos;re needed.</description>
	</item>
	<item>
		<title>Gender-Neutral Language</title>
		<link>http://tc.eserver.org/20472.html</link>
		<guid>http://tc.eserver.org/20472.html</guid>
		<description>One of the most significant changes taking place in English is the rejection of the way that &apos;man&apos; was assumed to include &apos;woman&apos;. Most of us want our writing to be friendly and inclusive. How can we avoid using &apos;man&apos;, &apos;he&apos;, and &apos;his&apos;? </description>
	</item>
	<item>
		<title>Making Sense</title>
		<link>http://tc.eserver.org/20468.html</link>
		<guid>http://tc.eserver.org/20468.html</guid>
		<description>When we are trying to communicate complicated ideas, it is important to be specific. One way to ensure that you will not be misunderstood is to look at your use of &apos;scope&apos;. &apos;Scope&apos; refers to which words go with which to form a &apos;sense unit&apos; in a sentence; for example, which nouns are covered by a particular verb or preposition. Often, poor punctuation or poor sentence construction messes the scope up. Scope isn&apos;t easy to explain, but you can get a handle on it once you have seen a few examples of how it works.</description>
	</item>
	<item>
		<title>Muddled Sentences</title>
		<link>http://tc.eserver.org/20470.html</link>
		<guid>http://tc.eserver.org/20470.html</guid>
		<description>Misplaced modifiers are usually obvious and easily fixed.</description>
	</item>
	<item>
		<title>Reported Speech: a Tense Issue</title>
		<link>http://tc.eserver.org/20474.html</link>
		<guid>http://tc.eserver.org/20474.html</guid>
		<description>The tense of the verb in a statement is, as a general rule, shifted back in time in reported speech.</description>
	</item>
	<item>
		<title>Sentenced to a Cruel End</title>
		<link>http://tc.eserver.org/20467.html</link>
		<guid>http://tc.eserver.org/20467.html</guid>
		<description>A simple definition of a sentence is: a set of words that expresses a complete thought and contains a subject and a predicate. Let&apos;s look at this.</description>
	</item>
	<item>
		<title>Using &apos;Which&apos; and &apos;That&apos;</title>
		<link>http://tc.eserver.org/20473.html</link>
		<guid>http://tc.eserver.org/20473.html</guid>
		<description>&apos;That&apos; clauses form a sense unit with the word they&apos;re attached to, and that&apos;s why they aren&apos;t preceded by a comma.</description>
	</item>
	<item>
		<title>Communicating in Spite of TLAs (Three-Letter Acronyms)</title>
		<link>http://tc.eserver.org/20095.html</link>
		<guid>http://tc.eserver.org/20095.html</guid>
		<description>The unchecked use of acronyms and initialisms in technical writing presents a huge obstacle to clarity and readability.&#xD;Although technical communicators are certainly more&#xD;aware of this problem than are the engineers, scientists,&#xD;and managers with whom they work, they need concrete&#xD;guidelines and at least a small degree of self-righteousness&#xD;on this subject to help them cope with the onslaught. That&#xD;acronyms frustrate communication is well-founded in&#xD;linguistic theory and common sense. Suggestions for&#xD;mitigating their effect include issues of audience, term&#xD;selectivity, frequency and occasion of use, and aesthetics.</description>
	</item>
	<item>
		<title>The Reference Book That &lt;i&gt;Editorial Eye&lt;/i&gt; Built</title>
		<link>http://tc.eserver.org/20002.html</link>
		<guid>http://tc.eserver.org/20002.html</guid>
		<description>About three years ago we were asked whether we would be interested in writing a new and different kind of style manual:&#xD;&#xD;    * In addition to covering all the traditional style topics, such as capitalization and punctuation, it would have chapters on grammar, confusable words, usage (including bias-free language), and all aspects of production, from design and typography to desktop publishing and printing.&#xD;    * Its audience would be the vast majority of working writers and editors, not just those who work with scholarly manuscripts.&#xD;    * It would be written and organized in a friendly, easy-to-read style and reflect the impact of the computer on every aspect of the publishing process. &#xD;&#xD;Although we were a bit cowed at the thought of tackling such a big project -- it turned out to be 836 pages -- we didn&apos;t see how we could turn down the chance to create a guide that was truly useful.</description>
	</item>
	<item>
		<title>When Technical Writers Don&apos;t Write Technically</title>
		<link>http://tc.eserver.org/19667.html</link>
		<guid>http://tc.eserver.org/19667.html</guid>
		<description>Technical writers are often asked to write more than just end-user manuals or online help systems. Due to company&#xD;size, layoffs, or a lack of&#xD;resources, the technical writer&#xD;might also be expected to deliver marketing&#xD;communication collateral, Web&#xD;site content, training materials, and&#xD;more. These additional tasks can daunt&#xD;those who have not been formally&#xD;trained in other writing styles or those&#xD;who do not switch writing styles easily.</description>
	</item>
	<item>
		<title>The Most Obvious Fault in Technical Writing</title>
		<link>http://tc.eserver.org/19636.html</link>
		<guid>http://tc.eserver.org/19636.html</guid>
		<description>The most obvious fault is wordiness. Fortunately, long-windedness is something that editors are particularly well equipped to fix.&#xD;Take a look at our manuals. They are huge, and their very bulk can make them inaccessible, especially when they are not&#xD;equipped with a good index or adequate&#xD;indicia in the corners of each page.</description>
	</item>
	<item>
		<title>The Style Guide is &apos;Dead&apos;: Long Live the Dynamic Style Guide!</title>
		<link>http://tc.eserver.org/19516.html</link>
		<guid>http://tc.eserver.org/19516.html</guid>
		<description>Nobody, least of all an editor like me, would argue that printed style guides are really dead--at least not in the sense that they&apos;re no longer with us and no longer useful. Yet there&apos;s no doubt that printed style guides are looking a little antequated these days. Despite how useful the guides are to writers and editors, they&apos;re simply too static for most writers, and don&apos;t take advantage of computer technology to make the writer&apos;s working life easier. But if you&apos;re thinking that online style guides are inherently better solutions, think again; using the computer to find static information certainly helps, but simply moving a paper guide online only exchanges one form of &apos;static&apos; for another.</description>
	</item>
	<item>
		<title>Writing Consistently Across Media: Ten Proofreading Tips</title>
		<link>http://tc.eserver.org/19019.html</link>
		<guid>http://tc.eserver.org/19019.html</guid>
		<description>Last time I wrote about consistency in online writing. Soon after, I received an email from Leslie Drechsler, a reader in Tustin, CA: &apos;As a Marketing Communications Specialist, I&apos;d love to hear your ideas on how to successfully implement consistency in an established business,&apos; she wrote. &apos;I thought developing a company style guide would solve the problem. But perhaps there are other ways to approach it.&#xD;&#xD;&apos;Perhaps this could be the subject of another article.&apos;&#xD;&#xD;Here&apos;s that article, Leslie. </description>
	</item>
	<item>
		<title>Frequently Asked Questions About English</title>
		<link>http://tc.eserver.org/18924.html</link>
		<guid>http://tc.eserver.org/18924.html</guid>
		<description>Asterisks.com answers some frequently asked questions about English usage.</description>
	</item>
	<item>
		<title>Style Sheets: The Abbreviated Answer</title>
		<link>http://tc.eserver.org/18872.html</link>
		<guid>http://tc.eserver.org/18872.html</guid>
		<description>As a project moves from writer to editor to designer and ack again, style sheets (abbreviated versions of style gides) offer quick access to answers during documentation development. Style sheets provide consistency, give a quick-reference point, set a project’s style from the beginning, eliminate confusion on major style points, and serve as a double check during revision. Designed specifically for a project, style sheet formats include laminated sheets and standees, and content ranges from grammar references to contact information.</description>
	</item>
	<item>
		<title>Technical Writing Rules You Didn&apos;t Learn in RHET 101</title>
		<link>http://tc.eserver.org/18463.html</link>
		<guid>http://tc.eserver.org/18463.html</guid>
		<description>To hyphenate or not to hyphenate, that is the question.  As compound nouns evolve over time in Eng-&#xD;lish, they gradually move from being written &apos;open&apos; (data base) to being hyphenated (data-base) to&#xD;being written &apos;closed&apos; (database).  Just where your particular word might be in its evolution is often un-&#xD;clear and subject to the inscrutable and highly individual logic of copy editors.  Consult a recent edition of&#xD;a standard dictionary.</description>
	</item>
	<item>
		<title>Understanding the Importance of Style Guides</title>
		<link>http://tc.eserver.org/14937.html</link>
		<guid>http://tc.eserver.org/14937.html</guid>
		<description>Style guides describe conventions for virtually every aspect of writing, ranging from such things as spelling, punctuation, and word usage, to structural and formatting issues. With the myriad of style guides in use, the dilemma for many writers is deciding which one to learn and apply in the trade.&#xD;&#xD;The answer to this is easy: learn at least one style guide thoroughly and keep a selected few others for backup. In the course of recruiting technical and generalist writers and editors for nearly a decade, I am sometimes shocked at the low level of familiarity with long-established style guides by people who claim to be seasoned professionals in this business. The reality is that it is plainly obvious to spot writers who “claim” to know a style guide and those who have actually taken the time to study it. The proof is in the pudding, as they say. The quality and consistency of a writer’s or editor’s output is the litmus test to how proficient he or she is in applying a given style guide.</description>
	</item>
	<item>
		<title>The Style Guide is Dead: Long Live the Dynamic Style Guide</title>
		<link>http://tc.eserver.org/14629.html</link>
		<guid>http://tc.eserver.org/14629.html</guid>
		<description>Arguing that printed style guides are too static to be useful, Hart recommends using a dynamic style guide, a system of templates, macros, and reference materials that actually guides writers through their work. The article also advocates direct interaction between editors and writers as a non-technical approach to a dynamic style.</description>
	</item>
	<item>
		<title>The Passive In Technical and Scientific Writing</title>
		<link>http://tc.eserver.org/13975.html</link>
		<guid>http://tc.eserver.org/13975.html</guid>
		<description>Almost every discussion of technical or scientific style mentions the passive voice, usually as a stylistic evil to avoid. While I doubt that many of us would endorse such extreme prescriptions as &apos;Always use the active voice,&apos; or &apos;A writer will almost automatically improve his style when he shifts from passive to active constructions,&apos; we may be more ready to accept Freedman&apos;s position in &apos;The Seven Sins of Technical Writing.&apos; His Sin 6 is &apos;the Deadly Passive, or, better, deadening passive; it takes the life out of writing, making everything impersonal, eternal, remote and dead,&apos;3 but he adds that &apos;frequently, of course, the passive is not a sin and not deadly, for there simply is no active agent and the material must be put impersonally.&apos;</description>
	</item>
	<item>
		<title>The Rhetoric of the Paragraph: A Reconsideration</title>
		<link>http://tc.eserver.org/13976.html</link>
		<guid>http://tc.eserver.org/13976.html</guid>
		<description>Efforts to define the fundamental structures that enable meaning in discourse have a long history, beginning with ancient speculation. Classical logic, rhetoric, and grammar imposed restrictions on the processes of composing, as well as the shapes of finished texts, in order to safeguard the truth by attending to prerequisites for its effective communication. From earliest times, a concern for vindicating some larger moral order, and for teaching others to appreciate it, has often motivated pronouncements on the nature of verbal form. From Quintilian to the present, for example, teacher-scholars have striven to insure that logical and aesthetic values celebrated in the classical doctrine of decorum are made suitably manifest in student performance, as though to enforce publicly accepted styles of thought and action by reference to acceptable forms of language.</description>
	</item>
	<item>
		<title>Grammar, Punctuation, Spelling</title>
		<link>http://tc.eserver.org/13719.html</link>
		<guid>http://tc.eserver.org/13719.html</guid>
		<description>The Web abounds with sites teaching grammar, punctuation, and spelling. Not surprisingly, most of these sites are provided by educational institutions, teachers, or business-writing consultants, presumably to make up for the lack of grammar teaching in so many school systems for the past several decades. Some are tutorials (masquerading as style guides) for technical communicators. Here are a few sites that I have found useful or that other people have recommended to me.</description>
	</item>
	<item>
		<title>Gender-Neutral Technical Writing</title>
		<link>http://tc.eserver.org/13363.html</link>
		<guid>http://tc.eserver.org/13363.html</guid>
		<description>Gender-neutral writing uses language that does not stereotype either sex nor appear to be referring to only one sex when that is not the writer&apos;s intention. In this article, you&apos;ll see why gender-neutral writing is important for technical writers to use, what gender-neutral writing is not, and how you can use gender-neutral writing in the documents you develop.</description>
	</item>
	<item>
		<title>Editing for Gender Neutrality</title>
		<link>http://tc.eserver.org/10807.html</link>
		<guid>http://tc.eserver.org/10807.html</guid>
		<description>How to be politically correct without mangling the English language. The goal is that the reader should not notice the writing.  </description>
	</item>
	<atom:link href="http://tc.eserver.org/dir/Articles/Writing/Style-Guides.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>