Additions to the Standard Base Documentation pattern

The information below might make for great additions to the Standard Base Documentation pattern.

I believe what I mean by setup is not only the who makes changes - but also how. Often in projects that are maintained locally in a single team there are many unwritten rules. When moving beyond the boundaries of a single team what I found helps a great deal is making these unwritten rules explicit. Things like

• who has to review
• how long should it be expected to take until a first pull request feedback
• who should approve, and how many Trusted Committers
• what coding guidelines should we follow
• what makes for valid concerns for rejecting pull requests or delaying them

... essentially all of the things that can lead to friction if left implicit (those can differ from team to team and from org to org).

Originally posted by @MaineC in https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/321#r634389124