Clarify project reporting structure and benefits (WG vs TAC) or remove option for future projects to report to TAC #325
Labels
administration
Content
Updates/additions to TAC content/process. Must include a changelog entry. Needs 3 approvals.
documentation
Improvements or additions to documentation
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.
The text was updated successfully, but these errors were encountered: