On Tue, Sep 1, 2020 at 01:50 AM, alexis richardson wrote:

Thanks for all those thoughts Matt and for reviewing the steering
committee proposal and GH issue
https://github.com/cncf/toc/issues/459. I'm going to topline you here
for brevity but LMK if you would like a detailed response on any
point.

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 associated
ISVs like Nats & Synadia, Linkerd & Buoyant, Crossplane & Upbound,
etc. Ultimately my motivation in helping CNCF get started, putting in
time on the TOC and our Principles, is to get to a place where users
benefit from a family of projects that are truly sustainable and
useful, and where innovation is based on a fair and level playing
field for many different ways to make projects succeed.

When I review a lot of the framing material for CNCF, it resonates
well with me. Like the principles of self-governing projects [1] 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 good
projects, and are becoming fixed on "means", eg how maintainers are
employed. Let's hear more from people on the challenges they are
seeing here.

My intuition is that you're right.

The SC model is really intended as ONE way to help. I like it because
it promotes participation from non-coding roles alongside coding
maintainers, and focuses on healthy outcomes.

I 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.

--msw

[1] https://github.com/cncf/toc/blob/master/PRINCIPLES.md#projects-are-self-governing