- "Steering committee" discussion
Re: "Steering committee" discussion
toggle quoted messageShow quoted text
I think my wording could be better - the graduation requirement should be for functional community control of the project roadmap (not merely a plan for a community-controlled roadmap)
On Tue, 29 Sep 2020 at 18:52, Alexis Richardson <alexis@...> wrote:
"Projects struggling to get maintainers when the owning entity is unwilling to give up control to the community"
This mostly does not happen. Although due to some bad actors, it can. Mostly projects are a handful of people on a mission, struggling to make it work, in the face of massive demands and uncertainty.
"What would the mechanism used to be sure that a “plan” for a community controlled roadmap becomes a reality?"
The SC model could generate
* quarterly roadmap
* contributor ladder
* contingency plan
What would the mechanism used to be sure that a “plan” for a community controlled roadmap becomes a reality? At present, holding graduation as the milestone for that is, imho, one of the most critical functions the CNCF has.
Projects struggling to get maintainers when the owning entity is unwilling to give up control to the community seems like a natural consequence.
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless
you can confirm the sender and know the content is safe.
Thanks everyone who came to the TOC call today - with extra thanks to Alexis for initiating the idea in the first place. I've tried to capture the key points:
Problem statement summary: projects that are controlled by a single vendor struggle to meet the current graduation requirement to have maintainers from multiple organizations (for valid reasons such as, they tend to hire the folks
who are expert in that project). This multi-organization requirement is intended to address two concerns:
1. longevity of the project (in the event that a vendor is acquired or goes out of business)
2. ensuring that the project roadmap is community controlled, and not only run in the commercial interest of the vendor (we want to avoid feature hold-back)
We recognize that the current multi-org requirement may not be the only (or even necessarily the best) way to address those concerns
As a graduation requirement, a project should demonstrate a plan for both 1. longevity plan and 2. community-controlled roadmap
As now, "maintainers" from a range of organizations is one way to address these points. A steering committee governance model can be another valid model. As at present, TOC isn't going to mandate any particular governance model (though we can discuss guidance
/ ideas / recommendations with projects). The TOC remains the final arbiter of what is considered an acceptable governance model.
Steering committees shouldn't be imposed on a project, we believe they will only be successful if they reflect the community surrounding the project (which can include end users and other vendors, and doesn't have to be limited to code committers)
Historically, one reason for projects to struggle to meet the current multi-org maintainer requirement is an inability to attract new maintainers. SIG Contrib Strategy is here to help! As a graduation requirement, a project should have a defined contributor
ladder that describes how someone can get involved, and the steps they need to take to reach a leadership role within a project.
As previously discussed we should tidy up the language about "maintainer" to make sure that it's clear that governance models can involve non-coding contributors and community members (e.g. a steering committee could involve end users driving the roadmap)
There is interest in the idea of "badging" for projects that could give end users other information (one example suggested was an indicator of how many commercial vendors offer support for a project). WG Governance are working on a proposal for this.
If this broadly reflects the consensus we can start on wordsmithing the graduation requirement changes in GitHub.
Many thanks everyone for your comments and feedback around these ideas!
Join email@example.com to automatically receive all group messages.