Clarify project reporting structure and benefits (WG vs TAC) or remove option for future projects to report to TAC

[justaugustus]

The current documentation around project lifecycle is ambiguous around the benefits a project would receive by reporting directly to the TAC, as opposed to up through a Working Group.

By @afmarcum's calculations, there is only one project (Sigstore) that reports to the TAC and 17 that report up through WGs.

The request to the @ossf/tac here is as the title implies:

• clarify project reporting structure and benefits (WG vs TAC) OR
• remove option for future projects to report to TAC

Given the feedback from TAC members in Slack (convo below), what I'm hearing is:

1. there are no clear benefits for a project to report directly to the TAC
2. having more projects report to the TAC would create an unsustainable burden on its members

---

From #tac on OpenSSF Slack:

@mlieberman85:
Fellow TAC members, there’s been some interest from some projects in OpenSSF (e.g. Scorecard) that when they graduated to report directly to the TAC and move away from being underneath a WG. I think it generally makes sense,  especially as projects grow beyond their original scope and as they grow out of the need for the guidance that the working group can provide. What are other’s thoughts?

@justaugustus:
Generalizing the convo a little, the project lifecycle doc currently states:

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.

...but does not appear to discuss when/why a project or the TAC may decide to report to a WG vs the TAC.In a brief discussion with Michael Lieberman, he mentioned that there's an upper bound to the amount of projects that the TAC can reasonably support.

Suggestion to remove the ambiguity:

• unclassified / sandbox / incubating —> must report to WG
• Graduated —> reports to TAC

@SecurityCRob:
The boggle there @justaugustus would be two-fold..... 1.) what's the benefit for everyone involved with this arrangement that can't be achieved with the current report-up through WG?  and 2.) there is not enough bandwidth/time to maybe double the # of things reporting directly to the TAC, again what's the value prop to the extra workload?

@justaugustus:
Great questions, CRob!
I think I may not have the context to answer either 🙂

1. This is probably best articulated by TAC members + WG leads? To a project, reporting to the TAC simplifies the reporting structure. A project could likely realize the same the benefits via either, just with an extra hop. Is there a visibility benefit or any additional benefits that a project would realize by reporting to the TAC? If not, then I may ask why that possibility exists.
2. Benefit to the project or the TAC? Same note about "add'l incentives of reporting to the TAC". About personal context, is there an easy way to view the current count of unclassified, sandbox, incubating, and graduated projects? What about the count of projects that report to TAC vs to WGs?

@afmarcum:
re: projects that report to TAC vs to WGs
Sigstore reports to the TAC and every other project reports to a WG (17 or so)

@lehors:
Indeed, it really is an exception for a project to report to the TAC directly. Quite selfishly having projects report to a WG means less direct load to the TAC. We get every WG to report to the TAC on a quarterly basis. It works because we can have a reasonably small number of WGs. If many projects eventually report to the TAC directly we will need to figure out a new way of getting reports for sure because the current model can't scale much.

This isn't to say it can't be made to work. At ASF for instance, all projects report to the same PMC but it is done entirely asynchronously and PMC meetings are a mere formality without much discussion.

Before we make such a change we should have at least a sense of what's to gain, given that the cost is real.

@justaugustus:
Arnaud — We're in agreement here in that it's not obvious what the benefit is reporting directly to the TAC.

To be clear, this was not necessarily a request for Scorecard to go top-level, but more so a request for clarity on the paths a project could choose and their respective value.

If directly to the TAC is a path that would cause undue burden to its members and has no tangible and/or documented benefit, then I would view this as a request to remove non-preferred options for projects exercising the project lifecycle in future.

@lehors:
I understand. That's a fair point. Thanks.

@torgo:
Feels to me like scorecard belongs under best practices… Feels like that’s important to connect with the other initiatives going on there - e.g. plugging it together with the work that we did in SCM best practices… If scorecard is telling people to do one thing and other initiatives are telling people something slightly different or using different language, then it cause confusion. Just my €.02.

@justaugustus:
Dan Appelquist — Just clarifying that I'm not referring to Scorecard here explicitly.
I'm looking for the general cases that a project exercising the lifecycle guidelines need to consider.

[SecurityCRob]

We'll discuss this at the 14May TAC call

[sevansdell]

Really good conversation, and @justaugustus thanks for capturing from Slack into a TAC issue.

My recommendation is to add clarity that projects should report to a WG. One item the TAC has been discussing this year is to how to improve the alignment, awareness and networking bidirectionally leveraging Working Groups. That's vertically up and down through SIGs and projects interlocking at the WG level. And then horizontally across between Working Groups.

As OpenSSF has evolved organically over the years, the need for WG and tools to interlock with each other is becoming more timely, and leaning into increased WG communication and coordination that provides a benefit to projects to report to a WG.

I'd like to see project managers play more of a role facilitating this type of interlock activity (versus minutes or putting together agendas). #308 I'll cross post over there.

Using scorecard as an example, I see a benefit of a project aligning to a WG is having their work championed through interlocks vertically and horizontally across WG with the help of project management staff. A perfect example is alignment between the BEST WG and the Metrics and Metadata WG, specifically the Metrics API SIG. I'd like to see an evaluation of leveraging structured results vs the metrics API, and be able to understand and communicate out to our stakeholders the value of each.

[sevansdell]

Any further discussion needed here, or can I start a PR to update the documentation with clarity using the thread above?