Docs Project workflow - beat writing
Beat writing is often a contributor's fist exposure to working with the Fedora project. It is fun, because the beat writer gets to learn about the new things coming up in the next release of Fedora. It is relatively simple, technically, since most of the work is done in the wiki, but also since the work is done in the wiki, it is out in the open and easy to get input from more experienced contributors.
Selecting a beat
Beat writers sign up for beats on the Documentation Beats page. The list of beats is carried over from the previous release. If there is a need for a new beat it can easily be added. Each release of Fedora has a different flavor, and in some releases there may be no significant updates to a beat. In other releases there may be some significant changes for which there was no beat in the previous release.
Beat writers have a variety of resources at their disposal for identifying what will appear in the next release of Fedora. A particular beat writer might not exploit all of these resources; each beat is different and each beat writer is different. The following are some of the assets the beat writer might exploit.
Many beats have a developer contact listed. This can be a good way to get some insight into what is happening in that area. However, each release of Fedora updates thousands of packages. Chances are no one individual is aware of all that is happening, even in a particular area, so additional research is required.
The major features for a release must each produce a feature page. These are then vetted for inclusion in the next release of Fedora. The Features page contains links to features being considered in upcoming releases of Fedora. Each of those pages will have a listing of accepted and proposed features.
Packages to be included in the next release of Fedora must first be in Rawhide. This means that the beat writer can install a new package from Rawhide and experiment with it well before the release. Of course, not all dependencies might be in the previous release, so sometimes installing an experimental package can have a cascading effect. For this reason, it may make sense to do a rawhide install to a stick or virtual machine.
The beat writer must also keep in mind that all features appearing in Rawhide might not become accepted features for the upcoming release, and once past feature freeze, many developers will begin working on the next+1 release, and that work will appear in Rawhide.
Alpha and Beta
The Alpha and Beta releases give an early view of the next release. Alpha is generally a good time, Beta comes a bit late for release notes, although it can be good for last-minute checks.
Not everyone can afford to dedicate a machine to test on, however, so there are two ways you can run the Alpha or Beta software conveniently:
- Virtualization - running test software in a VM is by far the most convenient. Installing a new virtual machine on Fedora is simple and painless. However, there are two constraints that may prevent you from using this approach:
- You need a machine with virtualization support
- You need lots of memory
- USB Stick - You can use the Live USB Creator to install the Alpha or Beta on a USB thumb drive. You may then boot to the thumb drive and experiment with the new software. The thumb drive allows you to create documents, perform configurations, install software, and perform other operations that you might not be able to do on a LiveCD. However, the USB drive is significantly slower than a hard drive, so performance changes might not be obvious.
One of the better ways to stay abreast of changes is to follow the Development mailing list. However, this is a high volume list, and keeping up can be a bit of a chore. And like any high volume list, there can be significant debate and off-topic discussions. Nonetheless, it can be a valuable resource for the beat writer.