Why Documentation Should Be Worth More Than Code

In most open-source contribution systems, code commits are king. Documentation updates are second-class. Config changes barely register.

I want to argue that this hierarchy is backwards.

The Current Weighting

If you look at how most projects value contributions:

Contribution Type	Perceived Value
New feature (code)	High
Bug fix (code)	High
Documentation update	Low
Config/CI changes	Very Low

This reflects a bias: we value doing over understanding. Ship the feature. Fix the bug. Documentation can wait.

But documentation is the interface between human understanding and machine behavior. Without it, code is a private language spoken by the person who wrote it.

An Alternative Weighting

What if we explicitly valued understanding over action?

CONTRIBUTION_WEIGHTS = {
    "documentation": 1.2,   # Understanding > action
    "code":          1.0,   # The baseline
    "tests":         1.1,   # Verification matters
    "config":        0.5,   # Necessary but mechanical
    "ci_cd":         0.3,   # Infrastructure maintenance
}

This small table encodes a philosophy: a project that understands itself is more valuable than a project that merely runs.

The Argument

1. Documentation Has Higher Leverage

One well-written explanation enables dozens of future contributors. One code commit enables one feature. The multiplier effect of documentation is dramatically higher.

Think about it: how many hours have you saved because someone wrote a good README? Now compare that to the time saved by any single function in that codebase.

2. Code Without Documentation Is Technical Debt

Undocumented code requires reverse-engineering by every future reader. That's repeated cost. Documented code pays the understanding cost once and amortizes it across every reader.

The accounting is clear: undocumented code has a hidden liability that documented code doesn't.

3. Documentation Requires Deeper Understanding

Writing clear documentation forces you to understand the system at a level that writing code doesn't require. You can write a function that works without understanding why it works. You cannot explain a function to someone else without that understanding.

Documentation is proof of comprehension. Code is only proof of execution.

4. The Bus Factor

If your best contributor gets hit by a bus (or more realistically, leaves for another job), what survives? Their code stays, but without documentation, the knowledge behind it is gone. Documentation is the only contribution type that transfers understanding from one mind to another.

Practical Implications

If you're building a contribution-tracking system:

1. Weight documentation higher. Not symbolically -- actually give it more points, more reputation, more recognition.

2. Track documentation coverage. What percentage of your public API has usage examples? What percentage of your architecture decisions are documented?

3. Make documentation a first-class review criterion. PRs without documentation updates for new features should require justification, not the other way around.

4. Celebrate documentation contributors. Your changelog should credit the person who wrote the migration guide as prominently as the person who wrote the migration.

The Meta-Point

The question "what type of contribution is most valuable?" is really asking "what do we optimize for?" If we optimize for features shipped, code wins. If we optimize for collective understanding of the system, documentation wins.

I think most mature projects would benefit from choosing the second optimization target. Features without understanding create complexity. Understanding without features creates wisdom. And wisdom is what turns a codebase from a pile of files into a living system.

Value the explainers. They're doing the harder work.

---

This weighting system is part of a contribution-backed token protocol I'm building. The values encoded in your scoring system ARE your project's values. Choose them consciously.