[Proposal] Review and update TAC's project progression documents

[AevaOnline]

As discussed in the last few TAC meetings, there is a broad interest in reviewing and updating our "project progression" documentation, including more clearly defining:

• what projects "get" from joining the OpenSSF
• the relationship between the TAC<->WG and TAC<->Projects
• distinction between WG's and Projects
• whether projects and WGs have a mentor from among the TAC, how often WGs/Ps report up to the TAC, and what should be in the reports
• ... and more.

This may be a fair bit of work, and likely worth splitting into multiple PRs. Let's track them here.

[joshbressers]

The working group lifecycle document can be found here
https://github.com/ossf/tac/blob/main/working-group-lifecycle.md

[SecurityCRob]

It could also be valuable to articulate the breadth of work that is currently going on and how our assorted components do/should be aligned. We had done a very basic "reference architecture" diagram for BlackHat last year that may be useful to start from. It would be nice to show our body or work so that new projects or ideas can see how their project might fill in a gap or compliment existing work.

[AevaOnline]

@SecurityCRob I agree that having an updated overview would be a helpful asset in this discussion.

If trying to frame the whole project-progression without an understanding of the projects that are already in-progress is like describing an elephant in the dark, then how about we take a phased approach?

1. TAC discusses and creates a set of questions for each Technical Initiative to complete, including: what is the current charter, who is the point of contact, and what are current gaps/needs.
2. TAC passes these questions to the Technical Initiatives, collects responses, updates github repo
3. TAC identifies a cadence for regular reviews with each Technical Initiative (quarterly? semi-annual?) and begins to schedule with the primary point of contact for each
4. After a first review is completed with each Technical Initiative, and the new TAC members all have the same information as a starting point, then the TAC revisits the broader questions raised here around funding, oversight, and the TAC<->TI relationship.

[joshbressers]

I spent a little looking at everything the OpenSSF has in this space
(side note, there are 38 repos in the ossf github org. It's sort of hard to navigate)

I want to start with the charter. This is the only one I could find
https://cdn.platform.linuxfoundation.org/agreements/openssf.pdf
It's clearly for members to review, the actual charter is pages 6-13. It would be handy to have a nicer copy of the charter available

The charter calls out the TAC as "Technical Advisory Council", but in many places I've seen it called the "Technical Advisory Committee" I assume we should use the language in the charter.

The charter has a section about committees, but nothing about working groups. I suspect the first point of clarification will be is a working group a committee? If working groups are committees, that charter section should be reviewed (section 4).

[lehors]

Hi all,
I'd like to point out that the proposed project lifecycle is very similar to the one Hyperledger started with 6+ years ago. We eventually renamed "Active" to "Graduated" because the term "Active" turned out to be very confusing. Indeed, we had (and still have) several projects that were effectively active but didn't meet the requirements to get out of Incubation (getting enough diversity is typically the blocker). If the intent is to eventually use the same project lifecycle for WGs and projects, I think this is a situation we may face in OpenSSF too so I would suggest we save ourselves the trouble of changing later and simply go with Graduated now. It's a term used in other LF projects such as CNCF.

For reference, see the Hyperledger project lifecycle. You'll see that we added several other stages in response to various situations we ran into. I'm not suggesting we adopt all of these now though. But changing names is always a pain so the sooner the better.

[lehors]

The charter calls out the TAC as "Technical Advisory Council", but in many places I've seen it called the "Technical Advisory Committee" I assume we should use the language in the charter.

I agree, because the charter is under the control of the Governing Board, so changing it requires GB approval. It's not necessarily hard to do but it's typically more work. :)

[sbtaylor15]

Here is the history of how the CD Foundation handled a working group moving to a project vs onboarding an existing open source project being added to the CDF.

[SecurityCRob]

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