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 [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 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. --msw [1] https://github.com/cncf/toc/blob/master/PRINCIPLES.md#projects-are-self-governing
|
|