When I started in this map data team, the department’s internal documentation system (in Confluence) had been built organically, without any particular strategy or writing expertise. I rebuilt the documentation system from the ground up, creating new processes, updating page structures, developing templates, and rewriting all documents.

After I reorganized and revamped the team’s knowledge base, I created the Style Guide for the other tech writer(s) on the team. You can see three selections of that Confluence page here.

Tables within Confluence pages don't export into PDFs particularly well, so please don't mind the ugliness. If you see a block that says "Unknown Attachment," it indicates an image or other file that Confluence cannot find. The program frequently broke our image links for no reason, despite plenty of IT support calls. This is one reason our guidelines stated that a writer should never document a process with only images!

N.B. The term “wiki” was used throughout all the Maps Ops teams, even when the Confluence in question was only updated by technical writers. We kept the term globally, despite the fact that none of the knowledge bases were communally edited.

In section 2. Introduction to Confluence and the Wiki, I explain how the knowledge base is organized and why.

In section 2. Fundamental Principles of Our Documentation, I outline the writer’s goals and guidelines.

Section 8. Style Guidelines is the knowledge base’s style guide that I developed. N.B. Technical writing is very exact, so there is significantly more detail and less flexibility than you might see in other style guides.