i, quaid

Some years ago we brought the concept of a beat writer in to Fedora, as a way of merging a tradition from writing with a tradition from open source. By breaking down a monolothic document such as the Fedora release notes in to modular chunks, multiple people can collaborate on the whole document while keeping focused on the content most important to them.

Every single subProject and SIG should have a beat writer.

If you do not, then you have no one committed to telling the world about your great feature, project, process, or whatever. If you want to be under the radar, fine, go ahead. But if anyone is relying upon your technology or efforts, then you owe it to the community to do your documentation.

Not having a beat writer is like a Linux distribution not contributing to the Linux kernel.

In the last release cycle, the features process was a very important and useful way that content about features made it in to the release notes and marketing materials. Here’s a funny story about that:

At the 2008 Red Hat Summit, Jeremy Katz was giving a talk about the Fedora live media feature. In that talk, he mentioned that he wasn’t perfectly satisfied with the state of data persistence in a live USB image at the time of Fedora 9’s release. Thus, he was a little concerned that the feature was highlighted and central to the documentation and marketing content. I sat in the audience and thought, “Ha! Teach you to mark a feature as 100% when it’s really not.”

When we wrote up release notes and marketing material for Fedora 9, we drew directly from the appropriate sections in each feature page. If a feature sponsor puts a note in such as, “Persistence rocks but still has some bugs in these areas …”, you can be 100% sure the release notes and marketing materials are going to reflect that.

The moral here is to own the content that is most important to you so that it says what you mean it to say.