move to the org document

release-management-flow.md

@@ -1,33 +0,0 @@
-This document aims to help the release manager managing the release.
-
-# pre release planning
-
-- [ ] create a new project and prioritize issues / bugs with the team lead and according to the current roadmap.
-- [ ] check with the team lead if this needs an intermediate release (intermediate release should be 2-3 weeks max).
-- [ ] a release kickoff meeting with the team aiming to get input from everyone and modify the project accordingly.
-- [ ] 2-3 days span where team members estimate their issues.
-- [ ] a release planning meeting where we agree on the release scope (intermediate and/or classic release).
-- [ ] after this meeting: all the issues / PR should have been qualified in term of effort and scope.
-- [ ] after this meeting: date for feature freeze, QA period, and release date should be set in the project title.
-
-
-# coding period
-
-- [ ] 10 min after each daily standup where the release manager give an update of the current situation and ETA.
-- [ ] release manager should make sure to be aware of the current state of each issues ans PRs during the coding period, so he/she can best provide support.
-
-# QA preparation
- 
-- [ ] prepare the internal QA document, assign team members.
-- [ ] prepare the external beta test document for beta testers.
-- [ ] 1 week before QA period, start engaging with beta testers and online.
-
-# feature freeze, QA period.
-
-- [ ] publish to remix-beta every day.
-- [ ] merge reviewed PRs.
-- [ ] a QA open sync meeting where we all do our assigned tasks.
-
-# post release
-
-- [ ] retrospective meeting.

release-management.md

@@ -64,6 +64,42 @@ The release manager is still responsible for ensuring a project is rolled out sm
  - During feature freeze, remix-beta should be updated every morning.
  - A meeting with Andy and Rob should be organized for ensuring the beta test results are properly handled.
 
+## check list:
+
+
+    ### pre release planning
+
+    - [ ] create a new project and prioritize issues / bugs with the team lead and according to the current roadmap.
+    - [ ] check with the team lead if this needs an intermediate release (intermediate release should be 2-3 weeks max).
+    - [ ] a release kickoff meeting with the team aiming to get input from everyone and modify the project accordingly.
+    - [ ] 2-3 days span where team members estimate their issues.
+    - [ ] a release planning meeting where we agree on the release scope (intermediate and/or classic release).
+    - [ ] after this meeting: all the issues / PR should have been qualified in term of effort and scope.
+    - [ ] after this meeting: date for feature freeze, QA period, and release date should be set in the project title.
+
+
+    ### coding period
+
+    - [ ] 10 min after each daily standup where the release manager give an update of the current situation and ETA.
+    - [ ] release manager should make sure to be aware of the current state of each issues and PRs during the coding period in order to have a better overview of who is working on what and best provide support to all the team members that are involved in the release.
+
+    ### QA preparation
+ 
+    - [ ] prepare the internal QA document, assign team members.
+    - [ ] prepare the external beta test document for beta testers.
+    - [ ] 1 week before QA period, start engaging with beta testers and online.
+
+    ### feature freeze, QA period.
+
+    - [ ] publish to remix-beta every day.
+    - [ ] merge reviewed PRs.
+    - [ ] a QA open sync meeting where we all do our assigned tasks.
+
+    ### post release
+
+    - [ ] retrospective meeting.
+
+
 ## Assignments:
 
 Aniket, Liana, David, Rob, Filip, Yann