Imagine the following situation: You’ve seen a certain discussion pop up multiple times and would like to draw the lessons learned together - but in a way that leaves space for others to provide their knowledge and experience.
One setup that turned out to be effective for this type of situation in gh#innersource was the following workflow:
- Open an issue, post the problem statement at the very top and invite people to discuss steps towards a solution of the stated problem. Those steps can be based on prior lessons learned, general best practices or personal experience.
- After the discussion has moved forward and people have a common understanding one volunteer will summarize what has been discussed and accepted as valuable to share with others as a set of recommendations.
- The resulting document gets posted as a pull request. After that time is left for other participants to refine the document in pull request review comments and suggestions.
- As soon as people affected by the decisions made in the document are in line the pull request is merged.
- Going forward the decision can be refined again with subsequent pull requests.
Caveat: Often those affected by the change will need to be notified explicitly for as long as this approach is still new or in instances where company structures shift.
This approach is a very simplified approach for making decisions in an asynchronous way. It’s in part inspired by how The Apache Software Foundation works, in part inspired by the Open Decision Making Framework, in particular the exercise for making transparent decisions in the Open Organisation workbook.
- 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?
- Checklist for base documentation … which base documentation should we think about when starting a project?
- 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.