Infinispan Documentation Strategy

The mission is to provide quality documentation for the Infinispan community. But how do you define what that means? What is quality documentation?

Documentation exists to help you solve problems. And the effectiveness of documentation in helping you do so is generally a good yardstick for measuring quality.

Over time I’ve defined what I believe to be the primary criteria for effective technical documentation:

Perhaps the most challenging aspect for working on the Infinispan documentation set is getting into that sweet spot that exists between the bleeding edge and the gardening.

The bleeding edge is where the action happens. Ideally docs should stay up to date with the code base and go through the same iterations, making improvements with each development cycle.

Gardening is how I like to think of the maintenance work that docs require. Much like an actual garden, documentation requires continual upkeep and management to avoid turning into an overgrown, unnavigable jungle of information.

As a team we’ve been implementing a documentation strategy to overcome these challenges and achieve our mission of delivering quality tech docs. This strategy centers around two things:

As I mentioned previously, documentation exists to help you solve problems. Nobody ever sits down and reads the docs like you would a novel. Usually you dip in when you hit a snag or are trying to work out how to do something.

Procedural content should provide a set of end-to-end steps that help you succeed with your goals.

Documentation that enumerates all available parameters and explains each possible value is great but if it doesn’t tell you how to combine parameters in the right way or when to set them, then it’s just giving users a long rope to go hang themselves with.

So hopefully one of the biggest things you’ll notice in the Infinispan documentation is that we’re adding more procedures. We want to give you the recommended fast path that gets you up and running as quickly as possible.

Topics are logical units of information that can stand alone and map to various information types, of which the three most common are Task, Concept, and Reference.

One of the benefits of a topic-based writing is that it helps simplify things. A big obstacle for any kind of writing is just getting a handle on what you need to explain. Technical writers get writer’s block too.

Topic-based writing helps to eliminate that obstacle and take the struggle out of developing content. Start with the task and break things down according to classification and figuring what you need to write becomes much easier.

At the same time topic-based writing reduces maintenance overhead. A huge win for topics is that they allow reuse. Write something once and use it in different contexts as needed.

Now that I’ve explained some of the motivation, I’d like to briefly delve into how we’ve organized the docs.

Documentation source lives in documentation/src/main/asciidoc and has three main subdirectories:

We really believe in all the changes we’ve been making to the docs. It’s been exciting to see just how much transformation the doc set has undergone in just over a year (PR 6674).

However, given that Infinispan is a community project, we also recognize that these changes have the potential to discourage contributions. Most documentation updates that come from community contributors are small edits or minor updates, usually one or two lines of text. Moving to a topic-based structure adds complexity and creates extra work to make those small changes because you have to sift through many more asciidoc files.

Planning for the new docs strategy was done with core contributors with the goal to preserve and encourage community participation. There have been doc PRs that introduced structural changes that others didn’t agreed with. Getting rejected and going back to the drawing board can feel like a setback but ultimately it’s about finding the solution where everyone’s a winner.

There is a balance to be had and, like so many things, you find it through conversation.

So, on that note, I’ll leave it with a request to join us and keep the conversation going.

Report doc bugs (or ask for new content), stop by our Zulip room and hang out for a while, or ask questions on StackOverflow.