Remove duplicate words

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

@@ -289,7 +289,7 @@ After this setting is applied, the JWT will contain the updated `iss` value. In
 
 ### Customizing the subject claims for an organization or repository
 
-To help improve security, compliance, and standardization, you can customize the standard claims to suit your required access conditions. If your cloud provider supports conditions on subject claims, you can create a condition that checks whether the `sub` value matches the path of the reusable workflow, such as `"job_workflow_ref:octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main"`. The exact format will vary depending on your cloud provider's OIDC configuration. To configure the matching condition on {% data variables.product.prodname_dotcom %}, you can can use the REST API to require that the `sub` claim must always include a specific custom claim, such as `job_workflow_ref`. You can use the REST API to apply a customization template for the OIDC subject claim; for example, you can require that the `sub` claim within the OIDC token must always include a specific custom claim, such as `job_workflow_ref`. For more information, see "[AUTOTITLE](/rest/actions/oidc)."
+To help improve security, compliance, and standardization, you can customize the standard claims to suit your required access conditions. If your cloud provider supports conditions on subject claims, you can create a condition that checks whether the `sub` value matches the path of the reusable workflow, such as `"job_workflow_ref:octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main"`. The exact format will vary depending on your cloud provider's OIDC configuration. To configure the matching condition on {% data variables.product.prodname_dotcom %}, you can use the REST API to require that the `sub` claim must always include a specific custom claim, such as `job_workflow_ref`. You can use the REST API to apply a customization template for the OIDC subject claim; for example, you can require that the `sub` claim within the OIDC token must always include a specific custom claim, such as `job_workflow_ref`. For more information, see "[AUTOTITLE](/rest/actions/oidc)."
 
 > [!NOTE]
 > When the organization template is applied, it will not affect any workflows already using OIDC unless their repository has opted in to custom organization templates. For all repositories, existing and new, the repository owner will need to use the repository-level REST API to opt in to receive this configuration by setting `use_default` to `false`. Alternatively, the repository owner could use the REST API to apply a different configuration specific to the repository. For more information, see "[AUTOTITLE](/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-a-repository)."

content/actions/using-github-hosted-runners/using-larger-runners/about-larger-runners.md

@@ -60,7 +60,7 @@ These features can enhance your CI/CD pipelines in the following ways.
 
 **{% data variables.product.prodname_dotcom %}-owned images:** These images are maintained by {% data variables.product.prodname_dotcom %} and are available for Linux x64, Windows x64, and macOS (x64 and arm) runners. For more information on these images and a full list of included tools for each runner operating system, see the [{% data variables.product.prodname_actions %} Runner Images](https://github.com/actions/runner-images) repository.
 
-**Partner Images:** Partner images are not managed by {% data variables.product.prodname_dotcom %} and are pulled from the Azure Marketplace. For more information about about the Windows 11 desktop image see [Microsoft Windows 11 Desktop](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/microsoftwindowsdesktop.windows-11?tab=Overview). For more information about the GPU runner compatible images, see [NVIDIA GPU-Optimized VMI](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/nvidia.ngc_azure_17_11) and [Data Science Virtual Machine - Windows 2019](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/microsoft-dsvm.dsvm-win-2019?tab=overview). For more information about the images for ARM-powered runners, see the [`actions/partner-runner-images` repository](https://github.com/actions/partner-runner-images). This is also the place to provide feedback or report issues about third-party images.
+**Partner Images:** Partner images are not managed by {% data variables.product.prodname_dotcom %} and are pulled from the Azure Marketplace. For more information about the Windows 11 desktop image see [Microsoft Windows 11 Desktop](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/microsoftwindowsdesktop.windows-11?tab=Overview). For more information about the GPU runner compatible images, see [NVIDIA GPU-Optimized VMI](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/nvidia.ngc_azure_17_11) and [Data Science Virtual Machine - Windows 2019](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/microsoft-dsvm.dsvm-win-2019?tab=overview). For more information about the images for ARM-powered runners, see the [`actions/partner-runner-images` repository](https://github.com/actions/partner-runner-images). This is also the place to provide feedback or report issues about third-party images.
 
 ### Understanding billing
 

content/admin/managing-github-actions-for-your-enterprise/getting-started-with-github-actions-for-your-enterprise/getting-started-with-github-actions-for-github-enterprise-cloud.md

@@ -27,7 +27,7 @@ You can use policies to control how enterprise members use {% data variables.pro
 
 ## Adding runners
 
-To run {% data variables.product.prodname_actions %} workflows, you need to use runners. {% data reusables.actions.about-runners %} If you use {% data variables.product.company_short %}-hosted runners, you will be be billed based on consumption after exhausting the minutes included in {% data variables.product.product_name %}, while self-hosted runners are free. For more information, see "[AUTOTITLE](/billing/managing-billing-for-github-actions/about-billing-for-github-actions)."
+To run {% data variables.product.prodname_actions %} workflows, you need to use runners. {% data reusables.actions.about-runners %} If you use {% data variables.product.company_short %}-hosted runners, you will be billed based on consumption after exhausting the minutes included in {% data variables.product.product_name %}, while self-hosted runners are free. For more information, see "[AUTOTITLE](/billing/managing-billing-for-github-actions/about-billing-for-github-actions)."
 
 For more information, see "[AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners)."
 

content/code-security/codeql-cli/codeql-cli-manual/github-upload-results.md

@@ -91,7 +91,7 @@ version 2.1.0 (this is the default version of SARIF used by CodeQL).
 By default, the CLI will wait for GitHub to process the SARIF file for a
 maximum of 2 minutes, returning a non-zero exit code if there were any
 errors during processing of the analysis results. You can customize how
-long the CLI will wait wait with `--wait-for-processing-timeout`, or
+long the CLI will wait with `--wait-for-processing-timeout`, or
 disable the feature with `--no-wait-for-processing`.
 
 #### `--wait-for-processing-timeout=<waitForProcessingTimeout>`

content/contributing/writing-for-github-docs/templates.md

@@ -342,9 +342,9 @@ The language guide introduction should include the following in a short paragrap
 ## Starting with the <language> workflow template
 
 {% comment %}
-Language guides typically walk through and build upon a workflow template template. If that format doesn't work, you can include a boilerplate workflow.
+Language guides typically walk through and build upon a workflow template. If that format doesn't work, you can include a boilerplate workflow.
 - Link to the GitHub Actions CI workflow template as the boilerplate reference code and then walk through and build on that code in this guide - https://github.com/actions/starter-workflows/tree/master/ci
-- Provide instructions for adding the workflow template template to a repository.
+- Provide instructions for adding the workflow template to a repository.
 - Include the starter template workflow code.
 {% endcomment %}
 

content/desktop/installing-and-authenticating-to-github-desktop/updating-github-desktop.md

@@ -19,7 +19,7 @@
    ![Screenshot of the menu bar on a Mac. Under the open "GitHub Desktop" dropdown menu, a cursor hovers over "About GitHub Desktop", highlighted in blue.](/assets/images/help/desktop/desktop-menu-about-desktop-mac.png)
 
 1. In the modal window, click **Check for Updates**.
    ![Screenshot of the "GitHub Desktop" window. Under version details and links to external resources, a button, labeled "Check for Updates", is outlined in orange.](/assets/images/help/desktop/check-for-updates.png)
 1. If an update is available, quit and relaunch {% data variables.product.prodname_desktop %} to install the update.
 
 ## Resolving a crash at launch by updating {% data variables.product.prodname_desktop %}
@@ -33,7 +33,7 @@
 1. Drag the {% data variables.product.prodname_desktop %} application from your "Downloads" folder to the "Applications" folder.
 1. Approve the dialog asking if you want to replace the existing application.
 1. Launch {% data variables.product.prodname_desktop %}.
-1. Approve the prompt stating that that application was downloaded from the internet.
+1. Approve the prompt stating that application was downloaded from the internet.
 
 {% endmac %}
 
@@ -41,11 +41,11 @@
 
 1. In the menu bar, select **Help**, then click **About GitHub Desktop**.
 
    ![Screenshot of the "GitHub Desktop" menu bar on Windows. In the open "Help" dropdown menu, an option labeled "About GitHub Desktop" is outlined in orange.](/assets/images/help/desktop/help-about-desktop-win.png)
 
 1. Click **Check for Updates**.
 
    ![Screenshot of the "GitHub Desktop" window. Under version details and links to external resources, a button, labeled "Check for Updates", is outlined in orange.](/assets/images/help/desktop/check-for-updates.png)
 
 1. If an update is available, quit and relaunch {% data variables.product.prodname_desktop %} to install the update.
 

content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets.md

@@ -106,7 +106,7 @@
 
 ### Additional settings
 
 {% ifversion pull-request-mergeability-security-changes %}
 {% data reusables.pull_requests.security-changes-mergeability %}
 {% endif %}
 
@@ -118,11 +118,11 @@
 
 {% data reusables.repositories.review-policy-overlapping-commits %}
 
-Optionally, you can choose to dismiss stale pull request approvals when commits are pushed that affect the diff in the pull request. {% data variables.product.company_short %} records the state of the diff at the point when a pull request is approved. This state represents the set of changes that the reviewer approved. If the diff changes from this state (for example, because a contributor pushes new changes to the pull request branch or clicks **Update branch**, or because a related pull request is merged into the target branch), the approving review is dismissed as stale, and the pull request cannot be merged until someone approves the work again. For information about the target branch branch, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)."
+Optionally, you can choose to dismiss stale pull request approvals when commits are pushed that affect the diff in the pull request. {% data variables.product.company_short %} records the state of the diff at the point when a pull request is approved. This state represents the set of changes that the reviewer approved. If the diff changes from this state (for example, because a contributor pushes new changes to the pull request branch or clicks **Update branch**, or because a related pull request is merged into the target branch), the approving review is dismissed as stale, and the pull request cannot be merged until someone approves the work again. For information about the target branch, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)."
 
 Optionally, you can choose to require reviews from code owners. If you do, any pull request that modifies content with a code owner must be approved by that code owner before the pull request can be merged into the protected branch. Note that if code has multiple owners, an approval from _any_ of the code owners will be sufficient to meet this requirement. For more information, see "[AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners)."
 
 {% ifversion last-pusher-require-approval %}
 Optionally, you can require an approval from someone other than the last person to push to a branch before a pull request can be merged. This means at least one other authorized reviewer has approved any changes. For example, the "last reviewer" can check that the latest set of changes incorporates feedback from other reviews, and does not add new, unreviewed content.
 
 For complex pull requests that require many reviews, requiring an approval from someone other than the last person to push can be a compromise that avoids the need to dismiss all stale reviews: with this option, "stale" reviews are not dismissed, and the pull request remains approved as long as someone other than the person who made the most recent changes approves it. Users who have already reviewed a pull request can reapprove after the most recent push to meet this requirement. If you are concerned about pull requests being "hijacked" (where unapproved content is added to approved pull requests), it is safer to dismiss stale reviews.

content/search-github/getting-started-with-searching-on-github/understanding-the-search-syntax.md

@@ -104,7 +104,7 @@ If your search query contains a qualifier that requires a username, such as `use
 | `QUALIFIER:USERNAME` | [`author:nat`](https://github.com/search?q=author%3Anat&type=Commits) matches commits authored by @nat |
 | `QUALIFIER:@me` | [`is:issue assignee:@me`](https://github.com/search?q=is%3Aissue+assignee%3A%40me&type=Issues) matches issues assigned to the person viewing the results |
 | {% ifversion copilot %} |
-| `QUALIFIER:@copilot` | [`is:pr reviewed-by:@copilot`](https://github.com/search?q=is:pr+reviewed-by:@copilot&type=pullrequests) matches pull requests reviewed by {% data variables.product.prodname_copilot_short %}. For more information, see see "[AUTOTITLE](/copilot/using-github-copilot/code-review/using-copilot-code-review)." |
+| `QUALIFIER:@copilot` | [`is:pr reviewed-by:@copilot`](https://github.com/search?q=is:pr+reviewed-by:@copilot&type=pullrequests) matches pull requests reviewed by {% data variables.product.prodname_copilot_short %}. For more information, see "[AUTOTITLE](/copilot/using-github-copilot/code-review/using-copilot-code-review)." |
 | {% endif %} |
 
 You can only use `@me` {% ifversion copilot %} or `@copilot` {% endif %} with a qualifier, and not as a search term, such as `@me main.workflow`.