The Gap Wasn't Interest
Open source documentation had a known problem for most of a decade: plenty of readers, almost no outside contributors fixing the typos and gaps they obviously noticed. Maintainers responded the way maintainers respond, with a CONTRIBUTING.md, then a longer CONTRIBUTING.md, then a "new contributor's guide to git" pinned at the top of the issue tracker. The guides got better every year. The contribution rate barely moved.
Then GitHub put a pencil icon next to the file. Click it, edit the text in a browser textarea, hit a button labeled something like "Propose changes," and it forks the repo, branches, commits, and opens a pull request for you, without the person ever typing git clone. Small-fix contribution rates went up. Not because anyone's git comprehension improved. The branching model, the staging area, the remote tracking, all of it was still there, just moved behind the button where the person fixing a typo never had to meet it.
That's the tell worth keeping. The barrier wasn't a gap in what people knew about git. It was that fixing a typo and understanding distributed version control are two unrelated tasks that the tool had welded together, and only one of them was what anyone actually wanted to do. No tutorial closes that gap, because the tutorial is teaching the wrong lesson at the wrong altitude: it explains the thing standing between the person and the task instead of removing it.
Call it the tutorial test. When a participation gap survives years of people trying to close it with better instructions, ask a narrow question: if you doubled the quality of the documentation tomorrow, would the gap plausibly shrink? If the honest answer is yes, you've got a knowledge or motivation problem, and writing the better guide is the correct move. If the honest answer is no, and you already have some evidence for that, because adequate guides have existed for a while and the number hasn't budged, then the documentation was never the bottleneck. The tool's shape assumes a skill the task doesn't require, and no amount of explaining that skill more clearly fixes a mismatch that explaining can't touch.
The trap is that the diagnosis gets made backward almost by default. "They're not interested" and "they haven't been taught" are both flattering to the tool, because both put the fix on the other side of the interface: write more, explain better, run a workshop. "The tool requires something the task doesn't need" puts the fix on your side, and it's a much more expensive fix, because it means redesigning the entry point instead of adding another page to the manual. Guides are cheap to produce and look like progress. Rebuilding the path so the unrelated skill isn't load-bearing anymore is slow, and it's an admission that the interface, not the audience, was wrong the whole time.
The same shape shows up anywhere a niche pursuit has a visible core of contributors and no growth at the edges for years running: the easy explanation is that most people just aren't that into it, and the explanation survives because nobody runs the test. The test only takes one question. Has anyone who actually wanted to do the thing been stopped by something that has nothing to do with wanting to do the thing. If yes, the fix isn't a better explanation of the obstacle. It's building a door around it.