Skip to content
Open
Changes from all commits
Commits
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
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 maintain a public GOVERNANCE.md file that explicitly defines the project's decision-making and committer processes
Copy link
Copy Markdown
Contributor

@CowFreedom CowFreedom Mar 27, 2026

Choose a reason for hiding this comment

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

The project must maintain a public GOVERNANCE.md file that explicitly defines the project's decision-making and committer processes

Strictly speaking, the Project Charter of each NeoNephos project defines the project's decision making and committer processes. Imho, a more appropriate wording would be something like:

The project must maintain a public GOVERNANCE.md file that provides references to the project's decision-making and committer processes and lists the TSC members.

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

I'd recommend just linking to the OpenSSF best practices badge requirement ( https://www.bestpractices.dev/en/criteria?details=true&rationale=true#1.governance ), so that you are more tightly aligned to OSS best practices.


##### 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 have adopted a Code of Conduct in a form acceptable to the NeoNephos Foundation, and maintain publicly accessible documentation of its release and governance processes
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

NeoNephos has a reference code of conduct. Maybe change to:

If the project wants to adopt its own Code of Conduct, it must be in a form acceptable to the NeoNephos Foundation.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I would like to avoid custom code of conducts. Is there really a requirement for this across projects already?

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Yes - the default CoC in the project charter is https://linuxfoundation.eu/policies/code-of-conduct. I would agree that projects without a CoC already stick with that, but if a project coming in has a CoC it could be LF Europe approved ( see 4b in the Technical Charter for any of the NeoNephos projects )

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Hmmm.... To me this reads like it is not required and all Projects could adopt the NeoNephos CoC.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Let’s avoid project‑specific Codes of Conduct. We should adopt a single, foundation‑wide Code of Conduct for all NeoNephos projects, regardless of stage. Also, the CoC topic is more a Governing Board level discussion rather than a TAC discussion.

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

So to be fair, CoC topic is a project level TSC discussion for activities in thier projects, and a TAC topic for cases of the broad community. GB has no weigh in here.

I would honestly recommend removing this line as it's already in the Technical Charter.


##### Approval Process

Expand Down