Skip to content

Latest commit

 

History

History
38 lines (30 loc) · 2.75 KB

intro.adoc

File metadata and controls

38 lines (30 loc) · 2.75 KB

The basics principles while writing the documentation

If someone reads a guide or a documentation for a software product, there is usually a specific reason for that. In the least often cases someone will open an article of the guide for Checkmk per accident. For this reason there are basic principles for that we create the content of this documentation.

This also and more importantly means, that there are things that this guide does not want to provide, e.g. a Best Practice or How To guide that is already covered by our blog or the more basic articles to monitoring in general.

Which kind of user and in which kind of situation should the guide be used?

  • I do look out for a sufficient monitoring tool. And it’s important to me, that I can monitor ORACLE in a comprehensive way. Is Checkmk applicable for me?

  • I have to take over the responsibility for Checkmk in my company and want to work myself into this topic in detail. And I do have time for reading the complete guide.

  • I do use Checkmk and I have a spexific requirement but I don’t know how to accomplish that.

  • I do use Checkmk and want to get deeper into the "processing of events" or get calmly familiar with that topic.

  • I do use Checkmk as a CRE Checkmk Raw Edition for a bit and want to see while reading if there are differences regarding the CEE Checkmk Enterprise Editions to notice if things work differently or if a change would be benefitial for me.

  • I am a full professional of Checkmk and want to write my own extensions, automate workloads, write scripts for Checkmk, etc.

  • I am a consultant for Checkmk and want to understand specific aspects of Checkmk precisely.

What experience or feeling should a user have while reading the guide?

complete

I do find, what I am looing for

pleasant

Reading the guide is not hard or boring

efficiency

I do find the information fast and I am able to get the content fast

useful

I not only understood what I was reading. I also able to endorsed to use the learned content in a new/different situation

accurate

What I have been reading is precise and correct

new

I learned (not intetionally) something new that I was not aware of before

These aspects should always be in mind, if you write new content. Not only that the software is documented but to make the content agile. In the end the documentation should encourage the reader for Checkmk to make the usage of this powerful and enormous software more fun and provide a sense of achievement.