I wish to note that it was @cra's idea. I just wrote about it and
toggle quoted messageShow quoted text
then talked about it a lot.
On Tue, Sep 29, 2020 at 6:43 PM Liz Rice <liz@...> wrote:
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!