After graduating from University in the midst of a pandemic, I knew that I wanted to be a tech writer, but I wasn’t sure how to start. Google Season of Docs was the perfect way to launch my career; it let me work on my own terms and led to me starting my own business and to subsequent tech writing jobs in open source. I am currently working as a tech writer at Google and volunteering for documentation-related open source projects.
Should you join an open source project?
The charm (and challenge) of open source is that the line between creators and users becomes blurred. Do you wish that your beloved tool had that one feature you really need? You can add it yourself! Other users might support your feature request and may even help you build it. Before you know it, you’re part of a wonderful community bound together by passion.
People join open source projects for many reasons:
- They believe in the vision of a project and want to help build it
- They want to build professional and technical skills
- They are motivated by the possibility of hundreds—or even thousands—of people using their work
Life in open source as a tech writer
Many contributors in open source come from a software engineering background. They are great at building software, but they sometimes struggle with documentation. Through Google Season of Docs, open source projects can hire technical writers to help them create much-needed content. These technical writers are likely the first person in the project working exclusively on educational content—which comes with ups and downs.
The fun parts
As an open source technical writer, you will often be in close contact with your users. Through researching user needs, technical writers develop more empathy for the struggles of the users. Many tech writers (myself included) find that this closeness helps them write better.
Contributing to open source also allows you to create documentation in different contexts. For example, you might have authored content in a CMS in the past—diving into an open source project gives you the opportunity to explore a docs-as-code workflow. Another circumstance could be that you wrote documentation in a different industry and you want to see what it’s like to document software. Changing up your writing routine helps you find more creative ways to tackle problems for the next project you work on.
The hard parts
Documentation quality can be quite variable in open source. While some pages might be really useful, others might be outdated, don’t follow the user workflow, or cover way too much information on one page. Making sense of the existing documentation landscape can feel like a daunting task.
Most open source projects suffer from gaps in the documentation. Since open source developers are so enmeshed with their code and the project, they have a lot of context, and suffer from the “curse of knowledge”. It’s hard for contributors, or anyone who has held a position for a while, to remember what it was like to be a beginner or new to a project. When developers write documentation, their brain auto-completes what is missing on the page.
Because many people work on open source for personal satisfaction, you might experience pushback from people who are protective of their documentation. I find it helpful to view pushback as an act of caring about documentation. Take a closer look at why you are receiving pushback:
- Do the developers have concerns about your technical understanding?
- Are they not ready to let go of their document?
- Do you have different ideas of who the user is and what their goals are?
Understanding developer concerns can help you reach the shared goal of improved documentation.
Succeeding in Google Season of Docs and beyond
These tips helped me make the most of my Google Season of Docs experience.
Gain clarity
Take time in the beginning of the project to really understand the software, the user’s needs, and your docs landscape. (I allocated one third of my entire project timeline to gaining clarity.) Talk to your project mentors, do user research, and perform a content audit—this will help you understand the current structure and identify weaknesses and gaps in the content.
Keep your community in the loop
Open source communities attract contributors from all over the world—which means communication is usually asynchronous and in writing. Transparent communication is a must to keep your users (and potential co-creators) engaged. When they know what’s going on, it’s easier for them to chip in.
Deal with pushbacks
Transparent communications and a solid documentation plan go a long way towards addressing concerns. It’s easier to receive support if your team knows what you’re doing.
Build a professional support network
Find other tech writers to geek out with, especially if you’re the only technical writer in your project. Groups like Write the Docs and The Good Docs project are good places to find like-minded people to brainstorm and learn with.
I hope you find a project that interests you and the bandwidth to participate in Google Season of Docs. It was a worthwhile experience for me, helped me advance in my career, and I hope the same for you.
P.S. You can find a detailed write up of my work for Season of Docs ‘21 on my website.
By Tina Luedtke, Technical Writer – Google
