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.

 

-bw

 

From: <cncf-toc@...> on behalf of Liz Rice <liz@...>
Date: Tuesday, September 29, 2020 at 10:44 AM
To: "cncf-toc@..." <cncf-toc@...>
Subject: [EXTERNAL] [cncf-toc] "Steering committee" discussion

 

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

 

Key points

• 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! 

 

Liz