Merge branch 'main' into patch-3

.github/PULL_REQUEST_TEMPLATE.md

@@ -4,7 +4,7 @@ Thank you for contributing to this project! You must fill out the information be
 
 ### Why:
 
-Closes: 
+Closes:
 
 <!-- If there's an existing issue for your change, please link to it above.
 If there's _not_ an existing issue, please open one first to make it more likely that this update will be accepted: https://github.com/github/docs/issues/new/choose. -->
@@ -16,7 +16,6 @@ If you made changes to the `content` directory, a table will populate in a comme
 
 ### Check off the following:
 
-- [ ] I have reviewed my changes in staging, available via the **View deployment** link in this PR's timeline (this link will be available after opening the PR).
-
-  - For content changes, you will also see an automatically generated comment with links directly to pages you've modified. The comment won't appear if your PR only edits files in the `data` directory.
-- [ ] For content changes, I have completed the [self-review checklist](https://docs.github.com/en/contributing/collaborating-on-github-docs/self-review-checklist).
+- [ ] A subject matter expert (SME) has reviewed the technical accuracy of the content in this PR. In most cases, the author can be the SME. Open source contributions may require a SME review from GitHub staff.
+- [ ] The changes in this PR meet [the docs fundamentals that are required for all content](http://docs.github.com/en/contributing/writing-for-github-docs/about-githubs-documentation-fundamentals).
+- [ ] All CI checks are passing.

.github/workflows/comment-release-note-info.yml

@@ -25,7 +25,7 @@ jobs:
         with:
           issue-number: ${{ github.event.pull_request.number }}
           body: |
-            Thank you for updating our GitHub Enterprise Server release notes. A member of the `docs-content-enterprise` team will review your changes.
+            Thank you for updating our GitHub Enterprise Server release notes. Please request a technical review for your changes. Once the technical review is complete, a member of the `docs-content-enterprise` team will review your changes.
 
             - If the change is urgent, post in `#docs-content-enterprise` on Slack.
             - Review the [style guide for release notes](https://docs.github.com/en/contributing/style-guide-and-content-model/style-guide#release-notes).

.github/workflows/hubber-contribution-help.yml

@@ -44,11 +44,11 @@ jobs:
       - name: Comment on the PR
         if: steps.membership_check.outputs.result == 'false'
         run: |
-          gh pr comment $PR --body "Thanks so much for opening this PR and contributing to GitHub Docs!
+          gh pr comment $PR --body "### Next: add the review label
 
-          - When you're ready for the Docs team to review this PR, add the *ready-for-doc-review* label to your PR, and it will be automatically added to the [Docs Content review board](https://github.com/orgs/github/memexes/901?layout=table&groupedBy%5BcolumnId%5D=11024). **Please factor in at least 72 hours for a review, even longer if this is a substantial change.**
-          - If you're adding a release note, request a technical review. The Docs team will review the PR after the technical review is complete.
-          - If your updates to the docs are more than a simple fix, you might want to go back and open an [issue](https://github.com/github/docs-content/issues/new/choose) to ensure we've covered all areas of the docs in these updates. Not doing so may result in delays or inaccurate documentation."
+          **🛎️ Is this PR ready for review?** A PR is ready for a docs review _after_ the self-review checklist is complete.
+
+           When this is ready for review, add the **\`ready-for-doc-review\`** label to this PR. The PR will then be automatically added to the [Docs Content review board](https://github.com/orgs/github/projects/2936). _Please allow at least 3 working days for a review, and longer if this is a substantial change._"
 
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

content/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/authenticating-to-the-github-api.md

@@ -28,15 +28,15 @@ You can authenticate {% data variables.product.prodname_actions_runner_controlle
    1. For "Homepage URL," enter `https://github.com/actions/actions-runner-controller`.
 
    1. Under "Permissions," click **Repository permissions**. Then use the dropdown menus to select the following access permissions.
-      * **Administration**: Read and write
+      * **Administration:** Read and write
 
         > [!NOTE]
         > `Administration: Read and write` is only required when configuring {% data variables.product.prodname_actions_runner_controller %} to register at the repository scope. It is not required to register at the organization scope.
 
-      * **Metadata**: Read-only
+      * **Metadata:** Read-only
 
    1. Under "Permissions," click **Organization permissions**. Then use the dropdown menus to select the following access permissions.
-      * **Self-hosted runners**: Read and write
+      * **Self-hosted runners:** Read and write
 
 {% data reusables.actions.arc-app-post-install-steps %}
 

content/actions/hosting-your-own-runners/managing-self-hosted-runners/monitoring-and-troubleshooting-self-hosted-runners.md

@@ -34,9 +34,9 @@ You may not be able to create a self-hosted runner for an organization-owned rep
 
     The status can be one of the following:
 
-    * **Idle**: The runner is connected to {% data variables.product.product_name %} and is ready to execute jobs.
-    * **Active**: The runner is currently executing a job.
-    * **Offline**: The runner is not connected to {% data variables.product.product_name %}. This could be because the machine is offline, the self-hosted runner application is not running on the machine, or the self-hosted runner application cannot communicate with {% data variables.product.product_name %}.
+    * **Idle:** The runner is connected to {% data variables.product.product_name %} and is ready to execute jobs.
+    * **Active:** The runner is currently executing a job.
+    * **Offline:** The runner is not connected to {% data variables.product.product_name %}. This could be because the machine is offline, the self-hosted runner application is not running on the machine, or the self-hosted runner application cannot communicate with {% data variables.product.product_name %}.
 
 ## Troubleshooting network connectivity
 

content/actions/hosting-your-own-runners/managing-self-hosted-runners/running-scripts-before-or-after-a-job.md

@@ -17,15 +17,15 @@ The custom scripts are automatically triggered when a specific environment varia
 
 The following scripting languages are supported:
 
-* **Bash**: Uses `bash` and can fallback to `sh`. Executes by running `-e {pathtofile}`.
-* **PowerShell**: Uses `pwsh` and can fallback to `powershell`. Executes by running `-command \". '{pathtofile}'\"`.
+* **Bash:** Uses `bash` and can fallback to `sh`. Executes by running `-e {pathtofile}`.
+* **PowerShell:** Uses `pwsh` and can fallback to `powershell`. Executes by running `-command \". '{pathtofile}'\"`.
 
 ## Writing the scripts
 
 Your custom scripts can use the following features:
 
-* **Variables**: Scripts have access to the default variables. The full webhook event payload can be found in `GITHUB_EVENT_PATH`. For more information, see "[AUTOTITLE](/actions/learn-github-actions/variables#default-environment-variables)."
-* **Workflow commands**: Scripts can use workflow commands. For more information, see "[AUTOTITLE](/actions/using-workflows/workflow-commands-for-github-actions)". Scripts can also use environment files. For more information, see [Environment files](/actions/using-workflows/workflow-commands-for-github-actions#environment-files).
+* **Variables:** Scripts have access to the default variables. The full webhook event payload can be found in `GITHUB_EVENT_PATH`. For more information, see "[AUTOTITLE](/actions/learn-github-actions/variables#default-environment-variables)."
+* **Workflow commands:** Scripts can use workflow commands. For more information, see "[AUTOTITLE](/actions/using-workflows/workflow-commands-for-github-actions)". Scripts can also use environment files. For more information, see [Environment files](/actions/using-workflows/workflow-commands-for-github-actions#environment-files).
 
 Your script files must use a file extension for the relevant language, such as `.sh` or `.ps1`, in order to run successfully.
 

content/actions/managing-workflow-runs-and-deployments/managing-deployments/managing-environments-for-deployment.md

@@ -80,17 +80,17 @@ Use a wait timer to delay a job for a specific amount of time after the job is i
 Use deployment branches{% ifversion deployment-protections-tag-patterns %} and tags{% endif %} to restrict which branches{% ifversion deployment-protections-tag-patterns %} and tags{% endif %} can deploy to the environment. Below are the options for deployment branches{% ifversion deployment-protections-tag-patterns %} and tags{% endif %} for an environment:
 
 {% ifversion deployment-protections-tag-patterns %}
-* **No restriction**: No restriction on which branch or tag can deploy to the environment.
+* **No restriction:** No restriction on which branch or tag can deploy to the environment.
 {%- else %}
-* **All branches**: All branches in the repository can deploy to the environment.
+* **All branches:** All branches in the repository can deploy to the environment.
 {%- endif %}
-* **Protected branches{% ifversion deployment-protections-tag-patterns %} only{% endif %}**: Only branches with branch protection rules enabled can deploy to the environment. If no branch protection rules are defined for any branch in the repository, then all branches can deploy. For more information about branch protection rules, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)."{% ifversion actions-protected-branches-restrictions %}
+* **Protected branches{% ifversion deployment-protections-tag-patterns %} only{% endif %}:** Only branches with branch protection rules enabled can deploy to the environment. If no branch protection rules are defined for any branch in the repository, then all branches can deploy. For more information about branch protection rules, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)."{% ifversion actions-protected-branches-restrictions %}
 
   > [!NOTE]
   > Deployment workflow runs triggered by tags with the same name as a protected branch and forks with branches that match the protected branch name cannot deploy to the environment.
 
   {% endif %}
-* **Selected branches{% ifversion deployment-protections-tag-patterns %} and tags{% endif %}**: Only branches{% ifversion deployment-protections-tag-patterns %} and tags{% endif %} that match your specified name patterns can deploy to the environment.
+* **Selected branches{% ifversion deployment-protections-tag-patterns %} and tags{% endif %}:** Only branches{% ifversion deployment-protections-tag-patterns %} and tags{% endif %} that match your specified name patterns can deploy to the environment.
 
   If you specify `releases/*` as a deployment branch{% ifversion deployment-protections-tag-patterns %} or tag{% endif %} rule, only a branch{% ifversion deployment-protections-tag-patterns %} or tag{% endif %} whose name begins with `releases/` can deploy to the environment. (Wildcard characters will not match `/`. To match branches{% ifversion deployment-protections-tag-patterns %} or tags{% endif %} that begin with `release/` and contain an additional single slash, use `release/*/*`.) If you add `main` as a branch rule, a branch named `main` can also deploy to the environment. For more information about syntax options for deployment branches, see the [Ruby `File.fnmatch` documentation](https://ruby-doc.org/core-2.5.1/File.html#method-c-fnmatch).
 

content/actions/security-for-github-actions/security-hardening-your-deployments/about-security-hardening-with-openid-connect.md

@@ -27,9 +27,9 @@ With OpenID Connect (OIDC), you can take a different approach by configuring you
 
 By updating your workflows to use OIDC tokens, you can adopt the following good security practices:
 
-* **No cloud secrets**: You won't need to duplicate your cloud credentials as long-lived {% data variables.product.prodname_dotcom %} secrets. Instead, you can configure the OIDC trust on your cloud provider, and then update your workflows to request a short-lived access token from the cloud provider through OIDC.
-* **Authentication and authorization management**: You have more granular control over how workflows can use credentials, using your cloud provider's authentication (authN) and authorization (authZ) tools to control access to cloud resources.
-* **Rotating credentials**: With OIDC, your cloud provider issues a short-lived access token that is only valid for a single job, and then automatically expires.
+* **No cloud secrets:** You won't need to duplicate your cloud credentials as long-lived {% data variables.product.prodname_dotcom %} secrets. Instead, you can configure the OIDC trust on your cloud provider, and then update your workflows to request a short-lived access token from the cloud provider through OIDC.
+* **Authentication and authorization management:** You have more granular control over how workflows can use credentials, using your cloud provider's authentication (authN) and authorization (authZ) tools to control access to cloud resources.
+* **Rotating credentials:** With OIDC, your cloud provider issues a short-lived access token that is only valid for a single job, and then automatically expires.
 
 ### Getting started with OIDC
 
@@ -159,8 +159,8 @@ The token also includes custom claims provided by {% data variables.product.prod
 With OIDC, a {% data variables.product.prodname_actions %} workflow requires a token in order to access resources in your cloud provider. The workflow requests an access token from your cloud provider, which checks the details presented by the JWT. If the trust configuration in the JWT is a match, your cloud provider responds by issuing a temporary token to the workflow, which can then be used to access resources in your cloud provider. You can configure your cloud provider to only respond to requests that originate from a specific organization's repository. You can also specify additional conditions, described below.
 
 Audience and Subject claims are typically used in combination while setting conditions on the cloud role/resources to scope its access to the GitHub workflows.
-* **Audience**: By default, this value uses the URL of the organization or repository owner. This can be used to set a condition that only the workflows in the specific organization can access the cloud role.
-* **Subject**: By default, has a predefined format and is a concatenation of some of the key metadata about the workflow, such as the {% data variables.product.prodname_dotcom %} organization, repository, branch, or associated [`job`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idenvironment) environment. See "[Example subject claims](#example-subject-claims)" to see how the subject claim is assembled from concatenated metadata.
+* **Audience:** By default, this value uses the URL of the organization or repository owner. This can be used to set a condition that only the workflows in the specific organization can access the cloud role.
+* **Subject:** By default, has a predefined format and is a concatenation of some of the key metadata about the workflow, such as the {% data variables.product.prodname_dotcom %} organization, repository, branch, or associated [`job`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idenvironment) environment. See "[Example subject claims](#example-subject-claims)" to see how the subject claim is assembled from concatenated metadata.
 
 If you need more granular trust conditions, you can customize the {% ifversion ghec %}issuer (`iss`) and {% endif %}subject (`sub`) claim{% ifversion ghec %}s that are{% else %} that's{% endif %} included with the JWT. For more information, see "[Customizing the token claims](#customizing-the-token-claims)".