Effective immediately, I have resigned from the Apache OpenOffice project.
An excerpt from my resignation letter, and related comments, are here.
I intend to become more involved with The Document Foundation and the LibreOffice project.
Dec 08 2010
New Perspectives on Technical Editing
I have an essay titled “Copyediting and Beyond” in New Perspectives on Technical Editing, edited by Avon J. Murphy, published by Baywood, 2010.
I am honored to appear in a book containing essays by some of the field’s leaders whom I admire greatly, including Carolyn Rude, Michelle Corbin, Geoff Hart, and George Hayhoe (an incomplete list).
Sep 10 2010
Developing Company Editing Standards
This article is nothing dramatically new, but it is a good summary. Developing Company Editing Standards, by Kristine Haugseth.
This presentation covers how to develop editing standards for content. It provides tips on how to get started when no conventions exist and how to improve coverage of topics when time and resources are limited. It describes how to get buy-in for editing standards from management and project members. This topic is of interest to all editors because pushback against editing changes is very common, and consistency is difficult to maintain without coworkers’ buy-in to established standards.
Jul 23 2010
The value of editors
Paul Ford, in Real Editors Ship, says some things I’ve been trying to tell people for years. Other editors will understand what he’s talking about; many of the people who need us most won’t get it. Here’s a quote:
Editors are really valuable, and, the way things are going, undervalued. These are people who are good at process. They think about calendars, schedules, checklists, and get freaked out when schedules slip. Their jobs are to aggregate information, parse it, restructure it, and make sure it meets standards. They are basically QA for language and meaning.
Jul 19 2010
Editing troubleshooting procedures
The Diagnosis-Resolution Structure in Troubleshooting Procedures, by David K. Farkas, on the WritersUA website.
In this paper, I define troubleshooting procedures and briefly sketch out how they are developed. Then I analyze the genre’s underlying architectural structure of diagnosis and resolution, showing both simple and complex configurations of symptoms and solution methods. These configurations are in part constrained by the nature of the technical problem; but they are also the consequence of design decisions. Understanding structure enables us to meaningfully classify the very diverse instances of this genre, reveals key design issues, and is apt to contribute to experimental research insofar as structure is central to many of the most useful research questions we can ask.