Janet Swisher on FLOSS Manuals, Open Source, and Book Sprints

janet-swisher-tech-writerWant to know how to run an open source ‘book sprint’? Janet Swisher does.

This week I had the good fortune to interview Janet Swisher, a technical writer based in Austin, Texas.

Janet, who’s worked in technical communication since 1999, is an Information Developer for a medium-sized software company. Her specialist areas include online help, tutorials, API documentation and programmer guides.  My “techie” cred is that she “can read code well enough to avoid asking obvious questions, and write code well enough to be dangerous”.janetswisherblog

Ivan: Could you tell us a little about your background and the type of activities you perform as a technical writer?

Janet: I’ve been technical writer for over 10 years.

Prior to that, I filled various roles related to software development, including testing, tech support, and build management.

I moved into tech writing because I wanted to combine my technical background with (mostly) written communication. I’ve worked on a wide range of software documentation, from embedded user assistance to programmer’s guides.

Ivan: DITA seems to be gaining acceptance in the technical writing community as the preferred method for creating structured documents. What do you see as the main benefit DITA offers? Also, how could DITA be improved, for example, better user interfaces in the toolsets?

Janet: The two main benefits I see from DITA are the abilities to reuse content and to attach metadata to content. Those benefits have the potential to drive the spread of DITA across business functions, beyond technical documentation.

ditaI’m relatively new to actually using DITA, so I have a limited view of its shortcomings and areas for improvement.

From what I’ve read about the upcoming 1.2 version of the standard, it includes a number of needed enhancements.

My impression is that customizing the output of the DITA Open Toolkit is one area where a lot of people have difficulty, so friendlier tools in that area would be helpful.

Ivan: Your website discusses FLOSS Manuals, writing Open Source, and also open source documentation. Could you talk a little about what attracts you to these areas, for example, what’s involved in developing the FLOSS manuals?

Janet: I’m attracted by the open source software ethos of community and sharing, and I see no reason why that shouldn’t apply to documentation as well as to software code. I’ve long been disappointed that there weren’t as many technical writers working on open source documentation as there are programmers working on open source code. Fortunately, that situation is starting to change.

One of the obstacles to professional tech writers becoming involved in open source has been the issue of tools.

Open source projects tend to frown on the proprietary documentation tools that professional tech writers are familiar with. So to become involved with an open source project, a tech writer often has to learn a new documentation toolset as well as learning about the software being documented. This can be one hurdle too many for people who have jobs and personal lives.

One reason that I initially became involved with the FLOSS Manuals project (www.flossmanuals.net) is that it provides a dead-easy-to-use platform for writing documentation. It’s based on wiki technology with a WYSIWYG HTML editor. So that eliminates the tools obstacle, right there.

floss-manuals

However, the FLOSS Manuals project is not just a technology platform. It’s also a community of people who are interested in creating documentation for open source software. It operates on the same principle as open source software in general, which is that anybody can contribute, and that the more people who participate, the better the quality will be.

The third thing that FLOSS Manuals has is a process model for creating documentation, which is the idea of “book sprints”. This is an event where you get together a set of people who are interested in creating a book on a particular topic, in a given place for a short period of time, typically 3 to 5 days, to focus on writing that book. There have been over a dozen books produced through book sprints, using the FLOSS Manuals website. While holding a book sprint is not necessary for creating a book on the FLOSS Manuals site, experience has shown that the books that were created in book sprints have the most ongoing participation.

Ivan – You co-presented two sessions at the STC Summit in May.

Documentation with Blogs, Wikis, and Online Communities with Anne Gentle and Understanding User-Generated Documentation: FLOSS Manuals with Scott Abel.

For those of us who didn’t make it to the conference, what did you find most interesting there? For example, a move towards web-based documenting, social media, or other trends that you see emerging?

Janet:  The key theme from both of the sessions I participated in was that, regardless of what product or service you offer, your customers are finding each other through the web, and they’re talking about their needs, their successes, and their failures with your offering. The conversations are already going on. The technology already exists for users to create their own content. If your company is not participating in that conversation, it is losing out on a wealth of information about its customers.

Furthermore, technical communicators, as a profession, are likely to move towards being content curators as much as content creators. If you can’t make that shift, you’re going to be competing with everyone else who is just a content creator, which is to say, everyone else. However, if you can add value with structure, vision, and insight, you will continue to be in demand.

Ivan: Finally, what advice would you give to those considering a career in technical writing?

Janet: To be successful in technical communication, you need to be excited about both the “technical” part and the “communication” part. If you see it merely as a way to get paid while working on your novel, or as a way out of a stalled engineering career, you’re not likely to be happy as a technical communicator. You need to be the kind of person who loves learning geeky stuff, and loves helping other people learn it, too. If you don’t have that, no matter how much technical or writing skill you have, you’re not likely to last long in this field.

About Janet

Big into Aikido. Not the Janet Swisher of the Missouri Pet Breeders Association.  If you want to know more, see her LinkedIn profile or visit here website, A Techie Tech Writers Blog at http://www.janetswisher.com

Once again, thanks to Janet for taking the time to speak with us.

How about you?

If you’d like to be interviewed for I Heart Tech Docs (or know someone we should interview!) please let me know. The Contact Us page has a nice, short, snappy contact form.

Try it out. It works!

Download these templates to start

Acceptance Test Plan

Contingency Plan

Software Development Templates

Acquisition Plan

Conversion Plan

Software Requirements Specification

Action Plan

Cost Benefit Analysis

Software Testing

API Documentation

Database Design

Standard Operating Procedures (SOP)

Audience Analysis

Datasheet

Statement of Work

Availability Plan

Deployment Plan

System Administration Guide

Bill of Materials

Design Document

System Boundary

Business Case

Disaster Recovery Plan

System Design Document

Business Continuity

Disposition Plan

System Specifications

Business Plan

Documentation Plan

Technical Writing Templates

Business Process

Employee Handbook

Test Plan

Business Requirements

Error Message Guide

Training Plan

Business Rules

Expression of Interest

Transition Plan

Capacity Plan

Fact Sheet

Troubleshooting Guide

Case Study

Feasibility Study

Use Case

Change Management Plan

Functional Requirements

User Guide

Communication Plan

Grant Proposal

Verification and Validation Plan

Concept of Operations

Implementation Plan

White Papers

Concept Proposal

Installation Plan

Work Instructions

Configuration Management Plan

Interface Control Document

Software Development Templates

Acceptance Test Plan

Maintenance Plan

Software Requirements Specification

Acquisition Plan

Market Research

Software Testing

Action Plan

Marketing Plan

Standard Operating Procedures (SOP)

API Documentation

Needs Statement

Statement of Work

Audience Analysis

Operations Guide

System Administration Guide

Availability Plan

Policy Manual

System Boundary

Bill of Materials

Project Plan

System Design Document

Business Case

Proposal Manager Templates

System Specifications

Business Continuity

Proposal Template

Technical Writing Templates

Business Plan

Quality Assurance Plan

Test Plan

Business Process

Release Notes

Training Plan

Business Requirements

Request for Proposal

Transition Plan

Business Rules

Risk Management Plan

Troubleshooting Guide

Capacity Plan

Scope of Work

Use Case

Case Study

Security Plan

User Guide

Change Management Plan

Service Level Agreement (SLA)

Verification and Validation Plan

Communication Plan

Setup Guide

White Papers

Concept of Operations

Social Media Policy

Work Instructions

Concept Proposal

Contingency Plan

 

Configuration Management Plan

Conversion Plan