agenda(collab): CoSAI TSC-WS Collaboration

[davidlabianca]

Agenda 8-May-26: CoSAI TSC-WS Collaboration

Guidestar: Rapid Onboarding & Navigation
Empower all participants—new members, workstream contributors, and end-users—to instantly identify:

• Current Status: The "State of the State" at CoSAI.
• The Roadmap: Upcoming plans, publications, and deliverables.
• Governance: How decisions are made and where those discussions happen.
• Engagement: Where to start, how to contribute, and whom to contact.

---

1: Mode (System Dynamics)

• Minimal Friction: Design workflows requiring the lowest possible user effort to find information.
• Automation-First: Default to automated routing and discovery (LLMs, agents, intelligent UX).

2: Execution (The "GitHub-First" Architecture)

• Develop in the Open: Establish GitHub as the single source of truth, deprecating isolated storage silos (e.g., minimizing Google Drive).
• Mandatory Publication: Maintain fanatical consistency in posting:
  • Meeting agendas and distilled summaries (actions/decisions, not raw notes).
  • RFCs, architectural decisions, and open discussions.
  • Work products, including early drafts.

3: Initialization (Where We Start)

• Define Approaches:
  • Weigh strict standardization against goal-oriented flexibility.
  • Evaluate standardized repo templates vs. individual, fit-for-purpose setups.
• Deploy Unifying Elements:
  • Establish CoSAI-wide GitHub project boards.
  • Formalize mailing list announcements and cross-posting protocols.
  • Restrict ephemeral/non-retained systems (like chat apps) strictly to transient coordination.
  • Build the unified CoSAI entry point (LLM prompt, agent, or UI gateway).

[jo5iah]

Key questions people often ask:

• What has CoSAI done
• What is CoSAI working on right now
• What is the maturity of the different work-in-progress
• What are the next milestones for work-in-progress
• How can I contribute
• How can we amplify our message
• Is there a tool for that; when will we build it

[jo5iah]

Meetings in WS2 have generally been structured into:

1. Welcome and Introductions
2. External Updates and Information Sharing
3. Internal Updates and deliverable estimates
4. Discussion on meeting topics

We can use a meeting template like this to better automate our meeting process/tracking/execution.

[davidlabianca]

Agenda 8-May-26: CoSAI TSC-WS Collaboration

Guidestar: Rapid Onboarding & Navigation Empower all participants—new members, workstream contributors, and end-users—to instantly identify:

• Current Status: The "State of the State" at CoSAI.
• The Roadmap: Upcoming plans, publications, and deliverables.
• Governance: How decisions are made and where those discussions happen.
• Engagement: Where to start, how to contribute, and whom to contact.

Decision: General agreement that this is the scope of our effort

[davidlabianca]

Feedback -> Two main threads but with priority:

• 1 How do new members and 3rd-parties engage
• 2 Sharing across workstreams

[zeal-somani]

To align with "GitHub-First" architecture and the goal of rapid onboarding, prioritize the following actions -- not in specific order.

1. Deploy a CoSAI-wide Project Board: Establish a global GitHub Project Board as outlined in the initialization phase. This will serve as the "State of the State" dashboard, providing a unified roadmap and visualizing progress across all workstreams in a single view.

2. Define Clear "Contribution Pathways"

• Consistent Labeling: Implementing a mandate to use "help wanted" labels across all CoSAI repositories to signal approachable tasks.
• Guidance Documentation: Ensuring every repository includes a clear link to the "how to contribute" section of the main cosai-tsc README.

3. Adopt a unified Meeting Issue Template and move to GH repos of each workstream. This automates the delivery of distilled summaries (decisions and action items) directly to GH

[s-mah]

If I had to prioritize one thing for next steps, it would be developing a cross-workstream roadmap that outlines upcoming plans, publications, and deliverables. I see this as the “north star” guiding downstream activities. Clear objectives and end goals help drive engagement and inform the rest of the workstreams and activities.

[shrey-bagga]

Absolutely agree with the comments above, I believe this is about rapid onboarding and navigation across CoSAI work, especially helping new participants understand current status, roadmap, governance, and where/how to engage.

One concrete thing that would help is a lightweight “map of work” for CoSAI : a single discoverable place that shows what is being worked on, which workstream it belongs to, who is leading it, where the canonical repo/issue/doc lives, what stage it is in, and where someone can contribute.

This could live in cosai-tsc, cosai-oasis, or a dedicated onboarding repo, but the important part is that it becomes the front door for navigation rather than another source of duplicated project detail.

The map could track a minimal set of fields:

• Workstream
• Initiative / deliverable
• Co-Leads
• Current status
• Maturity / phase
• Next milestone
• Canonical repo, issue, or document
• Meeting / decision links
• Contribution opportunities

I’d suggest prioritizing this in layers:

1. Define the common operating model for workstreams: roadmap, active initiatives, owners, meeting summaries, decision records, and contribution paths.
2. Create the CoSAI-wide map of work as the index across those workstreams.
3. Use GitHub-native mechanisms: issues, labels, project views, pinned docs, and templates.

Each workstream should own its own current state, while the CoSAI-wide map makes that state discoverable.

A good initial milestone would be a small pilot: pick one workstream, apply the common model, add it to the map of work, and validate whether a new participant can understand current work and find a useful contribution path within a few minutes. Once that works, we can scale the pattern across CoSAI.

[jo5iah]

Other items to consider including in GH:

• presentations
• blogs

And we should start noting exceptional items which will not appear in GH, but may need integration in order to meet the goals above. Perhaps we integrate with one shared calendar:

• meeting schedules
• planned deliverables (schedule)
• WS/SIG contributors, editors, etc.

One thought given all of the above is that perhaps we could build this incrementally as an MCP service with a Graph RAG back end, that semantically indexes entitites (including documents, WS, SIG, members) and events (publications, meetings) etc. This provides a ground truth mechanism that can operate above github, calendar, and even google docs. It also also simple interrogation of the relevant content, with data sources for justification. Encapsulating this data retrieval mechanism within an MCP service gets us further on the dogfood/toolbuilding path imho. We specify a limited set of questions to answer from the data, graph-RAG, MCP-ize, succeed, iterate.

Above, @shrey-bagga proposes a number of data we should track. We can do this tabularly (brittle) or in a graph (robust). I think we will need to plan for a flexible schema, so that we can pick a sub-problem, make it work, and do it again. I also believe it's good to design big and implement small, so capturing more ideas about what we want before we decide what to do may be helpful.

[claurau]

Other items to consider including in GH:

* presentations
* blogs

Blog posts are published on the CoSAI website, https://www.coalitionforsecureai.org/news/. We can easily create markdown files for those.

[sarahnovotny]

Big Agree. Org-wide: the "front door" needs to be answerable in one click and one minute.

The map-of-work, project-board, and engagement-ladder/Contribution Pathways proposals upthread converge on the same thing — anyone landing on this GH org or coalitionforsecureai.org should be able to resolve three questions fast:

• what has CoSAI published,
• what is in flight right now,
• how do I engage.

A status-and-owner frontmatter convention on every published doc plus an org-level index that renders from it gets us most of the way there cheaply. The richer ideas (graph-RAG, MCP gateway) are real but should sit on top of that minimum, not in place of it.

WS4-specific: we are realizing, to start at least, participation IS the contribution. And, we should say so out loud. WS4 produces guidance other organizations cite and POC(?) software to support that guidance. But this org shouldn't be a target to land a project here as social proof (e.g. the random unsolicited stuff we keep getting sent). The highest-value first move for a new participant (individual or organization) is to show up to a meeting, understand our directional interests (see the 1 minute overview above) comment substantively on an open RFC, or co-author a section of an in-flight priority. Submitting a fresh RFC or dropping a large doc into the PR queue is the advanced path, not the entry path. Finding a way to name this in welcoming language makes the workstream more accessable to outsiders.

Happy to participate with Shrey's common-operating-model proposal. converging what we've started with some skills and processes makes a lot of sense.

cc/ @imolloy

[sarahnovotny]

here's what we started with a reorg of our content and an update on CONTRIBUTING.md .

reorg branch https://github.com/cosai-oasis/ws4-secure-design-agentic-systems/blob/reorg/CONTRIBUTING.md

[imolloy]

I'm fully supportive of this effort and the goals listed. I'm increasingly coming to the conclusion that making this GitHub native is the way to go. It makes it easier to track progress, see who has contributed, and who is working on what. I think we have a few different personas though. There is one persona who wants to engage technically. For them the GitHub issues, PRs, projects and milestones will come naturally. for others it could be quite foreign. One option is to publish the content through github pages. That takes a little more work but could prove valuable for others.

The other reason I see going for GitHub native is what Sarah and I have been working on in terms of automating some of the workflows for managing the meetings. It's not seamless yes, but the hope is over time as more people engage via GitHub it will become more natural.

[afiune]

Strong +1 on the overall direction. I think the most important outcome here is not only better onboarding, but a repeatable cross-workstream collaboration model that makes dependencies, decisions, and deliverables visible across CoSAI.

The one area I haven’t seen covered explicitly is a cross-workstream dependency mechanism.

We should explicitly model cross-workstream dependencies. Without that, workstreams may progress in parallel while unintentionally duplicating concepts, diverging terminology, or missing shared assumptions.

Some lightweight options could include:

• A shared label taxonomy such as cross-ws, needs-tsc, dependency, decision, roadmap, and release
• A convention for linking related issues across repositories
• Leveraging the GitHub Project for overall cross-workstream dependency tracking
• Ensuring cross-WS blockers and alignment risks are visible in the existing weekly TSC review flow

This would help the TSC and workstream leads see where coordination is needed before misalignment becomes expensive to unwind.

[claurau]

Related to "Open Front Door": I would like us to create a unified onboarding process for new GitHub contributors (aka GH organization members). For instance, should we have a pinned discussion item in all WS repos for people request an invite to join the org or repo? Or should this be done in a different way(via a PR template)? What info do we need for the maintainer to be able to review? The PR template might be even better because then maintainers can see if someone has signed the CLA already (which is a prerequisite to being an org/repo member).