Community stability for maturing projects - updates to Graduation

[TheFoxAtWork]

As the ecosystem continues to grow, mature, and expand, we are experiencing more and more the the importance of positive, transparent, and kind community relations. These characteristics of a mature and functional project are absolutely essential for community and project health and something we often reflect on when reviewing project updates and applications.

In recent weeks we’ve noticed increased tension within the community around sustaining and growing maintainers and leadership within our ecosystem. A thriving project must be capable of demonstrating stability and sustainment in its maintainership and leadership as well as demonstrate a consistent application of stable governance processes.

We've opened this issue to propose the following updates to the application for Graduation and to drive community discussion around these proposed changes:

• Active and engaged leadership for at least a year prior to Graduation application. A project should have a maintainership that shows stability as a whole. This does not prohibit the addition of new maintainers, but requires continuity and maintainer overlap. Hand-offs should have clear expectations and partnership, including sufficient time for new maintainers to ramp up.

• Consistent application of governance and community growth processes for at least a year prior to Graduation application: Governance is defined, discoverable, and followed consistently. Projects should be able to present evidence of contributors and maintainers following a path of advancing contributions. This does not prohibit changes to a project’s governance, but requires that the project is able to successfully introduce and follow any such changes.

Why 1 year? This proposed time frame allows at least one conference cycle to pass, a time which projects receive a lot of attention and interest from the community and drives contributions. It is also an estimated sufficient time for a project to experience at least one release — another factor that can stress or test governance and leadership.

Please comment on this issue with additional suggestions, changes, ideas, etc.

[monadic]

Hi,

IMO it is very important that projects demonstrate a degree of sustainability and longevity before Graduation. A one year delay after Incubation seems fair. And the idea of verifying that the core people and community rules are stable(-ish) is a good question to ask.

But surely the issues we have seen with the projects under current scrutiny are not arising due to applications for graduation?

The question of how to maintain etcd after it became relatively Long Term Stable was raised in GB TOC joint meetings 4-5 years ago.

The issues faced by cortex could easily have arisen post graduation, no?

Alexis

[lizrice]

The gist of this makes a lot of sense but one point of clarification: I hope this doesn't mean that projects can't have made any governance changes at all in the year prior to graduation as that might encourage projects to sweep known issues under the carpet in the hope that they can sort them out post-graduation.

For example, in the Cilium project we have a few processes that have been working fine for the last few years but aren't terribly well documented, which we want to address before applying for graduation. If it's not substantially changing the way that the project operates, presumably writing things out clearly shouldn't force a delay, right?

[dims]

for sure @lizrice

[TheFoxAtWork]

Completely agree and a great clarification!

[jberkus]

Both of these requirements make sense, I'm wondering how we'd verify them on a consistent basis? This suggests that we need a new section in the Due Dilligence for graduation, at a minimum.

It also suggests that we should discuss governance with projects as soon as they make Incubating, as a consistent process.

[ewilderj]

TL;DR some slight wording suggestions to better embody the spirit of the changes.

Echoing @lizrice’s points, the spirit of this change makes sense. I too am a bit nervous of inadvertently interpreting all change as instability. For example, Falco has recently renewed its governance documentation in the way Liz references for Cilium, documenting existing practice and implementing some fixes. In these cases, change is documenting a stable state and introducing added stability.

One undesired adverse effect would be that a project would hold off improving governance for a year, apply for graduation, receive feedback on its governance, amend it, then have to cycle through another year. @jberkus point is also part of mitigating this possibility.

Regarding leadership, in most CNCF projects development is primarily resourced by employers. There is staff turnover and reallocation that is normal in these environments, so maintainer evolution is also going to happen. Additionally, maintainers are humans and the world is not predictable. The important thing is where it’s trending over a period of time for the project as a whole, not whether change has occurred. This is welcome, as it should encourage the member companies to take succession planning more seriously.

Here, a potential undesired adverse effect on leadership is that we accidentally enforce maintainer stasis, furthering maintainer burnout and work against inclusivity goals.

In summary, we might run the risk of encouraging stagnation not growth if projects interpret “stability” in too literal a sense. The expansion of each bullet point provides all the right level of detail, but the first words in each bullet might be handled too literally. How do we help apply the spirit of these requirements but avoid the adverse effects of trying to game based on wording?

Feel free to do what you want with this rewording, but I hope it gets even closer to the desired spirit.

• Active and engaged leadership for at least a year prior to Graduation application. A project should have a maintainership that shows stability as a whole. This does not prohibit the addition of new maintainers, but requires continuity and maintainer overlap. Hand-offs should have clear expectations and partnership, including sufficient time for new maintainers to ramp up.

• Consistent application of governance and community growth processes for at least a year prior to Graduation application: Governance is defined, discoverable, and followed consistently. Projects should be able to present evidence of contributors and maintainers following a path of advancing contributions. This does not prohibit changes to a project’s governance, but requires that the project is able to successfully introduce and follow any such changes.

[TheFoxAtWork]

@ewilderj this is precisely spot on, thank you so much for the suggested reword, i have updated the issue to reflect your suggestion verbatim.

[xmulligan]

I feel like

"Active and engaged leadership for at least a year prior to Graduation application. A project should have a maintainership that shows stability as a whole. This does not prohibit the addition of new maintainers, but requires continuity and maintainer overlap. Hand-offs should have clear expectations and partnership, including sufficient time for new maintainers to ramp up."

may fit better as an Incubation requirement. I think it fits well with the current "Have a healthy number of committers and demonstrate a substantial ongoing flow of commits and merged contributions." requirements.

[TheFoxAtWork]

I'm going to close this issue in favor of the TAG CS issue where this content is linked and could be included for when those discussions happen.

As a quick reminder, Issues on the TOC repo are often used to open community discussions and solicit feedback. Until a PR is merged and criteria formally documented as criteria (which set minimums for moving levels and the TOC is working on clarifying items beyond minimums) these discussions are considered informative.