How did you get into technical writing, Felicity?
In my former life I was a business analyst, and I always enjoyed the writing aspect of that role. I wrote functional specs, tech specs, and user testing plans.
I had studied English and loved writing, but technical writing was a new field to me. When I discovered technical writing was a thing you could do, I took a postgraduate course in Melbourne.
I went through the course with a good set of lecturers, who were active in the technical writing community. That’s how I got started as a tech writer, and have been enjoying it ever since.
How did you get into open source?
As a technical writer, I had always worked in the corporate world, documenting software and attending conferences in the corporate world. I started hearing more and more about open source and didn’t understand it.
Fast forward 12 years… and I had a baby and that was a catalyst to change my working life. I needed more control over my schedule and flexible work hours. One of the great things about working in open source is that there are a lot of opportunities to tailor your work-life balance. Even before the Covid-19 pandemic, remote work was common, and there is a lot of focus on the human side of technology, including staying happy and healthy.
I started with Open Strategy Partners, and coincidentally, at the same time I participated in the inaugural Google Season of Docs program. Since then, I joined the embryonic open source project for technical writing, The Good Docs, and I’m on the steering committee for that.
Tell us about The Good Docs and the Google Season of Docs.
The idea with The Good Docs is to produce best-practice templates to help open source project maintainers produce their own documentation. My mentor from the Google Season of Docs was the driving force behind this idea.
During the Season of Docs, I worked in an open source community focused on geospatial software. The Open Source Geospatial Foundation (OSGeo) is an umbrella for a large number of separate OSS projects. They were distributing their software together, but there was inconsistency across all the projects; each was managed by a different project owner and maintainer. So we focused on the quick start guides for each of these projects to make them consistent.
My mentor wanted me to focus on facilitating these project owners to learn how to do the work, rather than just swooping in, doing the work and leaving. We wanted to enable them to maintain their docs in the future. So we did spend a lot of time on communication.
Enablement and good communication are two common topics in open source that I feel passionate about. We wanted to continue to work on helping project maintainers create great documentation. So that’s what led to The Good Docs project.
It has a good, diverse group of people attached to it from Australia, the UK, and the US. We released the alpha versions of the templates at the 2019 Write The Docs event in Australia.
So you’re really all-in with open source now! That is great! How do you find it? Anything surprising?
I find the challenges of group work and getting consensus to be different. When you’re in a business in a hierarchical structure, you know clearly who your stakeholders are. But when you go into an open-source community and it’s all volunteers, you don’t know who to talk to. You want to be respectful because you have an awareness of being part of a larger group. And I’ve come to recognize that help may come from unexpected quarters.
A friend of mine, who is an open-source developer, said you can’t cut people out who appear to be “onlookers” just watching a conversation take place. You’re never just talking to one person in an open source community context.