Strimzi is supported by an extensive set of documentation. If you want to know what Strimzi does, there’s the Overview. If you want to get up-and-running quickly, the Quick Start guide can help. If you want to go deeper, we have specialized docs for Deploying and Upgrading or Configuring Strimzi. Kafka Bridge has its own documentation too.

But what don’t we have? And what do you want? That’s the purpose of this post. We’re looking for your input on Strimzi’s supporting documentation.

Addressing feedback

We do get feedback on the docs. And most of it is positive. Thanks for that. But we also get requests for improvement, which are equally appreciated.

Sometimes the requests are vague. We can’t do much with “Docs could be clearer” or “The procedure doesn’t work for me”. It’s this type of feedback that prompted this post, actually.

We want to help. Just tell us how.

We can really work with actionable feedback that considers context and content, as well as any pain points. For example, “It would be great if there was an example in the documentation that shows how to configure x to do y and achieve z. I’m struggling to get this working.”

Is there anything you don’t see in the documentation that you think should be addressed? Is there anything in the current documentation that you would like to see improved? We can always make good into better.

Let us know.

Targeted documentation

We can better understand where to take the documentation if we understand how Strimzi is being used in the field. The documentation covers the steps required to accomplish common goals. But we need to know if we have gaps and also identify if we’re covering the right things in the right way.

We want you to have a good experience using Strimzi (because its awesome) and the supporting documentation can leverage that. If we have the documentation right, you should be able to navigate the docs, find the task you’re looking to perform, then step through the task without impediment.

Obviously, we can’t cover all edge cases and outliers. But you should be able to locate the content that shows you how to deploy and use Strimzi without ambiguity. The documentation certainly shouldn’t leave you scratching your head trying to work out if you’re doing it right.

Let us know if there are gaps or use cases that are not yet covered. We might not know about them.

Adding to the documentation

As well as feeding back, we really encourage the community to be involved with directly contributing to the documentation. If you spot an error in the docs or think it would benefit from a change or addition, you can open a documentation pull request.

The documentation is written in asciidoc, a lightweight markup language similar to markdown. The Strimzi Documentation Contributor Guide shows how to make a change and push that change to the Strimzi GitHub repository.

You can also raise a GitHub issue against the documentation. Be sure to label it documentation.

If you want to suggest a bigger change to the documentation before plunging in, you can always raise it with the community for consideration.

Feedback channels

The Strimzi documentation is, and always will be, work in progress. But with your help we can shape it so that it provides the right level of support in the right way.

Please don’t hesitate to make suggestions. You can get in touch through any of these channels: