From Fedora Project Wiki
(Initial stub)
 
m (Add a header ... ooh, fancy!)
 
(2 intermediate revisions 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 8: Line 10:


== Create a wiki page ==
== 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 [http://rbergero.fedorapeople.org/schedules/f-{{FedoraVersionNumber|next}}/f-{{FedoraVersionNumber|next}}-quality-tasks.html 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 <code>Fedora NN QA Retrospective</code>, where <code>NN</code> represents the Fedora release number under test (e.g. [[Fedora {{FedoraVersionNumber|next}} 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 [[:Category:QA_Retrospective|previous QA retrospectives]].  Finally, be sure to include this page in the appropriate category <code><nowiki>[[Category:QA_Retrospective]]</nowiki></code>.


== Announce ==
== 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
* 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''
* 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>


== Update frequently ==
== Update frequently ==

Latest revision as of 19:58, 11 July 2011

QA.png


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

Update frequently

Last call

Recommendations

Tickets