Reducing Documentation Tax
05-sep-2026
The Pain
Today, while working on Ravi Wiki, I understood more clearly why reducing Documentation Tax matters.
I had moved away from WordPress and started building my own wiki partly because I wanted more technical independence. But I noticed something ironic. To publish one article on my own site, I was going through almost 18 different steps, from writing the article to checking Git, the repository, the build, the server, and finally whether the page was actually live.
I had gained independence, but publishing itself had become expensive.
How Acute Was It?
It was acute enough to defeat the purpose of the wiki.
If every small idea required an hour of operational work before I could publish it, I would eventually stop writing. The infrastructure might be reliable, but the habit the infrastructure was supposed to support would die.
That was the point when Documentation Tax stopped being an abstract idea for me. I was experiencing it directly.
The Solution
I started looking for ways to reduce the number of steps without throwing away the safeguards I had built.
Even getting the process down from roughly 18 steps to four or five would be a meaningful improvement.
The answer was a small shell command called publish.sh.
Instead of asking me to remember the entire deployment process every time, the script now performs most of the repetitive checks, builds, verification, staging, and publishing steps for me.
It took three committed iterations to get the automation working correctly, but the effort paid off.
The important part is that the checks did not disappear. They moved from my memory into the system.
The Way Forward
I want to reduce the friction further, but I do not want to optimize it in theory.
The next improvements should come from actually using the wiki and noticing where the remaining friction appears.
The goal is not zero steps.
The goal is to make publishing easy enough that when I notice an idea, the technology does not get in the way of writing it.