TSC General Meeting Agenda - 2025-08-21

[cdils]

Meeting Purpose: Strategic direction, governance, policy, cross-team priorities, and project oversight.

Audience: FAIR TSC members & open observers (as allowed).

Please add agenda items as comments below and up-vote on the items you'd like to discuss.

Meeting details

• Meeting is August 21, 2025 – 19:00 UTC (see it in your time zone)
• Link to Meeting Calendar

How to join

This call is open to anyone, but note that you need to have a profile/account at OpenProfile.dev to join the call.

Reminders

FAIR is part of the Linux Foundation. Meeting attendees are subject to both the Code of Conduct and the LF Antitrust Policy.

This meeting is recorded and publicly available via your OpenProfile.dev account.

[toderash]

Website Content

Content for review: https://docs.google.com/document/d/1hznQKiUKfN09-j3uxLfzKAGvxaZXYqSPmKezO-gLMJI/edit?usp=sharing

Please provide all feedback promptly.

Placeholder for @joedolson

[toderash]

Orphaned Projects

Came to light in describing all the WGs for the website content. All of our projects / repos should really be "owned" by a WG. The Technical Independence WG created two of these, but in closing the group (Temporary charter), we kind of orphaned them. Suggest we assign the FAIR Plugin to the FAIR-WG. The Planet instance should be shared (I think) between Community WG (wrt content) and Infrastructure WG (wrt platform). We should formally assign these for the record so those WG's can have it as part of their mandate.

[cdils]

Update: Creation of Infrastructure WG

[toderash]

Proposed Trust-Label (Moderation) WG

While we aren't ready to implement a full labeling system yet, a number of conversations are indicating the need to develop some guidelines as a bridge between the Moderation Spec and the FAIR Protocol spec. There are a few points where they don't quite align properly, so before changing either of them, I propose a WG to state the specific business rules we will need in order to determine what kind and level of trust we need in order to apply specific labels. Current discussions are largely in technical contexts for technical reasons or decisions that don't have a set of business rule requirements to work from, so I think we need to reframe this to get it right.

The initial deliverable would be largely non-technical to describe business needs only, and we should strive to have this in draft form as of the 1.0 release, as it will reflect the direction we plan to take to implement the trust signals that certain stakehholders (i.e., hosts) will be looking for. From there, with potential stakeholder review and comment, the next deliverable would be a set of technical requirements for the Trust Labeller and/or the Protocol & related nodes in the network that will be needed to implement the tech side of the identified business rules.

Eventually this WG would morph into being responsible for operating the trust labeller, so I propose forming a permanent Trust Signals WG which will receive changes to its mandate as the ecosystem matures with the development and implementation envisioned by the current mod spec.

[toderash]

Refer to Issue 49 for a longer description of factors and other issues for which this is a blocker. The proposed WG would need to tackle this somewhat urgently.

[cdils]

Agreed to move forward with this WG

[tacoverdo]

While working on the website text, I noticed I got lost a lot in all the documentation on GitHub. It's spread across all the repos, which makes it hard to navigate.

Could we create something like developer.yoast.com to bundle everything in one place?

[jazzsequence]

Do we want to revisit meeting up in Portland?