Creates project benefits #100
Conversation
Initial documentation of the OpenSSF Project Stages, responsibilities, and benefits of being an OpenSSF project intended for discussion. Does not have forms for projects; those are TBD based on confirmed requirements.
…ect-benefits Creates project_stages.md
project_stages.md
Outdated
| #### Incubating Entry Requirements and Considerations | ||
|
|
||
| * Projects must have a minimum of three maintainers with a minimum of two different company affiliations. | ||
| * Projects must be aligned with the OpenSSF mission and 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. |
There was a problem hiding this comment.
Pointing out the "address an unfulfilled need" phrase, as this is worth a TAC discussion.
Incentivizing collaboration is good, but as worded, it would seem to impose a requirement on projects that "there can only be one X, and the first one wins". Do we want that?
There was a problem hiding this comment.
+1 on the need for discussion. "Novel approach for existing areas" was an attempt to recognize that the first to apply isn't necessarily the only way (and disincentive rushed applications) , but there should be some mitigation to avoid duplicate functionality projects. I think given the OpenSSF's focus on improving existing project security, more resources for fewer projects is appropriate, rather than a market-driven approach.
There was a problem hiding this comment.
Ah, this could also have been a parsing error on my end :)
If I re-read this, and express the logic in SQL terms, as such, "project must (be aligned with the mission) AND (be a novel approach OR address an unfulfilled need OR be initial code for a working group)" ... then my concern is addressed.
Is that how you intended it to be read?
There was a problem hiding this comment.
I'll propose an edit
There was a problem hiding this comment.
| * Projects must be aligned with the OpenSSF mission and 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. | |
| * Projects 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. |
project_stages.md
Outdated
|
|
||
| * Projects must have a minimum of two maintainers with different company affiliations. | ||
| * Projects must be aligned with the OpenSSF mission and 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. | ||
|
|
There was a problem hiding this comment.
| * If contributing an existing Project to the OpenSSF, the contribution must undergo license and IP due diligence by the LF. |
project_stages.md
Outdated
| * Maintain a diversified contributor base (i.e. not a single-vendor project) with an active flow of contributions | ||
| * Follow security best practices (as recommended by the OpenSSF and others) | ||
| * Maintain a point of contact for vulnerability reports and follow coordinated vulnerability disclosure practices | ||
| * Implement, practice, and refine mature software development and release practices such a following a version schema |
There was a problem hiding this comment.
| * Implement, practice, and refine mature software development and release practices such a following a version schema | |
| * Implement, practice, and refine mature software development and release practices, such as adherence to semantic versioning, and having a declared policy for stable releases and backported fixes |
There was a problem hiding this comment.
Making this suggestion to start a conversation. I don't have a strong view on whether graduated projects must have a stable branch policy (though I think it is, in general, a good thing, and a mark of project maturity, there could also be projects to which this doesn't apply).
project_stages.md
Outdated
|
|
||
| * Projects must have a minimum of three maintainers with a minimum of two different company affiliations. | ||
| * Projects must be aligned with the OpenSSF mission and be a novel approach for existing areas or address an unfulfilled need. Projects with duplicate, similar or competing fuctionality to an existing OpenSSF project may be denied Graduation status if the TAC does not see technical justification for overlapping projects. | ||
| * Projects must be able to show adoption by multiple parties and that adoption's value to the open source community and or end users. |
There was a problem hiding this comment.
| * Projects must be able to show adoption by multiple parties and that adoption's value to the open source community and or end users. | |
| * Projects must be able to show production usage by more than three independent companies, and demonstrate the value that that adoption provides to the open source community and or end users. |
There was a problem hiding this comment.
Re "adoption" (vs production usage) and "multiple parties" (vs companies), one of the use cases I was thinking of was an open source project using an OpenSSF project in their build and release workflow.
There was a problem hiding this comment.
That makes a lot of sense. Since this should be a measure of maturity, and I agree that adoption in certain open source projects would demonstrate that, how could this be worded to avoid gaming this metric by demonstrating adoption in very small / low impact projects?
There was a problem hiding this comment.
That is a great question!
"critical adoption" by "multiple, significant parties"?
There was a problem hiding this comment.
seems ... too open-ended? I like it ... and at the same time, I think the context you so clearly articulated on the TAC call would be lost.
Perhaps a second clarifying sentence, or a parenthetical, could help? e.g.,
* Projects must be able to show adoption by multiple parties, which could be production deployments or substantial use by established external open source communities, and demonstrate the value of that adoption to either the end users or the open source community.
project_stages.md
Outdated
|
|
||
| #### Graduated Project Entry Requirements and Considerations | ||
|
|
||
| * Projects must have a minimum of three maintainers with a minimum of two different company affiliations. |
There was a problem hiding this comment.
| * Projects must have a minimum of three maintainers with a minimum of two different company affiliations. | |
| * Projects must have maintainers with a minimum of three different company affiliations. |
There was a problem hiding this comment.
Suggesting this change for two reasons:
- so that the bar for graduated is slightly higher than for the previous stage,
- so that, should one company pull out of a project, or be acquired by another contributing company, the project doesn't fall below the baseline sandbox acceptance criteria with only one contributing entity.
There was a problem hiding this comment.
+1
Will leave this open for others to discuss
Co-authored-by: Aeva Black <806320+AevaOnline@users.noreply.github.com>
project_stages.md
Outdated
| * May request OpenSSF budget for project improvements such as security audits or time-bound contracting needs | ||
| * May request OpenSSF for sustained maintainer stipends (details determined by OpenSSF and project leads) | ||
| * With additional TAC or WG approval, may fundraise for dedicated project funds, coordinated by the OpenSSF | ||
| * Projects may use the OpenSSF logo to promote their project (in accordance with the trademark guidelines). Projects may be referred to as an "OpenSSF Project" or "OpenSSF $ProjectName." |
There was a problem hiding this comment.
I didn't comment on the correlated sandbox/incubating lines, and will comment here.
This implies the creation of a Foundation-wide trademark enforcement program, at least for projects and related marketing materials. Pointing out that this should get discussed by the GB.
There was a problem hiding this comment.
+1 on GB discussion. Re TMs, the mark holder (LF) already has enforcement abilities, this is just a change to the usage guide of the mark. I don't think front-loaded approvals (ie "submit marketing materials for sign off") are the best use of resources, rather, having projects agree to abide by the usage guide as part of their acceptance, and the mark holder can become involved if there are notable patterns of misuse.
There was a problem hiding this comment.
+1 on not front-loading / over-loading with needing approval for every TM use.
+1 on having clear guidelines and requiring project leads to agree to abide by them.
Co-authored-by: Aeva Black <806320+AevaOnline@users.noreply.github.com>
Moves to match file structure of ossf#95
|
Since 31c8a99 is now landed, can you please rebase. Also i think they are using the working_process branch |
|
Also, @annabellegoth2boss , can you please find a place to plug this in (can go in new PR too) - #95 (comment). I think we need a period of notification here for every release going forward [notification by email or slack or something].
|
|
Adding ideas to @inferno-chromium 's suggestions for notifications
|
Hmm, I rebased to working_version_process, but I'm not seeing it a diff against tac/process/project-lifecycle.md... (and of course I forgot it would lose @AevaOnline's as changes and turn them into comments...will have to re-commit those) |
|
I'm afraid something went wrong with the series of commits and rebases for this PR. Instead of modifying the process/project-lifecycle.md file it is replacing it entirely. It results in every line being shown as new... |
|
Oh I know what silliness I did. This is my mistake. @lehors, because #95 was still in flight when I started, I didn't edit off your branch, I made a new file off the pre-95 repo. There are proposed changes to the project stages (and I remember losing your diagrams, let's add them back!), but much of it should be familiar. Since this section in #95 was a work in progress, are you all okay reviewing as is without a diff? (And I'll be wiser about my workflow next time...) |
|
You could get back on your feet by squashing all your commits and force pushing the result as a single commit against this PR. |
|
Update: New PR for review in #103 I think between the rebases and commits to be cherrypicked, I'm in a merge conflict hole ;) It'll probably just be easier in the long run if I open a new PR (can also add @AevaOnline's copyedits at that time which didn't get in in the file move). I can try to get to that today. |
Updates the project_lifecycle.md from the updated working_version_process branch. Integrates comments from AevaBlack on /ossf/pull/100
| @@ -0,0 +1,176 @@ | |||
| ## Becoming an OpenSSF Project | |||
|
|
|||
| The OpenSSF's mission is to inspire and enable the community to secure the open source software we all depend on. OpenSSF is focused on the security of existing open source project however, there are missing pieces in the tooling needed to improve project security. These pieces are the projects OpenSSF aims to steward and support. | |||
There was a problem hiding this comment.
| The OpenSSF's mission is to inspire and enable the community to secure the open source software we all depend on. OpenSSF is focused on the security of existing open source project however, there are missing pieces in the tooling needed to improve project security. These pieces are the projects OpenSSF aims to steward and support. | |
| The OpenSSF's mission is to inspire and enable the community to secure the open source software we all depend on. OpenSSF is focused on the security of existing open source projects however, there are missing pieces in the tooling needed to improve project security. These pieces are the projects OpenSSF aims to steward and support. |
|
|
||
| # Project Life Cycle | ||
|
|
||
| New projects to the OpenSSF, and progression through the project lifecycle, are approved by the Technical Advisory Committee (TAC). Projects oversight is provided by either the TAC (if project is independent from a WG) or a WG (if project is part of a specific WG and follows that WG's governance). |
There was a problem hiding this comment.
| New projects to the OpenSSF, and progression through the project lifecycle, are approved by the Technical Advisory Committee (TAC). Projects oversight is provided by either the TAC (if project is independent from a WG) or a WG (if project is part of a specific WG and follows that WG's governance). | |
| New projects to the OpenSSF, and progression through the project lifecycle, are approved by the Technical Advisory Committee (TAC). Project oversight is provided by either the TAC (if project is independent from a working group (WG)) or a WG (if project is part of a specific WG and follows that WG's governance). |
|
|
||
| New projects to the OpenSSF, and progression through the project lifecycle, are approved by the Technical Advisory Committee (TAC). Projects oversight is provided by either the TAC (if project is independent from a WG) or a WG (if project is part of a specific WG and follows that WG's governance). | ||
|
|
||
| Projects follow the Sandbox, Incubating, Graduated and Archival lifecycle stages defined below. Projects that seek widespread adoption and end user use are expected to progress through the stages. |
There was a problem hiding this comment.
| Projects follow the Sandbox, Incubating, Graduated and Archival lifecycle stages defined below. Projects that seek widespread adoption and end user use are expected to progress through the stages. | |
| Projects follow the Sandbox, Incubating, Graduated and Archival lifecycle stages defined below. Projects that seek widespread adoption and use are expected to progress through the stages. |
|
|
||
| The OpenSSF Sandbox is the entry point for early stage projects and has four goals: | ||
|
|
||
| * Encourage experimentation and open collaboration that can add value to the OpenSSF mission and build the ingredients of a successful Incubation level Project |
There was a problem hiding this comment.
| * Encourage experimentation and open collaboration that can add value to the OpenSSF mission and build the ingredients of a successful Incubation level Project | |
| * Encourage experimentation and open collaboration, adding value to OpenSSF's mission and building the ingredients of a successful Incubation level Project |
| The OpenSSF Sandbox is the entry point for early stage projects and has four goals: | ||
|
|
||
| * Encourage experimentation and open collaboration that can add value to the OpenSSF mission and build the ingredients of a successful Incubation level Project | ||
| * Facilitate alignment with existing Working Groups or Projects if this is desired |
There was a problem hiding this comment.
Why the "if this is desired"? I'd imagine alignment with WGs/projects should be a requirement for any project entering OpenSSF?
| * Projects must be aligned with the OpenSSF mission and be a novel approach for existing areas or address an unfulfilled need. Projects with duplicate, similar or competing fuctionality to an existing OpenSSF project may be denied Graduation status if the TAC does not see technical justification for overlapping projects. | ||
| * Projects must be able to show adoption by multiple parties and that adoption's value to the open source community and or end users. | ||
| * Projects must be able to show a consistent release cadence. | ||
| * Projects must have documented project governance and be able to demonstrate that governance in action. |
There was a problem hiding this comment.
| * Projects must have documented project governance and be able to demonstrate that governance in action. | |
| * Projects must have publicly documented project governance and be able to demonstrate that governance in action. |
|
|
||
| * Projects must have a minimum of two maintainers with different company affiliations. | ||
| * Projects must be aligned with the OpenSSF mission and 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. | ||
|
|
There was a problem hiding this comment.
How are these applications approved? Simple majority TAC vote…?
|
|
||
| #### 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. Once the diligence is complete and the proposal made, two weeks are allocated for public comment before a TAC vote is called. |
There was a problem hiding this comment.
Same vote question here as above. Simple majority of the TAC?
|
|
||
| ### Archiving | ||
|
|
||
| Open source projects have a lifecycle and there are times that 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, 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. |
| * A proposal must be put forth to the TAC or WG repo | ||
| * The TAC or parent WG will inform the project maintainers, OpenSSF end user community and wider community of all archiving proposals | ||
| * The proposal must remain open for at least 2 weeks of discussion after the maintainers are informed. | ||
| * A vote must be finalized with 2/3 approval from the TAC or parent WG. |
There was a problem hiding this comment.
Ah, this one does specify a vote amount (⅔). Is it the same for the others above, then?
|
I understand the plan was for this PR to be closed in favor of PR#103. Otherwise it's going to be hard to have one conversation with 2 parallel PRs. @annabellegoth2boss can you please close this one? |
Closing in favor of #103 |
Initial documentation of the OpenSSF Project Stages, responsibilities, and benefits of being an OpenSSF project intended for discussion. Does not have forms for projects; those are TBD based on confirmed requirements.