It’s that time again. Time to review, discuss and learn from any hiccups encountered while testing the previous release. No matter how successful a release is, there is always something to improve on. Fedora 15 was no exception.
First, some ground rules … we’re not trying to solve the world problems with this retrospective. It’s focused on Fedora QA, our interactions with other teams, and what we can improve on to better accomplish our goals. For a more general release retrospective, Jared already has an app for that. Next, this isn’t the place to point fingers and taunt other teams/people. Use your own blog for that . Let’s keep the retrospective as objective and actionable as possible. For example, when recording issues, it’s important to know the bug(s) involved and what factors contributed to the problem(s). I’m not interested in what Steve thinks Mary said that Jillian heard after passing out at 31 flavors last night.
Next, a bit of history. The process starts early each release when I draft a retrospective wiki page to track issues as they happen. I break the page down into three groups; 1) what worked (sometimes we get things right!), 2) what didn’t work (learn from our mistakes etc…), 3) wishlist (aka pony). It’s just my nature to want to know what went wrong, and try to fix it. Accordingly, most of the content focuses on problems we encounter during the release. Also, I wanted to have some concept of scope … which is where the wishlist/pony group comes in. I still don’t know if it really fits, but I find it interesting to see what comments people have without constraints.
The retrospective concept doesn’t really work if only one person provides feedback. So, I try to get the word out so anyone can add issues. This is an area where I could certainly do better, probably by blogging more about it. As the release progresses, I beg/plead/nag people closest to the issues to add some notes to the wiki. I’m sure most people get tired of my nagging for content, but I’ve seen too often where we forget the causes of a critical problem, or don’t properly record the conditions leading up to a failure. Without accurate data on the cause of problems, any corrective measures are just busy work. So, the release chugs along, and hopefully the list of good/bad/wishlist issues matures.
mental note … I need to document this in a SOP
Okay … so all that preamble just to let folks know I completed a draft of recommendations based on the Fedora 15 QA retrospective feedback. I’ll be sending this out to the test@ list for review shortly. Check it out, and tell me what you think. See something missing, don’t agree with something … just let me know.