Writing software documentation is hard. Maintaining it is even more challenging in both closed and open-source worlds. You are probably familiar with the disdain that everyone has for writing, maintaining, and updating documentation, especially software engineers. But it is a necessary process that helps future teams, users and developers to use your project and contribute effectively. It might be a factor between life and death for a project or adoption game changer.

In this post, I would like to share what, in my honest opinion, a “perfect” maintainer of an open source software should do. Yes, no one ever will be perfect: we all have limited time, we all make mistakes and have some skills to learn. However, there is nothing bad in defining what we should aim for. (: Some quick glossary for this (long) post: Maintainer: Person responsible for the open source project development and community.

Available on Prometheus blog here .

EDIT (2020.12.13): From Go 1.16, Go on Linux moves back to using MADV_DONTNEED when releasing memory. However, this blog post still applies in terms of how to monitor memory consumption, although we should see less memory cached by Go runtime. See this issue . TL;DR: Applications build with Go 1.12+ reports higher RSS memory usage on Linux. This does not mean that they require more memory, it’s just optimization for cases where there is no other memory pressure.

Available on Improbable blog here .

Available on Improbable blog here .