Create governance-based-project-setup.md
As discussed in Slack previously this adds a new pattern to link our Governance Levels with information on what pre-requisits need to be fulfilled to reach the respective governance level.
The pattern looks at several factors:
- Knowledge needed by contributors and host team.
- General advise on project structure.
- Maturity levels that need to be reached.
- Relevant patterns.
This pattern resonates. So from an atomic and or reductionist view it makes sense to stand on it's own. It is useful on it's own and many groups would or could benefit.
I also see stretch opportunities (taking a step back to an integrated or holistic view) with patterns that I/we (from Dojo Center) have proposed and that are in draft.
- #696 Circle Communities
- #695 Agile InnerSource Dojo
Stretch conversations can look orthogonal so I don't mean to necessarily unpack any intersection opportunities here.
Given a future professional opportunity as an influencer, director or coach I would consider leveraging the patterns above together.
TL/DR Very supportive and appreciative
I fully agree that we need another pattern with a more holistic view to go along with this one.
Thanks for your feedback, glad you find it helpful.
Thanks for the initial review @spier - really appreciate the input on this one.
@spier I believe I addressed your comments. Is there anything left to change before this can be merged?
@MaineC I have finally had time to fully digest your pattern here.
Thanks so much for taking that time! (And: Happy New Year!)
Only now I have actually understood what the pattern is trying to do, I think :) I have added some explanations at the beginning of the Solution section, describing my understanding if your approach.
What you added sounds correct!
I did wonder shortly if the content of this pattern could be merged into the "Governance Levels" pattern itself. Not sure about the pros-cons of this yet.
The reason I didn't do that is the length of the patterns: I wanted to keep Governance Levels very brief and concise so it's easy to read and understand. Also I wanted to keep focus there on the business decision itself without clouding the discussion with implementation details.
However as this PR has been sitting idle here for so long already, I suggest to get this merged in our repo, and decide at a later point how we want to proceed with this. Having this fully integrated into our repo will make it easier to get more eyeballs by other readers on it.
Sounds reasonable to me. :)
Thank you for documenting your practical InnerSource experiences, and sharing these with us! And sorry that this review took so long
No worries - glad to see this pattern making progress.