Merge pull request #28 from xebia/7.2-Describe-how-to-apply-the-benefits-of-open-source

7.2 describe how to apply the benefits of open source

Author: Chukslord1

learn-pr/github/manage-innersource-program-github/2-manage-innersource-program.yml

@@ -3,7 +3,7 @@ uid: learn.github.manage-innersource-program-github.2-manage-innersource-program
 title: How to manage a successful InnerSource program
 metadata:
   title: How to manage a successful InnerSource program
-  description: Learn to manage a successful InnerSource program on GitHub through effective discoverability, guidance, and maintenance.
+  description: Learn to manage a successful InnerSource program on GitHub through discoverability, guidance, repository setup, and collaboration best practices.
   ms.date: 09/19/2024
   author: a-a-ron
   ms.author: aastewar

learn-pr/github/manage-innersource-program-github/3-innersource-fundamentals.yml

@@ -3,7 +3,7 @@ uid: learn.github.manage-innersource-program-github.3-innersource-fundamentals
 title:  Exercise - InnerSource fundamentals
 metadata:
   title:  Exercise - InnerSource fundamentals
-  description: Learn to manage a successful InnerSource program on GitHub through effective discoverability, guidance, and maintenance.
+  description: Use checklists to evaluate your InnerSource readiness and improve your GitHub repositories through practical repository and team-based actions.
   ms.date: 09/19/2024
   author: a-a-ron
   ms.author: aastewar

learn-pr/github/manage-innersource-program-github/5-summary.yml

@@ -3,7 +3,7 @@ uid: learn.github.manage-innersource-program-github.5-summary
 title: Summary
 metadata:
   title: Summary
-  description: Review what you learned about InnerSource programs.
+  description: Review key practices for managing an InnerSource program using GitHub, including transparency, repository management, and collaboration.
   ms.date: 09/19/2024
   author: a-a-ron
   ms.author: aastewar

learn-pr/github/manage-innersource-program-github/includes/2-manage-innersource-program.md

@@ -10,13 +10,16 @@ Anyone can freely use, modify, and share open-source software. Using open-source
 
 An InnerSource program can offer numerous benefits beyond what traditional closed-source models provide.
 
-First, they *encourage transparency*. Access to the source code of other company projects can help developers be more productive when working on their own projects. They can see how different teams solve problems similar to the ones they're facing, and often find code and other assets that they can reuse. Access to team issues, pull requests, and project plans also provide better data for them to understand the velocity and direction of the project.
+First, they *support internal visibility*. Access to the source code of other company projects can help developers be more productive when working on their own projects. They can see how different teams solve problems similar to the ones they're facing, and often find code and other assets that they can reuse. Access to team issues, pull requests, and project plans also provide better data for them to understand the velocity and direction of the project.
 
-Next, they *reduce friction*. Let's say that a consumer team is dependent on a bug fix or new feature for a project owned by a different team. IN an InnerSource program, they have a channel through which they can propose the changes they need. And if those changes can't be merged in for any reason, the consumer team has the option of forking the project to meet their needs.
+Next, they *reduce friction*. Let's say that a consumer team is dependent on a bug fix or new feature for a project owned by a different team. In an InnerSource program, they have a channel through which they can propose the changes they need. And if those changes can't be merged in for any reason, the consumer team has the option of forking the project to meet their needs.
 
 Finally, they *standardize practices*. A common challenge development organizations face is that different teams often diverge in the ways they operate. Building an InnerSource program is a great opportunity to adopt standard conventions that can be used across every development team, even if they don't follow identical practices. For example, two teams might prefer different processes for accepting contributions. Having them standardize on the way they communicate their different processes makes it much easier for anyone to contribute to either.
 
-These examples are just a few of the benefits enjoyed by InnerSource programs. To learn more, see [An introduction to InnerSource](https://resources.github.com/whitepapers/introduction-to-innersource/?azure-portal=true).
+> [!TIP]
+> Consider using GitHub Discussions and GitHub Projects to further support InnerSource collaboration across teams.
+
+These examples are just a few of the benefits enjoyed by InnerSource programs. To learn more, see [An introduction to InnerSource](https://resources.github.com/whitepapers/introduction-to-innersource/).
 
 ## Set up an InnerSource program on GitHub
 
@@ -25,7 +28,11 @@ These examples are just a few of the benefits enjoyed by InnerSource programs. T
 You can configure GitHub repositories with three levels of visibility. Users who don't meet the visibility requirement see "not found" pages when they try to access your repository. The levels are:
 
 - **Public** repositories are visible to everyone. Use this visibility for projects that are truly open source and offer access to people inside and outside of your organization.
-- **Internal** repositories are only visible to members of the organization that owns them. Use this visibility for InnerSource projects.
+- **Internal** repositories are only visible to members of the enterprise that owns them.
+
+> [!NOTE]  
+> Internal repositories are only available to GitHub Enterprise customers. Use this visibility for InnerSource projects.
+
 - **Private** repositories are only visible to the owner and any teams or individuals they add. Use this visibility for projects that only specific users and groups should have access to.
 
 Once you establish repository visibility, you can configure permissions on an individual or team basis. There are five permission levels:
@@ -36,7 +43,7 @@ Once you establish repository visibility, you can configure permissions on an in
 - **Maintain** level is recommended for project managers who need to manage the repository without access to sensitive or destructive actions.
 - **Admin** level is recommended for people who need full access to the project, including sensitive and destructive actions like managing security or deleting a repository.
 
-Learn more about [repository access permissions by level](https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization?azure-portal=true).
+Learn more about [repository access permissions by level](https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization).
 
 ### Create discoverable repositories
 

learn-pr/github/manage-innersource-program-github/includes/3-innersource-fundamentals.md

@@ -7,7 +7,14 @@ The following guide provides you with a getting started and expanded checklist o
 - Project
 - Developers
 
-Using the provided checklists, pick one of these categories and compare the list of items to one of your existing repositories. If you're focusing on the repository itself, what files do you need to add or remove to add clarity around its purpose? How do you contribute to the repository or open up issues?
+Using the provided checklists, choose one category and compare it to one of your current repositories. For example, if you're focusing on the repository itself, which files should be added or removed to clarify its purpose and contribution process?
+
+**Example checklist – Repository:**
+- [ ] Add or update `README.md`
+- [ ] Include `LICENSE`
+- [ ] Provide a clear contribution guide (`CONTRIBUTING.md`)
+- [ ] Set repository visibility (public/internal/private)
+- [ ] Include issue and pull request templates
 
 After reading through the guide and identifying ways to improve your own GitHub repositories, return here for:
 

learn-pr/github/manage-innersource-program-github/includes/5-summary.md

@@ -1,17 +1,19 @@
-In this module, you learned how to manage a successful InnerSource program on GitHub through effective discoverability, guidance, and maintenance.
+In this module, you explored how to build and manage a successful InnerSource program on GitHub through effective discoverability, guidance, and maintenance.
 
 You learned about:
 
 - Contrasting user owned projects versus organization owned projects.
 - Making recommendations about the number of GitHub organizations you should have.
 - Creating discoverable repositories.
 - Creating robust repository READMEs.
-- Using templates for issue requests and pull requests.
+- Using templates for issues and pull requests.
 - Building transparency into repositories.
 - Measuring the success of InnerSource within your organization.
 - Distributing your InnerSource toolkit.
 
-Now that you have an InnerSource program together, learn to [Create an open-source program by using GitHub best practices](/training/modules/create-open-source-program-github/?azure-portal=true).
+Apply these practices to your team projects to strengthen your InnerSource approach.
+
+Now that you have an InnerSource program together, learn to [Create an open-source program by using GitHub best practices](/training/modules/create-open-source-program-github).
 
 ## Learn more