<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
categoryallspace2-Technical Editing
<channel>
	<title>Technical Editing</title>	<link>http://tc.eserver.org/dir/Technical-Editing</link>
	<description>A directory of resources about technical editing in the field of technical communication.</description>
	<language>en-us</language>
	<atom:link href="http://tc.eserver.org/dir/Technical-Editing.xml" rel="self" type="application/rss+xml" />
	<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>Technical Editing</title>
		<link>http://tc.eserver.org/dir/Technical-Editing</link>
	</image>
	<item>
		<title>Transline tecNews</title>
		<link>http://tc.eserver.org/31174.html</link>
		<guid>http://tc.eserver.org/31174.html</guid>
		<description>Kontinuierlich Nachrichten, Hintergrundberichte und Interviews rund um die technische Dokumentation und Redaktion, sowie die technische Übersetzung. In der Nachfolge der doculine news.</description>
	</item>
	<item>
		<title>Developing Indexes</title>
		<link>http://tc.eserver.org/31098.html</link>
		<guid>http://tc.eserver.org/31098.html</guid>
		<description>As a technical writer, you&apos;ll typically have to create indexes for the print books and for online helps you develop. The type of index we mean here is the classic back-of-book index that shows page numbers on which topics and subtopics occur within the book. An online index is much the same except that you supply hypertext links rather than page numbers.</description>
	</item>
	<item>
		<title>Hockey Sticks and User Assistance: Writing in Times of Resource Constraints</title>
		<link>http://tc.eserver.org/30818.html</link>
		<guid>http://tc.eserver.org/30818.html</guid>
		<description>If you have all the resources you need, do the very best job you can in all respects. But if your resources are tight, ask yourself whether you are writing the essential stuff at a level of quality users will notice. Also, ask whether the value of the documentation you are producing aligns with the economic pressures on your company.</description>
	</item>
	<item>
		<title>Editing Yourself</title>
		<link>http://tc.eserver.org/30361.html</link>
		<guid>http://tc.eserver.org/30361.html</guid>
		<description>Here are some tips that helped me edit my own writing.</description>
	</item>
	<item>
		<title>Rhetoric 5/4304: Technical Style and Editing</title>
		<link>http://tc.eserver.org/29787.html</link>
		<guid>http://tc.eserver.org/29787.html</guid>
		<description>Rhetoric 5/4304 emphasizes the editing process of technical materials, which includes the following: knowing different levels of editing, copyediting and proofreading, editing for organization and content, editing graphics, editing for effective document design, and learning how to work effectively and efficiently as a team member. We&apos;ll do hands-on editing to give you necessary knowledge/practice and to develop your editing skills.</description>
	</item>
	<item>
		<title>Experiencing Technical Writing as Textual Coordination</title>
		<link>http://tc.eserver.org/29647.html</link>
		<guid>http://tc.eserver.org/29647.html</guid>
		<description>This paper describes a recent study of how of four technical writers managed the many artifacts (existing texts and information technologies for producing and manipulating text) that mediated their writing process. The author describes the study and characterizes several recurrent patterns of mediation, including textual reuse, remediation of information, and the staging of texts and software programs. The author describes the value of a repertoire of information technologies to technical writing and argues that technological skill should be considered a core competency of the field.</description>
	</item>
	<item>
		<title>Syntax or Sin Tax: Which Should an Editor Choose?</title>
		<link>http://tc.eserver.org/29689.html</link>
		<guid>http://tc.eserver.org/29689.html</guid>
		<description>Proficiency and accuracy are necessary to edit technical communication, but both can be diminished by the conflict of standards and rules from respected sources. This difficulty is further compounded with the differing expectations of audiences, employers, and companies. To resolve potential problems, editors need to refresh their basic skills through workshops, professional journal articles, and the study of updated authoritative sources. Editors then need to address their audience expectations by developing appropriate style guides. By focusing upon the needs of the audience, editors draw upon a variety of sources, some of which may not agree upon the same standards and rules. In such cases, the editor may also break or bend rules to achieve the consistent, accurate communications that best serve the individual audience.</description>
	</item>
	<item>
		<title>The Art Of Editing: User&apos;s Guides Versus Technical Documents</title>
		<link>http://tc.eserver.org/30287.html</link>
		<guid>http://tc.eserver.org/30287.html</guid>
		<description>While contemplating topic areas for a presentation at this year&apos;s conference, our biggest challenge was the fact that not all technical editors edit the same type of documents. Presentations at STC conferences are heavily concentrated toward user documentation and software instructional manuals. With that as our prime focus, we identified six common elements that we both consider as we edit a document. We then compared our methods of approaching these elements. One of us edits primarily user&apos;s guides and procedural manuals; the other edits scientific and technical documents.</description>
	</item>
	<item>
		<title>Offres d&apos;emploi</title>
		<link>http://tc.eserver.org/29520.html</link>
		<guid>http://tc.eserver.org/29520.html</guid>
		<description>Une collection de listes de carrière, éditée au coin des rédacteurs techniques.</description>
	</item>
	<item>
		<title>Le Rédacteur Technique</title>
		<link>http://tc.eserver.org/29519.html</link>
		<guid>http://tc.eserver.org/29519.html</guid>
		<description>Un weblog qui cherche à servir de coin aux auteurs techniques.</description>
	</item>
	<item>
		<title>So You Want to be an Editor?</title>
		<link>http://tc.eserver.org/29417.html</link>
		<guid>http://tc.eserver.org/29417.html</guid>
		<description>Most technical communicators are hired primarily as writers and creators of information, but despite this, many of us must learn how to edit at some point. Whether the reasons are good (to prepare better first drafts for review) or bad (your employer won&apos;t pay for a full-time editorial position), the reality is inescapable: at some point you&apos;re going to have to edit your own writing or that of a colleague. The problem is that editing requires an entirely different mindset than writing, and it&apos;s difficult to make the mental shift from creating to revising.</description>
	</item>
	<item>
		<title>Substantive and Technical Editing: How Far Do You Go?</title>
		<link>http://tc.eserver.org/29256.html</link>
		<guid>http://tc.eserver.org/29256.html</guid>
		<description>Authors who cannot answer queries create a barrier to improvement of manuscripts. Some authors resist the idea that their papers might need major changes. Other authors depend on the editor to make changes that the author can and should make. Language barriers can require creative solutions. Also, there is the question of how far to go as an editor in reframing a report (for example, should an editor reframe the purpose of a paper?) and in correcting an author&apos;s errors (for example, a claim of a trend when none is shown).</description>
	</item>
	<item>
		<title>Core Principles of Information Architecture</title>
		<link>http://tc.eserver.org/28826.html</link>
		<guid>http://tc.eserver.org/28826.html</guid>
		<description>Technical editing is like information architecture. As technical editors, we complete development edits and usability edits to ensure organization, labeling, navigation and search &#xD;meet the users&apos; needs. As information architects, we are involved with &quot;the design of organization, labeling, navigation, and searching systems to help people find and manage information more successfully.&quot;</description>
	</item>
	<item>
		<title>A SIG Transformation: Past, Present, and Future</title>
		<link>http://tc.eserver.org/28164.html</link>
		<guid>http://tc.eserver.org/28164.html</guid>
		<description>A recent discussion about the STC&apos;s Technical Editing Special Interest Group (TE SIG) provided insights into the evolving role of communities of interest in the Society. At a meeting of the Carolina Chapter&apos;s local TE SIG, Diane Feldman, who is the manager of the Society-level SIG, provided members with an update on SIG activities.</description>
	</item>
	<item>
		<title>Now That You&apos;ve Got a Double Agent, What Do You Do With &apos;Em?</title>
		<link>http://tc.eserver.org/27461.html</link>
		<guid>http://tc.eserver.org/27461.html</guid>
		<description>Having demonstrated the importance of acquiring a double agent for writing projects, we now want to explain the best ways to successfully indoctrinate a double agent. This paper will help you prepare for, orient, train, and become a mentor for a double agent to help make him or her an effective member of your writing team.</description>
	</item>
	<item>
		<title>Technical and Professional Editing</title>
		<link>http://tc.eserver.org/27357.html</link>
		<guid>http://tc.eserver.org/27357.html</guid>
		<description>In this class, you will learn how to edit technical documents, from proofreading for errors at the surface to ensuring that the document contains appropriate content, organization, and visuals for its audiences. Students will also learn how to use traditional editing marks, editing functions within word processors, and principles of layout and design.</description>
	</item>
	<item>
		<title>Technical Editing</title>
		<link>http://tc.eserver.org/27356.html</link>
		<guid>http://tc.eserver.org/27356.html</guid>
		<description>In this class, students will learn how to edit technical documents, from proofreading for errors at the surface to ensuring that the document contains appropriate content, organization, and visuals for its audiences. Students will also learn how to use traditional editing marks, editing functions within word processors, and principles of layout and design. Finally, students will learn about the profession of editing and develop pieces to support their careers.</description>
	</item>
	<item>
		<title>Electronic Reporting of ANSYS Results</title>
		<link>http://tc.eserver.org/27092.html</link>
		<guid>http://tc.eserver.org/27092.html</guid>
		<description>This documents several ways to get ANSYS plots into your reports without getting out of your chair.</description>
	</item>
	<item>
		<title>Technischer Redakteur</title>
		<link>http://tc.eserver.org/26967.html</link>
		<guid>http://tc.eserver.org/26967.html</guid>
		<description>Der Technische Redakteur erstellt und aktualisiert aussagefähige, umsetzbare, verständliche technische Dokumentationen aller Art.</description>
	</item>
	<item>
		<title>Ressourcen f&amp;uuml;r Technische Redakteure und User Assistance Spezialisten</title>
		<link>http://tc.eserver.org/26464.html</link>
		<guid>http://tc.eserver.org/26464.html</guid>
		<description>Informationen, Fachartikel, Links, Downloads, Arbeitshilfen und Dienstleistungen zu den Themen User Assistance, Technische Dokumentation, Software-Dokumentation (Technische Dokumentation für Software, Online-Hilfen, Online-Dokumentation), Single Source Publishing (Single Sourcing, Cross Media Publishing)</description>
	</item>
	<item>
		<title>Editing That Works</title>
		<link>http://tc.eserver.org/26119.html</link>
		<guid>http://tc.eserver.org/26119.html</guid>
		<description>Collection of principles that can also form a process for editing web content to make it usable.</description>
	</item>
	<item>
		<title>Indexing Technical Documents: An Interview with Lori Lathrop</title>
		<link>http://tc.eserver.org/26025.html</link>
		<guid>http://tc.eserver.org/26025.html</guid>
		<description>Indexes are as important to your documentation as your documentation is to the product. Just as it would be difficult, if not impossible, for people to use your product without any documentation, it is equally difficult for people to use documentation without a good index.</description>
	</item>
	<item>
		<title>Controlled Languages in Industry</title>
		<link>http://tc.eserver.org/25310.html</link>
		<guid>http://tc.eserver.org/25310.html</guid>
		<description>A Controlled Language is a form of language with special restrictions on grammar, style, and vocabulary usage. Typically, the restrictions are placed on technical documents, including instructions, procedures, descriptions, reports, and cautions. One might consider formal written English to be the ultimate Controlled Language: a form of English with restricted word and grammar usages, but a standard too broad and too variable for use in highly technical domains. Whereas formal written English applies to society as a whole, CLs apply to the specialized sublanguages of particular domains.</description>
	</item>
	<item>
		<title>Substantive Editing: With an Eye on the User</title>
		<link>http://tc.eserver.org/24910.html</link>
		<guid>http://tc.eserver.org/24910.html</guid>
		<description>This workshop focuses on substantive editing with workshop materials that show fast and easy ways to analyze a piece of writing, especially writing that needs the concentrated effort of both the editor and the writer to turn it into a usable document. The workshop is practical in its focus providing tips, checklists, and techniques for approaching material that needs a heavy substantive edit.</description>
	</item>
	<item>
		<title>Seven Discrete Principles for Content Editing</title>
		<link>http://tc.eserver.org/24611.html</link>
		<guid>http://tc.eserver.org/24611.html</guid>
		<description>One of many lessons I learned in 30 years of Technical Editing was to separate myself from the crowd by learning to edit technical content, using seven reader-oriented techniques.</description>
	</item>
	<item>
		<title>Mystery Fiction and the Technical Communicator: The Editor&apos;s Role</title>
		<link>http://tc.eserver.org/24352.html</link>
		<guid>http://tc.eserver.org/24352.html</guid>
		<description>Technical editors can learn much from editors of mystery fiction. Both orchestrate elaborate game-playing and structuring as they serve as the reader&apos;s advocate.</description>
	</item>
	<item>
		<title>Ask the Indexer: Get Answers to your Indexing Questions from Experienced Technical Indexers</title>
		<link>http://tc.eserver.org/23799.html</link>
		<guid>http://tc.eserver.org/23799.html</guid>
		<description>After brief introductions by 4 panelists who are all members of the Indexing SIG (and experienced indexers and technical writers), we&#xD;plan to discuss Frequently Asked Questions (FAQs) about indexing, and allow plenty of time for questions.</description>
	</item>
	<item>
		<title>Knowledge Management - Challenge for Technical Editors</title>
		<link>http://tc.eserver.org/23453.html</link>
		<guid>http://tc.eserver.org/23453.html</guid>
		<description>Knowledge management - is it a challenge for technical editors? Shouldn&apos;t knowledge management be more than just taken for granted in technical editing? And isn&apos;t the technical editor also the knowledge manager, per se?</description>
	</item>
	<item>
		<title>Technical Translation: Craft, Not Commodity</title>
		<link>http://tc.eserver.org/22791.html</link>
		<guid>http://tc.eserver.org/22791.html</guid>
		<description>Describes the work of translators and suggests strategies buyers can use to find the best translator for their needs.</description>
	</item>
	<item>
		<title>Grammar Stammer</title>
		<link>http://tc.eserver.org/22691.html</link>
		<guid>http://tc.eserver.org/22691.html</guid>
		<description>Don&apos;t you think that it is a tragedy that 95 percent of the people who desire to be technical writers have a poor command over the language? I am sure all of us make a mistake or two, once in a while. But to make it in every sentence and paragraph shows utter disrespect for readers.</description>
	</item>
	<item>
		<title>Learning the Fine Art of Reviewing</title>
		<link>http://tc.eserver.org/22690.html</link>
		<guid>http://tc.eserver.org/22690.html</guid>
		<description>If you asked me what the most painful part of being a technical writer is, my answer would be: &apos;Getting reviews on time. Getting good feedback and inputs on your work.&apos; For me technical writing has been very pleasurable because I hardly got any review comments. My morale has therefore been very high. Project managers, developers and others are so busy trying to come up with good software (read trying to fix all the goof-ups and bugs!) that they usually tend to give documentation lesser importance. User manuals, who reads them anyway? We do not have time for it!</description>
	</item>
	<item>
		<title>One Hundred Simple Tech Writing Errors</title>
		<link>http://tc.eserver.org/22687.html</link>
		<guid>http://tc.eserver.org/22687.html</guid>
		<description>Here are the 100 writing errors that the author has encountered in his experience. (Followed by the subsequent article &apos;&lt;a href=&quot;http://tc.eserver.org/22688.html&quot;&gt;Ten More Errors in Technical Writing&lt;/a&gt;.&apos;)</description>
	</item>
	<item>
		<title>Ten More Errors in Technical Writing</title>
		<link>http://tc.eserver.org/22688.html</link>
		<guid>http://tc.eserver.org/22688.html</guid>
		<description>So, well, here are 10 more errors. This time we will focus on grammar and punctuation. Most of these are simplistic and obvious. But then they are too common. As usual, I have slipped in some content for the advanced writers too. (This article is a follow-up to &apos;&lt;a href=&quot;http://tc.eserver.org/22687.html&quot;&gt;One Hundred Simple Tech Writing Errors&#xD;&lt;/a&gt;.)</description>
	</item>
	<item>
		<title>Technical Editing: Discussion and Application Materials</title>
		<link>http://tc.eserver.org/22188.html</link>
		<guid>http://tc.eserver.org/22188.html</guid>
		<description>Assignments to complement Carolyn Rude&apos;s &lt;i&gt;Technical Editing&lt;/i&gt; textbook. Instructors can load the materials onto a server or student disks so that the students can respond at the  computer.</description>
	</item>
	<item>
		<title>Alternatives to the Paragraph</title>
		<link>http://tc.eserver.org/22128.html</link>
		<guid>http://tc.eserver.org/22128.html</guid>
		<description>&apos;It&apos;s all in the manual.&apos; How many times have you heard that - or said it in frustration? After all, when you are the person who wrote the manual, you know that all the answers are there. But time and again readers can&apos;t find what they need to know, or don&apos;t understand the material. Before you blame the reader, look again at how you&apos;ve presented the material.</description>
	</item>
	<item>
		<title>Editing Tables of Data</title>
		<link>http://tc.eserver.org/22125.html</link>
		<guid>http://tc.eserver.org/22125.html</guid>
		<description>Tables should allow readers to easily and accurately: see what subject matter and variables are being described; find out absolute values; observe relationships between variables. When you edit a table, it is useful to assess just how well it achieves these ends. Readers will feel confident with your table if they can quickly navigate around and absorb the data.</description>
	</item>
	<item>
		<title>The Role of the Editor in the Technical Writing Team</title>
		<link>http://tc.eserver.org/22113.html</link>
		<guid>http://tc.eserver.org/22113.html</guid>
		<description>Editing today covers far more than printed materials. In this discussion, I am assuming a technical editor may be required to deal with: printed materials (for example, books, pamphlets, quick reference cards); electronic (for example, online documentation, online help, web pages); video scripts; computer-based training materials. I am also assuming that the audience for the material being edited is not comprised of other technical people; or if it is, the editor is not the person responsible for ensuring the technical accuracy of the material.</description>
	</item>
	<item>
		<title>Working Electronically</title>
		<link>http://tc.eserver.org/22117.html</link>
		<guid>http://tc.eserver.org/22117.html</guid>
		<description>Editors need to know some basic techniques for dealing with files if they are going to be editing them electronically. These techniques apply to files in any format, but exactly what you do depends on which word-processor, desktop publishing program, help authoring system, or other software you are using.</description>
	</item>
	<item>
		<title>Technical Editing</title>
		<link>http://tc.eserver.org/21702.html</link>
		<guid>http://tc.eserver.org/21702.html</guid>
		<description>A brief perspective on technical editing.</description>
	</item>
	<item>
		<title>Ressourcen für Kollegen</title>
		<link>http://tc.eserver.org/21433.html</link>
		<guid>http://tc.eserver.org/21433.html</guid>
		<description>Von dieser Seite aus erreichen Sie ganz konzentriert Angebote im Internet, die für Übersetzer und Technische Redakteure besonders interessant sind. Naürlich gibt es auch in dieser Linklisten, getrennt für Übersetzer und Technische Redakteure. Bei Bedarf erscheinen Themen auch in beiden Listen, Sie können sich also wohl auf eine der Listen konzentrieren.</description>
	</item>
	<item>
		<title>Technikredaktor</title>
		<link>http://tc.eserver.org/21456.html</link>
		<guid>http://tc.eserver.org/21456.html</guid>
		<description>Technikredaktor möchte die Idee weiterverfolgen, Informationen zum Umfeld der technischen Dokumentation zu sammeln und einem breiteren Publikum zur Verfügung zu stellen.</description>
	</item>
	<item>
		<title>Editing Your Own Documentation</title>
		<link>http://tc.eserver.org/21411.html</link>
		<guid>http://tc.eserver.org/21411.html</guid>
		<description>Technical writers sometimes fall into the trap of thinking that the user is stupid. I have often heard technical writers say things like &apos;well, if the user can&apos;t figure that out, maybe he’s in the wrong job!&apos;</description>
	</item>
	<item>
		<title>Indexing Technical Documents</title>
		<link>http://tc.eserver.org/21380.html</link>
		<guid>http://tc.eserver.org/21380.html</guid>
		<description>If a document contains the information that a reader needs, but if the reader cannot find that information, then the document is useless. Worse than useless, it’s a hindrance. If I know that some information is not available, I won’t waste my time looking for it. However, if I think the information is available, and if I can’t find it after a period of fruitless searching, all I will have achieved is frustration.</description>
	</item>
	<item>
		<title>Coping with Wordslaughter and the &quot;Good Enough&quot; Syndrome</title>
		<link>http://tc.eserver.org/21317.html</link>
		<guid>http://tc.eserver.org/21317.html</guid>
		<description>Connatser provides advice for technical editors who aren&apos;t granted enough time or money to perform extensive revisions on poorly written documents.</description>
	</item>
	<item>
		<title>Let Editors Edit&#xD;</title>
		<link>http://tc.eserver.org/21305.html</link>
		<guid>http://tc.eserver.org/21305.html</guid>
		<description>We technician editors need not worry about declining employment if we can show companies the value of the technology of English. If we can demonstrate how editors can make turgid technical authors communicate better with words, sentences, paragraphs, and overall organization, we will be in demand for jobs that are more prestigious and careers that are infinitely more interesting -- because the need is so great.</description>
	</item>
	<item>
		<title>The ABCs of Writing a Technical Glossary</title>
		<link>http://tc.eserver.org/21216.html</link>
		<guid>http://tc.eserver.org/21216.html</guid>
		<description>This article identifies and explains format rules, style rules, and lexicographic conventions that have been shown to improve clarity and precision in a technical glossary. Rationale for the rules of language, presentation, and style are examined. The need to allow flexibility in following the rules is discussed in terms of strengthening the technical merit and vitality of the glossary.&#xD;&#xD;&#xD;This article also describes the computer-display techniques and file-management system used in committee to develop U.S. Federal Standard 1037C, Glossary of telecommunication terms, and to display the results both in the meeting room and on the Internet between meetings.</description>
	</item>
	<item>
		<title>Technical Editors: Are We Are Own Worst Enemies? Strategies For Working With Authors</title>
		<link>http://tc.eserver.org/20751.html</link>
		<guid>http://tc.eserver.org/20751.html</guid>
		<description>The authors explore two studies of cognitive assessments, the Myers Briggs Type Indicator and Boundary Spanning of technical communicators, give readers an opportunity to score themselves, and then they argue that knowing the cognitive differences between technical communicators and the authors they edit can help them&#xD;improve working relationships with authors. When&#xD;copyediting, they suggest making suggestions rather than&#xD;dictates; providing rationale for suggestions; basing&#xD;suggested changes on style guides, standard references&#xD;and communication research; and using a levels- of-edit&#xD;approach.</description>
	</item>
	<item>
		<title>Situational Editing: A Rhetorical Approach for the Technical Editor</title>
		<link>http://tc.eserver.org/20571.html</link>
		<guid>http://tc.eserver.org/20571.html</guid>
		<description>Argues that the rhetorical approach to communication considers situations individually and is necessary for technical editors because their work comprises a series of individual rhetorical decisions.&#xD;&#xD;Proposes a rhetorical theory of technical editing.</description>
	</item>
	<item>
		<title>Customizing Clipart</title>
		<link>http://tc.eserver.org/20549.html</link>
		<guid>http://tc.eserver.org/20549.html</guid>
		<description>Like many of you, I come from a training background. Like many of you, we’re experts in group facilitation, engaging our learners, and creating instructionally sound materials. Yet, many trainers are not graphic artists nor do we have a score of graphic artists helping us create our training presentations. As a result, our training presentations often may not adequately represent the professionalism and quality that we’ve built into our training.</description>
	</item>
	<item>
		<title>Copy Editors and Technical Editors: We are Family</title>
		<link>http://tc.eserver.org/19816.html</link>
		<guid>http://tc.eserver.org/19816.html</guid>
		<description>The authors of this paper have the unusual background of having worked in both the newspaper (copy editors) and business (technical editors) fields, which are not as diverse as people might think.</description>
	</item>
	<item>
		<title>How to Edit for Content</title>
		<link>http://tc.eserver.org/19673.html</link>
		<guid>http://tc.eserver.org/19673.html</guid>
		<description>Editing involves more than just formatting and inserting page numbers. You need to ask, &apos;How can I improve the communication?&apos;&#xD;</description>
	</item>
	<item>
		<title>Technical Editing</title>
		<link>http://tc.eserver.org/14568.html</link>
		<guid>http://tc.eserver.org/14568.html</guid>
		<description>This course will prepare you for the substantive editing and design of complex documents such as technical manuals, proposals, and research reports.  You will study the practice of editing as it applies to invention, arrangement, style, and delivery.  You will examine strategies for document management and explore the theoretical justifications for your editing decisions.</description>
	</item>
	<item>
		<title>Becoming a Journal Peer Reviewer</title>
		<link>http://tc.eserver.org/14383.html</link>
		<guid>http://tc.eserver.org/14383.html</guid>
		<description>This session will help participants understand the process for reviewing manuscripts submitted to &lt;i&gt;Technical Communication.&lt;/i&gt; It covers the types of articles the journal&#xD;publishes, review procedures and criteria, and&#xD;approaches to writing constructive evaluations.</description>
	</item>
	<item>
		<title>The Technical Editor and Document Databases: What the Future May Hold</title>
		<link>http://tc.eserver.org/13835.html</link>
		<guid>http://tc.eserver.org/13835.html</guid>
		<description>Technical editors ensure a document communicates with the reader.  With XML, active server pages, and dynamic document creation, Web pages are no longer simple hand-crafted text objects, but dynamic groupings of text assembled moments before the reader views the page.  With dynamic documents, high-level editing tasks will be, at best, vaguely defined during text creation.  To maximize the information content, future technical editors require tighter control over information consistency and content.</description>
	</item>
	<item>
		<title>Courses for Technical Editors in Australia</title>
		<link>http://tc.eserver.org/13722.html</link>
		<guid>http://tc.eserver.org/13722.html</guid>
		<description>I don&apos;t know of any tertiary-level courses in Australia specifically for technical editors, although there are several programs for general editors or journalists. I&apos;ll add information to this page as I find it. </description>
	</item>
</channel>
</rss>