matthew-update-innersource changed all references to Github to GitHub

content/innersource/codeowners-configuration.md

@@ -5,7 +5,7 @@ description: ""
 innersource: true
 hideToc: true
 ---
-For Github Code Owners is built in. See [About code owners](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) in the Github documentation for configuration details.
+For GitHub Code Owners is built in. See [About code owners](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) in the GitHub documentation for configuration details.
 
 For Bitbucket, follow the steps below in order to configure the CODEOWNERS plugin.
 

content/innersource/contribution-agreements.md

@@ -7,7 +7,7 @@ innersource: true
 
 Documentation known as the _Contributing Agreement_ which should be stored in the root of a repository or project subfolder in the case of a monorepo. Documentation should be provided in Markdown format.
 
-Both Bitbucket and Github have full support for rendering Markdown so it is easy for potential contributors to read and learn about the project.
+Both Bitbucket and GitHub have full support for rendering Markdown so it is easy for potential contributors to read and learn about the project.
 
 See [The Markdown Guide](https://www.markdownguide.org) for documentation.
 
@@ -40,7 +40,7 @@ The Contributing Agreement should be broken down as follows:
 
 **`README.md`** - provides a general description of the project, its intent and who the Trusted Committer(s) are for the project.
 
-This file is loaded by default when you open a repo in Bitbucket or Github. The `README.md` should link to the other InnerSource files for easy navigation.
+This file is loaded by default when you open a repo in Bitbucket or GitHub. The `README.md` should link to the other InnerSource files for easy navigation.
 
 A useful interactive tool for creating a readme can be found here - [https://www.makeareadme.com/](https://www.makeareadme.com/)
 

content/innersource/implementation-checklist.md

@@ -31,9 +31,9 @@ You can use this checklist to ensure that you complete all of the necessary step
 (see [Repository Configuration](./repository-configuration.md) for more in-depth details on this)
 
 - [ ] The repository description has a relevant description.
-- [ ] The repository has the trimble-innersource label for Bitbucket or the trimble-innersource topic in Github.
+- [ ] The repository has the trimble-innersource label for Bitbucket or the trimble-innersource topic in GitHub.
 - [ ] The repository has open read permissions for everyone.
-- [ ] For Bitbucket, the repository has write permissions so that anyone can submit a pull request, this is not required for Github.
+- [ ] For Bitbucket, the repository has write permissions so that anyone can submit a pull request, this is not required for GitHub.
 - [ ] The `main` and `develop` branches are protected so code cannot be committed without a Pull Request.
 - [ ] The repository should be configured to auto-unapprove Pull Requests when there is a new commit against the PR.
 

content/innersource/innersource-roles.md

@@ -48,7 +48,7 @@ The Trusted Committer role belongs to a person or persons who have been nominate
 
 6. Conduct code reviews with contributors according the code of conduct defined in the `CODE_OF_CONDUCT.md` file
 
-7. Participate and answer questions where appropriate (chat groups, Github discussions, Jira etc.)
+7. Participate and answer questions where appropriate (chat groups, GitHub discussions, Jira etc.)
 
 ## The Contributor Role
 

content/innersource/project-communication.md

@@ -7,7 +7,7 @@ innersource: true
 
 It is very important to set up a method of communication for existing contributors and people who want to contribute.
 
-Recommended would be either a Google Chat room or group or Github discussions.
+Recommended would be either a Google Chat room or group or GitHub discussions.
 
 ## Google Chat
 
@@ -21,9 +21,9 @@ To set up a Google Group, go to [Google Groups](https://groups.google.com/my-gro
 
 See [Google Chat Help](https://support.google.com/groups/answer/2464926?hl=en&ref_topic=2458761) for more details on using Google Groups
 
-## Github discussions
+## GitHub discussions
 
-Github discussions can be enabled from the repository settings screen if you have the appropriate permissions to do so. For more details see [Github discussions](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/enabling-or-disabling-github-discussions-for-a-repository)
+GitHub discussions can be enabled from the repository settings screen if you have the appropriate permissions to do so. For more details see [GitHub discussions](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/enabling-or-disabling-github-discussions-for-a-repository)
 
 ------
 

content/innersource/repository-configuration.md

@@ -8,26 +8,26 @@ hideToc: true
 
 Follow these guidelines to configure the repository for your project correctly to prepare it for InnerSource.
 
-- Code should be in a clearly named git repository in a project in an appropriate source control environment such as Bitbucket or Github.
+- Code should be in a clearly named git repository in a project in an appropriate source control environment such as Bitbucket or GitHub.
 
-- For BitBucket, the repository should have Write permissions enabled as without this Pull Requests cannot be created. You can configure permissions from the Repository Permissions screen. This is not needed to enable Pull Requests in Github.
+- For BitBucket, the repository should have Write permissions enabled as without this Pull Requests cannot be created. You can configure permissions from the Repository Permissions screen. This is not needed to enable Pull Requests in GitHub.
 
-- The description of the repository should illustrate what the project is about. The description can be set from the repository settings screen in Bitbucket or in Github in the Edit repository details dialog which can be accessed by clicking the cog in the About panel on the homepage for the repository.
+- The description of the repository should illustrate what the project is about. The description can be set from the repository settings screen in Bitbucket or in GitHub in the Edit repository details dialog which can be accessed by clicking the cog in the About panel on the homepage for the repository.
 
 - The repository should be a README.md file which contains the names and contact details for the Trusted Committer(s)
 
-- The `main` branch and, if applicable, the `develop` branch **MUST** be protected so code cannot be committed without a Pull Request. You can configure this from the Branch Permissions settings screen in Bitbucket or in Github you can set up branch protection rules from the repository settings screen in the Branches section under Code and automation.
+- The `main` branch and, if applicable, the `develop` branch **MUST** be protected so code cannot be committed without a Pull Request. You can configure this from the Branch Permissions settings screen in Bitbucket or in GitHub you can set up branch protection rules from the repository settings screen in the Branches section under Code and automation.
 
-- The repository should have the `trimble-innersource` label against it. Labels can be added at the bottom of the home screen for a BitBucket repository. In Github you can set this as a topic against the repository from the Edit repository details dialog.
+- The repository should have the `trimble-innersource` label against it. Labels can be added at the bottom of the home screen for a BitBucket repository. In GitHub you can set this as a topic against the repository from the Edit repository details dialog.
 
 - A default reviewer can also be configured for convenience. Default reviewers should always include a Trusted Committer. 
 
-    In Github you can configure default reviewers using a `CODEOWNERS` file in the repository. See [About code owners](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) in the Github documentation for configuration details.
+    In GitHub you can configure default reviewers using a `CODEOWNERS` file in the repository. See [About code owners](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) in the GitHub documentation for configuration details.
 
     You can also use `CODEOWNERS` files in Bitbucket with a plugin - see [configuring code owners](codeowners-configuration.md) for details.
 
 - Reviewers should always be asked to approve a Pull Request before being able to merge to develop or `main`. 
 
-    This can be configured from the auto-unapprove configuration screen in Bitbucket or for Github configure a branch protection rule to require a pull request before merging and check the option 'Dismiss stale pull request approvals when new commits are pushed'
+    This can be configured from the auto-unapprove configuration screen in Bitbucket or for GitHub configure a branch protection rule to require a pull request before merging and check the option 'Dismiss stale pull request approvals when new commits are pushed'