Repo sync

.github/instructions/content-guidelines.instructions.md

@@ -19,6 +19,20 @@ The strategic priority is simplification: create less content and remove content
 * Would a typical internet user figure this out on their own by exploring the UI?
 * Is the information presented at the moment the reader actually needs it?
 
+## Give opinionated, actionable guidance
+
+This applies whenever you give the reader advice or present ways to accomplish a task.
+
+* Be opinionated when there is a better way: when several approaches exist, recommend the best one and explain why, rather than presenting all options as equally valid. When they are genuinely equivalent, stay neutral.
+* Tell users the best practice AND how to follow it: whenever you state a best practice, pair it with concrete steps or an example so the reader can act on it, never the advice alone.
+
+## Focus on the reader's purpose, not the product
+
+Frame an article around what the reader is trying to accomplish, not the product or feature they use to do it. This applies when naming an article or deciding what a new or substantially reworked article should cover; do not use it to justify restructuring an article during a small edit.
+
+* Title articles by the reader's goal, not the product or feature. For example, "Secure your enterprise", not "Use GitHub Advanced Security".
+* Scope articles around a task, not a product. When a task naturally spans multiple features or products, look for the opportunity to cover them together in one task-focused article or tutorial rather than splitting into per-product articles. Keep each article to a single purpose (the task): combine features only when they serve that same task, not to bundle unrelated capabilities.
+
 ## Intros: pull people in
 
 This section applies mainly to the `intro` frontmatter field and, for conceptual articles, section openings.

CHANGELOG.md

@@ -1,5 +1,11 @@
 # Docs changelog
 
+**13 July 2026**
+
+We published [Bring your own key for GitHub Copilot](https://docs.github.com/en/copilot/concepts/models/bring-your-own-key). This article distinguishes between two different mechanisms for customers to use Copilot with custom models. We have also retitled corresponding how-to content to make the distinction clearer.
+
+<hr>
+
 **16 June 2026**
 
 We made some improvements to our documentation on Copilot policies:

content/admin/concepts/enterprise-best-practices/organize-work.md

@@ -12,12 +12,48 @@ redirect_from:
   - /admin/managing-accounts-and-repositories/managing-organizations-in-your-enterprise/best-practices-for-structuring-organizations-in-your-enterprise
   - /admin/concepts/best-practices-for-enterprises
   - /admin/concepts/best-practices
+  - /enterprise-onboarding/setting-up-organizations-and-teams/best-practices-for-organizations-in-your-enterprise  
+  - /enterprise-onboarding/setting-up-organizations-and-teams/best-practices
 allowTitleToDifferFromFilename: true
 category:
   - Get started with GitHub Enterprise
 ---
 
-{% data reusables.enterprise-onboarding.best-practices %}
+## Use organizations for work or governance
+
+There are two main models of using organizations:
+
+* **Group related work projects**: Group repositories for a specific application and related services. Teams that work on that application will then be able to communicate effectively and contribute across the different repositories.
+* **Group similar governance requirements**: Group repositories that require similar policies, security settings, or access restrictions. You will be able to apply the necessary settings to the organization at scale. For example, if you have highly confidential work projects or a specific data classification, group these in an organization where only a limited number of people have access.
+
+## Create organizations intentionally
+
+Creating organizations is a balance. While {% data variables.product.company_short %} continues to make organization management more scalable, you should be intentional about why you create an organization. It's always easier to add organizations than to remove them.
+
+Don't try to fit unnatural pieces of your company together into a single large organization. The administrative features of an enterprise account allow you to automate processes, manage access, and apply policies across multiple organizations at once. However, there are tradeoffs of segregating work into many different organizations:
+
+* It's easier for people to communicate within one organization, as @-mentions only work between members of the same organization.
+* It's easier for people to find resources in one organization, as there's only one place to search.
+
+You may want to start with a small number of organizations as you develop your strategy. After you build confidence in what works well for your business, you can create additional organizations as the need arises.
+
+You should regularly evaluate your strategies for access, governance, and organization of work. Cleaning up legacy organizations is a part of that process.
+
+{% ifversion enterprise-teams %}
+
+## Use teams to organize people
+
+Enterprise teams are the best way to control access and permissions at scale. Create teams and manage their membership as your primary means of performing actions like adding users to organizations, granting licenses, and delegating access to enterprise settings.
+
+When you use teams in this way, controlling membership of teams is a sensitive action. Limit the permission to control teams and their membership to a small number of people. If you use an external identity provider (IdP), sync teams to IdP groups so that team membership can be controlled by a central administrator.
+
+Use roles to delegate administrative duties to teams. This allows you to limit the number of enterprise owners in your company and give people just the permissions they need to do their jobs effectively. For example, a team of auditors can receive access to the enterprise audit log without being able to access any other settings.
+
+{% endif %}
+
+## Collaborate in organization-owned repositories
+
+We recommend collaborating in organization-owned repositories whenever possible and minimizing collaboration in user-owned repositories. Organization-owned repositories have more sophisticated security and administrative features, and they remain accessible even as enterprise membership changes.
 
 ## Use innersource practices
 

content/admin/concepts/enterprise-best-practices/use-innersource.md

@@ -6,9 +6,66 @@ versions:
   ghec: '*'
   ghes: '*'
 contentType: concepts
+redirect_from:
+  - /enterprise-onboarding/setting-up-organizations-and-teams/use-innersource
 allowTitleToDifferFromFilename: true
 category:
   - Get started with GitHub Enterprise
 ---
 
-{% data reusables.enterprise-onboarding.use-innersource %}
+You can use innersource practices to drive collaboration and productivity in your enterprise. Innersource makes it easy for all employees to discover and reuse work. This allows development teams to learn from each other's work, share their expertise, and avoid duplicating effort to recreate common services.
+
+## Make repositories discoverable
+
+Unless they contain sensitive information, you should aim to make repositories visible to all employees.
+
+To do this, encourage employees to use **internal** visibility whenever possible. Internal visibility allows any member of any organization in the enterprise to view the repository, regardless of whether the user is a member of the organization that owns the repository.
+
+You should also set permissive **base permissions** for organizations. An organization's base permission policy determines the default level of access that members of that organization have to all the organization's repositories. Generally, organizations should have at least a "Read" base permission so that all organization members can see any repository. Organization owners can then use teams to grant people greater levels of access in specific repositories.
+
+If you have more sensitive repositories that should not be widely visible, you can set up a dedicated organization with a more restrictive base permission and add specific teams to this organization.
+
+For more information, see [AUTOTITLE](/repositories/creating-and-managing-repositories/about-repositories#about-internal-repositories) and [AUTOTITLE](/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/setting-base-permissions-for-an-organization).
+
+## Document projects
+
+Organize and document your repositories so that people can search for work across the enterprise.
+
+Repository **READMEs** are effective because they're defined in files in the repository, so users can search for them like code. You can also create READMEs at the level of an organization or enterprise account to provide a higher-level overview of where to find different projects. For more formal internal documentation, consider setting up a **{% data variables.product.prodname_pages %} site** or **wikis**.
+
+You can use **repository topics** to group repositories that contain a certain programming language, are owned by a certain team, and so on. This is another way of making repositories easier to find.
+
+For more information, see:
+
+* [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes), [AUTOTITLE](/organizations/collaborating-with-groups-in-organizations/customizing-your-organizations-profile#adding-a-member-only-organization-profile-readme), and [AUTOTITLE](/admin/managing-your-enterprise-account/creating-a-readme-for-an-enterprise)
+* [AUTOTITLE](/pages/getting-started-with-github-pages/creating-a-github-pages-site)
+* [AUTOTITLE](/communities/documenting-your-project-with-wikis/adding-or-editing-wiki-pages)
+* [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/classifying-your-repository-with-topics)
+
+## Set up a culture for sharing work
+
+Encourage teams to publicize their work and share resources with other teams. {% data variables.product.github %} has a number of features that make this easier. For example, teams can:
+
+* Use **discussions** to make their work more visible to other teams. See [AUTOTITLE](/discussions/collaborating-with-your-community-using-discussions/participating-in-a-discussion#creating-a-discussion).
+* Create a dedicated internal repository for sharing **actions and reusable {% data variables.product.prodname_actions %} workflows**, which anyone can reference when they write a workflow within the enterprise. See [AUTOTITLE](/actions/how-tos/reuse-automations/share-with-your-enterprise).
+* Share reusable pieces of code in internal packages with **{% data variables.product.prodname_registry %}** registries. For enhanced security, you can give {% data variables.product.github %}'s security features access to these registries. See [AUTOTITLE](/packages/learn-github-packages/introduction-to-github-packages).
+* Set up common templates and frameworks as **template repositories** that other people can copy to get started with a project. See [AUTOTITLE](/repositories/creating-and-managing-repositories/creating-a-template-repository).
+
+Like with an open source project, you should ensure shared projects have a support model and a clearly defined team of maintainers, especially for services that many parts of your enterprise rely on. Ideally the maintainers team will contain representatives from the different teams that use the service.
+
+## Hide content from external collaborators
+
+If you have external contractors or collaborators who need access to your enterprise's projects, you can grant them a different level of access from regular employees.
+
+Specifically, you may want to hide internal repositories from an external collaborator. To do this:
+
+* If you use {% data variables.product.prodname_emus %}, provision an account for the user with the **guest collaborator** role. Guest collaborators don't have access to internal repositories by default, but they receive base permissions in organizations where they're added as members. They can also be added as repository collaborators in repositories.
+* If you do not use {% data variables.product.prodname_emus %}, add the user as an **outside collaborator** in the required repositories, but ensure they are not added as a member of any organization.
+
+Outside collaborators (called **repository collaborators** if you use {% data variables.product.prodname_emus %}) only have access to a specific repository. These users are not full organization members, so they do not receive the base level of access for the organization, and they cannot automatically see internal repositories in the enterprise unless they are a member of another organization.
+
+For more information, see {% ifversion ghec %}[AUTOTITLE](/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/enabling-guest-collaborators) and{% endif %} [AUTOTITLE](/organizations/managing-user-access-to-your-organizations-repositories/managing-outside-collaborators/adding-outside-collaborators-to-repositories-in-your-organization).
+
+## Next steps
+
+Now that you've set up organizations and teams, learn how to stay compliant and secure by setting up governance policies for your users and repositories. See [AUTOTITLE](/admin/concepts/security-and-compliance/enterprise-policies).

content/admin/concepts/enterprise-fundamentals/automations-in-your-enterprise.md

@@ -5,6 +5,8 @@ intro: Learn how {% data variables.product.prodname_github_apps %}, external ser
 versions:
   feature: enterprise-apps-public-beta
 contentType: concepts
+redirect_from:
+  - /enterprise-onboarding/github-apps/automations-in-your-enterprise
 category:
   - Get started with GitHub Enterprise
 ---

content/admin/concepts/enterprise-fundamentals/roles-in-an-enterprise.md

@@ -6,12 +6,38 @@ versions:
 shortTitle: Roles
 redirect_from:
   - /admin/overview/about-roles
+  - /enterprise-onboarding/feature-enhancements/about-access-permissions-on-github
+  - /enterprise-onboarding/setting-up-organizations-and-teams/about-roles-in-an-enterprise
 contentType: concepts
 category:
   - Get started with GitHub Enterprise
 ---
 
-{% data reusables.enterprise-onboarding.about-roles %}
+## What are roles?
+
+Roles allow you to delegate administrative duties and manage access securely at every level of your enterprise.
+
+A role is a **set of permissions** that you can assign to individuals or teams. A permission is the ability to perform a specific action, such as changing billing settings.
+
+A user in an enterprise has roles for both the enterprise account and organizations where they have access.
+
+* The enterprise-level roles define the user's access to enterprise settings.
+* Organization-level roles define the user's access to organization settings and repositories in an organization.
+
+## Predefined and custom roles
+
+Organization and enterprise roles can be **predefined** or **custom**. Enterprise custom roles are in {% data variables.release-phases.public_preview %}.
+
+* Predefined roles, such as enterprise owner, organization owner, or billing manager, are available for all accounts. They grant a predefined set of permissions to users or teams and may contain more permissions than someone needs to do their job.
+* Custom roles include your choice of fine-grained permissions. They can include access to account settings and (for organization custom roles) repository access, allowing you to provide teams with just the access they need to do their jobs. For example, you could allow a team to view your enterprise's audit logs without allowing them to change any settings.
+
+To follow the principle of least privilege access, we recommend using custom roles if they allow for the permissions you require. However, not all capabilities of predefined roles can currently be replicated in custom roles.
+
+## Who manages roles?
+
+Enterprise owners can create custom enterprise roles and assign enterprise roles to users and teams. They can also create custom organization roles to be used across organizations, but these roles can only be assigned by organization owners.
+
+Organization owners can grant organization roles and create custom organization roles, but cannot edit roles or change role assignments that are defined at the enterprise level.
 
 ## Next steps