From 989ceb9151afc714c668be65d328b3601c1c13c0 Mon Sep 17 00:00:00 2001 From: Stephen Augustus Date: Wed, 15 Apr 2026 08:08:38 -0400 Subject: [PATCH 1/4] Relax Sandbox entry requirements and clarify WG sponsorship This change is a draft proposal for discussion, addressing feedback from the TAC meeting on 2026-04-14 around PR #421 (OpenSSF Labs). Rather than introducing a new pre-Sandbox maturity level, the TAC discussed whether the Sandbox stage itself could be updated to better support early-stage and single-maintainer projects. Key changes: - Lower the Sandbox maintainer minimum from three (from two orgs) to one, with two strongly encouraged. Projects entering with fewer than two maintainers must reach that threshold by their first bi-annual TAC update (~6 months), or face archival review. - Move multi-organizational maintainer diversity (3+ maintainers, 2+ orgs) from a Sandbox entry gate to an Incubating entry requirement, where demonstrated community health is more meaningful. - Add an explicit Sandbox responsibility to actively grow the maintainer base and organizational diversity toward Incubating. - Clarify that all projects must report to a WG sponsor. Projects that cannot identify a suitable WG should submit their proposal and request that the TAC help identify an appropriate WG home. TAC sponsorship is not a path forward for new projects. - Clarify that project repositories must be hosted under the OpenSSF GitHub Enterprise Cloud instance; they are not required to use the ossf GitHub organization specifically. - Shorten the Sandbox archival dormancy trigger from 9 months to 6 months; Incubating and Graduated projects retain the 9-month trigger. - Add a note that Best Practices badge requirements will be revisited once OSPS Baseline conformance integration in the badge program is finalized. - Fix a pre-existing inconsistency in building-an-open-source- community.md, which stated "two maintainers" while project- lifecycle.md required three; update to reflect the new framing (multi-org diversity as an Incubating gate, not Sandbox entry gate). - Add a "Community growth plan" field to the Sandbox application template for projects entering below the full maintainer threshold. Co-Authored-By: Marcela Melara Co-Authored-By: Claude Signed-off-by: Stephen Augustus --- process/building-an-open-source-community.md | 2 +- process/project-lifecycle.md | 31 ++++++++++--------- .../templates/PROJECT_NAME_sandbox_stage.md | 16 ++++++++-- 3 files changed, 31 insertions(+), 18 deletions(-) diff --git a/process/building-an-open-source-community.md b/process/building-an-open-source-community.md index c7e8fb9c..663834ce 100644 --- a/process/building-an-open-source-community.md +++ b/process/building-an-open-source-community.md @@ -5,7 +5,7 @@ In open source software the sustainability and growth of projects significantly ## Importance of Maintainers from Multiple Organizations -The OpenSSF sandbox requirement, **Projects must have a minimum of two maintainers with different organization affiliations**, was adopted for the following reasons: +Multi-organizational maintainership is a requirement for projects to advance to the Incubating stage. Projects may enter the Sandbox with as few as one maintainer, but are expected to actively work toward building a diverse maintainer base. This expectation exists for the following reasons: ### Project resilience diff --git a/process/project-lifecycle.md b/process/project-lifecycle.md index 3852bd7f..af9fca2f 100644 --- a/process/project-lifecycle.md +++ b/process/project-lifecycle.md @@ -8,7 +8,7 @@ New [Projects](../organizational-structure-overview.md#definitions) to the OpenS ## Project Oversight -Projects report either directly to the Technical Advisory Council (TAC) or to a specific Working Group (WG). When a Project reports into a specific WG, that WG can support the Project's progression and provide recommendations to the TAC. The overseeing group provides Projects advice on technical direction, and is a point of escalation or dispute resolution in technical disagreements. The overseeing group does not set the charter or operations for Projects, but ensures Projects operate in line with the [Mission, Vision, Values, Strategy, and Roadmap (MVVSR)](https://openssf.org/about/). +Projects report to a specific Working Group (WG), which supports the Project's progression and provides recommendations to the TAC. Projects that cannot identify a suitable WG should submit their proposal and request that the TAC help identify an appropriate WG home. The overseeing WG provides Projects advice on technical direction, and is a point of escalation or dispute resolution in technical disagreements. The overseeing WG does not set the charter or operations for Projects, but ensures Projects operate in line with the [Mission, Vision, Values, Strategy, and Roadmap (MVVSR)](https://openssf.org/about/). @@ -39,13 +39,14 @@ The OpenSSF Sandbox is the entry point for early stage Projects and has four goa #### Project Responsibilities * Provides bi-annual updates to the TAC on technical vision and progress on vision. +* Actively works to grow the maintainer base and organizational diversity. Projects entering Sandbox with fewer than three maintainers from two or more organizations are expected to demonstrate progress toward this goal at each bi-annual TAC update, as multi-organizational representation is required for Incubating entry. * Maintains a diversified contributor base (i.e. not a single-vendor project). -* For code development, follows security best practices (as recommended by the OpenSSF and others), including passing the [OpenSSF Best Practices criteria](https://bestpractices.coreinfrastructure.org/en/criteria/0). +* For code development, follows security best practices (as recommended by the OpenSSF and others), including passing the [OpenSSF Best Practices criteria](https://bestpractices.coreinfrastructure.org/en/criteria/0). Note: badge requirements will be revisited once OSPS Baseline conformance integration in the badge program is finalized. * Provides project updates to OpenSSF Marketing Committee as requested. * Meet the "[Security Baseline - Once Sandbox](https://github.com/ossf/tac/blob/308c777124a05f1903301400653f1a7a944bd7be/process/security_baseline.md#baseline---once-sandbox)" requirements. #### Project Support -* Receives a TAC or WG sponsor for guidance on technical direction. The sponsor also ensures the Project operates within the scope of the OpenSSF, adheres to the OpenSSF code of conduct, legal and IP policies, and reserves the right to consult with the TAC to raise any related concerns. Projects can reach out to the TAC if concerns about sponsor involvement arise. +* Receives a WG sponsor for guidance on technical direction. The sponsor also ensures the Project operates within the scope of the OpenSSF, adheres to the OpenSSF code of conduct, legal and IP policies, and reserves the right to consult with the TAC to raise any related concerns. Projects can reach out to the TAC if concerns about sponsor involvement arise. * Receives consideration as in-scope for any submission to an OpenSSF-managed conference or event. * Receives OpenSSF Code of Conduct Committee support. * Reserved space for project updates in OpenSSF newsletters. @@ -54,12 +55,14 @@ The OpenSSF Sandbox is the entry point for early stage Projects and has four goa #### Sandbox Entry Requirements and Considerations -* Projects must have a minimum of three maintainers with a minimum of two different organization affiliations. +* Projects must have a minimum of one maintainer; two or more maintainers is strongly encouraged. Projects with fewer than two maintainers at entry must reach a minimum of two maintainers by their first bi-annual TAC update (approximately six months); failure to demonstrate progress toward this goal is grounds for archival review. See [Building an Open Source Community](building-an-open-source-community.md) for guidance on growing a maintainer base. * Projects must be aligned with the OpenSSF mission _and_ either be a novel approach for existing areas or address an unfulfilled need. It is expected that the initial code or specification developed by an OpenSSF WG be kept within their repository and will not function as a Project in its own right. Should the initial WG code or specification grow and mature that it warrants its own Project status, then it is subject to Sandbox entry requirements. It is preferred that extensions of an existing OpenSSF project collaborate with the existing project rather than seek a new project. -* Projects must seek one TAC sponsor or one WG sponsor (if reporting to a WG) - * TAC or WG sponsor agrees to attend Project meetings regularly - * TAC or WG sponsor does not need to have a formal role in Project, e.g., maintainer - * TAC or WG sponsor requests TAC approval +* Projects must seek a WG sponsor. Projects that cannot identify a suitable WG should reach out to the TAC for assistance in identifying one before submitting a proposal. + * The sponsor must be a member or lead of the sponsoring WG + * The sponsor governs the project as a Technical Initiative within the WG and ensures regular readouts of project progress to the overseeing group + * The sponsor does not need to have a formal role in the Project, e.g., maintainer + * The sponsor requests TAC approval on behalf of the project +* Projects must host their repository under the [OpenSSF GitHub Enterprise Cloud instance](https://github.com/enterprises/openssf/organizations). Projects are not required to use the `ossf` GitHub organization specifically; existing organizations may be moved under the OpenSSF Enterprise account. * If contributing an existing project to the OpenSSF, the contribution must undergo license and IP due diligence by the Linux Foundation (LF). See [Submission Process](#submission-process) below and [Sandbox application](templates/PROJECT_NAME_sandbox_stage.md). @@ -79,7 +82,7 @@ Incubating projects represent maturing but not fully realized projects. Incubati * Meets the "[Security Baseline - Once Incubating](https://github.com/ossf/tac/blob/main/process/security_baseline.md#security-baseline---once-incubating)" requirements. #### Project Support -* Receives guidance on technical direction from TAC and/or WG. The sponsor continues to ensure the Project operates within the scope of the OpenSSF, adheres to the OpenSSF code of conduct, legal and IP policies, and reserves the right to consult with the TAC to raise any related concerns. Projects can reach out to the TAC if concerns about sponsor involvement arise. +* Receives guidance on technical direction from the sponsoring WG. The sponsor continues to ensure the Project operates within the scope of the OpenSSF, adheres to the OpenSSF code of conduct, legal and IP policies, and reserves the right to consult with the TAC to raise any related concerns. Projects can reach out to the TAC if concerns about sponsor involvement arise. * Receives consideration as in-scope for any submission to an OpenSSF-managed conference or event. * Receives OpenSSF Code of Conduct Committee support. * Receives infrastructure support (details determined by project leads and OpenSSF Budget Committee). @@ -92,12 +95,12 @@ Incubating projects represent maturing but not fully realized projects. Incubati #### Incubation Entry Requirements and Considerations All requirements of Sandbox must be fulfilled, plus: -* Projects must have a minimum of three maintainers with a minimum of two different organization affiliations, and document the current list of maintainers. +* Projects must have a minimum of three maintainers with a minimum of two different organization affiliations, and document the current list of maintainers. This is where multi-organizational community health is validated; projects that entered Sandbox with fewer maintainers are expected to have grown their base to meet this requirement. * Projects must have met at least 5 times within the last calendar quarter since becoming `Sandbox`. * Projects must have defined a contributor guide, which makes it clear how and when contributors should be given increasing responsibilities towards maintainership of the project. (Example guides: [Sigstore](https://github.com/sigstore/community/blob/main/MEMBERSHIP.md), [AllStar](https://github.com/ossf/allstar/blob/main/contributor-ladder.md)) * Projects should be able to show adoption by multiple parties and adoption's value to the open source community and/or end users (may include adoption of beta/early versions) with the intent to showcase wide adoption by the project's consumers. * Projects must have documented, initial project governance. -* If reporting directly to the TAC, the TAC sponsor and Project should decide on continued TAC sponsor engagement going forward. Continued engagement may include, but is not limited to: +* If the project was granted an exception to report directly to the TAC, the TAC sponsor and Project should decide on continued TAC sponsor engagement going forward, or identify a WG that can take over sponsorship. Continued engagement may include, but is not limited to: * Project may consult about Project direction with TAC sponsor as needed throughout Incubating stage. * TAC sponsor should continue to monitor Project activities, though regular meeting attendance is optional. * Meet the "[Security Baseline - To Become Incubating](https://github.com/ossf/tac/blob/308c777124a05f1903301400653f1a7a944bd7be/process/security_baseline.md#baseline---to-become-incubating)" requirements. @@ -123,7 +126,7 @@ Graduated projects signal the highest level of maturity for an OpenSSF project. * Meets the "[Security Baseline - Once Graduated](https://github.com/ossf/tac/blob/main/process/security_baseline.md#security-baseline---once-graduated)" requirements. #### Project Support -* Receives guidance on technical direction from TAC and/or WG. +* Receives guidance on technical direction from the sponsoring WG. * Receives consideration as in-scope for any submission to an OpenSSF-managed conference or event. * Receives OpenSSF Code of Conduct Committee support. * Receives infrastructure support (details determined by project leads and OpenSSF Budget Committee). @@ -144,7 +147,7 @@ All requirements of Incubating must be fulfilled, plus: * Projects must have documented project governance and be able to demonstrate that governance in action. * When applicable, projects must have completed a security audit through a third party and addressed audit findings and recommendations. * Projects meet the "[Security Baseline - To Become Graduated](https://github.com/ossf/tac/blob/main/process/security_baseline.md#security-baseline---to-become-graduated)" requirements. -* If reporting directly to the TAC, TAC sponsor monitoring and consultation become optional. +* If the project was granted an exception to report directly to the TAC, TAC sponsor monitoring and consultation become optional at Graduation; the project is encouraged to identify a WG home if one has since become appropriate. #### Project Graduation Process: Incubating to Graduation @@ -154,7 +157,7 @@ See [Submission Process](#submission-process) below and [Graduation application] ### Archived -Open source projects have a lifecycle and there are times when projects become inactive due to a variety of reasons. There are also cases where a project may no longer want to be supported by the OpenSSF, the given effort no longer has broad community interest and participation, or the OpenSSF TAC may no longer wish to recommend the use of a project. Archiving happens through a vote of the TAC, and can be requested by the corresponding project's lead(s) or a TAC member. TI's that are dormant, with no activity for 9 months (meetings, mailing lists, or other publicly viewable channels) in a row should be considered good candidates for Archiving. +Open source projects have a lifecycle and there are times when projects become inactive due to a variety of reasons. There are also cases where a project may no longer want to be supported by the OpenSSF, the given effort no longer has broad community interest and participation, or the OpenSSF TAC may no longer wish to recommend the use of a project. Archiving happens through a vote of the TAC, and can be requested by the corresponding project's lead(s) or a TAC member. Sandbox projects that are dormant with no activity for 6 months (meetings, mailing lists, or other publicly viewable channels) in a row should be considered good candidates for Archiving. Projects at Incubating or Graduated stages that are dormant for 9 months should be considered good candidates for Archiving. #### Archiving Considerations diff --git a/process/templates/PROJECT_NAME_sandbox_stage.md b/process/templates/PROJECT_NAME_sandbox_stage.md index 15d68e71..ced0e7a8 100644 --- a/process/templates/PROJECT_NAME_sandbox_stage.md +++ b/process/templates/PROJECT_NAME_sandbox_stage.md @@ -1,12 +1,22 @@ ## Application for creating a new project at Sandbox stage ### List of project maintainers -The project must have a minimum of three maintainers with a minimum of two different organizational affiliations. +The project must have a minimum of one maintainer; two or more is strongly encouraged. Projects entering with fewer than two maintainers must reach a minimum of two by their first bi-annual TAC update. Projects must have a minimum of three maintainers from two or more organizations to be eligible for Incubating. * "name, affiliation, GitHub ID" +### Community growth plan +If the project is entering Sandbox with fewer than three maintainers from two or more organizations, describe how the project intends to grow its maintainer base and organizational diversity during the Sandbox phase. See [Building an Open Source Community](../building-an-open-source-community.md) for guidance. + * "description of planned outreach, collaboration, or other steps to grow the maintainer base" + ### Sponsor -Most projects will report to an existing OpenSSF Working Group, although in some cases a project may report directly to the TAC. The project commits to providing quarterly updates on progress to the group they report to. - * "name of the group the project reports to: either a Working Group or the TAC" +Projects must report to an existing OpenSSF Working Group. Projects that cannot identify a suitable WG should submit their proposal and request that the TAC help identify an appropriate WG home. The sponsor governs the project as a Technical Initiative within the WG and ensures regular readouts of project progress. The project commits to providing bi-annual updates on progress to the sponsoring WG. + * "name of the sponsoring Working Group" + * "name and GitHub ID of the sponsor (must be a member or lead of the sponsoring WG)" + +### GitHub organization +The project's repository must be hosted under the [OpenSSF GitHub Enterprise Cloud instance](https://github.com/enterprises/openssf/organizations). Projects are not required to use the `ossf` GitHub organization; existing organizations may be moved under the OpenSSF Enterprise account. + * "link to project repository" + * "confirm the repository is, or will be, hosted under the OpenSSF GitHub Enterprise Cloud instance" ### Mission of the project The project must be aligned with the OpenSSF mission and either be a novel approach for existing areas, address an unfulfilled need, or be initial code needed for OpenSSF WG work. It is preferred that extensions of existing OpenSSF projects collaborate with the existing project rather than seek a new project. From 7ca93d1ed470c16ef7d2f648917ba80c3f54a3c9 Mon Sep 17 00:00:00 2001 From: Stephen Augustus Date: Tue, 28 Apr 2026 02:13:35 -0400 Subject: [PATCH 2/4] Apply suggestions from code review Co-authored-by: Arnaud J Le Hors Signed-off-by: Stephen Augustus --- process/project-lifecycle.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/project-lifecycle.md b/process/project-lifecycle.md index af9fca2f..d60aab28 100644 --- a/process/project-lifecycle.md +++ b/process/project-lifecycle.md @@ -57,7 +57,7 @@ The OpenSSF Sandbox is the entry point for early stage Projects and has four goa * Projects must have a minimum of one maintainer; two or more maintainers is strongly encouraged. Projects with fewer than two maintainers at entry must reach a minimum of two maintainers by their first bi-annual TAC update (approximately six months); failure to demonstrate progress toward this goal is grounds for archival review. See [Building an Open Source Community](building-an-open-source-community.md) for guidance on growing a maintainer base. * Projects must be aligned with the OpenSSF mission _and_ either be a novel approach for existing areas or address an unfulfilled need. It is expected that the initial code or specification developed by an OpenSSF WG be kept within their repository and will not function as a Project in its own right. Should the initial WG code or specification grow and mature that it warrants its own Project status, then it is subject to Sandbox entry requirements. It is preferred that extensions of an existing OpenSSF project collaborate with the existing project rather than seek a new project. -* Projects must seek a WG sponsor. Projects that cannot identify a suitable WG should reach out to the TAC for assistance in identifying one before submitting a proposal. +* Projects must seek a sponsoring WG. Projects that cannot identify a suitable WG should reach out to the TAC for assistance in identifying one before submitting a proposal. * The sponsor must be a member or lead of the sponsoring WG * The sponsor governs the project as a Technical Initiative within the WG and ensures regular readouts of project progress to the overseeing group * The sponsor does not need to have a formal role in the Project, e.g., maintainer From 90616dbdd83ef7d4f161674e81f03ab864ec773d Mon Sep 17 00:00:00 2001 From: Stephen Augustus Date: Tue, 28 Apr 2026 02:42:40 -0400 Subject: [PATCH 3/4] Address reviewer feedback on Sandbox entry requirements Based on review feedback from lehors, gkunz, puerco, and marcelamelara: - Shift from time-gated maintainer growth to inactivity-based archival. Remove the requirement that single-maintainer projects must reach two maintainers by their first bi-annual TAC update. Active projects stay in Sandbox regardless of maintainer count; the sponsoring WG monitors activity and may initiate archival review after 6 months of dormancy. - Use "sponsoring WG" consistently for the WG entity and "sponsor" for the person, resolving ambiguity flagged by lehors. - Remove forward-reference to Incubating maintainer requirements from the Sandbox application template, per lehors. - Change line 64: the project's maintainer(s) submit the proposal and request TAC approval, not the sponsor, matching actual practice. - Consolidate redundant Sandbox responsibility bullets about growing the maintainer/contributor base into a single clear statement. - Fix stale intro text in building-an-open-source-community.md that described multi-org maintainership as "a prerequisite for joining" when it is now a prerequisite for advancing to Incubating. - Restore "submit their proposal and request" language on line 60, fixing a regression from the suggestions commit. Items deferred to TAC meeting discussion: - Lines 103 & 150: legacy TAC-direct reporting clauses (lehors) - Alternatives to archival such as project removal (puerco, mlieberman85) - Two-use-case framing for Labs (mlieberman85, deferred to #600) Co-Authored-By: Claude Signed-off-by: Stephen Augustus --- process/building-an-open-source-community.md | 2 +- process/project-lifecycle.md | 15 +++++++-------- process/templates/PROJECT_NAME_sandbox_stage.md | 2 +- 3 files changed, 9 insertions(+), 10 deletions(-) diff --git a/process/building-an-open-source-community.md b/process/building-an-open-source-community.md index 663834ce..8d670772 100644 --- a/process/building-an-open-source-community.md +++ b/process/building-an-open-source-community.md @@ -1,6 +1,6 @@ # Building an Open Source Community -In open source software the sustainability and growth of projects significantly depend on the diversity and engagement of their maintainer base. This document aims to underscore the importance of fostering a community with maintainers from multiple organizations, a prerequisite for joining the Open Source Security Foundation (OpenSSF). We will delve into the reasons why this diversity is critical, the benefits it brings, and provide actionable strategies to cultivate such a community. +In open source software the sustainability and growth of projects significantly depend on the diversity and engagement of their maintainer base. This document aims to underscore the importance of fostering a community with maintainers from multiple organizations, a requirement for advancing to the Incubating stage in the OpenSSF [project lifecycle](project-lifecycle.md). We will delve into the reasons why this diversity is critical, the benefits it brings, and provide actionable strategies to cultivate such a community. ## Importance of Maintainers from Multiple Organizations diff --git a/process/project-lifecycle.md b/process/project-lifecycle.md index d60aab28..5abb0f30 100644 --- a/process/project-lifecycle.md +++ b/process/project-lifecycle.md @@ -39,14 +39,13 @@ The OpenSSF Sandbox is the entry point for early stage Projects and has four goa #### Project Responsibilities * Provides bi-annual updates to the TAC on technical vision and progress on vision. -* Actively works to grow the maintainer base and organizational diversity. Projects entering Sandbox with fewer than three maintainers from two or more organizations are expected to demonstrate progress toward this goal at each bi-annual TAC update, as multi-organizational representation is required for Incubating entry. -* Maintains a diversified contributor base (i.e. not a single-vendor project). +* Actively works to grow and diversify the maintainer and contributor base. Single-maintainer projects entering Sandbox are expected to grow their community over time; multi-organizational representation (a minimum of three maintainers from two or more organizations) is required for Incubating entry. The sponsoring WG monitors project activity and may initiate an archival review for Sandbox projects that are dormant for 6 or more months. * For code development, follows security best practices (as recommended by the OpenSSF and others), including passing the [OpenSSF Best Practices criteria](https://bestpractices.coreinfrastructure.org/en/criteria/0). Note: badge requirements will be revisited once OSPS Baseline conformance integration in the badge program is finalized. * Provides project updates to OpenSSF Marketing Committee as requested. * Meet the "[Security Baseline - Once Sandbox](https://github.com/ossf/tac/blob/308c777124a05f1903301400653f1a7a944bd7be/process/security_baseline.md#baseline---once-sandbox)" requirements. #### Project Support -* Receives a WG sponsor for guidance on technical direction. The sponsor also ensures the Project operates within the scope of the OpenSSF, adheres to the OpenSSF code of conduct, legal and IP policies, and reserves the right to consult with the TAC to raise any related concerns. Projects can reach out to the TAC if concerns about sponsor involvement arise. +* Receives a sponsor from the sponsoring WG for guidance on technical direction. The sponsor also ensures the Project operates within the scope of the OpenSSF, adheres to the OpenSSF code of conduct, legal and IP policies, and reserves the right to consult with the TAC to raise any related concerns. Projects can reach out to the TAC if concerns about sponsor involvement arise. * Receives consideration as in-scope for any submission to an OpenSSF-managed conference or event. * Receives OpenSSF Code of Conduct Committee support. * Reserved space for project updates in OpenSSF newsletters. @@ -55,13 +54,13 @@ The OpenSSF Sandbox is the entry point for early stage Projects and has four goa #### Sandbox Entry Requirements and Considerations -* Projects must have a minimum of one maintainer; two or more maintainers is strongly encouraged. Projects with fewer than two maintainers at entry must reach a minimum of two maintainers by their first bi-annual TAC update (approximately six months); failure to demonstrate progress toward this goal is grounds for archival review. See [Building an Open Source Community](building-an-open-source-community.md) for guidance on growing a maintainer base. +* Projects must have a minimum of one maintainer; two or more maintainers is strongly encouraged. See [Building an Open Source Community](building-an-open-source-community.md) for guidance on growing a maintainer base. * Projects must be aligned with the OpenSSF mission _and_ either be a novel approach for existing areas or address an unfulfilled need. It is expected that the initial code or specification developed by an OpenSSF WG be kept within their repository and will not function as a Project in its own right. Should the initial WG code or specification grow and mature that it warrants its own Project status, then it is subject to Sandbox entry requirements. It is preferred that extensions of an existing OpenSSF project collaborate with the existing project rather than seek a new project. -* Projects must seek a sponsoring WG. Projects that cannot identify a suitable WG should reach out to the TAC for assistance in identifying one before submitting a proposal. +* Projects must seek a sponsoring WG. Projects that cannot identify a suitable WG should submit their proposal and request that the TAC help identify an appropriate WG home. * The sponsor must be a member or lead of the sponsoring WG * The sponsor governs the project as a Technical Initiative within the WG and ensures regular readouts of project progress to the overseeing group * The sponsor does not need to have a formal role in the Project, e.g., maintainer - * The sponsor requests TAC approval on behalf of the project + * The project's maintainer(s) submit the proposal and request TAC approval * Projects must host their repository under the [OpenSSF GitHub Enterprise Cloud instance](https://github.com/enterprises/openssf/organizations). Projects are not required to use the `ossf` GitHub organization specifically; existing organizations may be moved under the OpenSSF Enterprise account. * If contributing an existing project to the OpenSSF, the contribution must undergo license and IP due diligence by the Linux Foundation (LF). @@ -107,7 +106,7 @@ All requirements of Sandbox must be fulfilled, plus: #### Project Process: Sandbox to Incubation and direct entry to Incubation -Projects are required to undergo technical due diligence as a part of the process of entering Incubation, whether as a move from Sandbox to Incubation or entering Incubation directly. Technical Due Diligence is driven by a TAC or parent WG sponsor with close collaboration of the project. Once the diligence is complete and the proposal made, the Due Diligence document is made available to the community for two weeks to solicit public comment before a TAC vote is called. +Projects are required to undergo technical due diligence as a part of the process of entering Incubation, whether as a move from Sandbox to Incubation or entering Incubation directly. Technical Due Diligence is driven by the sponsor from the sponsoring WG with close collaboration of the project. Once the diligence is complete and the proposal made, the Due Diligence document is made available to the community for two weeks to solicit public comment before a TAC vote is called. See [Submission Process](#submission-process) below and [Incubation application](templates/PROJECT_NAME_incubation_stage.md). @@ -151,7 +150,7 @@ All requirements of Incubating must be fulfilled, plus: #### Project Graduation Process: Incubating to Graduation -Graduation requires undergoing due diligence as a part of the process to move from Incubation to Graduation. Due diligence is driven by a TAC or parent WG sponsor. For projects seeking Graduation, this may be a light refresh of the existing due diligence to cover the additional criteria, or a more in depth due diligence depending on the level of change the project has incurred since the original due diligence of Incubation was performed. Once the diligence is confirmed by the Sponsor to be complete and the proposal made, the Due Diligence document is made available to the community for two weeks to solicit public comment before a TAC vote is called. +Graduation requires undergoing due diligence as a part of the process to move from Incubation to Graduation. Due diligence is driven by the sponsor from the sponsoring WG. For projects seeking Graduation, this may be a light refresh of the existing due diligence to cover the additional criteria, or a more in depth due diligence depending on the level of change the project has incurred since the original due diligence of Incubation was performed. Once the diligence is confirmed by the Sponsor to be complete and the proposal made, the Due Diligence document is made available to the community for two weeks to solicit public comment before a TAC vote is called. See [Submission Process](#submission-process) below and [Graduation application](templates/PROJECT_NAME_graduation_stage.md). diff --git a/process/templates/PROJECT_NAME_sandbox_stage.md b/process/templates/PROJECT_NAME_sandbox_stage.md index ced0e7a8..36d2d6cf 100644 --- a/process/templates/PROJECT_NAME_sandbox_stage.md +++ b/process/templates/PROJECT_NAME_sandbox_stage.md @@ -1,7 +1,7 @@ ## Application for creating a new project at Sandbox stage ### List of project maintainers -The project must have a minimum of one maintainer; two or more is strongly encouraged. Projects entering with fewer than two maintainers must reach a minimum of two by their first bi-annual TAC update. Projects must have a minimum of three maintainers from two or more organizations to be eligible for Incubating. +The project must have a minimum of one maintainer; two or more is strongly encouraged. * "name, affiliation, GitHub ID" ### Community growth plan From 20dc3b466ce332155021c8ac167bb008783490c6 Mon Sep 17 00:00:00 2001 From: Stephen Augustus Date: Tue, 28 Apr 2026 02:55:07 -0400 Subject: [PATCH 4/4] Replace legacy TAC-direct reporting clauses with transitional provision The Incubating and Graduated sections contained clauses describing ongoing TAC-direct reporting as an accepted path. This contradicts the rest of the PR, which establishes WG sponsorship as the required model for all projects. Replace both clauses (Incubating line 102, Graduated line 147) with a unified transitional provision: projects accepted under prior rules with TAC-direct reporting should work with the TAC to identify a sponsoring WG; the TAC continues oversight until one is identified. Co-Authored-By: Claude Signed-off-by: Stephen Augustus --- process/project-lifecycle.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/process/project-lifecycle.md b/process/project-lifecycle.md index 5abb0f30..43aed359 100644 --- a/process/project-lifecycle.md +++ b/process/project-lifecycle.md @@ -99,9 +99,7 @@ All requirements of Sandbox must be fulfilled, plus: * Projects must have defined a contributor guide, which makes it clear how and when contributors should be given increasing responsibilities towards maintainership of the project. (Example guides: [Sigstore](https://github.com/sigstore/community/blob/main/MEMBERSHIP.md), [AllStar](https://github.com/ossf/allstar/blob/main/contributor-ladder.md)) * Projects should be able to show adoption by multiple parties and adoption's value to the open source community and/or end users (may include adoption of beta/early versions) with the intent to showcase wide adoption by the project's consumers. * Projects must have documented, initial project governance. -* If the project was granted an exception to report directly to the TAC, the TAC sponsor and Project should decide on continued TAC sponsor engagement going forward, or identify a WG that can take over sponsorship. Continued engagement may include, but is not limited to: - * Project may consult about Project direction with TAC sponsor as needed throughout Incubating stage. - * TAC sponsor should continue to monitor Project activities, though regular meeting attendance is optional. +* **Transitional provision:** Projects that were accepted under prior rules with TAC-direct reporting should work with the TAC to identify a sponsoring WG. Until a sponsoring WG is identified, the TAC continues in the oversight role. * Meet the "[Security Baseline - To Become Incubating](https://github.com/ossf/tac/blob/308c777124a05f1903301400653f1a7a944bd7be/process/security_baseline.md#baseline---to-become-incubating)" requirements. #### Project Process: Sandbox to Incubation and direct entry to Incubation @@ -146,7 +144,7 @@ All requirements of Incubating must be fulfilled, plus: * Projects must have documented project governance and be able to demonstrate that governance in action. * When applicable, projects must have completed a security audit through a third party and addressed audit findings and recommendations. * Projects meet the "[Security Baseline - To Become Graduated](https://github.com/ossf/tac/blob/main/process/security_baseline.md#security-baseline---to-become-graduated)" requirements. -* If the project was granted an exception to report directly to the TAC, TAC sponsor monitoring and consultation become optional at Graduation; the project is encouraged to identify a WG home if one has since become appropriate. +* **Transitional provision:** Projects that were accepted under prior rules with TAC-direct reporting should work with the TAC to identify a sponsoring WG. Until a sponsoring WG is identified, the TAC continues in the oversight role. #### Project Graduation Process: Incubating to Graduation