Re: Proposal for a new "Steering Committee Charter"
Josh Berkus
As promised, we had an in-depth discussion of the Steering Committee
proposal drafted by Alexis Richardson for the July 7th TOC meeting during the Governance WG meeting. Six members were present and participated in the discussion; notes are available here: https://docs.google.com/document/d/e/2PACX-1vSfiN1PRL3dH_ohfAs1lYvNWaBpAdvAI-9OQZYYIx8ahgy6230_oRbqljl6dUiGf5hTVJiferJgBmSX/pub Assessment: Regarding the specific proposal of using steering committees (SC) as a workaround for the requirement to have maintainers from multiple organizations for projects to move to the Graduated level, the Governance WG recommends that the TOC not adopt it. Full explanation: Steering Committees are frequently important governance tools for large and distributed projects, and more projects should consider having one as a channel for end-user, collaborator, and diverse audience representation. We valued Alexis’ writeup, and would like to incorporate it into our handbooks in progress for CNCF projects on how to develop governance. Projects that would need the "SC workaround" are projects that have been unable to attract a single maintainer from outside the original sponsoring organization, which is usually a sign of serious issues within the project. The Governance WG feels that the CNCF ecosystem is ill-served by moving projects with such problems to the Graduated level, and the proposal will not have the desired outcomes. Our decision was based on what we view as the inability of a non-technical Steering Committee to ensure that a project with maintainers* exclusively employed by the same organization treat submissions, roadmap items, and maintainer candidates from other organizations fairly. Even diligent SC members would find it difficult to understand enough about technical architecture decisions to differentiate between bias and legitimate objections in reviews. Further, unlike code and docs maintainers, it would be challenging for the TOC to monitor activity and involvement levels of SC members, as that would not create the same kind of contribution trail. For this proposal, we considered specifically projects that are having problems attracting contributors, because only such projects would need this mechanism. It certainly takes time to bring code reviewers up to speed, but the current requirement is a low bar; even a single dedicated documentation leader from an end-user company would technically satisfy it. While many folks have cited the Kubernetes project as an example, Kubernetes has a diversity of maintainers all the way down to the SIG level, so it would qualify for a maintainer multi-org requirement even without a Steering Committee. At this point, the Governance WG does not know of a good example of a project that successfully has used an SC to moderate the influence of development being dominated by a single company, so doing so would be experimental. As an experiment, we might adopt it for one specific project, but we'd want to see the outcome of that before we adopt it as general policy. Even Alexis’s document suggests that in problem cases it would be up to the TOC or their delegates to intervene to resolve project problems. Given this, it’s unclear what advantage having an SC would offer over Alexis’s original suggestion of having designated TOC monitors. Overall, our judgement was that adopting the SC workaround would be, in essence, removing the maintainer multi-organization requirement, and that it would be better to simply remove the requirement instead if that is the direction the TOC wishes to go. Drafted by Governance WG: Josh Berkus Dawn Foster Jennifer Davis Davinum Srinivas Paris Pittman (* by “maintainers” we mean involved, leading contributors with the authority to merge code, docs, and/or community materials into any of the key repos belonging to the project. Such contributors may be called "maintainers", "committers", or other titles. It does not refer to the official CNCF maintainer list for voting purposes, as that list contains many people who do not have merge authority in their individual projects.) -- -- Josh Berkus Kubernetes Community Red Hat OSPO
|
|