= Release team working process =

This is the way the release team is supposed to work.

== Overview ==
The release team process consists of the following activities:
 * Opening
 * Testing
 * Reviews
 * Release assembly
 * Bugfixing

=== Opening ===
This are the first things that the team should do after the official sprint opening:
 * Create a branch from the trunk. The name should be further determined(perhaps something like release01 or release01-pre-alpha-2)
 * Create a wiki page for the release. This will be ITERATION_<it_number>/Release
 * Select tasks for testing. Sort them by their testability and importance
 * Merge back valuable changes done on the previous release branch into the trunk
 * Disable nonworking functinality that is not supposed to be available and is messing the other code.

=== Testing ===
This refers to the last phase of a task's revision lifecycle. 

It includes th following:
 * Writing user documentation for each user related task
  * User documets are something like help
  * They describe what Sophie 2.0 features are available and the way the user can use them
 * Writing release documentation where applicable
  * It describes shortly the released features
  * Describes non-user features
 * Making manual test cases in our [http://sophie2.org/testlink TestLink instance].
  * Each feature should have at least one new test case each revision.
  * Related test cases should be found and listed.
 * Executing test cases
  * Execute newly created test case
  * Execute related test cases
 * Reporting bugs that were found during the tests
  * Bugs will be new tickets in our Trac environment but with a different workflow.
  * They should have a description and a link to the test case in testlink that found them.
 * Have a look at related bugs - this means look if there are new bugs in the related tests.

=== Reviews ===
 * We should do reviews on implementations done by functional teams
 * It this is needed we could help with desgin reviews

=== Release Asembly ===
 * Final bugfixes
 * Find workarounds for those bugs that cannot be fixed but
 * Disable things that cannot be fixed or worked around
 * Make the download page
 * Make the downloadanbles

=== Bugfixing ===

 * Choose bugs to fix from the opened ones in Trac
 * Take the bug ticket
 * Research for a bugfix
 * If a fix is available its resul must be described in the ticket
 * Change the status of the ticket

== Iteration schedule ==
 * The iteration begins with the general sprint opening - 1d
 * Do release team opening as described above - 2d
 * Start testing and bugfixing.
 * Start making reviews. We should always keep the tasks pending for a review as less as possible.
 * As the iteration progresses the less effort is spent on testing and more on reviewing.
 * Do the rekease assembly - 4d
 * Do the demo and the sprint closing

You can also look at the attached photos.

== Comments ==