Separate WGs and Projects lifecycles

[lehors]

This leverages the existing WG lifecycle and segregates the new lifecycle
inherited from CNCF to projects which are directly reporting to the TAC
or a parent WG.

Signed-off-by: Arnaud J Le Hors lehors@us.ibm.com

[lehors]

By the way, the charter actually makes it clear that projects are about developing code and WGs aren't: "Working Groups (non-software focused) and Projects (software focused)".

[david-a-wheeler]

But in practice that's not how many of us have used the word "project". I know that Aeva wants to use a different term for non-code projects, and I don't see a crisis if we do, but in that case we need a different word. I think around half of our "projects" aren't developing code. "Working Group" is also a confusing term. The best practices working group has many "projects" that don't generate code, it'd be confusing to use the same term for both levels. Can we find a better less-confusing term, if we're going to separate them like this?

[lehors]

I agree that we have activities called "projects" today that aren't software focused. "The GMFA distribution project" is one of them.

I also agree that using the same name at two different levels would be confusing. But using projects for the two different types of initiatives is arguably also confusing and I think we do need to differentiate them from a process point of view. Because the requirements and expectations just can't be the same. So, the question is how.

So, either we find a new name to use to differentiate one from the other - maybe taskgroup, taskforce, subgroup, activity? - or we have to write our process in a way that differentiates "non-software focused projects" from "software focused projects" (and revise the charter accordingly).

The latter is what it would take if we don't want to rock things but just capture what is going on today.

[lehors]

In an effort to avoid the issue raised by @david-a-wheeler I explored what it would look like to try and stick with the reality we are in in PR #96. Please check it out.

IMPORTANT NOTE: If the model proposed in PR #96 is preferred this PR should not be merged. Only one should be merged.

[AevaOnline]

But in practice that's not how many of us have used the word "project". I know that Aeva wants to use a different term for non-code projects,

@david-a-wheeler is correct -- I encourage everyone to adopt the language that is reflected in the Charter and shared by many of our sister-foundations. It's concise and clear enough, and would facilitate mobility between foundations for those of us who need it.

We also seem to have a third class as well, which is not reflected in the charter: a Technical Initiative that operates a public-facing web service. I believe we will need a name for that, and likely a charter update, to capture that Initiatives of this type have unique funding requirements and distinct obligations to the GB and to the community.

[AevaOnline]

The TAC should be described as the responsible party -- a WG can recommend a project move to specific maturity levels, but the TAC must approve it.

This provides consistency to all external parties who will rely on the OpenSSF as a whole to signal in a consistent manner, and it aligns with the Charter's definition of the TAC's role.

Proposed wording:

Projects are either directly under the governance of the Technical Advisory Committee (TAC) or a specific Working Group (WG). The TAC is responsible for reviewing and approving changes to all Project's Life Cycles. Where a Project reports into a specific WG, that WG can support the Project's progression and provide recommendations to the TAC.

[inferno-chromium]

nit: s/approving changes/approving significant changes
I don't think we would have time to look at all changes.

[lehors]

Done with @inferno-chromium's adjustment. I leave it to @AevaOnline to mark this resolved if that's ok.

[AevaOnline]

Some diligence is required -- e.g., sandbox projects must still have legal review and an IP transfer agreement, if a project is being contributed from an outside source.

[inferno-chromium]

I feel this is too strong of a requirement for an early stage project (I do agree that this is required for mature, company owned projects). We should keep as-is.

[lehors]

I've left it as-is for now.

[annebdh]

I think the Sandbox entry requirements and process (eg how due diligence is defined at this stage) is important for putting whatever the OpenSSF's vision for a "project landscape" is into practice. If the OpenSSF intends to be more opinionated, and donation/new projects is done in service of supporting upstream security changes, then I think a very lenient Sandbox entry would be misleading to maintainers (whose projects may be stuck in sandbox indefinitely). If the intention is to cultivate many new technologies in the space (a la CNCF), then a lenient Sandbox entry is more appropriate. In general, I have mostly heard the former being OpenSSF's POV on project donation, but I don't think I have yet seen this formalized through the TAC or GB.

[TheFoxAtWork]

Concur on some level of diligence. the key driving point (in my mind) is that the work is not intended to cultivate a complex and expanding ecosystem, rather to foster robust security upstream and therefore will require some evaluation. Alignment with the goals/objectives of the OpenSSF and aligned to an initiative immediately comes to mind, and a clear problem the project hopes to resolve. Further, understanding the true problem to be addressed, versus perceived problem and potential side effects of the potential solution should also be factors. Its easier to fix a problem early on than to try to patch it in production.

[AevaOnline]

Defining the scope/vision of the OpenSSF, so that we might evaluate projects against that, is a good discussion for the TAC to have. However, my initial point that IP Transfer is required for the sandbox stage stands.

I feel this is too strong of a requirement for an early stage project

@inferno-chromium , this isn't about feelings -- it is a legal matter. The LF cannot accept a pre-existing project without an IP Transfer agreement in place between the contributing company and the LF. Whomever holds the copyright on the project code, or trademark on its name, regardless of its maturity, must come to an agreement with the LF... or it is not an LF-managed project, and therefore would not be part of the OpenSSF and should not be using the OpenSSF name or brand.

[inferno-chromium]

@AevaOnline - Be respectful in your replies and please don't try to enforce your opinion over others. Lets other TAC members chime in as well. A definition of early stage project is important here and that will decide what needs to be put in place.

[AevaOnline]

This section should probably be moved down under the Graduation heading.

[lehors]

The way the document is currently structured is:
State n
Graduation process from stage n to stage n+1
State n+1
....

I take it that you would prefer:
State n
State n+1
Graduation process from stage n to stage n+1
....

I think we need to decide on the structure and be consistent throughout. I can go either way.

[AevaOnline]

Suggested change

	* Have committers from at least two organizations.
	* Have maintainers from at least three independent (where one is not a subsidiary of the other) organizations. A maintainer is defined as someone with the commit bit; i.e., someone who can accept and merge contributions to some or all of the project.

[AevaOnline]

Yes, I'm proposing the bar be set at 3, which is where the CNCF originally set the bar. Happy to discuss this as it is a significant change.

[inferno-chromium]

3 feels too strong. Maybe 2 with a few other open source contributors. Happy to discuss this in tac meeting, but seems fine to leave 2 for now.

[lehors]

I left it unchanged for now.

[lehors]

I have now updated this PR to incorporate the new terminology and structure @AevaOnline proposed. This does not swap WG and SIG though. That is done in PR #98 and should be the only difference between those two PRs.

[annebdh]

"Reporting Relationship" seems to answer the question, "What body approves the creation of $Initiative?" but line 31 gives two options. I think we could clarify this by either: adding an "Approving body" column or clarifying in line 19 who approves what kinds of projects (distinguishing between the tooling a WG needs to create vs a Project that is intended to be adopted outside of the WG)

[TheFoxAtWork]

The concept of an approving body is (IMO) a good idea regardless as it provides a concentrated point of review, support, or even correction. Reporting relationships don't necessarily imply an approval and it may be worth while to call out so that we can detail which of said items do or do not require the approval.

[lehors]

I think that's a valid point but that is better addressed in a followup PR.

[TheFoxAtWork]

does that PR exist? We don't want to lose this as an action item. even creating a stub in the table with "approving body == TBD" will be enough.

[inferno-chromium]

Considering today's TAC discussion, we need to add a line somewhere on how existing projects notify TAC on new releases, blog posts. Let's say what TAC governance we want on Scorecards V5, Package Analysis V2, releases next ? We should definitely think of lightweight approvals (send email to group and wait X days or open an issue, etc), while keeping everyone informed at the same time.

[dlorenc]

I think it's important to treat this as notification only. We're an Advisory Committee, not an Approval Committee.

[naveensrinivasan]

I think it's important to treat this as notification only. We're an Advisory Committee, not an Approval Committee.

+1

[inferno-chromium]

LGTM based on @AevaOnline recent email. We can continue to refine things in future PRs, esp stages, etc based on furthur discussion. This one is targeted towards terminologies. Please see if you can incorporate any of @annabellegoth2boss comments before merging.

[TheFoxAtWork]

What is healthy in regards to this? with this concept of "healthy number" also be reused as a criteria for the dashboard or criticality score? If not, why not?

[lehors]

I think that's a valid point that should be addressed independently. I will open an issue. Thanks.

[lehors]

See issue #101

[lehors]

I have incorporated changes that I think are non controversial or that are in keeping with the direction this was on. I do think the TAC will need to make a decision as to how much control/oversight it wants to exercise over the different groups. We clearly have some tension between those who would rather have more and those who would rather have less. With that in mind I left out of this PR the idea of adding a requirement for notification in case of significant events such as a blog post which I think is better left to a different PR.

[AevaOnline]

SO many thanks to @lehors for the work on this, and to everyone for the comments and discussion. Merging this now, please continue to open PRs and Issues to iterate on this.