matthew-update-innersource - added relevant information for Github users

content/innersource/codeowners-configuration.md

@@ -5,8 +5,9 @@ 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.
 
-Follow the steps below in order to configure the CODEOWNERS plugin:
+For Bitbucket, follow the steps below in order to configure the CODEOWNERS plugin.
 
 - Add a `CODEOWNERS` file in the root of your repository.
 

content/innersource/contribution-agreements.md

@@ -5,9 +5,9 @@ description: ""
 innersource: true
 ---
 
-Documentation known as the _Contributing Agreement_ which should be stored in the root of a repository or project in the case of a monorepo. Documentation should be provided in Markdown format.
+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.
 
-Bitbucket has full support for rendering Markdown into rich text format 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,13 +40,13 @@ 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. 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/)
 
 Numerous examples of `README.md` files can be found on GitHub.
 
-The `README.md` should also include details of the location and how to access the discussion forum as well as the relevant Jira project details.
+The `README.md` should also include details of the location and how to access any relevant discussion forum or chat group, as well as the relevant Jira project details if using Atlassian Tools to manage the project.
 
 **`GETTINGSTARTED.md`** - This could be optionally included to provide additional information which might not be needed in the general `README.md` for example a more detailed checklist of information which a contributor needs to know in order to provide a useful contribution - technical details of how the project is structured, how to run tests etc.
 

content/innersource/implementation-checklist.md

@@ -28,14 +28,14 @@ You can use this checklist to ensure that you complete all of the necessary step
 
 ## Repository Configuration
 
-(see [Repository Configuration](./repository-configuration.md))
+(see [Repository Configuration](./repository-configuration.md) for more in-depth details on this)
 
-- [ ] The repository description has a short description including the owner details.
-- [ ] The repository has the trimble-innersource label.
+- [ ] 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 open read permissions for everyone.
-- [ ] The repository has write permissions so that anyone can submit a pull request.
+- [ ] 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 auto-unapprove setting for the repository is set to ‘On’.
+- [ ] The repository should be configured to auto-unapprove Pull Requests when there is a new commit against the PR.
 
 ## Contribution Agreements
 
@@ -49,7 +49,7 @@ You can use this checklist to ensure that you complete all of the necessary step
 
 (see [Project Tracking](./project-tracking.md) and [Project Communication](./project-communication.md))
 
-- [ ] An epic has been created within a Jira project related to this repository to be used to track issues. The epic should have the label trimble-innersource.
+- [ ] An epic has been created within a Jira project or equivalent Issue Manager related to this repository to be used to track issues. The epic should have the label trimble-innersource.
 - [ ] Details of the epic and how to log issues and feature request are included in the `CONTRIBUTING.md`.
 - [ ] A communication channel is established that allows contributors and consumers to contact the owners (e.g. Google Chat group or email group). This is detailed in the `README.md`.
 

content/innersource/innersource-roles.md

@@ -14,7 +14,7 @@ The Owner is the person that has overall ownership of the project and who can ap
 
 ### Expectations of Owner
 
-- Works with the Architecture Review Board to ensure that this project's architecture direction is in line with the overall strategy and doesn't duplicate functionality available elsewhere
+- Works with the relevant project stakeholders to ensure that this project's architecture direction is in line with the overall strategy and doesn't duplicate functionality available elsewhere
 - Ensures that the InnerSource guidelines are applied to the project correctly.
 - Provides high-level business requirements and works with product owners, if relevant for this project, to ensure these requirements meet expected business outcomes.
 - Demonstrate excellent judgment, teamwork and ability to uphold development principles.
@@ -42,13 +42,13 @@ The Trusted Committer role belongs to a person or persons who have been nominate
 
 3. Keep the relevant documentation up to date
 
-4. Keep feature request and bug reports up to date in Jira.
+4. Keep feature request and bug reports up to date in Jira or equivalent issue manager.
 
 5. Communicate with contributors setting realistic expectations for timescales for review of Pull Requests
 
 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, Jira etc.)
+7. Participate and answer questions where appropriate (chat groups, Github discussions, Jira etc.)
 
 ## The Contributor Role
 

content/innersource/introduction.md

@@ -39,7 +39,7 @@ You can find the detailed guidelines on implementing the various aspects of Inne
 
 5. Set up a method of communication for existing contributors, consumers and people who want to contribute. Follow the guidance on [project communication](/innersource/project-communication/).
 
-6. Setup a project tracking to allow people to report and track issues/suggestions for your project. Follow the guidance on [project tracking](/innersource/project-tracking/).
+6. Setup a method of project tracking to allow people to report and track issues/suggestions for your project. Follow the guidance on [project tracking](/innersource/project-tracking/).
 
 Remember to check out the [implementation checklist](/innersource/implementation-checklist/) for more detailed steps and the rest of this section for more specific detail on the different InnerSource concepts.
 

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 Google group.
+Recommended would be either a Google Chat room or group or Github discussions.
 
 ## Google Chat
 
@@ -21,6 +21,10 @@ 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 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)
+
 ------
 
 Remember to publish details about how to join a chat or group in the `README.md` for your project.

content/innersource/project-tracking.md

@@ -7,7 +7,7 @@ innersource: true
 
 ## Guidelines for Project Owner
 
-The owner should create an **_Epic_** on a Jira project related to this with a label **trimble-innersource**. This Epic will be used to create tasks when someone finds any issues in this project or has improvement suggestions.
+The owner should create an **_Epic_** on a Jira project or equivalent issue management system with a label **trimble-innersource**. This Epic will be used to create tasks when someone finds any issues in this project or has improvement suggestions.
 
 ## Guidelines for Issue Reporters
 

content/innersource/publish-documentation.md

@@ -8,8 +8,6 @@ hideToc: true
 
 Opening up a project to InnerSource is one thing, but it is equally important to get users to adopt and contribute to it. It is therefore highly advisable that you have a way of publishing the project and making the InnerSource documentation available.
 
-Trimble maintains a list of projects which have been InnerSourced across the company. You can find the current list on the [Engineering @ Trimble website](https://sites.google.com/trimble.com/engineering/how-we-develop/innersource-shared-components).
-
 If you would like to have your InnerSource project included here then please contact {{< cloak-email address="matthew_dexter@trimble.com" display="Matthew Dexter" >}}.
 
 There are a couple of ways in which you can publish the documentation itself.

content/innersource/repository-configuration.md

@@ -8,18 +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 repository in an appropriate project.
+- Code should be in a clearly named git repository in a project in an appropriate source control environment such as Bitbucket or Github.
 
-- The repository should have Write permissions enabled as without this Pull Requests cannot be created. You can configure permissions from the Repository Permissions screen.
+- 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 include what the project is about and the contact details for the Trusted Committer(s). The description can be set from the repository settings screen.
+- 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 `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.
+- The repository should be a README.md file which contains the names and contact details for the Trusted Committer(s)
 
-- 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.
+- 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.
 
-- A default reviewer can also be configured for convenience. Default reviewers should always include the Trusted Committer.
+- 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.
+
+    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'
 
-- 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.
 
-Active Pull Requests against a project can be managed in BitBucket from the dashboard by clicking on the ![icon](/img/innersource/pull-request.png) icon on the left-hand side.