Yesterday I helped a bit with a Dreamwidth code tour. Every time Dreamwidth deploys a new update to the site, someone writes up explanations of what all the new bits are. Not just a summary of the big changes, but a sentence or a paragraph about every bugfix and improvement. Basically, imagine if release notes had explanations like this summary by ghoti:

Bug 4102: Checkboxes to retain relationships when renaming have disappeared
Category: Misc Backend
Patch by: denise and fu
Description: So when you rename your account, you're supposed to get checkboxes that keep your access list, filters, and stuff like that during the rename. Unfortunately those checkboxen had disappeared. This shouldn't happen anymore. If you got caught in this bug, please tell denise or fu.

for every bug. Then the code tour gets posted in the Dreamwidth Development community, and linked to from general Dreamwidth news posts. This effectively tells customers where their money's gone, showcases the work of volunteers, and provides examples for people who had been thinking of getting involved in bugfixing (a form of babydev-bait). I fear that the Wikimedia development pace is too high and its community size is too large to make this particular method effective for us, but I'm going to keep thinking about ways we could modify this tactic to achieve those goals for us.

I wrote the summaries of bugs 3186 & 3087, which took maybe ten or fifteen minutes from start to finish. It was fun to flex that muscle, remembering how to distill and translate and explain:

Most support requests are visible to everyone, so everyone can help answer them. For privacy, only Dreamwidth staff and trusted volunteers can see support requests in certain categories, like Account Payments issues or Terms of Service violations. But that wasn't clear to regular users on the support ticket submission page. Now it is, because there are asterisks marking those categories.

I remembered writing functional specifications as a project manager, and reading technical specs and translating them into "what this means for your weekend." I thought about my eventual goal of managing a product, a role that requires someone to think from logistical, marketing, design, financial, and technical perspectives.

Then this morning I picked up A Case of Need by Michael Crichton. He wrote it as a young doctor, under the pseudonym "Jeffery Hudson."

I cut a slice of the white lump and quick-froze it. There was only one way to be certain if the mass was benign or malignant, and that was to check it under the microscope. Quick-freezing the tissue allowed a thin section to be rapidly prepared. Normally, to make a microscope slide, you had to dunk your stuff into six or seven baths; it took at least six hours, sometimes days. The surgeons couldn't wait.

The key context you need to understand the emotional valence of the detail, always keeping the reader aware of what's normal and what's a surprise, what's the best practice and what shortcuts people end up taking. Crichton would have written that summary of the private category marking exactly as I did.

So -- just as I learned my long-distance mentorship skills from Beverly Cleary in Dear Mr. Henshaw, I learned my expository skill from Michael Crichton. Embarrassing, given what Crichton got up to in his later years, but I'll take my skill where I can get it.

(If I were smarter I could make a nice comparison among George Orwell, Alan Furst, Michael Crichton, and Ellen Ullman.)

(By the way, someone quoted from that A Case of Need passage in a comment in an FCC filing.)