Merge pull request #34049 from github/repo-sync

Repo sync

content/actions/using-jobs/setting-default-values-for-jobs.md

@@ -7,7 +7,7 @@ versions:
   ghes: '*'
   ghec: '*'
 ---
- 
+
 {% data reusables.actions.enterprise-github-hosted-runners %}
 
 ## Overview

content/actions/using-jobs/using-jobs-in-a-workflow.md

@@ -7,7 +7,7 @@ versions:
   ghes: '*'
   ghec: '*'
 ---
- 
+
 {% data reusables.actions.enterprise-github-hosted-runners %}
 
 ## Overview

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

@@ -22,6 +22,10 @@ Docs are organized into multiple levels of hierarchy on our site.
   * Categories
     * Map topics
       * Articles
+    * Articles
+  * Articles
+
+Organizing content is a balance between making specific groupings that help people find what they are searching for and limiting the layers of hierarchy through which people must navigate. Deep hierarchies with many map topics nested together can make it hard to find specific articles. Wide hierarchies with many categories or articles at the same level make it difficult for people to evaluate and decide what they want to select.
 
 ## Homepage content
 
@@ -44,6 +48,7 @@ For example, under the "Security" grouping on the homepage, in addition to the "
 Top-level doc sets are organized around a {% data variables.product.prodname_dotcom %} product, feature, or core workflow. All top-level doc sets appear on the {% data variables.product.prodname_docs %} homepage. You should only create a top-level doc set when there is a large amount of content to be contained in the new doc set, multiple categories that are broken down into map topics, and the topic applies across products, features, or account types. If the content could fit in any existing top-level doc set, it probably belongs in that existing doc set.
 * Top-level doc sets are of roughly equal importance to one another (each is centered on a {% data variables.product.prodname_dotcom %} product or major feature).
 * Most top-level doc sets have a landing page layout, unless there is a significant exception. For example, the "[Site policy](/free-pro-team@latest/site-policy)" doc set does not have guides or procedural articles like other doc sets, so it does not use a landing page layout.
+* Top-level doc sets can contain a mix of categories, map topics, or articles.
 
 ### Titles for top-level doc sets
 
@@ -57,9 +62,10 @@ Top-level doc sets are organized around a {% data variables.product.prodname_dot
 
 Categories are organized around a feature or a discrete set of tasks within a top-level doc set aligned with product themes. A category's subject is narrow enough that its contents are manageable and does not grow too large to use. Some categories appear on the homepage.
 * Categories often start small and grow with the product.
-* Large categories may contain map topics to subdivide content around more specific user journeys or tasks.
+* Categories may contain map topics to subdivide content around more specific user journeys or tasks.
 * Use long procedural articles to group related chunks of content and keep articles within the category streamlined.
 * When categories have more than ten articles, consider breaking the content into map topics or additional categories.
+* Categories can contain a mix of map topics or articles.
 
 ### Titles for categories
 
@@ -79,7 +85,9 @@ All categories have intros. Intros should be one sentence long and general or hi
 
 Map topics introduce a section of a category, grouping articles within a category around more specific workflows or subjects that are part of the category’s larger task.
 
-Map topics contain at least three articles. When map topics have more than eight articles, it may be useful to consider breaking the content into more specific map topics.
+Map topics contain at least two articles. When map topics have more than eight articles, it may be useful to consider breaking the content into more specific map topics.
+
+In general, avoid having a map topic within a map topic unless it is the best way to meet a specific user need.
 
 ### Titles for map topics
 

data/reusables/actions/jobs/section-running-jobs-in-a-container-credentials.md

@@ -1,6 +1,6 @@
 {% data reusables.actions.registry-credentials %}
 
-#### Example: Defining credentials for a container registry
+### Example: Defining credentials for a container registry
 
 {% raw %}
 

data/reusables/actions/jobs/section-running-jobs-in-a-container-volumes.md

@@ -6,7 +6,7 @@ To specify a volume, you specify the source and destination path:
 
 The `<source>` is a volume name or an absolute path on the host machine, and `<destinationPath>` is an absolute path in the container.
 
-#### Example: Mounting volumes in a container
+### Example: Mounting volumes in a container
 
 ```yaml
 volumes:

data/reusables/actions/jobs/section-using-jobs-in-a-workflow-id.md

@@ -1,6 +1,6 @@
 Use `jobs.<job_id>` to give your job a unique identifier. The key `job_id` is a string and its value is a map of the job's configuration data. You must replace `<job_id>` with a string that is unique to the `jobs` object. The `<job_id>` must start with a letter or `_` and contain only alphanumeric characters, `-`, or `_`.
 
-#### Example: Creating jobs
+### Example: Creating jobs
 
 In this example, two jobs have been created, and their `job_id` values are `my_first_job` and `my_second_job`.
 

data/reusables/actions/jobs/setting-default-values-for-jobs-defaults-run.md

@@ -2,7 +2,7 @@ You can use `defaults.run` to provide default `shell` and `working-directory` op
 
 {% data reusables.actions.defaults-override %}
 
-#### Example: Set the default shell and working directory
+### Example: Set the default shell and working directory
 
 ```yaml
 defaults:

src/audit-logs/lib/config.json

@@ -3,5 +3,5 @@
     "apiOnlyEvents": "This event is not available in the web interface, only via the REST API, audit log streaming, or JSON/CSV exports.",
     "apiRequestEvent": "This event is only available via audit log streaming."
   },
-  "sha": "0f13b3c0c28c57038519c0d02f7af59b0bdf1f9a"
+  "sha": "9db7c050f8f686843f7ebab7e8d8fd18a4f843f0"
 }

src/secret-scanning/lib/config.json

@@ -1,3 +1,3 @@
 {
-  "sha": "35246707cbead2143b53c7a62a5fca7a54fbfc0a"
+  "sha": "bf82c5b6f6d84eb3626f88002d542f939cddd010"
 }