See internal doc process here:

https://github.com/stolostron/rhacm-docs/blob/gh-pages/_pages/gen_availability_tasks.md

Open issues and attach each one, sharing across the team as needed.

Tasks to complete early staging

1. Remove old What's new entries so that the team can start over for the new release. Open a task for this.
2. Remove deprecation and removal items that are older than staged-N minus two (the squads help with this via the cross-squad issues that you open).
3. Clean the Errata release notes to only have the intro (both MCE and ACM). Open a task for this or use the task from step one.
4. Update link versions for OCP. Open a task for this. (Currently we use the earliest of N-2, unless the feature is built on a later OCP. See PM for guidance. If this changes, we need to change the note we added about this.)
5. Update any other versions, such as channel, RHEL, etc.... Get guidance from a tech lead on this.
6. Change support matrix links in the doc and on the Splash Page. (You can use the tasks you already opened for creating the new matrices)
7. If something went EOL, ensure the latest doc reflects those changes. See Deprecating and removing for that guidance. Open a task for this.
8. Work with console focal and engineers to ensure links in the console have not changed. You will need to know the deadline for code changes from the UI team. 
9. Create the Splash page with the links you need.

Preparing for Pencils Down

1. Ensure the build is regularly green. Ask writers fix any errors for their books a few days before GA and work to keep the build green closer to the agreed upon Pencils Down day.
2. Ask the team to work on reconciling the changes and merging active PRs to the stage branch. Since this depends on reviews and such, the PR list may not be clear in time, but no PRs for stage is the goal for Pencils Down.
3. Declare Pencils Down on the date/time so that the team pauses any pushing to stage.
4. Build stage. Check for green. Fix any errors.

Creating `production` branch from `stage` 

1. Create the new <release_number>_prod branch from the <release_number>_stage branch.
2. Protect the branch to keep anyone from bypassing rules in the production branch. Two users are needed to push stage into to prod: The creator and the reviewer. Go to {}Settings{} > {}Branches{}. (Because GitHub changes the UI at times, if this is not the workflow, you can simply Google something like "how to protect my branch in GitHub" for the process.)
3. Select {}Add rule{} in the Branch protection rules section. 
4. Add the branch name to the {}Branch name pattern{}. Example: `2x_prod`. 
5. Select {}Require a pull request before merging{}. 
6. Ensure that {}Require approvals{} is selected. 
7. Select {}Do not allow bypassing the above settings{} to prevent admins from bypassing this rule. Admins can bypass in `stage` IF needed, but not `prod`.
8. Select {}Create{} to apply the rule. 
9. Run a build with the prod branch in the command: `./acm_sync_asciidoc.sh 2.x 2.x_prod`
10. Ensure the build is clean.
11. Stop any builds until GA day and after because `prod` and `stage` are in the same directory. You can return to building stage after you publish.

Publishing doc and splash page

Ideally the architect or strategist is doing this but can be done by the lead, with overall big-picture in mind. See support from the DE/PM about arranging this when needed.

1. Log in to Pantheon.
2. See the Publish a GA version section of [Refreshing builds](refresh_builds.md) and complete the procedure. <!-- we probably need to rename this simply to "Publishing" because it is for GA and refresh.-->
2. Click {}Splash Pages{} in the navigation to view the splash pages. If you are not logged in to Pantheon, you will not see this item in the navigation.
3. Find the entry for {}Red Hat Advanced Cluster Management for Kubernetes{}. The entry should show the version of the product that you are pushing, with an `unpublished` label.
4. Click the name of the product to open the splash page. 
5. Add the categories for the documentation and drag the books into the correct categories, if necessary. 
6. When you are ready to publish it, expand {}Update/view product status{}.
7. Change the Product status from {}Unpublished{} to {}Published{}.
8. Click {}Save{} to save the changes.

Publishing support matrices

1. Publish MCE matrix at MCE GA, then update the previous matrix references with the newest version.
2. Publish ACM matrix at ACM GA, then update the previous matrix references with the newest version.
3. Double check that all links work in the documentation.
4. Request support matrix link update on product page

5. Clone CPPX-948(https://issues.redhat.com/browse/CPPX-948) and update the version numbers. This example was used for version 2.12. 
6. Request an update to the Support Matrix link on the product page to the new support matrix.
7. Submit the issue. It is usually a very fast turnaround. 

Additional required tasks

1. Publish the draft(s) for the Support Matrix. There should be an issue for the release that tracked this work. See the strategist or lead. Currently there is a matrix for ACM and MCE. 
2. Edit [Comet](https://comet.engineering.redhat.com/containers/products/5ec54aa3535cb70ab8c02996). <!{}check into this; I have not had to do this in a while. Ask Chris about this.{}>
3. Add the Support matrix to the [_Lifecycle_ page](https://access.redhat.com/support/policy/updates/advanced-cluster-management).
4. Double check that links to the Support matrix work after you publish.