SecurityCRob
commented
1 month ago We'll discuss this at the 14May TAC call
Open justaugustus opened 1 month ago
SecurityCRob
commented
1 month ago We'll discuss this at the 14May TAC call
sevansdell
commented
1 month ago 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). https://github.com/ossf/tac/issues/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
commented
3 weeks ago Any further discussion needed here, or can I start a PR to update the documentation with clarity using the thread above?
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:
Given the feedback from TAC members in Slack (convo below), what I'm hearing is:
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:
...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:
@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 🙂
@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.