-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify project reporting structure and benefits (WG vs TAC) or remove option for future projects to report to TAC #325
Comments
We'll discuss this at the 14May TAC call |
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. |
Any further discussion needed here, or can I start a PR to update the documentation with clarity using the thread above? |
This was a topic of conversation in the 9july2024 TAC call regarding the newly proposed MVP SIG and the request to house it directly underneath the TAC. We should continue that conversation here and determine guidelines to help us with these types of questions in the future. |
Did a little work on this one today. We'll need to update language in both https://github.com/ossf/tac/blob/4bae622108a01e672d211362340c5988147c9759/process/project-lifecycle.md and https://github.com/ossf/tac/blob/main/organizational-structure-overview.md. One thing we could do is work to have a single source of truth in the Main Org structure, and defer any reporting language out of the individual Project lifecycle and point to the main organizational structure image. Where does AO report? in the Main Organizational Structure image, I don't see it. https://github.com/ossf/tac/blob/main/organizational-structure-overview.md What I'd like to propose is that AO/Sigstore keep reporting to TAC, but going forward, all projects/SIGs report to a WG. If we agree, I can work to finalize the wording in PRs. |
I don't think we should use it often, but I'm in favor of having the option available for TIs to report to the TAC. https://github.com/ossf/Diagrammers-Society is a great example of a short-lived SIG that reported to the TAC and was very useful. In terms of Alpha Omega, I believe they are an "associated project" meaning that while they have a co-branding agreement to use the OpenSSF name, they are mostly independent from the OpenSSF. I know Alpha Omega has their own governance and funding, independent of the OpenSSF. I think they give TAC updates as a courtesy, or maybe as a term of their co-branding agreement? |
FYI I think this is a backlogged work item for the TAC and not a funding request as it isn't labeled with You can see the issues labeled with a funding request with something like: https://github.com/ossf/tac/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22TI%20Funding%20Request%22 |
/close-vote |
@steiza is there work that remains to make any clarifying points based on your last comment? |
It's my preference to leave open the option for TIs to report to the TAC, but for it to be something that isn't frequently used. That's how things are today, so I think we can close this issue out. |
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: