Merge branch 'main' into adding-pointers-to-how-&-where-transfer-requ…

…ests-can-be-approved

content/actions/hosting-your-own-runners/managing-self-hosted-runners/autoscaling-with-self-hosted-runners.md

@@ -18,27 +18,13 @@ type: overview
 
 You can automatically increase or decrease the number of self-hosted runners in your environment in response to the webhook events you receive with a particular label. For example, you can create automation that adds a new self-hosted runner each time you receive a [`workflow_job`](/webhooks-and-events/webhooks/webhook-events-and-payloads#workflow_job) webhook event with the  [`queued`](/webhooks-and-events/webhooks/webhook-events-and-payloads#workflow_job) activity, which notifies you that a new job is ready for processing. The webhook payload includes label data, so you can identify the type of runner the job is requesting. Once the job has finished, you can then create automation that removes the runner in response to the `workflow_job` [`completed`](/webhooks-and-events/webhooks/webhook-events-and-payloads#workflow_job) activity.
 
-## Recommended autoscaling solutions
+## Supported autoscaling solutions
 
-{% data variables.product.prodname_dotcom %} recommends and partners closely with two open source projects that you can use for autoscaling your runners. One or both solutions may be suitable, based on your needs.
+{% data variables.product.prodname_dotcom %} recommends using [actions/actions-runner-controller](https://github.com/actions/actions-runner-controller) for autoscaling your runners.
 
-The following repositories have detailed instructions for setting up these autoscalers:
-
-- [actions/actions-runner-controller](https://github.com/actions/actions-runner-controller) - A Kubernetes controller for {% data variables.product.prodname_actions %} self-hosted runners.
-- [philips-labs/terraform-aws-github-runner](https://github.com/philips-labs/terraform-aws-github-runner) - A Terraform module for scalable {% data variables.product.prodname_actions %} runners on Amazon Web Services.
-
-Each solution has certain specifics that may be important to consider.
-
-{% rowheaders %}
-
-| | actions-runner-controller | terraform-aws-github-runner |
-| :--- | :--- | :--- |
-| Runtime | Kubernetes | Linux and Windows VMs |
-| Supported Clouds | Azure, Amazon Web Services, Google Cloud Platform, on-premises | Amazon Web Services |
-| Where runners can be scaled | Enterprise, organization, and repository levels. By runner label and runner group. | Organization and repository levels. By runner label and runner group. |
-| How runners can be scaled | Webhook events, Scheduled, Pull-based | Webhook events, Scheduled (org-level runners only) |
-
-{% endrowheaders %}
+{%- ifversion fpt or ghec or ghes > 3.8 %}
+For more information, see "[AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/about-actions-runner-controller)."
+{% endif %}
 
 ## Using ephemeral runners for autoscaling
 

content/actions/managing-issues-and-pull-requests/commenting-on-an-issue-when-a-label-is-added.md

@@ -19,9 +19,9 @@ shortTitle: Add label to comment on issue
 
 ## Introduction
 
-This tutorial demonstrates how to use the [`peter-evans/create-or-update-comment` action](https://github.com/marketplace/actions/create-or-update-comment) to comment on an issue when a specific label is applied. For example, when the `help-wanted` label is added to an issue, you can add a comment to encourage contributors to work on the issue.
+This tutorial demonstrates how to use the {% data variables.product.prodname_cli %} to comment on an issue when a specific label is applied. For example, when the `help wanted` label is added to an issue, you can add a comment to encourage contributors to work on the issue. For more information about {% data variables.product.prodname_cli %}, see "[AUTOTITLE](/actions/using-workflows/using-github-cli-in-workflows)."
 
-In the tutorial, you will first make a workflow file that uses the [`peter-evans/create-or-update-comment` action](https://github.com/marketplace/actions/create-or-update-comment). Then, you will customize the workflow to suit your needs.
+In the tutorial, you will first make a workflow file that uses the `gh issue comment` command to comment on an issue. Then, you will customize the workflow to suit your needs.
 
 ## Creating the workflow
 
@@ -30,38 +30,38 @@ In the tutorial, you will first make a workflow file that uses the [`peter-evans
 1. Copy the following YAML contents into your workflow file.
 
     ```yaml copy
-    {% data reusables.actions.actions-not-certified-by-github-comment %}
-
-    {% data reusables.actions.actions-use-sha-pinning-comment %}
-
     name: Add comment
     on:
       issues:
         types:
           - labeled
     jobs:
       add-comment:
-        if: github.event.label.name == 'help-wanted'
+        if: github.event.label.name == 'help wanted'
         runs-on: ubuntu-latest
         permissions:
           issues: write
         steps:
           - name: Add comment
-            uses: peter-evans/create-or-update-comment@5f728c3dae25f329afbe34ee4d08eef25569d79f
-            with:
-              issue-number: {% raw %}${{ github.event.issue.number }}{% endraw %}
-              body: |
-                This issue is available for anyone to work on. **Make sure to reference this issue in your pull request.** :sparkles: Thank you for your contribution! :sparkles:
+            run: gh issue comment "$NUMBER" --repo "$REPO" --body "$BODY"
+            env:
+              GITHUB_TOKEN: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
+              NUMBER: {% raw %}${{ github.event.issue.number }}{% endraw %}
+              REPO: {% raw %}${{ github.repository }}{% endraw %}
+              BODY: >
+                This issue is available for anyone to work on.
+                **Make sure to reference this issue in your pull request.**
+                :sparkles: Thank you for your contribution! :sparkles:
     ```
 
 1. Customize the parameters in your workflow file:
-   - Replace `help-wanted` in `if: github.event.label.name == 'help-wanted'` with the label that you want to act on. If you want to act on more than one label, separate the conditions with `||`. For example, `if: github.event.label.name == 'bug' || github.event.label.name == 'fix me'` will comment whenever the `bug` or `fix me` labels are added to an issue.
-   - Change the value for `body` to the comment that you want to add. GitHub flavored markdown is supported. For more information about markdown, see "[AUTOTITLE](/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax)."
+   - Replace `help wanted` in `if: github.event.label.name == 'help wanted'` with the label that you want to act on. If you want to act on more than one label, separate the conditions with `||`. For example, `if: github.event.label.name == 'bug' || github.event.label.name == 'fix me'` will comment whenever the `bug` or `fix me` labels are added to an issue.
+   - Change the value for `BODY` to the comment that you want to add. GitHub flavored markdown is supported. For more information about markdown, see "[AUTOTITLE](/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax)."
 1. {% data reusables.actions.commit-workflow %}
 
 ## Testing the workflow
 
-Every time an issue in your repository is labeled, this workflow will run. If the label that was added is one of the labels that you specified in your workflow file, the `peter-evans/create-or-update-comment` action will add the comment that you specified to the issue.
+Every time an issue in your repository is labeled, this workflow will run. If the label that was added is one of the labels that you specified in your workflow file, the `gh issue comment` command will add the comment that you specified to the issue.
 
 Test your workflow by applying your specified label to an issue.
 
@@ -72,4 +72,4 @@ Test your workflow by applying your specified label to an issue.
 
 ## Next steps
 
-- To learn more about additional things you can do with the `peter-evans/create-or-update-comment` action, like adding reactions, visit the [`peter-evans/create-or-update-comment` action documentation](https://github.com/marketplace/actions/create-or-update-comment).
+- To learn more about additional things you can do with the GitHub CLI, like editing existing comments, visit the [GitHub CLI Manual](https://cli.github.com/manual/).

content/contributing/style-guide-and-content-model/style-guide.md

@@ -1248,6 +1248,8 @@ Use clear, simple language that’s approachable for a wide range of readers. Be
 
 Write for your audience: some jargon and technical terms are necessary, but don't rely on the assumption that every reader has the same level of technical expertise.
 
+Use the active voice whenever possible. Passive voices is acceptable when you need to emphasize the object of an action.
+
 We are a global developer community. Avoid turns of phrase, idioms, and slang that are specific to a particular region or country.
 
 To learn more about writing approachable content, see “[Microsoft's brand voice: Above all, simple and human](https://docs.microsoft.com/style-guide/brand-voice-above-all-simple-human) and “[Top 10 tips for Microsoft style and voice](https://docs.microsoft.com/style-guide/top-10-tips-style-voice).”
@@ -1439,10 +1441,40 @@ See the “[Product names](#product-names)” section of this guide.
 | type (in the user interface) | enter (in the user interface) |
 | enter (in the command line) | type (in the command line) |
 
-## Word order
+## Word choice
+
+### Ambiguous verbs
+
+When a task is required, or one option is preferred to another, avoid using ambiguous modal auxiliary verbs such as "may," "might," "ought," "should," "could," "would," and "can." These verbs can be interpreted as either a command or a suggestion. Instead, use verbs that clearly indicate whether the action is required or optional. If something is an option or suggestion, you can use these verbs so long as you make it clear that the action is optional.
+
+- **Use:** You can decide which keyboard shortcuts to use.
+- **Use:** Use the `git clone` command to clone a repository.
+- **Avoid:** You can use the `git clone` command to clone a repository.
+- **Avoid:** You could delete the branch.
+
+### Invisible plurals
+
+Avoid invisible plurals, which are words that have ambiguous meaning because they can be interpreted as singular or plural. For example, "file retrieval" could refer to retrieving a single file or multiple files.
+
+- **Use:** After the file is retrieved, select where to save it.
+- **Avoid:** After file retrieval, select where to save it.
+
+### Nominalizations
+
+Avoid nominalizations, which are nouns created from verbs or adjectives. Nominalizations can make sentences longer, harder to understand, and harder to translate.
+
+- **Use:** After the workflow concludes, the package will be visible.
+- **Avoid:** After the workflow has reached its conclusion, the package will be visible.
 
 ### Strings of nouns
 
 Avoid stacked modifiers (strings of nouns), which can lead to incorrect translations because translations may not be able to tell which word is modifying the other. You can rephrase the string of nouns using a preposition. If using a stacked modifier is essential, make sure the background information and context are clear so that readers and the translator can understand what is being modified.
 - **Use:** Default source settings for public repositories
 - **Avoid:** Public repository default source settings
+
+### Vague nouns and pronouns
+
+If a pronoun seems to refer to more than one antecedent, either reword the sentence to make the antecedent clear or replace the pronoun with a noun to eliminate ambiguity.
+
+- **Use:** After you make your final commit to your branch and merge your pull request, you can delete your branch.
+- **Avoid:** After you make your final commit to your branch and merge your pull request, you can delete it.

content/rest/overview/about-githubs-apis.md → content/rest/overview/comparing-githubs-rest-api-and-graphql-api.md

@@ -1,11 +1,13 @@
 ---
-title: About GitHub's APIs
+title: Comparing GitHub's REST API and GraphQL API
+shortTitle: Comparing GitHub's APIs
 intro: 'Learn about {% data variables.product.prodname_dotcom %}''s APIs to extend and customize your {% data variables.product.prodname_dotcom %} experience.'
 redirect_from:
   - /v3/versions
   - /articles/getting-started-with-the-api
   - /github/extending-github/getting-started-with-the-api
   - /developers/overview/about-githubs-apis
+  - /rest/overview/about-githubs-apis
 versions:
   fpt: '*'
   ghes: '*'

content/rest/overview/index.md

@@ -10,7 +10,7 @@ versions:
 topics:
   - API
 children:
-  - /about-githubs-apis
+  - /comparing-githubs-rest-api-and-graphql-api
   - /resources-in-the-rest-api
   - /api-versions
   - /media-types

content/webhooks/about-webhooks.md

@@ -41,7 +41,7 @@ Webhooks are used in a wide range of scenarios, including:
 
 When you create a webhook, you specify a URL and subscribe to events that occur on {% data variables.product.company_short %}. When an event that your webhook is subscribed to occurs, {% data variables.product.company_short %} will send an HTTP request with data about the event to the URL that you specified. If your server is set up to listen for webhook deliveries at that URL, it can take action when it receives one.
 
-For example, you could subscribe your webhook to events that occur when code is pushed to a repository, a pull request is opened, a {% data variables.product.prodname_pages %} site is built, or a new member is added to a team. You server could respond by deploying code to production, triggering a CI pipeline, sending a notification, or creating a {% data variables.product.company_short %} project for the new team member.
+For example, you could subscribe your webhook to events that occur when code is pushed to a repository, a pull request is opened, a {% data variables.product.prodname_pages %} site is built, or a new member is added to a team. Your server could respond by deploying code to production, triggering a CI pipeline, sending a notification, or creating a {% data variables.product.company_short %} project for the new team member.
 
 You must create a webhook within a specific repository, organization, {% ifversion ghes or ghec or ghae %}{% data variables.product.prodname_enterprise %}, {% endif %} {% ifversion fpt or ghec %}{% data variables.product.prodname_marketplace %} account, {% endif %} {% ifversion fpt or ghec %}{% data variables.product.prodname_sponsors %} account, {% endif %} or {% data variables.product.prodname_github_app %}. The webhook can only access resources that are available in the repository, organization, {% ifversion ghes or ghec or ghae %}{% data variables.product.prodname_enterprise %}, {% endif %} {% ifversion fpt or ghec %}{% data variables.product.prodname_marketplace %} account, {% endif %} {% ifversion fpt or ghec %}{% data variables.product.prodname_sponsors %} account, {% endif %} or {% data variables.product.prodname_github_app %} where it is installed. For more information, see "[AUTOTITLE](/webhooks/types-of-webhooks)."