- Istio Steering Committee
Re: Istio Steering Committee
Jaice Singer DuMars
toggle quoted messageShow quoted text
I am glad to see the discussion started. I've done a lot of governance work on various projects and am happy to help in any way I can.
On Tue, Aug 25, 2020 at 9:08 AM alexis richardson <alexis@...> wrote:
Good points Matt. Helm is well run and provides a useful model of one successful pattern.
I don't think there is one true governance rule for who is on the SC. IMHO it is critical to include non code maintainers, focus on people who have a real stake in success of projects and community, and avoid creating bureaucracy. Asking maintainers "how could an SC help?" is a good starting point in regard to the latter point.
On Tue, 25 Aug 2020, 16:45 Matt Farina, <matt@...
The Helm project has a similar model in its governance. There is a separation between Org Maintainers and Project Maintainers. The Org Maintainers are responsible for the project but not the technical decisions. The Project Maintainers own the code. The Helm Org Maintainers have restrictions that no one company/organization can have a majority of the members. That means you'll have at least 3 organizations represented. Currently, there are 7 companies represented.
One of the things that catches my attention about the Istio model is a matter of who decides which vendors to include. In the case of Istio it's Google. Who would even make these types of decisions for CNCF projects and have them work well for the people who maintain the code of those projects?
On Tue, Aug 25, 2020, at 11:11 AM, Jimmy Song wrote:
I think it's good for both vendors and end users.
On Aug 25, 2020, at 10:05 PM, Joe Beda <jbeda@...
It is great to see a model that limits the influence of a single vendor. The explicit split between coding and non-coding contributions is.. interesting.
One big difference worth calling out is the fact that the Istio model looks to have all credit for contributions accrue to companies, not individuals. This means that the community is defined by the vendors, not the contributors. If someone leaves a job they, by definition, will have to give up their position on the SC (if I’m reading it correctly).
Looking at similar projects and different models (k8s) this will probably lead to a different quality of community vs. those that put people and project above vendors (“Community over product or company” is a k8s value
I saw this news and wanted to highlight it. With kubecon behind us and apparently summer too, perhaps we can revisit the Steering Committee thread.
Istio is highlighting some benefits of an SC model
1. Applies across whole 'broad' project not just repo level
2. Encourages diversity via non coding SC members, eg as Dan says you can also write .md files
3. Focus on overall direction on behalf of end users and community (avoiding the open core problems we see in other cases)
I think we should arrange for a TOC session to discuss SCs.
Join email@example.com to automatically receive all group messages.