Editing in open source is about nurturing writers and non-writers, and watching where you tread to sustain a path of non-code contributions.
Open source software projects often need a lot of written content: documentation, web pages, blog posts, community event write-ups, and more. Such content helps build community around the software, and give it an identity. All of this content has to get generated by somebody™, and ideally, it gets edited by someone else.
There are two key aspects to editing in open source:
- Open source = volunteers, so tread gently.
- Open source = global communities, so tread mindfully.
Open source = volunteers
Tread gently.
Most writers I’ve edited for in open source software projects wouldn’t call themselves writers - they’re developers or UX designers or tech integrators. They’re also volunteering their writing time.
When I’m editing work created by unpaid people who don’t identify as writers, I go gently on my edits.
Specifically, I tend to keep the author’s voice as much as possible, and sometimes that means (gasp!) retaining some poor construction.
This approach has several benefits:
- Writers feel legitimate because they’ve gone through the editing process and improved the finished piece.
- Writers feel proud and validated to see their writing in print.
- Writers are more likely to continue to contribute their writing, which ultimately benefits the project and the broader community.
As an open source editor, you might also be volunteering your own time. Editing lightly is faster, meaning you can meet deadlines and keep pace with the project.
Open source = global communities
Tread mindfully.
The open source projects I work with are global, and English is the preferred language. That means working with many people for whom English is not their first language.
Editing for global communities requires sensitivity to cultural differences. My job as an editor is about thinking globally—having a broad awareness of what is region-specific and might not convey meaning across borders.
This could be word choice, figures of speech, language conventions, currency punctuation, and hemispherical bias. I don’t always know all the answers, but I know enough to flag the things that might not work. Here, I’m advocating for the reader and being sensitive in my feedback to the writer.
Minimalist editing
My approach when editing in open source is to consider the broader context of the writer and the project.
- Is the writer usually a non-writer?
- Is English the second or third language for this writer?
- Have they ever contributed before?
I don’t go for brutal edits with a heavy red pen, I tend to dial my editing back a bit. Of course, I polish the writing and try to add value to the finished piece, but not at the expense of my author’s psyche. If an article needs more substantial changes, I’ll try to occupy a space of collaborative writing rather than heavy-handed editing. (We’re all in this together!)
As an open source advocate, I believe in the importance of non-code contributions for the health of any project. Editing lightly in open source sustains non-code contributions. If people know there is a friendly editor (who is not TOO heavy with the red pen), they’re more likely to write the next README, blog post, community sprint review, or team retrospective—and the community benefits as a result.
Image credits: Tropical green forest photo by wirestock on Freepik.
