diff --git a/src/guide/about-this-guide.md b/src/guide/about-this-guide.md
index 0909671..c97b0f5 100644
--- a/src/guide/about-this-guide.md
+++ b/src/guide/about-this-guide.md
@@ -3,3 +3,7 @@
This guide is being maintained through the [OpenJDK Developers' Guide Project](https://openjdk.org/census#guide). The [source repository](https://github.com/openjdk/guide) is available at GitHub. The revision hash at the bottom of this page refers to the last published commit.
Comments and questions may be sent to [guide-dev@openjdk.org](mailto:guide-dev@openjdk.org). Please let us know if there's anything in the guide that isn't clear.
+
+::: {.box}
+[To the top](#){.boxheader}
+:::
diff --git a/src/guide/backporting.md b/src/guide/backporting.md
index 57d77a2..392d9a0 100644
--- a/src/guide/backporting.md
+++ b/src/guide/backporting.md
@@ -54,6 +54,8 @@ In order to be allowed to push a change to one of the OpenJDK update development
If the update release is in rampdown, changes are pushed to the release repository (e.g. [`jdk17u`](https://github.com/openjdk/jdk17u)). During rampdown the bar to get changes in are significantly higher and fixes need to be approved with [jdk<release>u-critical-request]{.jbs-label} / [jdk<release>u-critical-yes]{.jbs-label}.
+If your request to backport a change is denied, but you for some reason already created the backport issue in JBS (why?!), the backport issue should be closed as [Won't Fix]{.jbs-value}.
+
## Using the Skara tooling to help with backports
The Skara tooling includes support for backports. [The official Skara documentation](https://wiki.openjdk.org/display/SKARA/Backports) describes in detail how to work with the tooling to create backport PRs on GitHub or using the CLI tools. As described in the documentation, the [`/backport`](https://wiki.openjdk.org/display/SKARA/Commit+Commands#CommitCommands-/backport) command can be used on a commit or a PR to create the backport PR. If a backport PR is manually created, set the PR title to `Backport <original commit hash>`. This ensures that the bots will recognize it as a backport as opposed to a main fix specifically targeting an older release. One can tell whether or not the bots recognized a PR as a backport by the [backport]{.label} label being added if it's recognized.
diff --git a/src/guide/fixing-a-bug.md b/src/guide/fixing-a-bug.md
index d96102b..02027bb 100644
--- a/src/guide/fixing-a-bug.md
+++ b/src/guide/fixing-a-bug.md
@@ -94,7 +94,7 @@ For the purposes of brevity this document will use the term "bug" to refer to bo
#. **Create a changeset**
- Follow the instructions in [Producing a Changeset].
+ Follow the instructions in [Working With Pull Requests].
#. **Update the bug content**
@@ -102,7 +102,7 @@ For the purposes of brevity this document will use the term "bug" to refer to bo
#. **Push the changeset into the Project's forest**
- Follow the instructions in [Producing a Changeset]. If working with a Sponsor, send the changeset to the development mailing list so that they can handle the final push.
+ Follow the instructions in [Working With Pull Requests]. If working with a Sponsor, send the changeset to the development mailing list so that they can handle the final push.
The push will trigger a update to the bug which will make the following changes:
diff --git a/src/guide/jbs-jdk-bug-system.md b/src/guide/jbs-jdk-bug-system.md
index ced72b8..267bc8d 100644
--- a/src/guide/jbs-jdk-bug-system.md
+++ b/src/guide/jbs-jdk-bug-system.md
@@ -195,7 +195,7 @@ Once you are made, or you make yourself, the assignee of an issue you take on th
Some additional fields should be filled out or updated as you get a better understanding of the issue:
-* For a regression, if you identify the fix that caused it, add a relates-to link to that issue (and add a [[regression_]{.jbs-label}(ID)](#regression-id) label) and set the [Introduced in Build]{.jbs-field} or [Introduced in Version]{.jbs-field} field.
+* For a regression, if you identify the fix that caused it, add a relates-to link to that issue (and add a [[regression_]{.jbs-label}(ID)](#regression_id) label) and set the [Introduced in Build]{.jbs-field} or [Introduced in Version]{.jbs-field} field.
* The [Description]{.jbs-field} usually explains what went wrong and how the failure was found, then there's some investigation and eventually the root cause is found. At this point the [Summary]{.jbs-field} should be updated to correctly describe the bug. The [Description]{.jbs-field} however should remain a description of how the failure was found.
* The [Affects Version/s]{.jbs-field} should be updated if you in your investigation finds that the issue is older than what is indicated by the current [Affects Version/s]{.jbs-field}.
@@ -622,7 +622,7 @@ Examples: If a bug fix only corrects a change in the build system, then add the
</td>
</tr>
<tr>
- <td class="dictionary">[[regression_]{.jbs-label}*(ID)*]{#regressionId}</td>
+ <td class="dictionary">[[regression_]{.jbs-label}*(ID)*]{#regression_id}</td>
<td class="dictionary">
Used to identify the fix that caused the regression, where known.
</td>
diff --git a/src/guide/release-notes.md b/src/guide/release-notes.md
index cd6d5bb..b85cc1d 100644
--- a/src/guide/release-notes.md
+++ b/src/guide/release-notes.md
@@ -72,7 +72,7 @@ The following are general practices that should be followed when creating releas
* [Description]{.jbs-field} - the JEP Summary text have already been heavily reviewed and also approved by the project lead. It should be the first sentence in the release note description. That would be analogous to the "change that was made" sentence in other release note descriptions. The remaining text would be composed of the background info from the JEP.
* [Description]{.jbs-field} - The JEP release note description should contain the link to the JEP.
* Single release note for multiple changes
- * A link to the parent issue that the note is a sub-task of, will be placed alongside the summary in the releasenotes. If note relates to additional changes, then add them as [Relates]{.jbs-field} links to the note and add the label [RN-multiple-links]{.jbs-label} - see [JDK-8284975](https://bugs.openjdk.org/browse/JDK-8284975) as an example.
+ * A link to the parent issue that the note is a sub-task of, will be placed alongside the summary in the releasenotes. If note relates to additional changes, then add them as [Relates]{.jbs-field} links to the note and add the label [RN-MultipleLinks]{.jbs-label} - see [JDK-8284975](https://bugs.openjdk.org/browse/JDK-8284975) as an example.
* Multiple release notes for the same change
* If more than one release note is required for the same set of fixes, then open additional sub-tasks with the same [Affects Version]{.jbs-field} - see [JDK-8073861](https://bugs.openjdk.org/browse/JDK-8073861) as an example.
* Release notes across backports
@@ -119,12 +119,12 @@ Unless labeled otherwise it will be assumed that the release note documents a ch
[[RN-]{.jbs-label}_(distro)_]{#RN-distro}
: Used to indicate that the release note is only relevant for a specific JDK distribution. E.g. [RN-Oracle]{.label}
+[[RN-MultipleLinks]{.jbs-label}]{#RN-MultipleLinks}
+: Used to indicate that the release note should refer to multiple changes - see [Advanced options](#advanced-options) section.
+
[[~~RN-Change~~]{.jbs-label}]{#RN-Change}
: Deprecated. This is the default and no label is needed to indicate this.
-[[RN-multiple-links]{.jbs-label}]{#RN-multiple-links}
-: Used to indicate that the release note should refer to multiple changes - see [Advanced options](#advanced-options) section.
-
## Querying the release notes
diff --git a/src/guide/working-with-pull-requests.md b/src/guide/working-with-pull-requests.md
index be6b779..e4ee253 100644
--- a/src/guide/working-with-pull-requests.md
+++ b/src/guide/working-with-pull-requests.md
@@ -68,7 +68,7 @@ If you have an actual reason to create a PR before the change is all done, make
#. **Make sure all relevant groups are included**
- The bot will make an attempt to include the groups that need to review your change based on the location of the source code you have changed. There may be aspects of your change that are relevant to other groups as well, and the mapping from source to groups isn't always perfect, so make sure all relevant groups have been included, and add new labels using [`/label`](https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands#PullRequestCommands-/label) if needed. Consult the [Code Owners]{#code-owners} section if you are unsure of who owns the code you are changing.
+ The bot will make an attempt to include the groups that need to review your change based on the location of the source code you have changed. There may be aspects of your change that are relevant to other groups as well, and the mapping from source to groups isn't always perfect, so make sure all relevant groups have been included, and add new labels using [`/label`](https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands#PullRequestCommands-/label) if needed. Consult the [Code Owners](#code-owners) section if you are unsure of who owns the code you are changing.
#. **Allow enough time for review**