I believe Hugh works at Grafana.

The Apache Software Foundation is now more than 300 projects. See https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fprojects.apache.org%2F

When I worked at SourceForge, this was a major thing I worked on. I called it the "Yeah, but what does it *DO*" campaign, and I'd try to get projects to explain what their project was actually for, rather than saying that it was "an effort to build a fast, efficient, best of breed tool XYPDQ object-hierarchical framework" or whatever.

Turns out that a lot of people find this kind of thinking revolutionary. It's honestly eye-opening when you say some people might not know what their whizbang is used for.

Good documentation is typically not written by "most coders". It's written by writers. Some of us do indeed get a thrill from writing good documentation. I've been doing this for 20 years because it's fun, not because I'm paid for it, in much the same way that you have been coding, because it's fun. Different people find different things fun. The trick is to make it easier for these kinds of people to get access to the communities which are typically coder-dominated. (As you might guess, there's more about this in the article.)

Yes, there are plenty of counterexamples. And those communities - I presume you are referring to Linux? Or did you mean something else? - are remarkably hard for beginners to break into, unless they display a similarly belligerent attitude. Thus, this kind of attitude is self-perpetuating, and it makes it remarkably hard to improve the tone of the community over time. Monkey see, monkey do.

Look, I'm not declaring this to be a theory or a law of community organization. I'm saying that when you're nice to people, you tend to make it easier for them to solve problems.

From the article: ... there are some amazing books out there that you should read if you care about this stuff. First, I'd recommend Conversation and Community, by Anne Gentle. And if you're looking for a conference about this stuff, there are two that I'd suggest: Write The Docs and OpenHelp.

As I mention in the article (you did read it, right?) is that there are different voices required for different types of documentation. There's a place for both the "straight to the point" (reference docs) and "conversational" (howtos, more learning-oriented exposition) voices, depending on who you're talking to, and how much they already know.

"RTFM" is defined in the first sentence of the first paragraph of the article.

I'm still living in Lexington.

http://www.youtube.com/watch?v=QE3XsZaL-zo

Presumably so that other people can continue the development.

I've been talking with the developer in question this morning, and he'll be putting the code into Git this evening or this weekend, as he has time.