Starting the InnerSource initiative we needed a place to collect documentation as well as a place for operational coordination. We decided to dogfood suggested tooling and created a GitHub repository. Going forward, I will refer to it as gh#innersource here.
Before publicly discussing gh#innersource as a project, a certain amount of base documentation was being created. As a baseline this meant creating an initial README.md. This document serves as an entry point for newcomers to the project. It addresses not only future users but also features sections for future contributors and Trusted Committers. Most important this document needs to make clear what the project will be about, typically listed as the purpose or mission of the project.
In our case it also listed channels through which to reach the project. It indicated that questions could be asked through both, a company-wide slack channel with the same name as the GitHub project or the issue tracker in the GitHub project. In addition we added information on how to get involved, including brief instructions on how to fork the project and open pull requests. Besides the fact that there are official project channels that should be used for any communication related to the project, the README also included a list of Trusted Committers responsible for the project - essentially as a means of enabling others to put faces to names. Last but not least the README had a section for frequently asked questions so that common answers could be linked to instead of having to re-type them over and over.
Update: There now is an InnerSource pattern under review upstream that formalizes the information.
- Introduction to series
- Voting in new Trusted Committers … how do we find and activate new contributors and turn them into Trusted Committers
- Checklist for internal meetups … internal meetups should be as remote friendly as possible. What do we need for that?
- Issues - for brainstorming … issues not only as digital versions of sticky notes, but also for brainstorming
- Issues - for tracking work and asking questions … tracking work, asking questions, further use cases for issues
- Lazy consensus … avoid waiting endlessly by adopting lazy consensus for non-controversial changes
- Templates to drive standards … pilot recommendations locally, derive a template from the successful pilot, only then roll that pilot out as a standard to others
- External tools? … GitHub only? By far not - if appropriate switch to another tool, but link your content together for better findability. Careful: Search gets harder the more tools you introduce.