Re: Istio Steering Committee
On Tue, Sep 1, 2020 at 01:50 AM, alexis richardson wrote:
Understood. I'm scattering comments all around, and zooming back out
makes sense to re-focus the thread toward a goal.
At this point, I am just really keen to hear from teams and associatedWhen I review a lot of the framing material for CNCF, it resonates
well with me. Like the principles of self-governing projects  and
"minimum viable governance." With guiding principles, there is often
ambiguity. I've seen in many cases ambiguity causes a sense of
confusion and unease, and guiding principles are translated into
evaluative criteria to add comfort and safety.
I made an analogy during the CNCF SIG Contributor Strategy meeting
today: to me, it's like promotion criteria that is commonly found at
larger companies. In my experience, some corporate career ladders are
set up in ways that have some ambiguity to provide multiple paths to a
promotion. Both managers and employees sometimes ask, "can I have a
specific example of a work project, and generally quantifiable
evidence, that when completed will assure me a promotion?"
In the current incubation and graduation process, people associated
with the projects are bound to ask, "why aren't we getting promoted?
Just tell me what I have to do to graduate, and we'll do it. But we
_need_ to graduate."
I'm worried that we've lost sight of some of the "ends", eg goodMy intuition is that you're right.
The SC model is really intended as ONE way to help. I like it becauseI worry that recommending a "Steering Committee" will be confusing,
especially because it is not a well-established set of practices that
are based in commonly held governance philosophies. It is a shorthand,
and a proxy, for something that gives us short term comfort, without
empirical evidence that implementing such a committee results in the
"ends" that we (in a broader community use of the word) want to
encourage. It might even be used for optical purposes to give an
appearance of openness, when in fact the rules are constructed to
favor particular players in competitive spaces.
So, I think that multiple things are true at once:
* the "Have committers from at least two organizations." requirement
for graduation may constrain the ways that projects evolve over
time, and act as an unnecessary barrier and bureaucratic requirement
that will slow them down, rather than help build a sustainable
project and diverse ecosystem around it
* finding ways to encourage that people in non-coding roles be
recognized as peers that are committed to a project's mission /
charter, and be able to take on responsibilities of leadership, is a
valuable time investment for the SIG
* using the term "Steering Committee" for this effort may cause
confusion, especially if there is a recommended structure and
practices that are not well understood and adopted across multiple
open-source projects and collaborative community settings.