Merge pull request #33979 from github/repo-sync

Repo sync

src/ghes-releases/lib/release-templates/release-steps-0.md

@@ -9,7 +9,7 @@ labels:
   - GHES {{ release-number }}
 ---
 
-This issue tracks Docs Content's work for the GA release of a new version of GHES.
+This issue tracks Docs work for the GA release of GHES {{ release-number }}.
 
 <!-- issue-fields start -->
 
@@ -25,7 +25,7 @@ This issue tracks Docs Content's work for the GA release of a new version of GHE
 
 ## Instructions for triage
 
-- [ ] In the Enterprise focus area's project, adjust the "Cycle" field for this issue to the cycle containing the target date.
+- [ ] In the Enterprise project, adjust the "Cycle" field to the cycle containing the target date.
 
 <br/>
 
@@ -40,7 +40,7 @@ This issue tracks Docs Content's work for the GA release of a new version of GHE
 - [ ] **On the RC date**, merge PR for RC when instructed by the GHES Releases team.
 - [ ] After merging PR for RC, notify the API team in [#ecosystem-api](https://github.slack.com/archives/C1042T6MS) on Slack that they can now merge "Update OpenAPI 3.x Descriptions" PRs in [`github/rest-api-description`](https://github.com/github/rest-api-description/pulls), which you blocked as part of the issue for preparing OpenAPI assets.
 - [ ] Notify the Docs Content first responder (`@TBD`) that they can now merge OpenAPI PRs.
-- [ ] Create a PR to complete [these steps](https://github.com/github/docs-content/issues/12972#issuecomment-1947981671) to close the consolidated `github/releases` issue, https://github.com/github/releases/issues/3925.
+- [ ] To close this issue, open a PR to complete [these steps](https://github.com/github/docs-content/issues/12972#issuecomment-1947981671).
 ```
 
 ## Resources

src/ghes-releases/lib/release-templates/release-steps-1.md

@@ -10,7 +10,7 @@ labels:
 
 ## Instructions for triage
 
-- [ ] In the Enterprise focus area's project, adjust the "Cycle" field for this issue to the cycle containing the target date.
+- [ ] In the Enterprise project, adjust the "Cycle" field to the cycle containing the target date.
 
 ## Instructions for assignee
 
@@ -25,7 +25,7 @@ labels:
 
 ### [👀](#prerequisites) Prerequisites
 
-- To simplify creation of the publication PR, install the GitHub CLI, then authenticate.
+- Install the GitHub CLI, then authenticate.
 
   - For more information about installation, see [README.md](https://github.com/cli/cli#installation) in the cli/cli repository.
   - To authenticate, run the `gh auth login` command. For more information about authentication, see [gh auth login](https://cli.github.com/manual/gh_auth_login) in the GitHub CLI manual.
@@ -39,7 +39,7 @@ labels:
 
 ### [🆕](#creation) Create the publication branch for a new version of GHES
 
-To enable a new version of GHES on GitHub Docs, you must update the site's supported versions, create placeholder data, and add a banner for the release candidate (RC).
+To enable a new version of GHES on GitHub Docs, update the site's supported versions, create placeholder data, and add a banner for the release candidate (RC).
 
 - [ ] In `github/docs-internal`, from `main`, create a new branch named <code>ghes-VERSION-rc</code>. For example, `ghes-3.10-rc`.
 
@@ -55,7 +55,7 @@ To enable a new version of GHES on GitHub Docs, you must update the site's suppo
      export const supported = ['3.10', '3.9', '3.8', '3.7', '3.6']
      ```
 
-  - [ ] For `releaseCandidate`, change the variable definition from `null` to the version we're releasing. For example, if the release version is 3.10:
+  - [ ] For `releaseCandidate`, change the variable definition from `null` to the release version. For example, if the release version is 3.10:
 
      ```js
      export const releaseCandidate = '3.10'
@@ -73,33 +73,35 @@ To enable a new version of GHES on GitHub Docs, you must update the site's suppo
 
   - [ ] Add and commit the changes.
 
-- [ ] Optionally, on your workstation, run the local development environment for GitHub Docs and verify that the new GHES version is enabled. For more information, see "[About versions of GitHub Docs](https://docs.github.com/get-started/learning-about-github/about-versions-of-github-docs)".
+- [ ] Optionally, on your workstation, run the local development environment for GitHub Docs and verify that the new GHES version is enabled. See "[About versions of GitHub Docs](https://docs.github.com/get-started/learning-about-github/about-versions-of-github-docs)".
 
 - [ ] Push your changes.
 
-- [ ] Create a PR for your branch. For the body, copy the contents of the body comment for the [previous release](https://github.com/github/docs-internal/pull/44684), modifying it to reflect this release.
+- [ ] Create a PR. For the body, copy the contents of the body comment for the [previous release](https://github.com/github/docs-internal/pull/44684), modifying it to reflect this release.
 
-- [ ] Link your PR to this issue. For more information, see "[Linking a pull request to an issue](https://docs.github.com/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#manually-linking-a-pull-request-to-an-issue-using-the-pull-request-sidebar)".
+- [ ] Link your PR to this issue. See "[Linking a pull request to an issue](https://docs.github.com/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#manually-linking-a-pull-request-to-an-issue-using-the-pull-request-sidebar)".
 
 <br/>
 <a name="check-failures">
 
 ### [🚨](#check-failures) Resolve check failures
 
-After you create the publication PR, ensure that the PR's checks pass as soon as possible. If you experience a check failure that does not appear below, contact Docs Engineering for support.
+After you create the publication PR, ensure that the checks pass as soon as possible. If you experience a check failure that isn't listed below, contact Docs Engineering for support.
 
 #### Link Checker: On PR / check-links (pull_request)
 
-If this check fails, you generally must fix broken links.
-
 Our link checker validates links the site. If links are broken immediately after creation of your publication PR, the broken link was missed upon introduction because it's within content that did not yet render anywhere on the site. There are two common reasons for these failures.
 
-- We've mentioned GitHub.com-only features within GHES articles that are also versioned for FPT or GHEC. For more information, see [Enterprise products](https://github.com/github/docs-content/blob/main/focus-areas/enterprise/writing-for-enterprise/products.md#feature-availability) in the Enterprise focus area docs.
-- We've linked from content outside of the API or webhooks docs to API or webhook docs that we haven't yet generated and published from the OpenAPI schema in github/github.
+- We mentioned GitHub.com-only features within GHES articles that are also versioned for FPT or GHEC. See [Enterprise products](https://github.com/github/docs-content/blob/main/focus-areas/enterprise/writing-for-enterprise/products.md#feature-availability) in the Enterprise focus area docs.
+- We linked from content outside of the API or webhooks docs to API or webhook docs that have not yet been generated and published from the OpenAPI schema in github/github.
 
-If you're unfamiliar with the content with the broken link, consult the DRI for the content's focus area. For more information, see the [README](https://github.com/github/docs-content/blob/main/focus-areas/README.md) in `github/docs-content`.
+If you aren't familiar with the content with the broken link, consult the DRI for the content's focus area. See the [README](https://github.com/github/docs-content/blob/main/focus-areas/README.md) in `github/docs-content`.
 
-For links that are broken due to in-progress work elsewhere in the docs, you can comment out problematic versioning temporarily using {% raw %}`{% comment %}`{% endraw %} tags in Liquid or by prepending `#` in YAML front matter. If you comment out any versioning, leave a comment on the **Files changed** tab with an explanation of the temporary change and tracking the necessary updates in the PR's body. After the necessary changes are in `main`, uncomment the versioned content.
+For broken links due to in-progress work elsewhere in the docs, you can comment out problematic versioning temporarily by:
+- using {% raw %}`{% comment %}`{% endraw %} tags in Liquid or 
+- prepending `#` in YAML front matter. 
+
+If you comment out versioning, explain the temporary change in a comment on the **Files changed** tab, and track the necessary updates PR's body. After the necessary changes are in `main`, uncomment the versioned content.
 
 For content from the OpenAPI schema, note the affected content with broken links in the PR's body.
 
@@ -112,21 +114,21 @@ For content from the OpenAPI schema, note the affected content with broken links
 
 After your publication PR's are passing, complete the following maintenance **daily**.
 
-1. On your workstation, in your clone of `github/docs-internal`, ensure the environment is clean and there are no pending changes.
+1. In your clone of `github/docs-internal`, ensure the environment is clean and there are no pending changes.
 
 1. Check out `main`, then pull the latest changes.
 
 1. Check out your publication branch,  <code>ghes-VERSION-rc</code>, then merge changes from `main`.
 
 1. Push the changes.
 
-1. If any new check failures arise, refer to "Addressing check failures" above.
+1. If new check failures arise, refer to "Addressing check failures" above.
 
-1. If any merge conflicts arise, resolve them. If you're not sure how to resolve the conflict, consult the DRI for the content's focus area. For more information, see the [README](https://github.com/github/docs-content/blob/main/focus-areas/README.md) in `github/docs-content`.
+1. If merge conflicts arise, resolve them. If you're not sure how to resolve the conflict, consult the DRI for the content's focus area. See the [README](https://github.com/github/docs-content/blob/main/focus-areas/README.md) in `github/docs-content`.
 
 <br/>
 <a name="publication">
 
 ### [🚢](#publication) Complete preparation for the RC and publish the docset
 
-To complete preparation and publish the docset, continue the tasks in {{ release-steps-0-url }}. Leave this issue open until you merge the publication PR.
+Continue the tasks in {{ release-steps-0-url }}. Leave this issue open until you merge the publication PR.

src/ghes-releases/lib/release-templates/release-steps-2.md

@@ -10,11 +10,15 @@ labels:
 
 ## Instructions for triage
 
-- [ ] In the Enterprise focus area's project, adjust the "Cycle" field for this issue to the cycle four weeks before the target date.
+- [ ] In the Enterprise project, adjust the "Cycle" field to the cycle **four weeks** before the target date.
 
 ## Instructions for assignee
 
-To prepare for a GHES RC, you must monitor for late-breaking content changes, validate the content we're publishing, gather and revise release notes, and share the release notes with stakeholders.
+To prepare for a GHES RC, you will:
+- monitor for late-breaking content changes
+- validate the content being published
+- gather and edit release notes
+- share release notes with stakeholders
 
 - [Track content work and progress toward final builds](#tracking)
 - [Populate the Release Tracker's "GHES Docs" view](#population)
@@ -176,7 +180,7 @@ At least a week before the ship date for the RC, request review of the PR with t
 
 1. After you've received writer and PM approval, merge the PR into the topic branch that you created for the PR to close {{ release-steps-1-url }}.
 
-1. Link the PR to this issue as well. For more information, see "[Linking a pull request to an issue](https://docs.github.com/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#manually-linking-a-pull-request-to-an-issue-using-the-pull-request-sidebar)".
+1. Link the PR to this issue as well. See "[Linking a pull request to an issue](https://docs.github.com/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#manually-linking-a-pull-request-to-an-issue-using-the-pull-request-sidebar)".
 
 1. To provide other GTM teams like Support Delivery an advance look at changes in the release, share a link to the release notes on the staging deployment and a link to the YAML file in **Files changed** tab within the PR for {{ release-steps-1-url }}.