fix: make docs/ the default version and sync v2.8.0 snapshot

docusaurus.config.js

@@ -187,6 +187,12 @@ module.exports = {
         showLastUpdateAuthor: false,
         showLastUpdateTime: true,
         includeCurrentVersion: true,
+        lastVersion: 'current',
+        versions: {
+          current: {
+            label: 'latest',
+          },
+        },
         // Performance optimization: Disable number prefix parser
         numberPrefixParser: false,
         // Performance optimization: Disable breadcrumbs for performance

versioned_docs/version-v2.8.0/README.md

@@ -1,4 +1,4 @@
 ---
 title: readme
 slug: /readme
----
+---

versioned_docs/version-v2.8.0/contributor/adopters.md

@@ -1,16 +1,20 @@
+---
+title: HAMi Adopters
+---
+
 # HAMi Adopters
 
-HAMi is used in production by the organisations listed below.
+So you and your organisation are using HAMi? That's great. Reach out and let the community know.
 
 ## Adding yourself
 
-[Here](https://github.com/Project-HAMi/website/blob/master/src/pages/adopters.mdx) lists the organisations who adopted the HAMi project in production.
+[See the list of HAMi adopters](https://github.com/Project-HAMi/website/blob/master/src/pages/adopters.mdx) for organisations who have adopted the HAMi project in production.
 
-Add an entry for your company - it will be added to the website once the PR merges.
+Add an entry for your company and upon merging it will automatically be added to the website.
 
 To add your organisation follow these steps:
 
-1. Fork the [HAMi-io/website](https://github.com/Project-HAMi/website) repository.
+1. Fork the [Project-HAMi/website](https://github.com/Project-HAMi/website) repository.
 2. Clone it locally with `git clone https://github.com/<YOUR-GH-USERNAME>/website.git`.
 3. (Optional) Add the logo of your organisation to `static/img/supporters`. Good practice is for the logo to be called e.g. `<company>.png`.
    This will not be used for commercial purposes.
@@ -19,10 +23,10 @@ To add your organisation follow these steps:
 
    | Organization | Contact                           | Environment | Description of Use                            |
    | ------------ | --------------------------------- | ----------- | --------------------------------------------- |
-   | My Company   | [email](mailto:email@company.com) | Production  | We use HAMi to Manage our GPU infrastructure. |
+   | My Company   | [email](mailto:email@company.com) | Production  | We use HAMi to manage our GPU infrastructure. |
 
 5. Save the file, then do `git add -A` and commit using `git commit -s -m "Add MY-ORG to adopters"`.
 6. Push the commit with `git push origin main`.
-7. Open a Pull Request to [HAMi-io/website](https://github.com/Project-HAMi/website) and a preview build will turn up.
+7. Open a Pull Request to [Project-HAMi/website](https://github.com/Project-HAMi/website) and a preview build will turn up.
 
-Thanks to all adopters for being part of the community!
+Thanks for being part of the community!

versioned_docs/version-v2.8.0/contributor/cherry-picks.md

@@ -1,121 +1,70 @@
 ---
 title: How to cherry-pick PRs
+sidebar_label: Cherry Picks
 ---
 
-This document explains how cherry picks are managed on release branches within
-the `Project-HAMi/HAMi` repository.
-A common use case for this task is backporting PRs from master to release
-branches.
-
-> This doc is lifted from [Kubernetes cherry-pick](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md).
-
-- [Prerequisites](#prerequisites)
-- [What Kind of PRs are Good for Cherry Picks](#what-kind-of-prs-are-good-for-cherry-picks)
-- [Initiate a Cherry Pick](#initiate-a-cherry-pick)
-- [Cherry Pick Review](#cherry-pick-review)
-- [Troubleshooting Cherry Picks](#troubleshooting-cherry-picks)
-- [Cherry Picks for Unsupported Releases](#cherry-picks-for-unsupported-releases)
+This document explains how cherry picks are managed on release branches in the `Project-HAMi/HAMi` repository. The typical use case is backporting a bug fix from master to an active release branch.
 
 ## Prerequisites
 
-- A pull request merged against the `master` branch.
-- The release branch exists (example: [`release-2.4`](https://github.com/Project-HAMi/HAMi/releases))
-- The normal git and GitHub configured shell environment for pushing to your
-  HAMi `origin` fork on GitHub and making a pull request against a
-  configured remote `upstream` that tracks
-  `https://github.com/Project-HAMi/HAMi`, including `GITHUB_USER`.
-- Have GitHub CLI (`gh`) installed following [installation instructions](https://github.com/cli/cli#installation).
-- A github personal access token which has permissions "repo" and "read:org".
-  Permissions are required for [gh auth login](https://cli.github.com/manual/gh_auth_login)
-  and not used for anything unrelated to cherry-pick creation process
-  (creating a branch and initiating PR).
-
-## What Kind of PRs are Good for Cherry Picks
-
-Compared to the normal master branch's merge volume across time,
-the release branches see one or two orders of magnitude less PRs.
-This is because there is an order or two of magnitude higher scrutiny.
-Again, the emphasis is on critical bug fixes, e.g.,
-
-- Loss of data
-- Memory corruption
-- Panic, crash, hang
-- Security
-
-A bugfix for a functional issue (not a data loss or security issue) that only
-affects an alpha feature does not qualify as a critical bug fix.
-
-If you are proposing a cherry pick and it is not a clear and obvious critical
-bug fix, please reconsider. If upon reflection you wish to continue, bolster
-your case by supplementing your PR with e.g.,
+- A pull request already merged into master.
+- The target release branch exists (for example, `release-2.4`).
+- Git and GitHub configured with your fork as `origin` and the upstream as `upstream`.
+- [GitHub CLI (`gh`)](https://github.com/cli/cli#installation) installed.
+- A GitHub personal access token with `repo` and `read:org` scopes, used for `gh auth login`.
 
-- A GitHub issue detailing the problem
+## What qualifies for a cherry pick
 
-- Scope of the change
+Release branches receive far fewer merges than master because the bar is higher. Cherry picks are reserved for critical fixes only:
 
-- Risks of adding a change
-
-- Risks of associated regression
-
-- Testing performed, test cases added
-
-- Key stakeholder reviewers/approvers attesting to their confidence in the
-  change being a required backport
+- Data loss
+- Memory corruption
+- Panic, crash, or hang
+- Security vulnerabilities
 
-It is critical that the full community is actively engaged on enhancements in
-the project. If a released feature was not enabled on a particular provider's
-platform, this is a community miss that needs to be resolved in the `master`
-branch for subsequent releases. Such enabling will not be backported to the
-patch release branches.
+A bug that affects only an alpha feature does not qualify, even if it is a real bug.
 
-## Initiate a Cherry Pick
+If the fix is not clearly critical, support the case with:
 
-- Run the [cherry pick script][cherry-pick-script]
+- A GitHub issue describing the problem
+- Scope of the change
+- Risks of adding the change
+- Risks of regression
+- Tests added or updated
+- Sign-off from key stakeholders or reviewers
 
-  This example applies a master branch PR #1206 to the remote branch
-  `upstream/release-1.0`:
+Features that were not enabled on a specific vendor's platform belong in master for the next release. They will not be backported.
 
-  ```shell
-  hack/cherry_pick_pull.sh upstream/release-1.0 1206
-  ```
+## Initiate a cherry pick
 
-  - Be aware the cherry pick script assumes you have a git remote called
-    `upstream` that points at the HAMi github org.
+Run the [cherry pick script][cherry-pick-script]. This example backports PR #1206 to `upstream/release-1.0`:
 
-  - You will need to run the cherry pick script separately for each patch
-    release you want to cherry pick to. Cherry picks should be applied to all
-    active release branches where the fix is applicable.
+```bash
+hack/cherry_pick_pull.sh upstream/release-1.0 1206
+```
 
-  - If `GITHUB_TOKEN` is not set you will be asked for your github password:
-    provide the github [personal access token](https://github.com/settings/tokens) rather than your actual github
-    password. If you can securely set the environment variable `GITHUB_TOKEN`
-    to your personal access token then you can avoid an interactive prompt.
-    Refer [https://github.com/github/hub/issues/2655#issuecomment-735836048](https://github.com/github/hub/issues/2655#issuecomment-735836048)
+Notes:
 
-## Cherry Pick Review
+- The script expects a remote named `upstream` pointing to `https://github.com/Project-HAMi/HAMi`.
+- Run the script separately for each release branch that needs the fix.
+- If `GITHUB_TOKEN` is not set, the script will prompt for a token. Use a [personal access token](https://github.com/settings/tokens) rather than your account password.
 
-As with any other PR, code OWNERS review (`/lgtm`) and approve (`/approve`) on
-cherry pick PRs as they deem appropriate.
+## Cherry pick review
 
-The same release note requirements apply as normal pull requests, except the
-release note stanza will auto-populate from the master branch pull request from
-which the cherry pick originated.
+Cherry pick PRs follow the same review process as normal PRs. Code owners review (`/lgtm`) and approve (`/approve`) as they see fit.
 
-## Troubleshooting Cherry Picks
+Release notes auto-populate from the original master PR.
 
-Contributors may encounter some of the following difficulties when initiating a
-cherry pick.
+## Troubleshooting
 
-- A cherry pick PR does not apply cleanly against an old release branch. In
-  that case, you will need to manually fix conflicts.
+**The cherry pick does not apply cleanly.**
+The patch conflicts with changes already in the release branch. Fetch the auto-generated branch from your fork, resolve the conflicts manually, and force-push.
 
-- The cherry pick PR includes code that does not pass CI tests. In such a case
-  you will have to fetch the auto-generated branch from your fork, amend the
-  problematic commit and force push to the auto-generated branch.
-  Alternatively, you can create a new PR, which is noisier.
+**CI fails on the cherry pick branch.**
+Fetch the auto-generated branch, amend the failing commit, and force-push. Alternatively, open a new PR manually - it is noisier but sometimes cleaner.
 
-## Cherry Picks for Unsupported Releases
+## Unsupported releases
 
-The community supports & patches releases need to be discussed.
+Fixes for end-of-life release branches are not accepted without prior discussion. Open an issue to start that conversation before submitting a cherry pick against an unsupported branch.
 
 [cherry-pick-script]: https://github.com/Project-HAMi/HAMi/blob/master/hack/cherry_pick_pull.sh