[pull] main from github:main

.github/agents/copilot-readability-editor-2.md

@@ -0,0 +1,128 @@
+---
+name: "Copilot-Readability-Editor-2"
+description: "Improves the readability and scannability of an article provided by the user, applying plain language principles and the GitHub Docs team's style guide and writing standards."
+tools: ['read', 'edit/editFiles', 'search', 'web', 'github/*', 'execute']
+
+---
+
+# Copilot-Readability-Editor Agent
+
+You are an expert editor for the GitHub Docs content team. Your job is to maximize the readability of articles using plain language principles and the Docs team's writing standards.
+
+## Readability Score Target
+
+Your primary goal is to improve the Flesch Reading Ease score. Target 35+ (ideally 40+).
+
+The Flesch formula rewards:
+* **Shorter sentences** (biggest impact)
+* **Fewer syllables per word**
+
+When in doubt, make two short sentences instead of one medium sentence.
+
+## Editing Process
+
+Follow this two-pass approach:
+
+1. **First pass—Split sentences**: Find all sentences over 20 words and break them into 2+ shorter sentences. This is the single biggest driver of improved readability scores.
+2. **Second pass—Simplify words**: Replace complex words with simpler alternatives where meaning is preserved.
+
+## Sentence Structure Targets
+
+* **Target 12-15 words per sentence on average** (not just "under 20")
+* Aim for 1.5-2x more sentences than the original while keeping similar word count
+* When you see a sentence with commas, em dashes, or "and/or" conjunctions, consider splitting it
+* Make sure no more than 25% of sentences contain more than 20 words
+* Avoid consecutive sentences starting the same way
+
+## Word Choice for Readability
+
+Replace multi-syllable words when a shorter synonym exists:
+
+| Instead of | Use |
+|------------|-----|
+| instantiates | starts, creates |
+| utilize | use |
+| functionality | features |
+| configuration | setup, settings |
+| implementation | setup, code |
+| appropriate | right, correct |
+| indicates | shows |
+| requirements | needs |
+| assistance | help |
+
+Keep unavoidable technical terms (MCP, Copilot, repository) but simplify surrounding words to compensate.
+
+## Plain Language Principles
+
+* Use concise, everyday language. Explain or remove jargon when it doesn't support user understanding.
+* Use full terms, not shortened versions (repository, not repo).
+* Use active voice and personal pronouns ("you," "your"); favor present tense.
+* Write one idea per sentence; avoid redundancy, vague modifiers, and ambiguous phrasing.
+* Limit paragraphs to 150 words or fewer.
+* State the topic at the start of each paragraph; clarify connections between paragraphs.
+
+## Scannability (Conservative Approach)
+
+* Do NOT add new headings unless clearly beneficial
+* Do NOT add excessive bold formatting
+* Do NOT create headers that would only have one sentence of content
+* Convert long inline lists to bulleted lists, but preserve existing structure otherwise
+* Focus on sentence clarity over structural changes
+* Structure logically with clear, descriptive headings and short sections
+
+## Audience Guidance
+
+When editing, consider the audience type:
+* [Builders](https://github.com/github/docs-team/discussions/5060)
+* [Drivers](https://github.com/github/docs-team/discussions/5061)
+* [Learners](https://github.com/github/docs-team/blob/main/personas/learners/best-practices-for-learners-content.md)
+
+## Formatting Rules
+
+* When creating lists, use asterisks (*) instead of hyphens (-)
+* Do not end list items with periods if the items are not complete sentences
+* Use "For more information, see [link]" or "See [link]" before links that provide additional details; do not use a colon or other formats
+* Consider splitting a paragraph or list item when it includes two topics or steps, or is notably longer than others
+
+## What to Preserve
+
+* Retain all essential technical details: defaults, warnings, and admin options
+* Do not remove sentences about defaults, feature scope, or access unless clearly repeated
+* Retain essential usage details, admin options, and warnings unless obviously redundant
+* Do not alter the intent of verbs and actions (e.g., "navigate" does not necessarily mean "select")
+
+## Avoid These Patterns
+
+Based on past tests, do NOT:
+* ❌ Add excessive bold text on every key term
+* ❌ Create subheadings with bold text instead of actual ## headings
+* ❌ Add headers that only have one sentence of content
+* ❌ Use "See: [link]" with a colon (use "See [link]" instead)
+* ❌ Convert simple prose to overly nested lists
+* ❌ Reorganize sections unless clearly beneficial
+
+## Review Process
+
+1. Read through the article once, noting barriers to readability
+2. Identify sentences over 20 words that can be split
+3. Identify complex words that can be simplified
+4. Make changes according to the guidelines above
+5. Only analyze and edit the specific `.md` files provided
+6. Do not move or delete files
+7. Make edits only when they provide meaningful improvements
+8. Submit edits as a pull request
+
+## References
+
+* [Example: good readability and scannability PR](https://github.com/github/docs-internal/pull/57154)
+* [Readability improvement outcomes & examples](https://github.com/github/docs-team/discussions/5971)
+
+## Quality Checklist
+
+- [ ] Flesch Reading Ease score improved (target 35+)
+- [ ] Sentences average 12-15 words; no more than 25% exceed 20 words
+- [ ] Language is clear, direct, and free from unnecessary complexity
+- [ ] Article is easy to scan (headings, lists, short paragraphs)
+- [ ] Article follows the Docs team's style, tone, and formatting standards
+- [ ] Technical details, defaults, and warnings are preserved
+- [ ] Summary and at least 2 before/after examples included in output

.github/workflows/index-general-search.yml

@@ -26,9 +26,11 @@ on:
 permissions:
   contents: read
 
-# This allows a subsequently queued workflow run to cancel previous runs
+# This allows a subsequently queued workflow run to cancel previous runs.
+# Include the triggering workflow's conclusion in the group so that runs triggered
+# by skipped Purge Fastly workflows don't cancel runs triggered by successful ones.
 concurrency:
-  group: '${{ github.workflow }} @ ${{ github.head_ref }} ${{ github.event_name }}'
+  group: '${{ github.workflow }} @ ${{ github.head_ref }} ${{ github.event_name }} ${{ github.event.workflow_run.conclusion }}'
   cancel-in-progress: true
 
 env:
@@ -40,7 +42,9 @@ env:
 
 jobs:
   figureOutMatrix:
-    if: ${{ github.repository == 'github/docs-internal' }}
+    # Skip immediately if triggered by a non-successful Purge Fastly run.
+    # This prevents skipped runs from canceling valid indexing runs via concurrency.
+    if: ${{ github.repository == 'github/docs-internal' && (github.event_name != 'workflow_run' || github.event.workflow_run.conclusion == 'success') }}
     runs-on: ubuntu-latest
     outputs:
       matrix: ${{ steps.set-matrix.outputs.result }}
@@ -55,11 +59,13 @@ jobs:
             const allPossible = ["en", ...allNonEnglish]
 
             if (context.eventName === "workflow_run") {
+              // Job-level `if` already ensures we only get here for successful runs,
+              // but keep this as a safety check.
               if (context.payload.workflow_run.conclusion === "success") {
                 return ["en"]
               }
-              console.warn(`NOTE! It was a workflow_run but not success ('${context.payload.workflow_run.conclusion}')`)
-              console.warn("This means we're not going to index anything in the next dependent step.")
+              // This shouldn't happen due to job-level filter, but handle gracefully.
+              console.warn(`Unexpected: workflow_run with conclusion '${context.payload.workflow_run.conclusion}'`)
               return []
             }
 

.github/workflows/purge-fastly.yml

@@ -22,7 +22,9 @@ env:
 
 jobs:
   send-purges:
-    # Run when workflow_dispatch is the event (manual) or when deployment_status is the event (automatic) and it's a successful production deploy
+    # Run when workflow_dispatch is the event (manual) or when deployment_status is the event (automatic) and it's a successful production deploy.
+    # NOTE: This workflow triggers on all deployment_status events (including staging), but only runs for production.
+    # Non-production deploys will show as "skipped" - this is expected behavior.
     if: >-
       ${{
         github.repository == 'github/docs-internal' &&

content/admin/monitoring-and-managing-your-instance/monitoring-your-instance/about-the-monitor-dashboards.md

@@ -43,7 +43,7 @@ Within the pre-built dashboards you can find various sections grouping graphs of
 
 {% ifversion ghes-opentelemetry %}
 
-If you have enabled metrics for OpenTelemetry, then additional dashboards are available, see: [AUTOTITLE](/admin/monitoring-and-managing-your-instance/monitoring-your-instance/opentelemetry-metrics/enable-advanced-dashboards).
+If you have enabled metrics for OpenTelemetry, then additional dashboards are available, see: [AUTOTITLE](/admin/monitoring-and-managing-your-instance/monitoring-your-instance/opentelemetry-metrics/advanced-dashboards).
 
 {% endif %}
 

content/admin/monitoring-and-managing-your-instance/monitoring-your-instance/opentelemetry-metrics/about-opentelemetry-metrics.md

@@ -35,7 +35,7 @@ OpenTelemetry metrics offer several advantages over the legacy collectd system:
 * **Extensible**: Support for custom metrics and external monitoring integrations
 * **Native endpoints**: Direct integration with service `/metrics` endpoints for efficient monitoring
 
-With OpenTelemetry, advanced Grafana dashboards with enhanced visualization and monitoring capabilities are available, see: [AUTOTITLE](/admin/monitoring-and-managing-your-instance/monitoring-your-instance/opentelemetry-metrics/enable-advanced-dashboards).
+With OpenTelemetry, advanced Grafana dashboards with enhanced visualization and monitoring capabilities are available, see: [AUTOTITLE](/admin/monitoring-and-managing-your-instance/monitoring-your-instance/opentelemetry-metrics/advanced-dashboards).
 
 ## Key components
 

content/admin/monitoring-and-managing-your-instance/monitoring-your-instance/opentelemetry-metrics/enable-advanced-dashboards.md → content/admin/monitoring-and-managing-your-instance/monitoring-your-instance/opentelemetry-metrics/advanced-dashboards.md

@@ -1,6 +1,8 @@
 ---
-title: Enabling advanced dashboards of OpenTelemetry metrics
+title: Advanced dashboards of OpenTelemetry metrics
 intro: 'After enabling OpenTelemetry metrics collection on your {% data variables.product.prodname_ghe_server %} instance, you have access to additional dashboards with enhanced visualization and monitoring capabilities.'
+redirect_from:
+  - /enterprise/admin/monitoring-and-managing-your-instance/monitoring-your-instance/opentelemetry-metrics/enable-advanced-dashboards
 versions:
   feature: ghes-opentelemetry
 topics:
@@ -10,7 +12,7 @@ topics:
   - Monitoring
   - Performance
 type: how_to
-shortTitle: Enable advanced dashboards
+shortTitle: Advanced dashboards
 ---
 
 {% data reusables.enterprise.opentelemetry-migration %}
@@ -21,9 +23,18 @@ shortTitle: Enable advanced dashboards
 
 {% endif %}
 
+## Prerequisites
+
+* OpenTelemetry metrics are enabled for your {% data variables.product.prodname_ghe_server %} instance
+
+
 ## Additional dashboards
 
+{% ifversion ghes < 3.19 %}
 When OpenTelemetry metrics are enabled, you can turn on advanced Grafana dashboards with enhanced visualization and monitoring capabilities.
+{% else %}
+When OpenTelemetry metrics are enabled, you will have access to advanced Grafana dashboards with enhanced visualization and monitoring capabilities.
+{% endif %}
 
 * **Elasticsearch** - Detailed metrics for search performance, indexing operations, and cluster health
 * **Nomad** - In-depth monitoring of job scheduling, resource allocation, and service orchestration
@@ -33,12 +44,15 @@ When OpenTelemetry metrics are enabled, you can turn on advanced Grafana dashboa
 
 These dashboards provide more granular insights into your {% data variables.product.prodname_ghe_server %} instance's performance and can help with advanced troubleshooting and capacity planning.
 
-## Prerequisites
+{% ifversion ghes < 3.19 %}
+## Enabling advanced dashboards
+
+### Prerequisites
 
-* OpenTelemetry metrics are enabled for your {% data variables.product.prodname_ghe_server %} instance
 * SSH access to your {% data variables.product.prodname_ghe_server %} instance
 
-## Enabling advanced dashboards
+---
+
 
 {% data reusables.enterprise_installation.ssh-into-instance %}
 1. Run the following command to enable advanced dashboards:
@@ -50,3 +64,4 @@ These dashboards provide more granular insights into your {% data variables.prod
 {% data reusables.enterprise.apply-configuration %}
 
 After running these commands, your external Grafana instance will have access to additional pre-configured dashboards.
+{% endif %}

content/admin/monitoring-and-managing-your-instance/monitoring-your-instance/opentelemetry-metrics/configuring-opentelemetry-for-your-instance.md

@@ -169,5 +169,5 @@ sudo journalctl -u victoriametrics -f
 
 ## Next steps
 
-* To enable advanced monitoring dashboards, see [AUTOTITLE](/admin/monitoring-and-managing-your-instance/monitoring-your-instance/opentelemetry-metrics/enable-advanced-dashboards)
+* To enable advanced monitoring dashboards, see [AUTOTITLE](/admin/monitoring-and-managing-your-instance/monitoring-your-instance/opentelemetry-metrics/advanced-dashboards)
 * To set up external monitoring, see [AUTOTITLE](/admin/monitoring-and-managing-your-instance/monitoring-your-instance/opentelemetry-metrics/setting-up-external-monitoring-with-opentelemetry).

content/admin/monitoring-and-managing-your-instance/monitoring-your-instance/opentelemetry-metrics/index.md

@@ -8,7 +8,7 @@ topics:
 children:
   - /about-opentelemetry-metrics
   - /configuring-opentelemetry-for-your-instance
-  - /enable-advanced-dashboards
+  - /advanced-dashboards
   - /setting-up-external-monitoring-with-opentelemetry
 shortTitle: OpenTelemetry metrics
 ---

content/code-security/concepts/security-at-scale/choosing-a-security-configuration-for-your-repositories.md

@@ -36,8 +36,6 @@ The {% data variables.product.prodname_github_security_configuration %} offers a
 
 The {% data variables.product.prodname_github_security_configuration %} includes {% data variables.product.prodname_GH_code_security %} and {% data variables.product.prodname_GH_secret_protection %} features. Applying the configuration to private and internal repositories in your organization will incur usage costs or require licenses.
 
-To start securing repositories in your organization with the {% data variables.product.prodname_github_security_configuration %}, see [AUTOTITLE](/code-security/securing-your-organization/enabling-security-features-in-your-organization/applying-the-github-recommended-security-configuration-in-your-organization).
-
 ## Choosing a {% data variables.product.prodname_custom_security_configuration %}
 
 If you are familiar with {% data variables.product.company_short %}'s security products, and you have specific security needs that the {% data variables.product.prodname_github_security_configuration %} can't meet, you can create and apply {% data variables.product.prodname_custom_security_configurations %}. With {% data variables.product.prodname_custom_security_configurations %}, you can:

content/code-security/concepts/supply-chain-security/about-dependabot-version-updates.md

@@ -34,21 +34,31 @@ contentType: concepts
 
 {% data variables.product.prodname_dependabot %} takes the effort out of maintaining your dependencies. You can use it to ensure that your repository automatically keeps up with the latest releases of the packages and applications it depends on.
 
-{% data reusables.dependabot.dependabot-updates-supported-repos-ecosystems %}
+{% data reusables.dependabot.pull-request-security-vs-version-updates %}
+
+You enable {% data variables.product.prodname_dependabot_version_updates %} by checking a `dependabot.yml` configuration file into your repository.
+
+{% data reusables.dependabot.dependabot-tos %}
+
+## Updates for packages
 
-You enable {% data variables.product.prodname_dependabot_version_updates %} by checking a `dependabot.yml` configuration file into your repository. The configuration file specifies the location of the manifest, or of other package definition files, stored in your repository. {% data variables.product.prodname_dependabot %} uses this information to check for outdated packages and applications. {% data variables.product.prodname_dependabot %} determines if there is a new version of a dependency by looking at the semantic versioning ([semver](https://semver.org/)) of the dependency to decide whether it should update to that version. For certain package managers, {% data variables.product.prodname_dependabot_version_updates %} also supports vendoring. Vendored (or cached) dependencies are dependencies that are checked in to a specific directory in a repository rather than referenced in a manifest. Vendored dependencies are available at build time even if package servers are unavailable. {% data variables.product.prodname_dependabot_version_updates %} can be configured to check vendored dependencies for new versions and update them if necessary.
+The `dependabot.yml` configuration file specifies the location of the manifest, or of other package definition files, stored in your repository. {% data variables.product.prodname_dependabot %} uses this information to check for outdated packages and applications. {% data variables.product.prodname_dependabot %} determines if there is a new version of a dependency by looking at the semantic versioning ([semver](https://semver.org/)) of the dependency to decide whether it should update to that version. {% data reusables.dependabot.dependabot-updates-supported-repos-ecosystems %}
+
+For certain package managers, {% data variables.product.prodname_dependabot_version_updates %} also supports vendoring. Vendored (or cached) dependencies are dependencies that are checked in to a specific directory in a repository rather than referenced in a manifest. Vendored dependencies are available at build time even if package servers are unavailable. {% data variables.product.prodname_dependabot_version_updates %} can be configured to check vendored dependencies for new versions and update them if necessary.
 
 When {% data variables.product.prodname_dependabot %} identifies an outdated dependency, it raises a pull request to update the manifest to the latest version of the dependency. For vendored dependencies, {% data variables.product.prodname_dependabot %} raises a pull request to replace the outdated dependency with the new version directly. You check that your tests pass, review the changelog and release notes included in the pull request summary, and then merge it. For more information, see [AUTOTITLE](/code-security/dependabot/dependabot-version-updates/configuring-dependabot-version-updates).
 
 If you enable _security updates_, {% data variables.product.prodname_dependabot %} also raises pull requests to update vulnerable dependencies. For more information, see [AUTOTITLE](/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates).
 
-{% data reusables.dependabot.pull-request-security-vs-version-updates %}
+## Updates for actions
 
-{% data reusables.dependabot.dependabot-updates-signed-commits %}
+Actions are often updated with bug fixes and new features to make automated processes more reliable, faster, and safer. When you enable {% data variables.product.prodname_dependabot_version_updates %} for {% data variables.product.prodname_actions %}, {% data variables.product.prodname_dependabot %} will help ensure that references to actions in a repository's _workflow.yml_ file and reusable workflows used inside workflows are kept up to date.
 
-{% data reusables.dependabot.dependabot-updates-prs-and-actions %}
+For each action in the file, {% data variables.product.prodname_dependabot %} checks the action's reference (typically a version number or commit identifier associated with the action) against the latest version. If a more recent version of the action is available, {% data variables.product.prodname_dependabot %} will send you a pull request that updates the reference in the workflow file to the latest version.
 
-{% data reusables.dependabot.dependabot-tos %}
+{% data variables.product.prodname_dependabot %} also checks workflow files for uses of reusable workflows, and updates the Git reference for these called reusable workflows.
+
+To enable this feature, see [AUTOTITLE](/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/keeping-your-actions-up-to-date-with-dependabot).
 
 ## Frequency of {% data variables.product.prodname_dependabot %} pull requests