You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Move Technical Charter and license scan requirements to the Sandbox stage (#824)
This aligns with the current practice of onboarding new projects into the LF first and then bringing to the TAC formally once the trademark and any license concerns are addressed.
Signed-off-by: John Mertic <[email protected]>
Copy file name to clipboardExpand all lines: process/lifecycle.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -43,6 +43,8 @@ Projects submitted to the Academy Software Foundation at the Sandbox Stage are i
43
43
44
44
To be accepted at the Sandbox stage, a project must:
45
45
46
+
* Have completed and approved the Technical Charter and agree to transfer any relevant trademarks to The Linux Foundation or its affiliate, LF Projects, LLC, and to assist in filing for any relevant unregistered ones.
47
+
* Have had a successful license scan with any critical issues remedied.
46
48
* Submit a completed [Project Contribution Proposal Template](proposal_template.md) to the TAC.
47
49
* Provide such additional information as the TAC may reasonably request.
48
50
* Present the project’s proposal to the TAC. Project teams should be prepared to present a detailed (20-30 minutes in length) overview of the project and speak to the information in the contribution proposal.
@@ -81,13 +83,11 @@ A project at the Incubation Stage has begun to form a community and develop its
81
83
82
84
To be accepted at the Incubation stage, a project must meet the Sandbox requirements plus:
83
85
84
-
* Have completed and approved the Technical Charter and agree to transfer any relevant trademarks to The Linux Foundation or its affiliate, LF Projects, LLC, and to assist in filing for any relevant unregistered ones.
85
86
* Have defined its technical governance, including:
86
87
* A README file welcoming new community members to the project and explaining why the project is useful and how to get started ( follow the guidelines at the [README checklist](https://github.com/ddbeck/readme-checklist) to create an excellent README file ).
87
88
* A CODEOWNERS or COMMITTERS file to define individuals or teams responsible for code in a repository; document current project owners and current and emeritus committers.
88
89
* A RELEASE file that documents the release methodology, cadence, criteria, etc.
89
90
* Have achieved and maintained an OpenSSF Best Practices Badge at the [Passing Level](https://bestpractices.coreinfrastructure.org/en/criteria).
90
-
* Have had a successful license scan with any critical issues remedied.
91
91
* Have a defined project mission and scope
92
92
* An overview of the project’s architecture and features defined ( equivalent to the [documentation_architecture](https://www.bestpractices.dev/en/criteria?details=true&rationale=true#1.documentation_architecture) OpenSFF Best Practices Silver Level badge requirement. )
93
93
* A documented project roadmap ( equivalent to the [documentation_roadmap](https://www.bestpractices.dev/en/criteria?details=true&rationale=true#1.documentation_roadmap) OpenSFF Best Practices Silver Level badge requirement. )
0 commit comments