Discussion on project donation criteria/ process

[lukehinds]

This issue is to gather initial ideas on what could constitute the criteria needed to donate a project to the OpenSSF.

Some initial thoughts..

• We would likely need tiers and criteria for each tier. "sandbox" (seeded within a working group) or a "top level project" (aka alpha/omega, sigstore)
• Would we want to avoid large overlap with other openssf projects ( xkcd.com/927) and instead seek to consolidate efforts upon existing projects?
• What would the project receive in return for joining (marketing, slack channel, mailing list, name on website etc) and for each tier.
• How would they apply, what information is required from the project? We provide a template?
• What would the review time duration be for the TAC to perform an assessment?

Existing implementations

k8s: https://github.com/cncf/toc/blob/main/process/graduation_criteria.adoc

ccc: https://github.com/confidential-computing/governance/blob/main/project-progression-policy.md#iii-stages---definitions--expectations

Previous discussions

#70

https://lists.openssf.org/g/openssf-tac/message/374

[dlorenc]

• What would the project receive in return for joining (marketing, slack channel, mailing list, name on website etc) and for each tier.

This is the big one I'd like to work out first for all the tiers. We created the incubating and graduated tiers earlier, but we never had much to offer so all the existing WGs and Projects never had a real reason to apply for the higher level.

I think we do have some kind of funding now, so we could figure out what we can offer. If it's all just slack and calendar access, then the sandbox level will be roughly the same as the incubation or graduated ones.

• Would we want to avoid large overlap with other openssf projects ( xkcd.com/927) and instead seek to consolidate efforts upon existing projects?

My personal opinion is to leave this one off and allow multiple efforts. It can be confusing and is not always ideal, but if we try to prevent overlap it might lead to cookie licking, scope creep, and political arguments. I'd rather have two groups doing something than no one doing it.

[dcmiddle]

• What would the project receive in return for joining (marketing, slack channel, mailing list, name on website etc) and for each tier.

ccc: https://github.com/confidential-computing/governance/blob/main/project-progression-policy.md#iii-stages---definitions--expectations

Higher at that link is a list of benefits including test infrastructure and a paid internship thru Outreachy.

Hyperledger is in the midst of organizing benefits by maturity level:
https://wiki.hyperledger.org/display/HYP/Project+and+Lab+Services

[gkunz]

Hi,

based on the fact that the current process is defined only for working groups, I created a related issue (#73) end of last year. Copying some thoughts over so that we can focus on one issue.

• Shall the life-cycle process be extended from working group level down to sub-project level? This would allow WGs to host multiple sub-projects with varying levels of maturity and to better reflect the state of each sub-project.

• Can we define a general recommendation for how new projects join OpenSSF, e.g. as part of a working group.

• Shall the life-cycle process of projects include a “graduated” level (incubating, active, graduated, end-of-life) to indicate that a project has achieved a level of maturity which is suitable for broad adoption.

• Shall the life-cycle process define criteria for graduating projects from WGs-hosted-level to top level (sibling to WGs). Maybe that’s the key feature of the “graduated” level.

[dlorenc]

To avoid conflating "is with ought to be", here's my understanding of the existing processes and mechanics:

• The OpenSSF allows for "Technical Initiatives" to join, and they ultimately fall under the TAC.
• Technical Initiatives can be Projects or Working Groups. Projects are intended to be mostly code-based, but there's no clear distinction in the charter.
• The Initiatives ultimately fall under the TAC, but the TAC does not have direct control of the initiatives:
  
• Instead, Initiatives govern themselves. There are no restrictions placed on this today. Most of the Working Groups have chairs who make most decisions. Working groups are free to create sub-projects as they see fit.

For lifecycle:

• The TAC reviews new Working Groups following a defined process, and we have "Incubating" and "Active" tiers.
• There is no clear process for onboarding or tiering of Projects.
• All Working Groups are currently Incubating.

Now on to the "ought to" section. Here are some clarifications I'd like to see in the short term:

• Merge the concepts of WG and Project, and update the Lifecycle and Abilities documents to apply to both. The distinction is blurry, confusing, and unneccessary as far as I can tell.
• Clarify what "benefits" Initiatives receive at each tier.

For longer term clarity, I'd like to discuss what we want the OSSF to look like in a few years. We could go a bunch of different directions here, so aligning on vision is an important first step in determining the correct and required process.

[david-a-wheeler]

As far as the WG decisions go, to add a new project within a WG, WGs ask for general consensus at a meeting and/or mailing list (doesn't need to be unanimous). At least, that's what I've seen WGs typically do. I don't know if that's been formally written down (if not, we should!).

[dlorenc]

I don't know if that's been formally written down (if not, we should!).

I'm not aware of this being written anywhere, but I think it would need to be written in each WG/Project's respective governance. Right now most don't have any written governance because of the confusion in the charter with the TSC stuff.

If I remember correctly, each WG initially started with a CHARTER.md file but it was actually just copy/pasted from the OSSF high level charter. Some still have this file: https://github.com/ossf/wg-best-practices-os-developers/blob/main/CHARTER.md which isn't really the right file.

I think the TAC here could require certain governance characteristics, but can't/shouldn't prescribe exact models. The CNCF has a governance policy that's roughly like "you must have governance and it must be written down". We could be more prescriptive or less here.

For example, the Sigstore governance is going to look much different than the Best Practices WG governance. That's a good thing IMO!

[JasonKeirstead]

I will leave some thoughts here from another organization I chair.

This is a template onboarding form that we ask of a newly suggested / donation requested project:

Project Name
 
Project Use Case (Value in one sentence)
 
Project Description (Detailed)


Project value to end user

Project contribution to <organization> goals and mission (<link to mission statement>)

Why, in your opinion, is <organization> the most appropriate host for this project?

What support are you looking for from <organization> members? 

Is this an existing project? If so, link to web page / repo
 
Does this project integrate with any existing projects or deliverables?

Project Implementation Details

Existing / Proposed Open Source License

Implementation Language(s)

Dependency Technologies
 
Primary Project Sponsor(s)
 
How will this project be resourced on an ongoing basis?

What is the scope (expected lifespan of this project’s development lifecycle)?

List the current project maintainers, and their Github user IDs

Optional Supporting Documentation

Screenshots
 
Demonstration videos
 
Architectural diagrams
 
Whitepapers

Comments

The sponsor company or group or other entity fills out this form and submits it to the governing board. The governing board reviews the form and votes on if they project should be accepted or not. The vote is open and transparent.

Back to the OpenSSF - if a WG is going to onboard projects without approval of the TAC, then that WG should at a minimum have to achieve a working consensus of the WG membership. Having a meeting with only a small group of attendees that say "LGTM!" is not sufficient for consensus or proper governance. Neither is brief threads on slack. If there is not a call with sufficient quorum for consensus then an email should at least be sent out so that proper consensus can be gauged.

[dlorenc]

The sponsor company or group or other entity fills out this form and submits it to the governing board. The governing board reviews the form and votes on if they project should be accepted or not. The vote is open and transparent.

Do you have an example here of this filled out? I'm curious what type of info gets filled in here for the "dependency technologies" section.

[JasonKeirstead]

@dlorenc Here is one example of a filled out form - https://lists.oasis-open-projects.org/g/oca-pgb/topic/posture_attribute_collection/86296436?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,60,86296436,previd=1634850167098158291,nextid=1631809231533596042&previd=1634850167098158291&nextid=1631809231533596042

[dlorenc]

I think we should probably scope this issue to "Top Level" Technical Initiatives, as defined in the OSSF Charter, in order to reduce confusion between "subprojects" which might be under WGs (scorecards, metrics dashboard) and Projects (sigstore and Alpha/Omega) which are directly under the TAC.

Relevant sections are Exhibit B, Section 1a and Section 6c.

[JasonKeirstead]

@dlorenc I think if this issue is only scoped for top-level initiatives, then an identical one needs to be opened for WG initiatives then. There has to be some OSSF-wide guidance and consistency on how WGs onboard projects - and it should at least need working a consensus.

[dlorenc]

@dlorenc I think if this issue is only scoped for top-level initiatives, then an identical one needs to be opened for WG initiatives then. There has to be some OSSF-wide guidance and consistency on how WGs onboard projects - and it should at least need working a consensus.

The discussion on WG governance mostly happened here: #9 (comment)

Working groups need to define their own governance which the TAC can review, but the TAC can't directly tell them how to operate.

There are also separate issues for each WG in #29 #30 #31 #32 #33 etc. We reviewed scope, but not governance last year.

It's probably worth going through that again once the new TAC is seated.

[lehors]

@dlorenc I think if this issue is only scoped for top-level initiatives, then an identical one needs to be opened for WG initiatives then. There has to be some OSSF-wide guidance and consistency on how WGs onboard projects - and it should at least need working a consensus.

The discussion on WG governance mostly happened here: #9 (comment)

Working groups need to define their own governance which the TAC can review, but the TAC can't directly tell them how to operate.

There are also separate issues for each WG in #29 #30 #31 #32 #33 etc. We reviewed scope, but not governance last year.

It's probably worth going through that again once the new TAC is seated.

I don't mean to derail this thread but I think the current structure is overkill for the size of the WGs and projects we currently have. It would make sense to simplify the structure and put every WG and project under the governance of the TAC until a WG or project gets so big that the TAC wants to delegate and set up a dedicated TSC.

For that matter while currently it is assumed that every WG has a TSC in charge, I have not seen any TSC actually operating nor how it is decided who gets to be member of these TSCs. If this is documented somewhere please let me know. Thanks.

[dlorenc]

For that matter while currently it is assumed that every WG has a TSC in charge, I have not seen any TSC actually operating nor how it is decided who gets to be member of these TSCs. If this is documented somewhere please let me know. Thanks.

That's correct to my understanding, I'm not aware of any WGs with TSCs - only chairs.

[joshbressers]

I wonder if this discussion should be backed up to answer the question about having any gates to let a project in. For example the CNCF has certain expectations for projects to join (the sandbox stage is a low bar)
https://github.com/cncf/toc/blob/main/process/project_proposals.adoc

In a meeting a few weeks ago I believe @brianbehlendorf made the comment that the OpenSSF doesn't want to end up as a dumping ground for projects. Which group gets to set this expectation? The board or the TAC maybe?

[dlorenc]

In a meeting a few weeks ago I believe @brianbehlendorf made the comment that the OpenSSF doesn't want to end up as a dumping ground for projects. Which group gets to set this expectation? The board or the TAC maybe?

Yeah I think it's up to the tac to decide this.

[JasonKeirstead]

To build further on @lehors and @joshbressers comment above

• We don't decide how WGs onboard projects, that is up to the WGs. So here are a bunch of issues TAC: Review and approve Identifying Security Threats WG charter #29 TAC: Review and approve Security Tooling WG charter #30 TAC: Review and approve Best Practices WG charter #31 TAC: Review and approve Vulnerability Disclosures WG charter #32 TAC: Review and approve Digital Identity Attestation WG charter #33 for those WG charters
• However, each of them are referring to TSCs that don't actually exist in practice
• Meanwhile, all are "LGTM", with no comments, and as of now are slated for closure next week
• Meanwhile, WGs are actively onboarding projects with the OSSF stamp left and right, without said TSC nor consensus mechanism. The decision making process on how this is done is therefore overly opaque, not consistent. It makes the OSSF feel more like the wild west than a well-governed organization.

A sound governance and decision making in the OSSF is the single most important thing to get right to ensure success of the organization - so this is all very critical. Right now this all feels very "hand wavey". I don't think enough focus is being put on this, and I don't know how to escalate it. Hoping @brianbehlendorf can comment.

[joshbressers]

@JasonKeirstead Your note about the charters is alarming, thank you for bringing this up.

Most of those charters aren't filled in.
For example: https://github.com/ossf/wg-identifying-security-threats/blob/main/CHARTER.md

It would be inappropriate to close those issues as they stand today. I'm adding this to the next TAC agenda.

[dlorenc]

+1 on not closing the issues.

[AevaOnline]

+1 on not closing the issues
+1 on ensuring that all WGs have charters -- and then reviewing them with the TAC
+1 on both WGs and Projects "reporting" in to the TAC. We don't need an extra layer at our current size, and a single layer is what is currently outlined in the OpenSSF Charter itself (though the TAC can delegate this if it decides to).

+100 on making this all more transparent, consistent, and documented in a single place.

[lukehinds]

note: this is now in motion here: #91

[SecurityCRob]

This has been documented here: https://github.com/ossf/tac/blob/main/process/project-lifecycle.md