Skip to content

docs: reinstate baseline adopter counts for growth and graduated stages #2

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dsterz wants to merge 1 commit into
base: main
Choose a base branch
from
+2 −2
Open

docs: reinstate baseline adopter counts for growth and graduated stages #2

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions lifecycle-policy/project-lifecycle-policy.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -127,7 +127,7 @@ Projects in the Growth stage are generally expected to move out of the Growth st

##### Acceptance Criteria

The TAC has not yet defined requirements for the Growth Stage.
* The project must document that it is being used successfully in production by at least two independent organisations, which, in the TAC’s judgement, are of adequate quality and scope
Copy link
Copy Markdown
Member

@jakobmoellerdev jakobmoellerdev Mar 27, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: production can be defined extremely differently based on context and size of deployment of a tool. Thus I would heed caution here and we should maybe make it more defined

Copy link
Copy Markdown
Author

@dsterz dsterz May 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an excellent point @jakobmoellerdev, i agree that "production" for a small developer CLI tool looks very different than "production" for a massive cloud orchestration platform. Attempting to write a rigid, one-size-fits-all definition of "production" into the governance policy would create unnecessary bureaucracy.

Copy link
Copy Markdown
Contributor

@fmui fmui Apr 10, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about this? It adds a bit more precision.

The project must demonstrate to the TAC that it is being used successfully in production, or adopted as a dependency in a released product or open-source project, by at least two independent organisations or projects. The TAC will assess whether the evidence presented is adequate in quality and scope, taking into account the nature of the project. Where specific usage details cannot be disclosed, a brief written attestation from each such organisation or project confirming its use will suffice.

Copy link
Copy Markdown
Author

@dsterz dsterz May 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also see your good pint @fmui that adding a sentence gives the TAC discretion to judge the "quality and scope" based on the nature of the project and i feel this is the the right approach. Not suprisingly this the same concept that was part of the original June 2024 NeoNephos Lifecycle Policy, which is fair and fine and very transparent to have it discussed and agreed upon in public with everyone while reaching somehow consensus.

Copy link
Copy Markdown
Contributor

@hardl hardl Apr 27, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Imho not only the term "production" can be a bit fuzzy, but also "successfully" ;)
Also "being used" probably should be explained in more detail, especially if it covers also a non-direct dependency.
E.g. let's assume a product adopted NeoNephos' "Project Foo", which has a dependency to NeoNephos' "Project Bar", does that mean "Project Bar" can claim being used by the Product? Would the AC even be fully met in that example, since there are 2 "production" adopters from 2 different organisations, i.e. the product org and NeoNephos itself (via Project Foo)?

Copy link
Copy Markdown
Contributor

@fmui fmui Apr 27, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See my comment above.
It's really difficult to cover all possible cases. Therefore, I suggested this sentence: The TAC will assess whether the evidence presented is adequate in quality and scope, taking into account the nature of the project.

Copy link
Copy Markdown
Author

@dsterz dsterz May 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fmpov this is a great direction, and I appreciate how we are collaboratively shaping this!

Building on your good proposal to give the TAC the flexibility to evaluate 'quality and scope' on a case-by-case basis, I think we have a great opportunity to pair this agility with our core NeoNephos value of transparency.

Since 'production' looks different for every project, allowing the TAC to use its judgment is exactly the right move. To make this work nicely, I propose we add a simple requirement for the TAC to publicly document their reasoning when they approve a project's maturity.

Doing this in both the Growth and Graduated stages achieves two very positive things for our foundation:

  1. It builds ultimate trust: Enterprise adopters can read exactly why the TAC deemed a project ready, giving them the confidence to adopt it.

  2. It mentors future projects: By publishing these assessments, we create a public track record of what 'good' looks like, which will greatly help new projects understand what they need to aim for.

I suggest we update the PR with the following text for both stages:

Growth Stage: The project must document that it is being used successfully in production by at least two independent organisations. The TAC will assess whether the evidence presented is adequate in quality and scope, taking into account the nature of the project. To ensure transparency and guide future projects, the TAC will publish a public summary of its assessment and reasoning prior to the final approval vote.

Graduated Stage: The project must verify production use by at least 5 independent organisations, subject to formal TAC due diligence. The TAC will assess whether the evidence presented is adequate in quality and scope, taking into account the nature of the project. To ensure transparency and build ecosystem trust, the TAC will publish a formal report detailing its assessment and reasoning for public review prior to the final approval vote.

What do you think of this hybrid approach?

It gives the TAC the flexibility they need while keeping our governance beautifully transparent.

Copy link
Copy Markdown

@ScheererJ ScheererJ May 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am surprised that after the comments by two reviewers that production might not be a good term it still shows up in the proposal. Let's get rid of it.
From my point of view, a more realistic approach would be that each project has an adopters page and the users of the project can open PRs to add themself to the list. This is doable and provides some general information. After all, it is hard to get real evidence that a company is using a project, but if at least an employee of a company takes the time to open a PR it seems like some invest into the project.
WDYT?

Copy link
Copy Markdown
Author

@dsterz dsterz May 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can see your confusion @ScheererJ , I personally read it like we need to be more clear about what it means and how it is defined not that's an issue to have it in generel.
I actually would prefer to keep it rather than dropping it.
"production (ready)" is a well known term and strong positive signal towards a proven use, quality etc.

However i imply we are targeting a production metric thorugh industry adoption like it has been defined in the very first lifecycle policy before removal or who it is in the CNCF, which does not mean we have to keep it, thats why i like that we take a moment to think about the implications for the foundation and its endusers (here Donators + Adopters)

The other route we could take is like e.g. the Eclipse Foundation where the production metric is rather an evaluation of the presence of an adopter ecosystem, graduating there to a mature phase depends primary on proving an active adopter community.

These are my thoughts on this.

Copy link
Copy Markdown

@ScheererJ ScheererJ May 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dsterz In the document your write in production. Now you use production (ready). Those are already very different meanings indicating that this might not be a good fit.
Anyway, my main point is that we should not create rules, which we cannot enforce. It is incredibly hard to determine for an external entity, i.e. the TAC, whether something is running in production or is production (ready). It is much more realistic to look at a list of company names contributed/added via PR from people from those companies.
TLDR: I would like us to use a down-to-earth approach, which we can actually execute instead of some fuzzy vision, which is not tangible.


##### Approval Process

Expand Down Expand Up @@ -158,7 +158,7 @@ Graduated Stage projects are expected to participate actively in TAC proceedings

##### Acceptance Criteria

The TAC has not yet defined requirements for the Graduated Stage.
* The project must verify production use by at least 5 independent organisations, subject to formal TAC due diligence
Copy link
Copy Markdown
Contributor

@fmui fmui Apr 10, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See comment above - just with five usages.


##### Approval Process

Expand Down