From Fedora Project Wiki
m (More content)
m (Add a header ... ooh, fancy!)
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
{{header|qa}}
This SOP describes the best practices for running a productive release QA retrospective.   
This SOP describes the best practices for running a productive release QA retrospective.   


Line 15: Line 17:
== Announce ==
== 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.
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 [https://admin.fedoraproject.org/mailman/listinfo/test-announce test-announce mailing list].
* Send an announcement mail to the [https://admin.fedoraproject.org/mailman/listinfo/test-announce test-announce mailing list].
* Post a blog article to [http://planet.fedoraproject.org Fedora Planet] - ''multiple posts encouraged''
* Post a blog article to [http://planet.fedoraproject.org Fedora Planet] - ''multiple posts encouraged''
* Contact the [[FWN|Fedora Weekly News]] [[FWN/Beats#Beats_Sections|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 <code>#fedora</code>
* If you microblog (ala twitter), update your status referencing <code>#fedora</code>


Latest revision as of 19:58, 11 July 2011

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.


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 42 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 encourage feedback. Announce that the retrospective page is ready for feedback to appropriate channels. Some suggested comm

Update frequently

Last call

Recommendations

Tickets

Retrieved from "https://fedoraproject.org/w/index.php?title=User:Jlaska/QA:SOP_release_retrospective&oldid=245217"