Release Management/Worry Lists
This process started with the Firefox 14 release when Release Management became more than one person's job. The practice was developed as a way to keep a record of what the release manager on point for a specific version was 'worrying' about. If used correctly it becomes a place to check the current status of a release with bucketing of bugs, lists of what bugs need to land for a specific Beta, and it can also contain general notes on timing & specific reminders throughout the 18 week cycle.
The two main use cases are:
1. Release manager on point for a release has a place to sort out and prioritize their current concerns and action items in a space that isn't just a bugzilla query. This worry list can help you bucket issues in ways that result in emails, outreach, getting QA attention, looking for assignees, and elevating questions to release-drivers about stability concerns.
2. If the release manager on point was to disappear for any reason, another release manager can leverage the worry list and know at-a-glance what the most pressing issues for a release are given the time. Eg: Beta 4 is supposed to get kicked off today, here's the list of "must land by beta 4" bugs that the previous RM was counting on. This can really help when you initially take over the release, before you get familiar with the full spectrum of what is currently open and tracked.
There is a worry list template which helps identify some of the main areas of interest another release manager might have if they were to suddenly be handed a release in mid-stream.
Historical Worry Lists
These examples demonstrate how worry lists have been used over the course of the last few years: