User:Jlaska/QA:SOP release retrospective

This SOP describes the best practices for running a productive release QA retrospective.

Background

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.

[...] a retrospective is a meeting held by a project team at the end of a project or process (often after an iteration) to discuss what was successful about the project or time period covered by that retrospective, what could be improved, and how to incorporate the successes and improvements in future iterations or projects. http://en.wikipedia.org/wiki/Retrospective#Software_development

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 41 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 [[Category:QA_Retrospective]].

Announce

Once the retrospective page is ready, it's time to solicit feedback. Announce that the retrospective page is ready for feedback to appropriate channels.

• Send an announcement mail to the test-announce mailing list.
• Post a blog article to Fedora Planet - multiple posts encouraged
• If you microblog (ala twitter), update your status referencing #fedora