New Governance Models for Different Team Sizes

[riverma]

Purpose

• SLIM already has a default governance model recommendation here but it needs some rework for prime time.
• In this PR, we are proposing two new governance models, one for medium and one for smaller sized teams to have a total of three governance model recommendations. We'd also like more community input on best practice governance approaches.

Proposed Changes

• [ADD] Small and medium sized team governance models
• [CHANGE] Renamed the role "collaborators" to "committers"

Issues

• [Improve Existing Best Practice Guide]: Governance Model for Small Teams #138

Testing

• See a live demo here: https://riverma.github.io/slim/docs/guides/governance/governance-model/

[riverma]

NOTE: I'd like to propose (after merging this) to apply the new "Medium Size Team" template (sample here) to the SLIM Governance Model, which would mean combining the SLIM TSC and PSC.

[riverma]

Some feedback received so far:

• How do the roles defined get mapped to GitHub Teams? Should we offer guidance or automation there?
• Maybe three tiers of governance is too much, can we get away with just two? i.e. large and small projects?

[jpl-jengelke]

Some feedback received so far:

• How do the roles defined get mapped to GitHub Teams? Should we offer guidance or automation there?
• Maybe three tiers of governance is too much, can we get away with just two? i.e. large and small (move medium to small?) projects?

I feel we should do large and small and skip over medium. Someone can integrate parts of large if they want to extend the small group model.

On that note, I think all SLIM example repos should default to the small model.

[jpl-jengelke]

Approved with the proviso that we should limit the models to two -- medium (renamed small) and large.

[PaulMRamirez]

Consider adding a diagram of a suggest path to merit. Apache Software Foundation has such an example https://training.apache.org/presentations/comdev/apache-intro/#/path-of-merit.

Another consideration is at times for medium or large teams a project could chose a governance where the path to merit is sped up by having Committers automatically put onto the Steering Committee. This is just an option and a decision to be made by those that adopt one of these governance models.

[thomas-bc]

A comment that I made internally (see Slack thread) about the following:

Any contributor who has made a non-trivial contribution should be on-boarded as a committer in a timely manner.

Some open-source projects might be very touchy about allowing write permissions to external contributors. Branch protection and permissions can be set in place to alleviate some concerns, but there's always a non-zero risk. For example, through allowing arbitrary commits on the main repo's branches, one could be concerned about this indirectly allowing external contributors to execute arbitrary code on self-hosted GitHub Action runners, if the repo has any.

@riverma suggested this new phrasing, which I personally really like:

Any contributor who has made a non-trivial contribution should be considered as a candidate for the committer role by the steering committee or the product manager.

[riverma]

Thank you for your review @thomas-bc and your suggestions! Will incorporate the new phrasing 👍

[riverma]

Consider adding a diagram of a suggest path to merit. Apache Software Foundation has such an example https://training.apache.org/presentations/comdev/apache-intro/#/path-of-merit.

Another consideration is at times for medium or large teams a project could chose a governance where the path to merit is sped up by having Committers automatically put onto the Steering Committee. This is just an option and a decision to be made by those that adopt one of these governance models.

💯 that @PaulMRamirez - great suggestion for adding a visual. I'll incorporate that.

[riverma]

Re-opening this PR as work has not finished.

[riverma]

Closing in place of: #170