Organizations of all sizes and in all industries are chatting about InnerSource concepts. This course walks you through some of the key concepts of InnerSource and helps you build up an internal toolkit for adopting InnerSource practices.
Tags: none
Organizations of all sizes and in all industries are chatting about InnerSource concepts. This course walks you through some of the key concepts of InnerSource and helps you build up an internal toolkit for adopting InnerSource practices.
After completing this course, you'll be able to:
- Contrast user versus organization owned projects
- Create discoverable repositories
- Create robust repository READMEs
- Use issue and pull request templates
- Make sensible configuration decisions for repositories, like using protected branches and CODEOWNERS
- Build transparency into repositories through well documented branching strategies, project management techniques, and workflow best practices
- Prioritize what matters when measuring InnerSource and collaboration
- Distribute your InnerSource toolkit
You'll be able to answer questions like:
- What is the difference between InnerSource and open source?
- How can my organization create repositories to organize work?
- How should my organization handle bug reports?
- How should I document my workflows to share with my team members?
- How do I measure success in my projects?
As we work, we'll create a resource that others can use within your organization. This repository will be useful even after you finish this course.
We assume in this course you understand GitHub terminology and concepts. If you need help with this, take our Introduction to GitHub. You'll also want a working understanding of GitHub Pages. We have a course on GitHub Pages as well. Finally, it helps if you have prior experience working on team project.
For this course we'll use GitHub Pages and Jekyll.
This is the best course for someone working at a company or organization that already works InnerSource. Or for a company or organization that is transitioning to InnerSource. This would be a great course for a technical leader interested in bringing transformation to their workflows.
Most of the ideas here work for all repositories on GitHub. This course has some content specific to working within an organization. If you are an open-source maintainer or contributor, this course has content that would be useful.
This repository will be a working website that you can publish as your own InnerSource landing page.
As we work, we'll create a resource that others can use within your organization. This repository will be useful even after you finish this course.
This is how this course will move along:
- Every new issue or pull request will start with a challenge question
- You'll answer the challenge question (don't worry, there are no right or wrong answers!)
- The question will highlight the importance of each topic in InnerSource practices
Here's your first challenge question!
InnerSource and open source are the same thing.
- True
- False
This pull request is about repository ownership and naming conventions.
Does a repository exist at https://github.com/githubtraining/training-manual?
- True, there is a repository at the given URL
- False, no repository exists at the given URL
InnerSource and open source are very similar concepts, but they're not the same.
Open source software is public and typically accepts contributions from outside of an organization.
InnerSource is the practice of adopting open source patterns internally within your organization. An organization that practices InnerSource may or may not also maintain open source software.
You can find your next steps in the next pull request.
A repository does exist at githubtraining/training-manual, but it is private.
Why can't you see it then? Review the Files Changed tab and see if you can figure it out. Expand this text if you'd like an explanation.
There are three types of repository visibility: public, internal, and private.
Our repository, githubtraining/training-manual, isn't public. It could be internal, which means only members of the organizations that an account owns will see it. Or, it could be private, which means only teams and individuals that have been granted access to it can see it.
This is an example of why ownership structure is important. Otherwise, it can be difficult for members of your team to find and contribute to projects. Having too many disconnected organizations with restrictive permissions isolates each organization's work.
Here are some recommendations based on some ✨ admirable ✨ use of GitHub that we've seen:
- Use the internal visibility (currently in beta) if you're working on behalf of an enterprise account.
- Name your repositories meaningfully. Usually a simple project or application name is best.
- Read the additions in the
Files changedtab - Approve this pull request (if needed)
- Merge this pull request
- Delete the branch
This pull request is about making repositories discoverable.
What is this repository for?
You can find your next steps in your [next pull request]({{ url }}).
This repository is the source code for https://services.github.com.
Did you guess it? Probably not, because it doesn't contain many of the necessary elements to make a repository discoverable.
Some suggestions to ensure your teammates can find your repository are:
- Use a descriptive repository name
- Give your repository a description
- Provide a URL for the deployment of the app, or documentation about this project
Discover more about how to make a repository discoverable by visiting the Files Changed tab. It's OK if you want to do this later, any resources we cover throughout the course will be available at the end.
- Review the additions about discoverability in the
Files changedtab - Approve this pull request (if needed)
- Merge this pull request
- Delete the branch
Let's now learn about issue and pull request templates.
Here are four different ways you could submit a bug report. Which is the right way?
- Open an issue on GitHub
- Create a Jira issue
- Open an internal support ticket
- Direct message or email the maintainer
You can find your next steps in your [next pull request]({{ url }}).
Every project can have a different way to submit bug reports, so all the answers are right.
But, how could you know? With issue and pull request templates, you can take the mystery out of the equation. Templates show those across the organization the preferred way to contribute.
- Review the examples and types of template files in the
Files changedtab - Approve this pull request (if needed)
- Merge this pull request
- Delete the branch
This pull request covers a few common workflows that may be used within your organization.
Suppose you'd like to contribute to the repository pictured below. Which branch should you use as a base for your contributions?
-
main -
release-v1.0 -
bug-fix -
green-colors -
config-release-drafter
You can find your next steps in your [next pull request]({{ url }}).
The real answer is that, without documentation, we don't know!
This pull request covers the basics, but here are some recommendations to help any contributor know the right way to open pull requests:
- Use protected branches. Doing so will allow you to accept pull requests without fear of breaking production code.
- Use
CODEOWNERSin combination with protected branches to ensure the right people review changes. - If you haven't picked a workflow, use a common and well documented one.
- Be explicit about your deployment and release strategy.
- Review the changes in the
Files changedtab - Approve this pull request (if needed)
- Merge this pull request
- Delete the branch
It's time to discuss project management!
Here's some open issues in this company project. You're eager to help with this project. Which issue should you work on?
- Issue 6: Restyle the slides
- Issue 5: Improve the README
- Issue 4: Add a caption to an existing slide
- Issue 3: Add a new slide
- Issue 2: Activity 1: Your first caption
You can find your next steps in your [next pull request]({{ url }}).
Without a clear project management strategy, you might as well pick any issue.
Being explicit about your project management tool will help potential contributors. Whether it's inside of GitHub or elsewhere, communicate so they know whether their help is immediately helpful.
- Review the changes in the
Files changedtab - Approve this pull request (if needed)
- Merge this pull request
- Delete the branch
Once you've implemented InnerSource strategies, how do you know it's working?
What might be some ways to measure the success of InnerSource strategies?
You can find your next steps in your [next pull request]({{ url }}).
Those are great ideas!
Here are some other ideas for measuring how well you're doing:
- Time to market
- Pull requests to fix bugs
- Pull requests to add suggested features
- Number of collaborators to a project outside of maintaining team
- Review the changes in the
Files changedtab - Approve this pull request (if needed)
- Merge this pull request
- Delete the branch
It's time to publish the InnerSource toolkit you've been working on.
To publish:
- Go to the Settings tab for this repository
- Scroll down to the section titled GitHub Pages
- Select main branch in the Source drop down
That's all! GitHub Pages will then deploy your site and report its status back to me.
You can find your next steps in your [next pull request]({{ url }}).
You finished this course. You can see a deployed version of our work together at [your new GitHub Pages site]({{ deploymentURL }}). Feel free to share this link directly with others, or you can save the resources in one of the following ways.
- If you'd like to just save the contents to your machine, you can:
- Use this shortcut link to [download the files]({{ downloadURL }})
- Download the files by clicking on the Code tab, clicking on Clone or download and clicking Download ZIP
- Clone the repository to your machine
- If you'd like to transfer the repository to an organization on GitHub:
- If your organization is on GitHub.com, [fork it]({{ forkURL }})
- If your organization is on GitHub Enterprise Server, transfer the repository
I won't track any further events in this repository.
Your next steps are in the Innersource learning path.