diff --git a/content/actions/reference/security/secure-use.md b/content/actions/reference/security/secure-use.md
index 8876f100de3e..74a7a245f2b5 100644
--- a/content/actions/reference/security/secure-use.md
+++ b/content/actions/reference/security/secure-use.md
@@ -113,9 +113,21 @@ This means that a compromise of a single action within a workflow can be very si
 
 You can help mitigate this risk by following these good practices:
 
-* **Pin actions to a full length commit SHA**
-
-  Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload. {% data reusables.actions.actions-pin-commit-sha %}
+* **Pin actions to a full-length commit SHA**
+
+  Pinning an action to a full-length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload. {% data reusables.actions.actions-pin-commit-sha %}
+
+  For an example of using a full-length commit SHA in a workflow, see [AUTOTITLE](/actions/how-tos/write-workflows/choose-what-workflows-do/find-and-customize-actions#using-shas).
+  
+  {%- ifversion actions-blocklist-sha-pinning %}
+  
+  {% data variables.product.github %} offers policies at the {% ifversion ghec or ghes %}repository, organization, and enterprise{% else %}repository and organization{% endif %} level to require actions to be pinned to a full-length commit SHA:
+    * To configure the policy at the repository level, see [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#managing-github-actions-permissions-for-your-repository).
+    * To configure the policy at the organization level, see [AUTOTITLE](/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#managing-github-actions-permissions-for-your-organization).
+    {%- ifversion ghec or ghes %}
+    * To configure the policy at the enterprise level, see [AUTOTITLE](/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#policies).
+    {%- endif %}
+  {%- endif %}
 
 * **Audit the source code of the action**
 
diff --git a/content/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise.md b/content/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise.md
index 91d180fc36ff..1768b8029e13 100644
--- a/content/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise.md
+++ b/content/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise.md
@@ -53,6 +53,9 @@ You can also limit the use of public actions {% ifversion actions-workflow-polic
 * **Allow all actions {% ifversion actions-workflow-policy %}and reusable workflows{% endif %}:** Any action {% ifversion actions-workflow-policy %}or reusable workflow{% endif %} can be used, regardless of who authored it or where it is defined.
 * **Allow enterprise actions {% ifversion actions-workflow-policy %}and reusable workflows{% endif %}:** Only actions {% ifversion actions-workflow-policy %}and reusable workflows{% endif %} defined in a repository within the enterprise can be used. {% ifversion ghec %}Blocks all access to actions authored by {% data variables.product.prodname_dotcom %}, such as the [`actions/checkout`](https://github.com/actions/checkout) action.{% endif %}
 * {% data reusables.actions.policy-label-for-select-actions-workflows %}: Any action {% ifversion actions-workflow-policy %}or reusable workflow{% endif %} defined in a repository within the enterprise can be used, plus any action {% ifversion actions-workflow-policy %}or reusable workflow{% endif %} that matches criteria you specify.
+{%- ifversion actions-blocklist-sha-pinning %}
+* **Require actions to be pinned to a full-length commit SHA**: All actions must be pinned to a full-length commit SHA to be used. This includes actions from your enterprise and actions authored by {% data variables.product.github %}. {% ifversion actions-workflow-policy %}Reusable workflows can still be referenced by tag.{% endif %} For more information, see [AUTOTITLE](/actions/reference/security/secure-use#using-third-party-actions).
+{%- endif %}
 
 <span id="allowing-select-actions-and-reusable-workflows-to-run" ></span>
 
@@ -64,7 +67,7 @@ If you choose this option, actions {% ifversion actions-workflow-policy %}and re
 * **Allow Marketplace actions by verified creators:** Allows all {% data variables.product.prodname_marketplace %} actions created by verified creators, labeled with {% octicon "verified" aria-label="The verified badge" %}.{% ifversion ghes %}
 
    Only available if you have {% data variables.product.prodname_github_connect %} enabled and configured with {% data variables.product.prodname_actions %}. See [AUTOTITLE](/admin/github-actions/managing-access-to-actions-from-githubcom/enabling-automatic-access-to-githubcom-actions-using-github-connect).{% endif %}
-* **Allow specified actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %}:** Allows actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %} that you specify. You can specify individual actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %} or entire organizations and repositories.
+* **Allow{% ifversion actions-blocklist-sha-pinning %} or block{% endif %} specified actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %}:** Allows actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %} that you specify. You can specify individual actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %} or entire organizations and repositories.
 
 When specifying actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %}, use the following syntax:
 
@@ -76,6 +79,13 @@ When specifying actions{% ifversion actions-workflow-policy %} and reusable work
 * To specify a pattern, use the wildcard character, `*`.
    * To allow all actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %} in organizations that start with `space-org`, use `space-org*/*`.
    * To allow all actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %} in repositories that start with octocat, use `*/octocat**@*`.
+* To specify multiple patterns, use `,` to separate patterns.
+   * To allow all actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %} from the `octocat` and `octokit` organizations, use `octocat/*, octokit/*`.
+{%- ifversion actions-blocklist-sha-pinning %}
+* To block specific patterns, use the `!` prefix.
+   * To allow all actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %} from the `space-org` organization, but block a specific action like `space-org/action`, use `space-org/*, !space-org/action@*`.
+   * By default, only actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %} specified in the list will be allowed. To allow all actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %} while also blocking specific actions, use `*, !space-org/action@*`.
+{%- endif %}
 
 Policies never restrict access to local actions on the runner filesystem (where the `uses:` path start with `./`).
 
diff --git a/content/get-started/exploring-projects-on-github/contributing-to-open-source.md b/content/get-started/exploring-projects-on-github/contributing-to-open-source.md
new file mode 100644
index 000000000000..c156e5339441
--- /dev/null
+++ b/content/get-started/exploring-projects-on-github/contributing-to-open-source.md
@@ -0,0 +1,149 @@
+---
+title: Contributing to open source
+intro: 'Learn how to make a contribution to an open source project that will be accepted by maintainers.'
+versions:
+  fpt: '*'
+  ghes: '*'
+  ghec: '*'
+shortTitle: Contribute to open source
+---
+
+In this article, you'll learn how to contribute to an open source project by working through an example. We'll guide you through making a contribution to the `github/docs` repository: familiarizing yourself with the repository, finding an area to contribute, making and submitting a pull request, and working with maintainers to get your changes accepted.
+
+## Orienting yourself with the project guidelines
+
+Before you start, it's important to understand the project's guidelines and requirements.  
+
+### Why are guidelines important?
+
+Every project has its own conventions, coding standards, and contribution processes that you'll need to follow:
+
+* **Code style and formatting requirements:** How code should be formatted, naming conventions, and linting rules
+* **Testing guidelines:** How to run tests, what tests are required for new features, and testing conventions
+* **Pull request process:** How to structure your pull request, what information to include, and review expectations
+* **Development setup:** How to set up your local development environment, required dependencies, and build processes
+* **Issue reporting:** How to report bugs, request features, or ask questions
+* **Communication channels:** Where to ask questions, discuss changes, or get help from maintainers
+
+Taking time to read through these will save time, for both you and the maintainers, and make it more likely that your contribution will be accepted.
+
+### Finding the guidelines
+
+To access these guidelines and requirements, navigate to the **Community Standards** checklist in the **Insights** tab. For our example, we'll use the [`github/docs` Community Standards](https://github.com/github/docs/community).
+
+* **README:** Provides an overview of the project. The content can vary, but the README helps users and contributors quickly understand what the project is and how to use it, along with links to other documentation.
+* **Code of Conduct:** Defines acceptable behavior standards for project contributors and community members, and establishes expectations and procedures for addressing violations.
+* **Contributing:** Provides guidelines and instructions for contributors to the project. It helps streamline the contribution process by setting clear expectations and encouraging consistent collaboration.
+* **License:** Legally defines how others can use, modify, and distribute the code, protecting both the maintainers and users by setting clear terms for copyright and permissions.
+
+  * For example, the `github/docs` repository uses the Creative Commons License for the documentation, which is a license type that is specifically for creative works. The software code in `github/docs` is under the MIT license, which is a permissive license that allows anyone to use the code contained in it.
+  * You can learn about other common license types with the [Choose a license](https://choosealicense.com/licenses/) tool.
+
+* **Security policy:** Provides instructions for reporting security vulnerabilities to maintainers of the repository.
+
+Review each of the resources that are available for the `github/docs` repository.
+
+## Finding an area to contribute
+
+When first contributing to a project, starting with minor fixes like documentation improvements or small bug reports can help you familiarize yourself with the codebase and contributor workflow. In this example, you'll be looking for issues using the `help wanted` and `good first issue` labels to surface specific issues that are open for external contributors. Then you'll use {% data variables.product.prodname_copilot_short %} to help provide context about the issue.
+
+1. Navigate to the **Issues** tab of the `github/docs` repository, then use the **Labels** filter and select "help wanted" to view open issues that maintainers have specifically marked as needing community help.
+1. Look through the list of issues and find one you would be interested in working on.
+{% data reusables.copilot.immersive-mode-instructions %}
+1. In the prompt box, enter the following prompt:
+
+      ```text copy
+      Can you summarize the key points and next steps from this issue?
+      ```
+
+1. Read through the context {% data variables.product.prodname_copilot_short %} provided, along with the comments from other contributors and maintainers to see if the issue is one you want to work on. If you have specific questions you can ask directly in the issue or in the project's Discord, IRC, or Slack, if applicable.
+
+> [!TIP] If you ever work on an issue **without** the `help wanted` or `good first issue` labels, it's a good idea to ask the maintainers in the issue if you can open a pull request, to confirm your planned contribution aligns with the project's goals.
+
+## Creating your own copy of a project
+
+Now you're ready to get started contributing. Because you don't have access to edit the repository, you first need to create a **fork**: your own copy of the repository where you can safely make changes and submit them back for maintainer review. In this example, we'll walk through creating a fork of the `github/docs` repository.
+
+1. Navigate to the `GitHub Docs` project at https://github.com/github/docs.
+1. In the top-right corner of the page, click **Fork**.
+1. Under "Owner," select the dropdown menu and click an owner for the forked repository.
+1. By default, forks are named the same as their upstream repositories. Optionally, to further distinguish your fork, in the "Repository name" field, type a name.
+1. Optionally, in the "Description" field, type a description of your fork.
+1. Optionally, select **Copy the DEFAULT branch only**.
+
+    For many forking scenarios, such as contributing to open-source projects, you only need to copy the default branch. If you do not select this option, all branches will be copied into the new fork.
+
+1. Click **Create fork**.
+
+## Cloning a fork of a project
+
+Now you have a fork of the `github/docs` repository under your account, but you need to get it to your local machine to get started working on your changes.
+
+1. On {% data variables.product.github %}, navigate to **your fork** of the `github/docs` repository.
+{% data reusables.repositories.copy-clone-url %}
+1. On Mac or Linux, open Terminal. On Windows, open Git Bash.
+{% data reusables.command_line.change-current-directory-clone %}
+1. Type `git clone`, and then paste the URL you copied earlier. It will look like this, with your {% data variables.product.github %} username instead of `YOUR-USERNAME`:
+
+    ```shell copy
+    git clone https://github.com/YOUR-USERNAME/docs
+    ```
+
+1. Press **Enter**. Your local clone will be created.
+
+## Making changes in a topic branch
+
+Now it's time to make changes! Before you start, it's a good idea to create a **topic branch** with a **descriptive name** in your fork. Using a topic branch lets you keep your work separate from the default branch of the repository.
+
+```shell copy
+git checkout -b YOUR_TOPIC_BRANCH
+```
+
+After switching to your topic branch, open your favorite text editor or IDE and start coding. Follow these best practices:
+
+* Use {% data variables.product.prodname_copilot_short %} to provide code suggestions, giving you confidence in your changes.
+* Document your code and write tests. These are often overlooked, and can help ensure your contribution gets merged.
+* Ask {% data variables.product.prodname_copilot_short %} questions about the issue to help you further understand the requirements for implementation.
+* Use {% data variables.product.prodname_copilot_short %} to review your changes to ensure they meet the project’s coding style and documentation requirements.
+* Use {% data variables.product.prodname_copilot_short %} to help with instructions for building and testing the project on your local machine.
+
+## Committing and pushing your changes
+
+When your changes are ready, you can stage and commit them in your repository. When writing a commit message, use a clear, concise commit title under 50 characters that summarizes what the commit does. Group related changes into single commits when possible, but keep unrelated changes in separate commits.
+
+```shell copy
+git add .
+git commit -m "a short description of the change"
+```
+
+Try to keep commit description lines under 72 characters for better readability. When you've finished committing your local changes and are ready to push them to {% data variables.product.github %}, push your changes to the remote.
+
+```shell copy
+git push
+```
+
+## Submitting a pull request
+
+Now that you've pushed your changes to {% data variables.product.github %}, you're ready to open a pull request. You can open a pull request for review even if you have not finalized the changes you've made in your branch. Opening a pull request early on in the contribution process gives awareness to the maintainers, and allows them to give initial feedback about your changes.
+
+1. Go to your forked repository on GitHub. For example, `https://github.com/YOUR-USERNAME/docs`.
+1. You should see a prompt to "Compare & pull request" for your recently pushed branch. Click it.
+1. If not, go to the "Pull requests" tab and click "New pull request".
+1. Ensure the **base** repository is `github/docs` and the base branch is their main branch (e.g., `main`).
+1. Ensure the **head** repository is your fork (`YOUR-USERNAME/docs`) and the compare branch is your branch.
+1. Type a title and description for your pull request. In the description, reference the issue that your pull request will close. For example, `Closes: #15`. This will provide context for your pull request and automatically close the issue out once the pull request is merged.
+
+  > [!TIP] Avoid force pushing once a pull request has been submitted for review. This makes it more difficult for maintainers to see that you are addressing their feedback.
+
+## Working with project maintainers
+
+Once your pull request has been submitted, the next step is for a project maintainer to review and provide feedback. Project maintainers may request changes to match the codebase's style or architecture, sometimes requiring you to refactor substantial portions of your work.
+
+* When feedback arrives about your pull request, respond promptly and professionally even if criticism feels harsh. Maintainers are typically focused on code quality.
+* If changes are requested for your pull request, don't open a new pull request to address the changes. Keeping the existing pull request open and making changes there helps prevent the maintainers from losing context.
+* If your pull request remains unaddressed for weeks, politely follow up with a comment requesting feedback. Do **not** directly mention the handles of maintainers. Maintainers often balance open source work with full-time responsibilities, and understanding their time constraints fosters better collaboration.
+* If your contribution does not get accepted, ask the maintainers for feedback so that you can have that context for the next time you want to make a contribution.
+
+## Next steps
+
+You now know how to identify the right issues to work on, craft contributions that maintainers want to merge, and how to navigate the pull request review process. The open source community on {% data variables.product.github %} is ready for your unique perspective and skills. Find a new project that excites you, identify an issue to work on, and start contributing.
diff --git a/content/get-started/exploring-projects-on-github/finding-ways-to-contribute-to-open-source-on-github.md b/content/get-started/exploring-projects-on-github/finding-ways-to-contribute-to-open-source-on-github.md
index 75389cb3eb46..bb9d17cba902 100644
--- a/content/get-started/exploring-projects-on-github/finding-ways-to-contribute-to-open-source-on-github.md
+++ b/content/get-started/exploring-projects-on-github/finding-ways-to-contribute-to-open-source-on-github.md
@@ -16,45 +16,62 @@ versions:
   ghec: '*'
 topics:
   - Open Source
-shortTitle: Contribute to open source
+shortTitle: Finding open source projects
 ---
+
+Open source software powers much of the technology you use daily, from the web browser on your screen to the [NASA Ingenuity helicopter that flew on Mars](https://github.com/readme/featured/nasa-ingenuity-helicopter).
+
+Contributing to open source software allows you to build upon your technical expertise, boost your portfolio, help shape the future of technology, and connect with developers across the globe.
+
 ## Discovering relevant projects
 
-If there's a particular topic that interests you, visit `github.com/topics/<topic>`. For example, if you are interested in machine learning, you can find relevant projects and good first issues by visiting https://github.com/topics/machine-learning. You can browse popular topics by visiting [Topics](https://github.com/topics). You can also search for repositories that match a topic you're interested in. See [AUTOTITLE](/search-github/searching-on-github/searching-for-repositories#search-by-topic).
+With the vast array of available open source projects spanning numerous domains and technologies, finding where to begin your contribution journey can seem overwhelming. If you have open source software that you use daily, that's a great place to get started! {% data variables.product.github %} also provides several tools that can help narrow down your search to a project that fits your domain.
 
-If you're interested in contributing to projects that **reduce the carbon emissions of software**, review [{% data variables.product.github %}'s Green Software Directory](https://github.com/github/GreenSoftwareDirectory).
+### Using {% data variables.copilot.copilot_chat_short %} to find open source projects
 
-If you've been active on {% data variables.product.prodname_dotcom %}, you can find personalized recommendations for projects and good first issues based on your past contributions, stars, and other activities in [Explore {% data variables.product.prodname_dotcom %}](https://github.com/explore).
+You can use {% data variables.copilot.copilot_chat_short %} to help find open source repositories that match an area you want to improve or boost your skills in.
 
-Keep up with recent activity from repositories you watch, as well as people and organizations you follow, with your personal dashboard. For more information, see [AUTOTITLE](/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-user-account-settings/about-your-personal-dashboard).
+Open [{% data variables.copilot.copilot_chat_short %}](https://github.com/copilot) and start a general purpose chat. In this example, we'll ask {% data variables.product.prodname_copilot_short %} to find open source projects written in the Python programming language.
 
-{% data reusables.support.ask-and-answer-forum %}
+```text copy
+ I'm looking for a list of open source projects written in Python that are accepting new contributors. Narrow down the list to repositories that use the `good first issue` or `help wanted` labels and have over 100 stars on GitHub.
+```
 
-## Finding good first issues
+Using the `good first issue` and `help wanted` labels in the search will help {% data variables.product.prodname_copilot_short %} filter for repositories that open for first-time contributors. After searching, {% data variables.product.prodname_copilot_short %} will provide a link to a full list of repositories with those labels in the context of your search.
 
-If you already know what project you want to work on, you can find beginner-friendly issues in that repository by visiting `github.com/<owner>/<repository>/contribute`. For an example, you can find ways to make your first contribution to `electron/electron` at https://github.com/electron/electron/contribute.
+### Using other resources to find projects to contribute to
 
-## Opening an issue
+If there's a particular topic that interests you, visit `github.com/topics/<topic>`. For example, if you are interested in machine learning, you can find relevant projects and good first issues by visiting https://github.com/topics/machine-learning. You can also search for repositories that match a topic you're interested in. See [AUTOTITLE](/search-github/searching-on-github/searching-for-repositories#search-by-topic). You can browse popular repositories of the day by visiting [Trending](https://github.com/trending).
+
+If you're interested in contributing to projects that **reduce the carbon emissions of software**, review [{% data variables.product.github %}'s Green Software Directory](https://github.com/github/GreenSoftwareDirectory).
+
+If you've been active on {% data variables.product.prodname_dotcom %}, you can find personalized recommendations for projects and good first issues based on your past contributions, stars, and other activities in [Explore {% data variables.product.prodname_dotcom %}](https://github.com/explore).
 
-If you encounter a bug in an open source project, check if the bug has already been reported. If the bug has not been reported, you can open an issue to report the bug according to the project's contribution guidelines.
+## Checking if the repository is actively maintained
 
-## Validating an issue or pull request
+Before getting started contributing to an open source repository, it's recommended to check if the repository is being actively maintained. {% data variables.product.prodname_copilot_short %} can analyze a repository and tell you about its recent activity.
 
-There are a variety of ways that you can contribute to open source projects.
+1. On the {% data variables.product.prodname_dotcom %} website, go to the repository you want to chat about.
+1. Click the **{% octicon "copilot" aria-hidden="true" aria-label="copilot" %}** {% data variables.product.prodname_copilot %} icon at the top right of the page.
+   The full-page, immersive, mode {% data variables.copilot.copilot_chat %} is displayed. The heading at the top of the chat panel will show the name of the repository as an attachment.
+1. In the prompt box, type "Is this repository being actively maintained?" and press <kbd>Enter</kbd>.  {% data variables.product.prodname_copilot_short %} replies in the chat panel.
 
-### Reproducing a reported bug
+You can also visit the **Pulse** view under the **Insights** tab in the repository to get an overview of recent activity. See the [`github/docs` Pulse](https://github.com/github/docs/pulse) for an example of what an active open source project looks like.
 
-You can contribute to an open source project by validating an issue or adding additional context to an existing issue.
+## Finding ways to contribute
 
-### Testing a pull request
+There are many ways to contribute to open source projects.
 
-You can contribute to an open source project by merging a pull request into your local copy of the project and testing the changes. Add the outcome of your testing in a comment on the pull request.
+* **Looking through the issue tracker**: Look for bugs that need fixing or reproduction, feature requests, or documentation improvements. Many open source projects use the `good first issue` or `help wanted` labels to make it easier for new contributors to find issues to work on.
+* **Testing a pull request**: You can contribute by merging a pull request into your local copy of the project and testing the changes. Add the outcome of your testing in a comment on the pull request.
+* **Installing and testing the project**: As you use an open source project, note any bugs, usability issues, or missing features you encounter. Sharing these pain points can provide valuable feedback to other contributors.
+* **Improving the documentation**: Documentation improvements are almost always welcome, and can be an excellent way to start contributing while learning the project.
+* **Adding tests**: Many projects need better test coverage, which helps you learn the codebase while adding value.
 
-### Updating issues
+Each open source project will have a different approach to how they want to accept contributions. If you're looking to add a new feature or have discovered a bug, you'll want to open an issue outlining your proposed approach before investing significant development time. This can save effort by aligning with maintainer expectations early on.
 
-You can contribute to an open source project by adding additional information to existing issues.
+Remember that non-code contributions like improving documentation, design, or community support are just as valuable as code contributions, and often have a lower barrier to entry.
 
-## Further reading
+## Next steps
 
-* [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/classifying-your-repository-with-topics)
-* [AUTOTITLE](/organizations/collaborating-with-groups-in-organizations/about-your-organization-dashboard)
+Now that you've found an open source project to work on and have learned about different ways to contribute, you are ready to make your first contribution. Head over to [AUTOTITLE](/get-started/exploring-projects-on-github/contributing-to-open-source) to walk through the end-to-end process of making a contribution.
diff --git a/content/get-started/exploring-projects-on-github/index.md b/content/get-started/exploring-projects-on-github/index.md
index 06e5bfba0de3..4a4653b7d257 100644
--- a/content/get-started/exploring-projects-on-github/index.md
+++ b/content/get-started/exploring-projects-on-github/index.md
@@ -15,6 +15,7 @@ topics:
   - Projects
 children:
   - /finding-ways-to-contribute-to-open-source-on-github
+  - /contributing-to-open-source
   - /using-github-copilot-to-explore-projects
   - /contributing-to-a-project
   - /saving-repositories-with-stars
diff --git a/data/features/actions-blocklist-sha-pinning.yml b/data/features/actions-blocklist-sha-pinning.yml
new file mode 100644
index 000000000000..ce685cdd0e43
--- /dev/null
+++ b/data/features/actions-blocklist-sha-pinning.yml
@@ -0,0 +1,5 @@
+# Versioning for repo/org/enterprise policy settings for actions blocklist and SHA pinning policies.
+versions:
+  fpt: '*'
+  ghec: '*'
+  ghes: '>=3.19'
diff --git a/data/reusables/actions/actions-use-policy-settings.md b/data/reusables/actions/actions-use-policy-settings.md
index 14d3c9ef5c98..e5a95b3ef5d5 100644
--- a/data/reusables/actions/actions-use-policy-settings.md
+++ b/data/reusables/actions/actions-use-policy-settings.md
@@ -1,3 +1,7 @@
 If you choose {% data reusables.actions.policy-label-for-select-actions-workflows %}, actions {% ifversion actions-workflow-policy %}and reusable workflows{% endif %} within your {% ifversion ghec or ghes %}enterprise{% else %}organization{% endif %} are allowed, and there are additional options for allowing other specific actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %}. For more information, see [Allowing select actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %} to run](#allowing-select-actions{% ifversion actions-workflow-policy %}-and-reusable-workflows{% endif %}-to-run).
 
 {% ifversion ghec or fpt %}When you allow actions{% ifversion actions-workflow-policy %} and reusable workflows from only in{% else %} local to{% endif %} your {% ifversion ghec or ghes %}enterprise{% else %}organization{% endif %}, the policy blocks all access to actions authored by {% data variables.product.prodname_dotcom %}. For example, the [`actions/checkout`](https://github.com/actions/checkout) action would not be accessible.{% endif %}
+
+{% ifversion actions-blocklist-sha-pinning %}
+When you enable **Require actions to be pinned to a full-length commit SHA**, all actions must be pinned to a full-length commit SHA to be used. This includes actions from your {% ifversion ghec or ghes %}enterprise{% else %}organization{% endif %} and actions authored by {% data variables.product.github %}. {% ifversion actions-workflow-policy %}Reusable workflows can still be referenced by tag.{% endif %} For more information, see [AUTOTITLE](/actions/reference/security/secure-use#using-third-party-actions).
+{% endif %}
diff --git a/data/reusables/actions/allow-specific-actions-intro.md b/data/reusables/actions/allow-specific-actions-intro.md
index 5101bfd92624..422954be0c6d 100644
--- a/data/reusables/actions/allow-specific-actions-intro.md
+++ b/data/reusables/actions/allow-specific-actions-intro.md
@@ -9,7 +9,7 @@ When you choose {% data reusables.actions.policy-label-for-select-actions-workfl
 
 * **Allow actions created by {% data variables.product.prodname_dotcom %}:** You can allow all actions created by {% data variables.product.prodname_dotcom %} to be used by workflows. Actions created by {% data variables.product.prodname_dotcom %} are located in the `actions` and `github` organizations. For more information, see the [`actions`](https://github.com/actions) and [`github`](https://github.com/github) organizations.
 * **Allow Marketplace actions by verified creators:** {% ifversion ghes %}This option is available if you have {% data variables.product.prodname_github_connect %} enabled and configured with {% data variables.product.prodname_actions %}. For more information, see [AUTOTITLE](/admin/github-actions/managing-access-to-actions-from-githubcom/enabling-automatic-access-to-githubcom-actions-using-github-connect).{% endif %} You can allow all {% data variables.product.prodname_marketplace %} actions created by verified creators to be used by workflows. When GitHub has verified the creator of the action as a partner organization, the {% octicon "verified" aria-label="The verified badge" %} badge is displayed next to the action in {% data variables.product.prodname_marketplace %}.
-* **Allow specified actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %}:** You can restrict workflows to use actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %} in specific organizations and repositories. Specified actions cannot be set to more than 1000.
+* **Allow{% ifversion actions-blocklist-sha-pinning %} or block{% endif %} specified actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %}:** You can restrict workflows to use actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %} in specific organizations and repositories. Specified actions cannot be set to more than 1000.
 
   To restrict access to specific tags or commit SHAs of an action{% ifversion actions-workflow-policy %} or reusable workflow{% endif %}, use the same syntax used in the workflow to select the action{% ifversion actions-workflow-policy %} or reusable workflow{% endif %}.
 
@@ -20,7 +20,11 @@ When you choose {% data reusables.actions.policy-label-for-select-actions-workfl
 
   You can use the `*` wildcard character to match patterns. For example, to allow all actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %} in organizations that start with `space-org`, you can specify `space-org*/*`. To allow all actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %} in repositories that start with octocat, you can use `*/octocat**@*`. For more information about using the `*` wildcard, see [AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet).
 
-  Use `,` to separate patterns. For example, to allow `octocat` and `octokit`, you can specify `octocat/*, octokit/*`.
+  Use `,` to separate patterns. For example, to allow all actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %} from the `octocat` and `octokit` organizations, you can specify `octocat/*, octokit/*`.
+
+  {% ifversion actions-blocklist-sha-pinning %}
+  Use the `!` prefix to block patterns. For example, to allow all actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %} from the `space-org` organization, but block a specific action like `space-org/action`, you can specify `space-org/*, !space-org/action@*`. By default, only actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %} specified in the list will be allowed. To allow all actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %} while also blocking specific actions, you can specify `*, !space-org/action@*`.
+  {% endif %}
 
   {% ifversion fpt or ghec %}
 
@@ -29,4 +33,4 @@ When you choose {% data reusables.actions.policy-label-for-select-actions-workfl
 
   {% endif %}
 
-This procedure demonstrates how to add specific actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %} to the allow list.
+This procedure demonstrates how to add specific actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %} to the list.
diff --git a/data/reusables/repositories/request-changes-tips.md b/data/reusables/repositories/request-changes-tips.md
index 7e3c762dc070..4bec3fc6ea11 100644
--- a/data/reusables/repositories/request-changes-tips.md
+++ b/data/reusables/repositories/request-changes-tips.md
@@ -3,5 +3,7 @@
 > * Repository owners and administrators can merge a pull request even if it hasn't received an approving review, or if a reviewer who requested changes has left the organization or is unavailable.
 > * If both required reviews and stale review dismissal are enabled and a code-modifying commit is pushed to the branch of an approved pull request, the approval is dismissed. The pull request must be reviewed and approved again before it can be merged.
 > * When several open pull requests each have a head branch pointing to the same commit, you won’t be able to merge them if one or both have a pending or rejected review.
-> * If your repository requires approving reviews from people with write or admin permissions, then any approvals from people with these permissions are denoted with a green check mark, and approvals from people without these permissions have a gray check mark. Approvals with a gray check mark do not affect whether the pull request can be merged.
+> * If your repository requires approving reviews from people with write or admin permissions, the reviewers sidebar groups approvals by permission level. Approvals can appear in two sections:
+>     * The **top section** mostly contains approvals from people with write or admin permissions that count toward merge requirements. Approvals by {% data variables.product.prodname_copilot %} also appear in this section even though {% data variables.product.prodname_copilot %} reviews do not count toward those requirements.
+>     * The **collapsible section (if present)** shows approvals from reviewers whose reviews do not affect whether the pull request can be merged.
 > * Pull request authors cannot approve their own pull requests.{% ifversion copilot %} You will also not be able to approve a pull request that was raised by {% data variables.product.prodname_copilot %} if it was you who assigned {% data variables.product.prodname_copilot_short %} to the issue to which the pull request relates.{% endif %}