This SOP describes the best practices for running a productive release QA retrospective.
A software retrospective is a process by which a team reviews successes and failures, makes recommendations and executes corrective action. A retrospective is an iterative process that works best when consistently applied to a project. The exact frequency and format will differ between projects and teams. This page documents the process used by Fedora QA.
Create a wiki page
The best time to start the retrospective page is early in the release. Ideally, this is before any QA-owned tasks in the Fedora schedule. By starting the retrospective early, you can record events as the happen. This helps avoid memory gaps three months later when attempting to summarize the feedback.
To get started, create a wiki page named
Fedora NN QA Retrospective, where
NN represents the Fedora release number under test (e.g. Fedora 31 QA Retrospective). At a minimum, include three different sections for feedback; 1) what worked well, 2) what didn't work and 3) wish list. You can find examples from previous QA retrospectives. Finally, be sure to include this page in the appropriate category
Once the retrospective page is ready, it's time to encourage feedback. Announce that the retrospective page is ready for feedback to appropriate channels. Some suggested comm
- Send an announcement mail to the test-announce mailing list.
- Post a blog article to Fedora Planet - multiple posts encouraged
- Contact the Fedora Weekly News QA beat writer to ensure it is mentioned in the upcoming news article
- Send an announcement to http://fedoraforum.org
- If you microblog (ala twitter), update your status referencing