doc: specify release owner, clarify some steps

.github/ISSUE_TEMPLATE/prepare_release.md

@@ -15,15 +15,17 @@ For detailed info on the release process refer to https://github.com/waku-org/nw
 
 ### Items to complete
 
+All items below are to be completed by the owner of the given release.
+
 - [ ] Create release branch
 - [ ] Assign release candidate tag to the release branch HEAD. e.g. v0.30.0-rc.0
-- [ ] Generate and edit releases notes
+- [ ] Generate and edit releases notes in CHANGELOG.md
 - [ ] _End user impact_: Summarize impact of changes on Status end users (can be a comment in this issue).
 - [ ] **Validate release candidate**
 
   - [ ] **On Waku fleets**
     - [ ] Lock `waku.test` fleet to release candidate version
-    - [ ] Continuously stress `waku.test` fleet for a week (e.g. from `waku-dev`)
+    - [ ] Continuously stress `waku.test` fleet for a week (e.g. from `wakudev`)
     - [ ] Search _Kibana_ logs from the previous month (since last release was deployed), for possible crashes or errors in `waku.test` and `waku.sandbox`.
       - Most relevant logs are `(fleet: "waku.test" OR fleet: "waku.sandbox") AND message: "SIGSEGV"`
     - [ ] Run release candidate with `waku-simulator`, ensure that nodes connected to each other
@@ -31,17 +33,16 @@ For detailed info on the release process refer to https://github.com/waku-org/nw
 
   - [ ] **On Status fleet**
     - [ ] Deploy release candidate to `status.staging`
-    - [ ] Perform [sanity check](https://www.notion.so/How-to-test-Nwaku-on-Status-12c6e4b9bf06420ca868bd199129b425)
-      - [ ] Connect 2 instances to `status.staging` fleet
-      - [ ] Send contact request across and accept
+    - [ ] Perform [sanity check](https://www.notion.so/How-to-test-Nwaku-on-Status-12c6e4b9bf06420ca868bd199129b425) and log results as comments in this issue.
+      - [ ] Connect 2 instances to `status.staging` fleet, one in relay mode, the other one in light client.
       - [ ] 1:1 Chats with each other
       - [ ] Send and receive messages in a community
       - [ ] Close one instance, send messages with second instance, reopen first instance and confirm messages sent while offline are retrieved from store
     - [ ] Perform checks based _end user impact_
-    - [ ] Ask other CCs to point their instance to `status.staging` for a week and use the app as usual.
+    - [ ] Ask other (Waku and Status) CCs to point their instance to `status.staging` for a week and use the app as usual.
     - [ ] Ask Status/QA to perform sanity checks (as described above) + checks based on _end user impact_
     - [ ] Get other CCs sign-off: they comment on this PR "used app for a week, no problem", or problem reported, resolved and new RC
-    - [ ] Get Status/QA sign-off
+    - [ ] **Get Status/QA sign-off**. Ensuring that `status.test` update will not disturb ongoing activities.
 
 - [ ] **Proceed with release**
 
@@ -54,9 +55,8 @@ For detailed info on the release process refer to https://github.com/waku-org/nw
 - [ ] **Promote release to fleets**.
   - [ ] [Deploy final release to `waku.sandbox` fleet](https://ci.infra.status.im/job/nim-waku/job/deploy-waku-sandbox)
   - [ ] Deploy final release to `waku.prod`
-  - [ ] Deploy final release to `status.staging`
-  - [ ] Deploy final release to `status.test` (soon to be `status.prod`)
+  - [ ] [Deploy final release to `status.staging` fleet](https://ci.infra.status.im/job/nim-waku/job/deploy-shards-staging/)
+  - [ ] [Deploy final release to `status.test` fleet](https://ci.infra.status.im/job/nim-waku/job/deploy-shards-test/) ([soon to be `status.prod`](https://github.com/status-im/infra-shards/issues/33))
 
-post release
-
-    Submit a PR from the release branch to master. Important to commit the PR with "create a merge commit" option.
+- [ ] **Post release**
+  - [ ] Submit a PR from the release branch to master. Important to commit the PR with "create a merge commit" option.