It is still under construction and content may change. Do not rely on the information on this page.
How to be a Beat Writer
There is plenty of information on the wiki about how to become a beat writer. We need people who will pick up a piece that interests them and help tell the world. What is lacking is help in how to execute the duties of a beat writer. This page hopes to address that. Please take care to note that these are the opinions of one beat writer, and perhaps something of an outlier at that.
The Process
During the release cycle, there are things that need to be done to stay on top of the release. Most of these, honestly, are pretty lightweight. They may seem a bit daunting at first, but really, they're not too bad. The hardest part, though, is understanding what is expected; this page hopes to address that.
Finding out what a Beat looks like
The beat page in the wiki ultimately becomes a section of the release notes for the next release of Fedora. It's primary objective is to help people understand what has changed. Depending on the beat, it might be helpful to begin with a 'short' synopsis of what is in the beat, but the main thrust should be to describe the changes between the next release and the previous.
Just how detailed this should be depends on the particular topic. For many packages a simple note mentioning a new version of a particular package, perhaps with a short description of new features is adequate. For a completely new package, you may want to be a little more detailed. Most packages come from an upstream project, so in general you want to include a link to the upstream's release notes.
Sometimes a package has changed in a way that requires action from a user. Perhaps the user must install an external package, perhaps (s)he must do some sort of file conversion. When this happens, the beat must include at least a warning, and a link to the details. In cases where there are probably many users, and especially when those users might be less experienced, then a detailed, step-by-step description of what needs to be done is in order.
Read through the current version of the release notes. You will see examples of both very brief descriptions and very detailed descriptions. As you read through the release notes, keep in mind that the audience for, say, gcc is a very different audience than that for the Flash plugin, for example, even though they end up in the same document.
Finding out what is in the Beat
This sounds simple, but is probably the hardest part. You took on (or are thinking of taking on) the Beat Writer duties because there is a subject within Fedora that you care about, and maybe are even familiar with. You probably already use some of the packages in your particular beat. The operative word there is some. Fedora now has well over 11,000 packages. Chances are there are packages in your area you don't know about. The good news is that you are likely to find packages you wish you knew about sooner!
PackageKit is one obvious place to start. PackageKit is not organized by Beats. As a result, not all packages are in obvious places in PackageKit, and many packages "belong" in multiple groups. But at least PackageKit is a start. The GUI for PackageKit wasn't really aimed at Beat Writers, so this process can be a little tedious.
When you are looking around in PackageKit, at least scan groups that don't seem to be related to your beat. The people who organized the groups in PackageKit had a different point of view. Even when a package at first seems way out of bounds for a particular group, usually if you give it a little thought, you can see the rationale, even though you may not agree with it.
If your particular ares of interest is supported by a SIG, then the SIG's page on the wiki is probably the best place to look. The SIG page not only has the current packages, but often has news of planned packages. Unfortunately, not all beats are supported by SIGs.