Repo sync

content/actions/how-tos/manage-runners/larger-runners/manage-larger-runners.md

@@ -195,9 +195,11 @@ You can control the maximum number of jobs allowed to run concurrently for speci
 > * To use static IP addresses, your organization must use {% data variables.product.prodname_ghe_cloud %}. {% data reusables.enterprise.link-to-ghec-trial %}
 > * macOS {% data variables.actions.hosted_runner %}s do not support static IP addresses.
 
-You can enable static IP addresses for {% data variables.actions.hosted_runner %}s. When you do this, the {% data variables.actions.hosted_runner %}s are assigned static IP address ranges. All IP addresses in the range assigned are usable. By default, you can configure up to 10 different {% data variables.actions.hosted_runner %}s with IP ranges for your account. {% data reusables.actions.larger-runner-static-ip-contact-support %}
+You can enable static IP addresses for {% data variables.actions.hosted_runner %}s. When you do this, the {% data variables.actions.hosted_runner %}s are assigned static IP address ranges. All IP addresses in the range assigned are usable. By default, you can configure up to 10 {% data variables.actions.hosted_runner %} pools with static IP address ranges for your account. {% data reusables.actions.larger-runner-static-ip-contact-support %}
 
-The number of available IP addresses in the assigned ranges does not restrict number of concurrent jobs specified for autoscaling. Within a runner pool, there is a load balancer which allows for high reuse of the IP addresses in the assigned ranges. This ensures your workflows can run concurrently at scale while each machine is assigned a static IP address.
+Each {% data variables.actions.hosted_runner %} you create is not a single machine. It is a pool of runners that automatically scales out to handle concurrent jobs, up to the maximum concurrency you set when creating the runner. All jobs in the pool share the same static IP address range. This means a single {% data variables.actions.hosted_runner %} with one static IP range can handle many jobs running at the same time without requiring additional runners.
+
+The number of available IP addresses in the assigned ranges does not restrict the number of concurrent jobs. Within a runner pool, there is a load balancer which allows for high reuse of the IP addresses in the assigned ranges. This ensures your workflows can run concurrently at scale while each machine is assigned a static IP address.
 
 {% ifversion ghec %}
 

content/actions/reference/runners/larger-runners.md

@@ -84,7 +84,7 @@ If you notice the jobs that target your {% data variables.actions.hosted_runner
 
 By default, {% data variables.actions.hosted_runners %} receive a dynamic IP address that changes for each job run. Optionally, {% data variables.product.prodname_ghe_cloud %} customers can configure their {% data variables.actions.hosted_runners %} to receive static IP addresses from {% data variables.product.prodname_dotcom %}'s IP address pool. For more information, see [AUTOTITLE](/authentication/keeping-your-account-and-data-secure/about-githubs-ip-addresses).
 
-When enabled, instances of the {% data variables.actions.hosted_runner %} will receive IP addresses from specific ranges that are unique to the runner, allowing you to use the ranges to configure a firewall allowlist. {% ifversion fpt %}You can use up to 10 {% data variables.actions.hosted_runners %} with static IP address ranges in total across all your {% data variables.actions.hosted_runners %}{% endif %}{% ifversion ghec %}You can use up to 10 {% data variables.actions.hosted_runners %} with static IP address ranges for the {% data variables.actions.hosted_runners %} created at the enterprise level. In addition, you can use up to 10 {% data variables.actions.hosted_runners %} with static IP address ranges for the {% data variables.actions.hosted_runners %} created at the organization level, for each organization in your enterprise{% endif %}. For more information, see [AUTOTITLE](/actions/using-github-hosted-runners/managing-larger-runners#networking-for-larger-runners).
+When enabled, instances of the {% data variables.actions.hosted_runner %} will receive IP addresses from specific ranges that are unique to the runner, allowing you to use the ranges to configure a firewall allowlist. Each {% data variables.actions.hosted_runner %} is a pool that automatically scales out to its configured maximum concurrency, and all jobs in that pool share the same static IP address range. This means you do not need to create additional runners to run more concurrent jobs. {% ifversion fpt %}You can use up to 10 {% data variables.actions.hosted_runner %} pools with static IP address ranges in total across all your {% data variables.actions.hosted_runners %}{% endif %}{% ifversion ghec %}You can use up to 10 {% data variables.actions.hosted_runner %} pools with static IP address ranges at the enterprise level. In addition, you can use up to 10 {% data variables.actions.hosted_runner %} pools with static IP address ranges at the organization level, for each organization in your enterprise{% endif %}. For more information, see [AUTOTITLE](/actions/using-github-hosted-runners/managing-larger-runners#networking-for-larger-runners).
 
 {% data reusables.actions.larger-runner-static-ip-contact-support %}
 

content/admin/data-residency/network-details-for-ghecom.md

@@ -86,7 +86,7 @@ git clone SUBDOMAIN@SUBDOMAIN.ghe.com:OWNER/REPO.git
 
 ## Supported regions for Azure private networking
 
-If you use Azure private networking for {% data variables.product.company_short %}-hosted runners, the supported Azure regions on {% data variables.enterprise.data_residency_site %} differ from those on {% data variables.product.prodname_dotcom_the_website %}.
+{% data variables.product.company_short %} deploys your runners in the same Azure region as the subnet you connect them to. Because of this, your subnet must be in one of the supported regions. If you use Azure private networking for {% data variables.product.company_short %}-hosted runners, the supported Azure regions on {% data variables.enterprise.data_residency_site %} differ from those on {% data variables.product.prodname_dotcom_the_website %}.
 
 ### Supported regions in the EU
 

content/copilot/reference/copilot-usage-metrics/copilot-usage-metrics.md

@@ -282,6 +282,7 @@ Each entry in the aggregated `totals_by_ai_adoption_phase` array contains:
 | `avg_pull_requests_reviewed` | `number` | No | Average pull requests reviewed per user in this phase. |
 | `avg_pull_requests_created` | `number` | No | Average pull requests created per user in this phase. |
 | `avg_pull_requests_merged` | `number` | No | Average pull requests merged per user in this phase. |
+| `total_pull_requests_merged` | `integer` | No | Total pull requests merged by users in this phase. Applies to the organization day and enterprise day aggregated reports. |
 | `avg_pull_requests_median_minutes_to_merge` | `number` | No | Average of the per-user median minutes to merge for users in this phase. |
 
 ### Breakdown dimension values

content/search-github/searching-on-github/searching-issues-and-pull-requests.md

@@ -285,6 +285,7 @@ You can filter pull requests based on their [review status](/pull-requests/colla
 | <code>review-requested:<em>USERNAME</em></code> | [**type:pr review-requested:benbalter**](https://github.com/search?utf8=%E2%9C%93&q=type%3Apr+review-requested%3Abenbalter&type=Issues) matches pull requests where a specific person is requested for review. Requested reviewers are no longer listed in the search results after they review a pull request. If the requested person is on a team that is requested for review, then review requests for that team will also appear in the search results.
 | <code>user-review-requested:@me</code> | [**type:pr user-review-requested:@me**](https://github.com/search?q=is%3Apr+user-review-requested%3A%40me+) matches pull requests that you have directly been asked to review.
 | <code>team-review-requested:<em>TEAMNAME</em></code> | [**type:pr team-review-requested:github/docs**](https://github.com/search?q=type%3Apr+team-review-requested%3Agithub%2Fdocs&type=pullrequests) matches pull requests that have review requests from the team `github/docs`. Requested reviewers are no longer listed in the search results after they review a pull request.
+| <code>team-review-requested-user:<em>USERNAME</em></code> | [**type:pr team-review-requested-user:benbalter**](https://github.com/search?q=type%3Apr+team-review-requested-user%3Abenbalter&type=pullrequests) matches pull requests that have review requests from any team that a specific person is a member of. Review requests directed at the user specifically are not included. Requested reviewers are no longer listed in the search results after they review a pull request.
 
 ## Search by when an issue or pull request was created or last updated
 

data/reusables/actions/azure-vnet-network-communication.md

@@ -1,4 +1,4 @@
-To facilitate communication between {% data variables.product.company_short %} networks and your VNET, a {% data variables.product.company_short %}-hosted runner's network interface card (NIC) deploys into your Azure VNET.
+To facilitate communication between {% data variables.product.company_short %} networks and your VNET, a {% data variables.product.company_short %}-hosted runner's network interface card (NIC) deploys into your Azure VNET. The runner is always deployed in the same Azure region as your subnet.
 
 Because the NIC lives within your VNET, {% data variables.product.company_short %} cannot block inbound connections. By default, Azure virtual machines will accept inbound connections from the same VNET. For more information, see [`AllowVNetInBound`](https://learn.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview#allowvnetinbound) on Microsoft Learn. It is recommended to explicitly block all inbound connections to the runners. {% data variables.product.company_short %} will never require inbound connections to these machines.
 

data/reusables/actions/azure-vnet-supported-regions.md

@@ -1,4 +1,4 @@
-The {% data variables.product.prodname_actions %} service supports a subset of all the regions that Azure provides. To facilitate communication between the {% data variables.product.prodname_actions %} service and your subnet, your subnet must be in one of the supported regions.
+{% data variables.product.company_short %} deploys your runners in the same Azure region as the subnet you connect them to. Because of this, your subnet must be in one of the supported regions. The {% data variables.product.prodname_actions %} service supports a subset of all the regions that Azure provides, which facilitates communication between the {% data variables.product.prodname_actions %} service and your subnet.
 
 > [!NOTE] If you use {% data variables.enterprise.data_residency_short %} on {% data variables.enterprise.data_residency_site %}, the supported regions are different. See [AUTOTITLE](/admin/data-residency/network-details-for-ghecom#supported-regions-for-azure-private-networking).
 

data/reusables/actions/larger-runner-static-ip-contact-support.md

@@ -1 +1 @@
-If you would like to use more than 10 larger runners with static IP address ranges, please contact {% data variables.contact.contact_support %}.
+If you would like to use more than 10 larger runner pools with static IP address ranges, please contact {% data variables.contact.contact_support %}.