Merge pull request #56124 from github/repo-sync

Repo sync

Author: docs-bot

content/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs.md

@@ -347,8 +347,6 @@ jobs:
 
 ## `vars` context
 
-{% data reusables.actions.configuration-variables-beta-note %}
-
 The `vars` context contains custom configuration variables set at the organization, repository, and environment levels. For more information about defining configuration variables for use in multiple workflows, see [AUTOTITLE](/actions/learn-github-actions/variables#defining-variables-for-multiple-workflows).
 
 ### Example contents of the `vars` context

content/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks.md

@@ -46,9 +46,10 @@ Forking a repository is similar to duplicating a repository, with the following
 * Code pushed to a fork is visible to all repositories in the fork network, even after that fork is deleted.
 * You can use a pull request to suggest changes from your fork to the upstream repository.
 * You can bring changes from the upstream repository to your fork by synchronizing your fork with the upstream repository.
-* Forks have their own members, branches, tags, labels, policies, issues, pull requests, discussions, actions, projects, and wikis.
 * Forks inherit the restrictions of their upstream repositories. For example, branch protection rules cannot be passed down if the upstream repository belongs to an organization on a {% data variables.product.prodname_free_team %} plan.
 
+Like duplicated repositories, forks have their own members, branches, tags, labels, policies, issues, pull requests, discussions, actions, projects, and wikis.
+
 ## Further reading
 
 * [AUTOTITLE](/pull-requests/collaborating-with-pull-requests/getting-started/about-collaborative-development-models)