chore(issue_template): Update release tracking issue

.github/ISSUE_TEMPLATE/02-advanced-issue.md

@@ -7,15 +7,13 @@ assignees: ''
 
 ---
 
-# Title
-
 <!--
-- Ensure the title is specific and descriptive
+- Ensure the PR title is specific and descriptive
 - Avoid acronyms if possible
 -->
 
 ## Description
-    
+
 <!--
 - "What" are we trying to achieve
 - Briefly describe what this issue aims to achieve
@@ -25,7 +23,7 @@ Examples:
 -->
 
 ## Value
-         
+
 <!--
 - "Why" do we want to do this
 - Clearly define the value this brings to customers or why else it is important if not _directly_ for customers (e.g. internal tooling or improvements, technical debt, ...)
@@ -38,7 +36,7 @@ Examples:
 -->
 
 ## Dependencies
-    
+
 <!--
 - Consider and name any internal and external dependencies and constraints
 - List all known necessary resources (e.g. cluster, customers, people, repositories, libraries...)
@@ -59,14 +57,14 @@ Examples:
         - Marketing / Showcase
 - Initial tasks might just be _separate_ research tasks, which, upon completion, lead to more tasks in this task/epic
 - When creating the list of tasks make sure to put them in an order and focus on creating minimum marketable features
-- This is the _Definition of Done_ which (mostly, exception are marketing tasks) represents the technical "completeness" of a task 
+- This is the _Definition of Done_ which (mostly, exception are marketing tasks) represents the technical "completeness" of a task
 
 Example:
   - Marketing: Prepare a blog post outlining the new CRD versioning support, our policies around CRD versioning and the current versions we do support
 -->
 
 ## Acceptance Criteria
-  
+
 <!--
 - List acceptance criteria
 - Define clear objective criteria for when we would consider this issue "Done"
@@ -80,12 +78,11 @@ Example:
     - Traces are exported via OTLP and can be seen in Jaeger (or equivalent trace visualisation tool) (achieves a goal, while only being as prescriptive as necessary)
     - CRD versioning is seamlessly integrated into our operators, allowing for the specification of multiple versions within CRDs.
     - Backward compatibility is maintained for at least two previous versions of CRDs.
-    - 
 
 -->
 
 ## (Information Security) Risk Assessment
-      
+
 <!--
 - Outline any information security (this includes cybersecurity) or any other obvious risks and the controls how to mitigate them
 - This is relevant for ISO 27001, the Cyber Resilience Act and other standards/norms
@@ -99,7 +96,6 @@ Example:
     - ...
 -->
 
-
 ## Accessibility Assessment
 
 <!--
@@ -109,17 +105,16 @@ Example:
 -->
 
 ## Quality
-          
+
 <!--
 - Outline how this issue will be tested
 - Compatibility:
   - Try to ensure compatibility with all our supported versions (e.g. Kubernetes, OpenShift, product versions)
   - List any potential compatibility issues you're aware of
--->   
-
+-->
 
 ## Release Notes
-                     
+
 <!--
 - Write a short sentence or abstract that can go into the release notes
 - This way it is also documented for anyone finding _just this_ issue later
@@ -135,12 +130,11 @@ NOTE: This section is not meant to be displayed, therefore it is in a comment. Y
 - [ ] Delete everything that is irrelevant for this particular issue.
 - [ ] Add appropriate labels
 
-
 - There are different types of issues/epics, which might require different subsets (or no) sections of the above
     - e.g. "Update product versions"
     - e.g. "Implement new feature"
 - In the whole issue write out all acronyms that are not industry standard at least once. Example: OpenPolicyAgent (OPA)
 - If this is part of another issue please make sure to link the two in both places (parent & child)
 - If CRD changes (not necessarily breaking) are required, make sure structs/enums/fields are documented and are rendered properly in the CRD generation tool
 - Also see our [Development Philosophy](https://app.nuclino.com/Stackable/Stackable-Handbook/Development-Philosophy-ba280b20-b8cd-4fb6-a863-ff6d8c9f1af2)
--->    
+-->

.github/ISSUE_TEMPLATE/04-pre-release-openshift-tests.md

@@ -22,7 +22,7 @@ Part of <https://github.com/stackabletech/issues/issues/TRACKING_ISSUE>
 
 Make sure to run the tests using the following parameters:
 
-```
+```plain
 TEST_PLATFORM: OpenShift on replicated.com (4.15.0-okd)
 GIT_BRANCH_OR_TAG: origin/main
 OPERATOR_VERSION: 0.0.0-dev

.github/ISSUE_TEMPLATE/06-release.md

@@ -4,118 +4,158 @@ about: This template can be used to track the progress of the SDP
 title: "chore(tracking): SDP Release YY.M.X"
 labels: ['epic']
 assignees: ''
-
 ---
 
 <!--
     DO NOT REMOVE THIS COMMENT. It is intended for people who might copy/paste from the previous release issue.
     This was created by an issue template: https://github.com/stackabletech/issues/issues/new/choose.
 -->
 
-# Stackable Release YY.M.X
-
 > [!IMPORTANT]
 > Important dates:
+>
 > - ... - Release planning
 > - ... - Lock product versions
 > - ... - Final operator-rs release at CoB
 > - ... - Begin bumping operator-rs crates in each operator
-> - ... - Begin release-day tasks (release branches are cut)
+> - ... - Begin release-branching tasks
 > - ... - Target release date (marketable)
 
-## Release checklists
-
-Replace the items in the task lists below with the applicable Pull Requests / Issues
+> [!TIP]
+> Replace the items in the task lists below with the applicable Pull Requests / Issues.
 
-### General Pre-Requisites (before Feature Freeze)
+## Early Pre-release tasks
 
 > [!TIP]
 > These tasks should be done earlier in the process to lessen the burden at Pre-release time.
 
-```[tasklist]
-### Early Pre-release tasks
-- [ ] [Create a "Release Retro" issue](https://github.com/stackabletech/issues/issues/new?template=08-release-retro.md)
+- [ ] [Create a "Release Retro" issue][epr-1]
 - [ ] Define product versions to include in the next release
-- [ ] [Update and release operator-rs workspace members](https://github.com/stackabletech/operator-rs/issues/new?template=release-workspace-members.md)
-- [ ] [Update Rust toolchain of operators](https://github.com/stackabletech/operator-templating/issues/new?template=pre-release.md)
-- [ ] [Update Rust dependencies of operators](https://github.com/stackabletech/issues/issues/new?template=05-pre-release-operator-rust-deps.md)
-- [ ] [Major or Minor Container Images updates](https://github.com/stackabletech/docker-images/issues/new?template=early-pre-release.md)
-- [ ] [Patch Container Images updates](https://github.com/stackabletech/docker-images/issues/new?template=early-pre-release.md)
-```
+- [ ] [Update and release operator-rs workspace members][epr-2]
+- [ ] [Update Rust toolchain of operators][epr-3]
+- [ ] [Update Rust dependencies of operators][epr-4]
+- [ ] [Major or Minor Container Images updates][epr-5]
+- [ ] [Patch Container Images updates][epr-5] (Do not reuse the previous issue)
+- [ ] Run `niv update` and test via `make run-dev` (operator-templating)
+
+[epr-1]: https://github.com/stackabletech/issues/issues/new?template=08-release-retro.md
+[epr-2]: https://github.com/stackabletech/operator-rs/issues/new?template=release-workspace-members.md
+[epr-3]: https://github.com/stackabletech/operator-templating/issues/new?template=pre-release.md
+[epr-4]: https://github.com/stackabletech/issues/issues/new?template=05-pre-release-operator-rust-deps.md
+[epr-5]: https://github.com/stackabletech/docker-images/issues/new?template=early-pre-release.md
+
+## Pre-release
 
 > [!TIP]
 > These tasks should be done a week or so before the release date.
 
-```[tasklist]
-### Pre-release
 - [ ] Run all of the test suites in Jenkins (with all product versions, not just "nightly")
-- [ ] [Check and update getting-started scripts](https://github.com/stackabletech/issues/issues/new?template=03-pre-release-getting-started-scripts.md)
-- [ ] [Check and update demo charts](https://github.com/stackabletech/demos/issues/new?template=pre-release-chart-updates.md)
-- [ ] [Test demos and upgrade from stable to nightly release](https://github.com/stackabletech/demos/issues/new?template=pre-release-upgrade-testing.md)
+- [ ] [Check and update getting-started scripts][pr-1]
+- [ ] [Check and update demo charts][pr-2]
+- [ ] [Test demo upgrades (stable to nightly)][pr-3]
+- [ ] [Test demos from scratch (nightly)][pr-4]
 - [ ] Ensure integration tests are successful on OpenShift (run with `--test-suite openshift` against Replicated OKD)
-- [ ] Check stackable-utils scripts in dry-run mode work
-```
+- [ ] Check [stackable-utils] scripts in dry-run mode work
+- [ ] Search for open issues labeled with [scheduled-for/YY.M.X][pr-5]
 
-### Other Pre-Requisites (before Feature Freeze)
+[pr-1]: https://github.com/stackabletech/issues/issues/new?template=03-pre-release-getting-started-scripts.md
+[pr-2]: https://github.com/stackabletech/demos/issues/new?template=pre-release-chart-updates.md
+[pr-3]: https://github.com/stackabletech/demos/issues/new?template=pre-release-upgrade-testing.md
+[pr-4]: https://github.com/stackabletech/demos/issues/new?template=pre-release-from-scratch-testing.md
+[pr-5]: https://github.com/search?q=org%3Astackabletech+label%3Ascheduled-for%2FYY.M.X&type=issues&state=open
 
-Search for open issues labeleded with [`scheduled-for/YY.M.X`](https://github.com/search?q=org%3Astackabletech+label%3Ascheduled-for%2FYY.M.X&type=issues&state=open)
+## Release branching
 
-```[tasklist]
-### Other release-specific pre-requisites
-- [ ] Run `niv update` and test via `make run-dev` (operator-templating)
-```
+> [!CAUTION]
+> A small change freeze is required until these tasks have been completed.
 
-### Feature freeze
+> [!TIP]
+> See [stackable-utils] for script to create tags and update changelogs.
 
-This will not be so crucial with release branches, but is nonetheless sensible as it will make it easier to cherry-pick any release-related bugfixes from main into the release branch.
+- [ ] Create release branch for docker-images
+- [ ] Create release branches for operators
+- [ ] Create release branch for demos
+- [ ] _Wait for images to be built before proceeding_
 
-### End of the release cycle (Release day)
+## Release candidate testing
+
+> [!WARNING]
+> To be discussed during the on-site.
+>
+> Getting started scripts use particular product versions (this would have been updated in the
+> early-pre-release stage), however, at this point in time, the images will be tagged with an rcX
+> tag.
+
+<!--
+
+> [!TIP]
+> As issues are discovered, they can be fixed on the `main` branch, and cherry-picked into the release branch.
+>
+> Please ensure the changelog is updated and correct for the release after cherry-picking changes.
+> Please also keep PR links as they are in `main` (do not update them for the cherry-picked PR).
 
-```[tasklist]
-#### Technical tasks
-- [ ] Create release branch for docker-images (see stackable-utils for script to create branches)
-- [ ] Create release branches for operators (see stackable-utils for script to create branches)
-- [ ] Create release branch for demos (see stackable-utils for script to create branches)
-- [ ] _Wait for images to be built_
 - [ ] [Check and update getting-started scripts](https://github.com/stackabletech/issues/issues/new?template=07-release-getting-started-scripts.md) for the Release Candidate
 - [ ] [Test demos and upgrade from previous to this release](https://github.com/stackabletech/demos/issues/new?template=release-upgrade-testing.md) for Release Candidate (only fresh install)
-- [ ] Create release tag(s) for docker-images (see stackable-utils for scripts to create tags)
-- [ ] Create release tag(s) for operators (see stackable-utils for scripts to create tags)
-- [ ] Update release version in changelogs on main branches (see stackable-utils for script to do this)
-- [ ] Generate CRD docs [website](https://crds.stackable.tech/) for the new release by following these [instructions](https://github.com/stackabletech/crddocs)
+
+-->
+
+## Release tagging
+
+> [!TIP]
+> See [stackable-utils] for script to create tags and update changelogs.
+
+- [ ] Create release tag(s) for docker-images
+- [ ] Create release tag(s) for operators
+- [ ] Update release version in changelogs on main branches
+- [ ] _Wait for images to be built before proceeding_
 - [ ] Test `stackablectl` with locally updated (to new release number) `releases.yaml`
-- [ ] Update `release.yaml` in https://github.com/stackabletech/release/blob/main/releases.yaml
-- [ ] [Check and update getting-started scripts](https://github.com/stackabletech/issues/issues/new?template=07-release-getting-started-scripts.md)
-- [ ] [Test demos and upgrade from previous to this release](https://github.com/stackabletech/demos/issues/new?template=release-upgrade-testing.md)
+- [ ] Update [release.yaml](https://github.com/stackabletech/release/blob/main/releases.yaml)
+- [ ] Release stackablectl
+
+## Release verification
+
+> [!TIP]
+> These tasks do not block the Documentation tasks below and can be done concurrently.
+
+- [ ] [Check getting-started scripts][rv-1]
+- [ ] [Test demos from scratch (YY.M.X)][rv-2]
 - [ ] Check that an upgrade can be performed on an existing cluster without data loss (cycling demo)
 - [ ] Run all integration tests (for both `x86_64` and ~`aarch64`~ (defer aarch64 until interu is used))
 - [ ] Ensure integration tests are successful on OpenShift (run with `--test-suite openshift` against Replicated OKD)
-- [ ] Release stackablectl
-```
+
+[rv-1]: https://github.com/stackabletech/issues/issues/new?template=07-release-getting-started-scripts.md
+[rv-2]: https://github.com/stackabletech/demos/issues/new?template=release-upgrade-testing.md
+
+## Documentation tasks
 
 > [!TIP]
 > Name the release-notes branch `docs/release-notes-YY.M.X` so that the link below takes you directly to the [Pull Request template][docs-pr-template].
 
-[docs-pr-template]: https://github.com/stackabletech/documentation/tree/main/.github/PULL_REQUEST_TEMPLATE/release-notes.md&title=chore(tracking):%20Release%20Notes%20for%20SDP%20YY.M.X
-
-```[tasklist]
-#### Documentation tasks
+- [ ] Generate CRD docs [website][dt-1] for the new release by following these [instructions][dt-2]
 - [ ] Create a stackabletech/documentation branch called `docs/release-notes-YY.M.X`
 - [ ] Compile list of new product features in newly supported versions for the YY.M.X release (for the blog post)
-- [ ] Begin writing the release notes with the [Pull Request template](https://github.com/stackabletech/documentation/compare/main...docs/release-notes-YY.M.X?template=release-notes.md&title=chore(tracking):%20Release%20Notes%20for%20SDP%20YY.M.X)
+- [ ] Begin writing the release notes with the [Pull Request template][dt-3]
 - [ ] Update SDP release version in `documentation/modules/ROOT/pages/getting-started.adoc` and test the release install command
-- [ ] Cut a release branch (see [scripts/make-release-branch.sh](https://github.com/stackabletech/documentation/blob/main/scripts/make-release-branch.sh))
-- [ ] Update releases in the playbook (see [scripts/publish-new-version.sh](https://github.com/stackabletech/documentation/blob/main/scripts/publish-new-version.sh))
+- [ ] Cut a release branch (see [scripts/make-release-branch.sh][dt-4])
+- [ ] Update releases in the playbook (see [scripts/publish-new-version.sh][dt-5])
 - [ ] Remove any references to HEAD and main from the Antora playbooks on the release branch (replace with the release branch)
 - [ ] Update antora.yaml version in stackabletech/demos on the release branch - the stackable-utils release-scripts should do this like they do for products and operators.
 - [ ] Set the release to "Released" in the Feature Tracker and create a new release (ping @lfrancke)
-- [ ] Update the getting-started page in the main docs and check it works with this release: https://github.com/stackabletech/documentation/blob/main/modules/ROOT/pages/getting-started.adoc
-```
+- [ ] Update the [getting-started page][dt-6] in the main docs and check it works with this release
+
+[dt-1]: https://crds.stackable.tech/
+[dt-2]: https://github.com/stackabletech/crddocs
+[dt-3]: https://github.com/stackabletech/documentation/compare/main...docs/release-notes-YY.M.X?template=release-notes.md&title=chore(tracking):%20Release%20Notes%20for%20SDP%20YY.M.X
+[dt-4]: https://github.com/stackabletech/documentation/blob/main/scripts/make-release-branch.sh
+[dt-5]: https://github.com/stackabletech/documentation/blob/main/scripts/publish-new-version.sh
+[dt-6]: https://github.com/stackabletech/documentation/blob/main/modules/ROOT/pages/getting-started.adoc
+[docs-pr-template]: https://github.com/stackabletech/documentation/tree/main/.github/PULL_REQUEST_TEMPLATE/release-notes.md&title=chore(tracking):%20Release%20Notes%20for%20SDP%20YY.M.X
 
-Marketing tasks can now reference published documentation.
+## Marketing tasks
+
+> [!NOTE]
+> Marketing material can now reference published documentation.
 
-```[tasklist]
-#### Marketing tasks
 - [ ] Write marketing / customer oriented release summary to be published in the marketing channels
 - [ ] Update the homepage banner (as long as we have it) to point to the new release
 - [ ] Write a blogpost / news article announcing the new release (optional)
@@ -127,19 +167,22 @@ Marketing tasks can now reference published documentation.
 - [ ] Post an announcement in the GitHub [Discussions Announcement forum](https://github.com/stackabletech/community/discussions/categories/announcements) and make it a pinned discussion while at the same time removing the old pinned thread
 - [ ] Post an announcement in Discord
 - [ ] Post an announcement on DOK Community in the #be-shameless Channel (Ping Lars or Jim)
-- [ ] Post an announcement via OSBA (Ping Lars, [email protected])
+- [ ] Post an announcement via OSBA (Ping Lars, <mailto:[email protected]>)
 - [ ] Send announcement to Kubernetes Podcast (Ping Lars)
 - [ ] Send announcement to Heiser
 - [ ] Ping the stackable-ionos-tech channel or anyone responsible once all tags are created
-```
 
-```[tasklist]
-#### Post-release tasks
+## Post-release tasks
+
 - [ ] Test demo upgrades, which were skipped in the previous testing (optional)
-- [ ] Update the list of supported SDP releases in Jira (ping Jim)
-- [ ] Openshift certification. Create an issue from this [template](https://github.com/stackabletech/issues/blob/main/.github/ISSUE_TEMPLATE/olm_manifests.md) for the OLM manifests
-- [ ] Mark any releases older than one year as "end-of-life" [in the documentation](https://github.com/stackabletech/documentation/blob/f751e7ff7cddacae7d2c6c2c6c1d1c877c7aa11c/antora.yml#L18) (update antora.yaml on the applicable branches).
-- [ ] Post YY.M.X release retro (use issue created at the start of the process)
-- [ ] Update the release tracking template (optional)
-- [ ] [Create the next release tracking task](https://github.com/stackabletech/issues/issues/new?template=06-release.md) (if the date is available)
-```
+- [ ] Update the list of supported SDP releases in Jira (ping @Jimvin)
+- [ ] Openshift certification. [Create an issue][pt-1] to track the creation of the OLM manifests
+- [ ] Mark any releases older than one year as "end-of-life" in the documentation (update [antora.yaml][pt-2] on the applicable branches).
+- [ ] _Link to release retro issue (use issue created at the start of the process)_
+- [ ] Update the release tracking templates (optional)
+- [ ] [Create the next release tracking task][pt-3] (if the date is available)
+
+[pt-1]: https://github.com/stackabletech/issues/issues/new?template=09-olm_manifests.md
+[pt-2]: https://github.com/stackabletech/documentation/blob/f751e7ff7cddacae7d2c6c2c6c1d1c877c7aa11c/antora.yml#L18
+[pt-3]: https://github.com/stackabletech/issues/issues/new?template=06-release.md
+[stackable-utils]: https://github.com/stackabletech/stackable-utils/blob/main/release/README.md