1. Topics
  2. Istio Steering Committee

Istio Steering Committee

Liz Rice
 

Thank you everyone who’s putting such thought into this topic. I would like to get a discussion on this onto the TOC meeting agenda at a point where the SIG Contrib Strategy folks have had a chance to discuss and think through the issues (are we at that point yet?) and, since he made the original proposal, when Alexis is available. 



On Tue, 1 Sep 2020 at 22:29, Matt Farina <matt@...> wrote:
If a steering committee is recommended then the reasons for it need to be well documented and articulated. There are a lot of assumptions and they are not shared. That is ripe for miscommunications.

Governance is often a reflection of the people involved, the culture they have, and needs they run into. If I were looking at different projects at different points in their lifecycles with different target audiences, I would likely recommend different governance structures that suit them. The goal is to make them and their users successful.

A recommendation for one particular form of governance then gets quite prescriptive. If someone doesn't follow it because it doesn't suit their culture and needs, how will people look at them?

I would hope that the people who make any recommendations around forms of governance have a lot of experience working with them and within them. That gives the people standing among developers to even suggest the items. Those who don't have heavy experience with community governance handing forms of governance to those on projects will likely not be met well by developers.

I would suggest starting with cultural elements that we would like to see present in any form of governance. If these are part of a steering committee than we would need to articulate them in detail so we can teach people about them. Those cultural elements can likely be suggested to many forms of governance.

I'm also reminded that something like 99% of those who use a project never contribute or say anything. If a vocal element in the 1% gets to push their direction than it may have an impact on the 99% that we often don't think about. I've been taught to give everyone a chance to voice their opinions and not let a small loud subset dictate things. Letting vocal end users have an out-sized voice could easily do that. That's why I think it's healthy for project leaders to go out to users and talk with them. This way you can learn from many users... many of which are not vocal in the day to day.

- Matt Farina

On Tue, Sep 1, 2020, at 5:12 PM, alexis richardson wrote:
Correct, I think that model is overly prescriptive to recommend for every project. 

I'm proposing a pattern that can be instantiated in more than one way, depending on what the project team think it needs.  Your model below could be one way.



On Tue, 1 Sep 2020, 21:58 Matt Wilson, <msw@...> wrote:
On Tue, Sep  1, 2020 at 01:33 PM, alexis richardson wrote:
>
> Well, the nomenclature isn't completely new.  But I think the practices
> include novel parts eg end users having a say in overall direction.

End users having a say in overall direction isn't novel. To me, the
communities and ecosystems that are the most resilient and sustainable
mindfully include everyone in the evolution of the software, and of
the working structure of the community / ecosystem around it.

Perhaps you are suggesting is that end-users having a *binding vote*
in a fixed-Seat governing body, where formal voting happens most often
by convening the holders of those seats at an appointed time, at
which having 60% of the Seats shall constitute a quorum?

I don't think that's the kind of Steering Committee you are
proposing. But that kind of Steering Committee exists in the world,
with spotlights shining on it.

--msw
Josh Berkus
 

On 9/1/20 1:58 PM, Matt Wilson wrote:
Perhaps you are suggesting is that end-users having a *binding vote*
in a fixed-Seat governing body, where formal voting happens most often
by convening the holders of those seats at an appointed time, at
which having 60% of the Seats shall constitute a quorum?
This can actually be a great structure for a project with a small number
of vendors doing most of the technical work, but larger number of
users. The difficulty is recruiting users with a sufficient depth of
technical knowledge to have meaningful input, e.g. if the end-user SC
members don't really understand the API, they're not gonna spot a
breaking change.

The other problem is avoiding "captive" users. If a project's
leadership group contains only the staff of one vendor, and that
vendor's commercial users, then it's still a single-company project.
You'd need to have at least a few "freeware" users in there to mix
things up.

--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO
Matt Wilson
 

On Wed, Sep 2, 2020 at 09:22 AM, Josh Berkus wrote:

On 9/1/20 1:58 PM, Matt Wilson wrote:
Perhaps you are suggesting is that end-users having a *binding vote*
in a fixed-Seat governing body, where formal voting happens most often
by convening the holders of those seats at an appointed time, at
which having 60% of the Seats shall constitute a quorum?
This can actually be a great structure for a project with a small number
of vendors doing most of the technical work, but larger number of
users. The difficulty is recruiting users with a sufficient depth of
technical knowledge to have meaningful input, e.g. if the end-user SC
members don't really understand the API, they're not gonna spot a
breaking change.
I'm not personally aware of a good example of a strict quorum voting
structure that provided an empowering voice or an ability for people
who are not technically as deep. But I am definitely curious to learn
more about effective practices put in place by communities, keeping in
mind that effective practices for one group of humans may differ for
another. Is there one I should study more closely?

The other problem is avoiding "captive" users. If a project's
leadership group contains only the staff of one vendor, and that
vendor's commercial users, then it's still a single-company project.
You'd need to have at least a few "freeware" users in there to mix
things up.
This is one of the areas where I continue to struggle to understand
the concern. To me, open-source licenses make it difficult to hold
users/adopters "captive." When vendors make an attempt to do so, it
can result in others stepping up to create better, more "open"
conditions. Sometimes (historically, rarely) that means starting a new
community, since that is something that open-source licenses enable.

The voices of "freeware" users is an important and valuable. When it
comes to how a vendor invests their time, I think that paying
attention to paying customers is a natural thing to do. Paying
attention to non-paying customers can be a very important part of your
business, especially in growing your business. I do not think that a
vendor has an obligation to provide free services or development for
"freeware" users. Also, I do not think that there needs to be some
structural element to open-source governance recommendations, to
"ensure" that a project is being "open enough."

I think this is an interesting conversation, but it doesn't
necessarily get closer to resolving https://github.com/cncf/toc/issues/459.

I would like to make a suggestion: none of what I have seen proposed
can _guarantee_ that "the project is open to contributions regardless
of employer" as was summarized as the objective in
https://github.com/cncf/toc/issues/459#issuecomment-641550257.

It seems that what is being asking for is evidence, or perhaps
"proof", as embodied a project's documentation (as proposed with the
SC concept) or commit history (as it currently stands in the
graduation criteria), that they are open to contributions from
all. What matters far more to _me_ is what happens in cases where a
project is faced with disagreements, and how they are resolved
constructively and collaboratively. And it may be that a community has
never faced any material disagreement.

Rather than focusing on various tests and studying past events, I
would rather see the TOC and (only in the very rarest of
circumstances) GB be able to act as an ombudsman for those rare
significant disagreements that reach an impasse, because each
circumstance of disagreement is going to be unique and can require a
collection of facts before judgment.

--msw
Josh Berkus
 

On 9/2/20 2:49 PM, Matt Wilson wrote:
I think this is an interesting conversation, but it doesn't
necessarily get closer to resolving https://github.com/cncf/toc/issues/459.
Yeah, I would love to see more of the other discussion on the gov-wg ML.
Pick it up there?

I would like to make a suggestion: none of what I have seen proposed
can _guarantee_ that "the project is open to contributions regardless
of employer" as was summarized as the objective in
https://github.com/cncf/toc/issues/459#issuecomment-641550257.

It seems that what is being asking for is evidence, or perhaps
"proof", as embodied a project's documentation (as proposed with the
SC concept) or commit history (as it currently stands in the
graduation criteria), that they are open to contributions from
all. What matters far more to _me_ is what happens in cases where a
project is faced with disagreements, and how they are resolved
constructively and collaboratively. And it may be that a community has
never faced any material disagreement.
The "proof" is where it is. If there are people who are allowed to
merge code/docs for the project and work for multiple organizations,
that's probably the strongest proof we can obtain that contributions are
not limited by employer.

It is definitely true that there are other possible demonstrations of
openness to contributions. That's why I asked the TOC to rule on a
rationale; by making the *reason* paramout, SIGS/TOC are a position to
judge borderline cases. And if open source is good for anything, it's
creating borderline cases.

Rather than focusing on various tests and studying past events, I
would rather see the TOC and (only in the very rarest of
circumstances) GB be able to act as an ombudsman for those rare
significant disagreements that reach an impasse, because each
circumstance of disagreement is going to be unique and can require a
collection of facts before judgment.
...not quite sure what you're saying here, in practical terms.

--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO
41 - 44 of 44