chore: update release templates (#9775)

.github/ISSUE_TEMPLATE/z_release_feature.md

@@ -7,7 +7,7 @@ assignees: ''
 
 ---
 
-When development is ready to begin on a [Feature Release](https://docs.communityhealthtoolkit.org/core/releases/feature_releases/#release-names), an engineer on the appropriate Care Team or Allies should be nominated as a Release Engineer. They will be responsible for making sure the following tasks are followed, though not necessarily doing the work themselves.
+When development is ready to begin on a [Feature Release](https://docs.communityhealthtoolkit.org/core/releases/feature_releases/#release-names), an engineer should be nominated as a Release Engineer. They will be responsible for making sure the following tasks are followed, though not necessarily doing the work themselves.
 
 # Planning
 
@@ -20,7 +20,7 @@ When development is ready to begin on a [Feature Release](https://docs.community
 
 - [ ] Create a new release branch in `cht-core` from the most recent release and call it  `<major>.<minor>.<patch>-FR-<FEATURE-NAME>`. If latest is `3.15.0` and the feature is to "allow movies to be uploaded", call it `3.15.0-FR-movie-upload`. Done before the release so all PRs can be set to merge to this branch, and not to `master`.
 - [ ] Set the version number in `package.json` and `package-lock.json` and submit a PR. The easiest way to do this is to use `npm --no-git-tag-version version <feature-release>`.
-- [ ] Ensure QA is briefed and is partnering with the Trio to ensure early and often checks of the feature are on track to be of production quality from the start.
+- [ ] Ensure QA is briefed and is partnering with the Engineers and any involved CHT Community members to ensure early and often checks of the feature are on track to be of production quality from the start.
 
 # Releasing
 

.github/ISSUE_TEMPLATE/z_release_major.md

@@ -7,7 +7,7 @@ assignees: ''
 
 ---
 
-# Planning - Product Manager
+# Planning - CHT Community 
 
 - [ ] Create a GH Milestone for the release. We use [semver](http://semver.org) so if there are breaking changes increment the major, otherwise if there are new features increment the minor, otherwise increment the service pack. Breaking changes in our case relate to updated software requirements (egs: CouchDB, node, minimum browser versions), broken backwards compatibility in an api, or a major visual update that requires user retraining.
 - [ ] Add all the issues to be worked on to the Milestone. Ideally each minor release will have one or two features, a handful of improvements, and plenty of bug fixes.
@@ -55,9 +55,7 @@ If all is good, then in 24h, I will start the release. Thanks!
 
 See below for some highlights, read the [release notes]({{<paste-url>}}) for full details.
 
-Following our support policy, versions {{versions}} are no longer supported. Projects running these versions should start planning to upgrade in the near future. For more details read our [software support documentation](https://docs.communityhealthtoolkit.org/core/releases/#supported-versions).
-
-Check out our [roadmap](https://github.com/orgs/medic/projects/112/views/21) to see what else is currently being working on.
+Following the CHT's support policy, versions {{versions}} are no longer supported. Projects running these versions should start planning to upgrade in the near future. For more details read the CHT [software support documentation](https://docs.communityhealthtoolkit.org/core/releases/#supported-versions).
 
 ## {{version}} Highlights
 
@@ -74,5 +72,5 @@ Check out our [roadmap](https://github.com/orgs/medic/projects/112/views/21) to
 We’ve also implemented loads of other improvements and fixed a heap of bugs.
 
 ```
-- [ ] Add one last update to the #product-team Slack channel and use the thread to lead an internal release retrospective covering what went well and areas to improve for next time.
+- [ ] Add one last update to the #development Slack channel and use the thread to lead an internal release retrospective covering what went well and areas to improve for next time.
 - [ ] Mark this issue "done" and close the Milestone.

.github/ISSUE_TEMPLATE/z_release_patch.md

@@ -7,7 +7,7 @@ assignees: ''
 
 ---
 
-# Planning - Product Manager
+# Planning - CHT Community 
 
 - [ ] Create an GH Milestone and add this issue to it.
 - [ ] Add all the issues to be worked on to the Milestone.
@@ -39,7 +39,7 @@ If all is good, then in 24h, I will start the release. Thanks!
     - [ ] Manually document any known migration steps and known issues.
     - [ ] Add a link to the new release page in the [Release Notes](https://docs.communityhealthtoolkit.org/core/releases/#release-notes) section.
     - [ ] Assign the PR to:
-        - The Director of Technology or a developer
+        - A developer
         - An SRE to review and confirm the documentation on upgrade instructions and breaking changes is sufficient
 - [ ] Create a release in GitHub from the release branch so it shows up under the [Releases tab](https://github.com/medic/cht-core/releases) with the naming convention `<major>.<minor>.<patch>`, and change the Target dropdown to the release branch (eg: `4.4.x`). This will create the git tag automatically. Ensure the release notes PR above is merged. Link to the release notes in the description of the release.
 - [ ] Confirm the release build completes successfully and the new release is available on the [market](https://staging.dev.medicmobile.org/_couch/builds_4/_design/builds/_view/releases). Make sure that the document has new entry with `id: medic:medic:<major>.<minor>.<patch>`