docs: shift project health check to PR-based report instead of mandatory presentation

[rocketstack-matt]

What & why

This proposes a change to the project health-check process: instead of a mandatory in-person TOC presentation, each project submits its semi-annual health-check report as a pull request. The TOC reviews the report PR, and a project is only scheduled to present at a future TOC meeting if the TOC has open questions or concerns after reviewing the report. A clear, complete written report may remove the need to present at all.

To make the report easy to produce, this also adds an optional AI-assisted drafting prompt maintainers may use (at their discretion) to generate a first draft from public GitHub and LFX Insights data — while remaining responsible for verifying and amending every figure before submitting.

Changes

• New project-reports/AI-REPORT-PROMPT.md — optional AI drafting prompt for the report (works with an agentic gh-capable assistant, with a fallback path for plain chat assistants). Metrics use a trailing-365-day window labelled per figure.
• project-reports/README.md — Review Process rewritten so the report PR is the primary deliverable and presentation is conditional; references the AI prompt; title and template wording updated; non-participation wording reconciled.

To keep the governing docs internally consistent with the new model:

• operations/processes/projects/incubation.md — the semi-annual maintenance requirement is now report submission, with presentation only if the TOC requests one.
• operations/processes/activities.md — the project health review is conducted from the report PR; LFX Insights reviewed there; present only on TOC concern.
• operations/governance.md — health-review cadence reads "per project report".
• project-reports/SCHEDULE.md — retitled to a report schedule with report-centric columns.
• project-reports/toc-review-email-template.md — notifies maintainers to submit a report PR rather than prepare a presentation.

[Copilot]

Pull request overview

Shifts the FINOS semi-annual project health check from a mandatory TOC presentation to a PR-submitted written report, with presentations scheduled only when the TOC has unresolved questions after reviewing the report.

Changes:

• Rewrites the project health-check process docs to make the report PR the primary deliverable and presentation conditional.
• Adds an optional AI-assisted drafting prompt to help maintainers generate a first draft from public GitHub/LFX data (with explicit verification expectations).
• Updates scheduling and notification templates to align with the report-centric process.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
project-reports/toc-review-email-template.md	Updates maintainer reminder email to request a report PR and make presentations conditional.
project-reports/SCHEDULE.md	Renames schedule to a report schedule and updates column terminology accordingly.
project-reports/README.md	Reframes the review workflow around report PR submission and conditional presentations; links to AI prompt.
project-reports/AI-REPORT-PROMPT.md	Adds an optional AI drafting prompt with sourcing/window requirements and a maintainer verification checklist.
operations/processes/projects/incubation.md	Updates the incubating maintenance requirement from mandatory presentation to report PR + conditional presentation.
operations/processes/activities.md	Updates TOC “Project Health Review” process to be driven by report PR review and follow-up scheduling when needed.
operations/governance.md	Updates governance responsibility table cadence wording from “per project presentation” to “per project report”.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[eddie-knight]

I am not in favor of this for a few reasons:

1. Time cost. This group historically spends far more time on asynchronous conversations, even when fewer people are involved. Work per project will increase, even if some elements of the initial review are automated.
2. Feedback. There is no longer a clear avenue for how TOC feedback will be issued to projects following their report.
3. Questions. PR-based clarification questions dramatically increase the time allocated on each review.
4. Distribution of Labor. Additional process and tooling will be required to assign reviewers for each presentation and subsequent LFX Insights health check. This will also require time allotted by the Chairs to chase down TOC members who forget/fail to follow through on an assignment.
5. Human connection. We previously stated a goal of acting as advisors to the ecosystem, an objective which would be possible with a live component to the project reviews. Without the presentations, we have no current plan to establish a human-to-human connection between maintainers and the TOC.
6. Visibility. Handling reviews in an ongoing cadence gives the TOC a guaranteed way to stay up to date with the ecosystem at large. However, members of the TOC have low-incentive to read an AI-generated report from maintainers, but high incentive to listen to a 5 minute update highlighting the elements that are most interesting to the presenter along with 5 minutes of topical insight from fellow TOC members.

Perhaps it's just my own personal preference, but I have >literally zero interest< in reading reports, and immense interest in hearing updates from maintainers.

The currently approved process allocates 20 minutes per project per year: approximately 20 hours annually when FINOS reaches 60 projects at incubating or graduated level. It allows readers to read and listeners to listen. It enables a human-to-human connection with maintainers. And it has dramatically less risk of complication due to asynchronous coordination of the TOC reviewers.

[psmulovics]

@eddie-knight , I am with you - problem, as @mindthegab put, scaling. When we had 25 projects (eg a year ago), it was feasible to do it more manual and human touch; now with 60+ projects, I don't think it is anymore possible to scale.

[eddie-knight]

Nacking to prevent premature merge.

-1 vote from my perspective

[eddie-knight]

@psmulovics Where is the 60 number coming from? Even if we split up projects like FDC3 and count every SIG on the landscape, I'm only seeing 50 listed. And that's a really liberal way to count already.

Also, this is a bit of a red herring: We're talking about 20 hours annually when we reach 60 projects. We aren't locked in to having the meetings during our open fortnightly meeting — although it shouldn't be a problem because our meetings frequently expand with freeform discussion to fill the time allotted.

[mindthegab]

@psmulovics Where is the 60 number coming from? Even if we split up projects like FDC3 and count every SIG on the landscape, I'm only seeing 50 listed. And that's a really liberal way to count already.

https://landscape.finos.org/stats - the correct number is indeed 50. WIth all the Labs project, and the increased inbound I won't be surprised if we hit 60 soon.

Also, this is a bit of a red herring: We're talking about 20 hours annually when we reach 60 projects. We aren't locked in to having the meetings during our open fortnightly meeting — although it shouldn't be a problem because our meetings frequently expand with freeform discussion to fill the time allotted.

With 2x TOC 1h meetings a month, you have 24 hours TOTAL TOC meeting time. Re scheduling MORE meetings, I have heard from @rocketstack-matt and many others about meeting fatigue and instead they encoursage the FINOS team to reuse exiting venues. So I just wanted to relay that so you have that data point, don't shoot the messenger :)

[mindthegab]

These are my [NON BINDING] comments. I appreciate you guys having a discussion about this today.

FWIW, I think this overall process is more lean and think this aligns with practices I've seen in other mature foundations (e.g. see Apache here. Plus it puts the onus on the maintainers to do a GREAT report and leaves discretion to the TOC as to who they want to speak to.

That being said @eddie-knight - I just wanted to have a conversation about this - I have no vote here and seriously you guys should decide what's best. I also don't want to slow the process down.

I think it's great the TOC wants to talk to project FWIW - from a FINOS operational standpoint my only requirements are:

• Whatever you decide, TOC should reach out ahead of time to finos-project-maintainers@ BEFORE any reach out from the FINOS team. We can then follow up. Outlining the process, expectations, when the next report is due. etc. This should be somethign that happens every 6 months. Goal: Don't surprise them and show them that FINOS is acting on your behalf as you discharge your healtcheck responsibility.

• I don't think it's the plan, but I'd like the FINOS team not to be thrown in a "bulk meeting organization" if the problem you are trying to solve for is "TOC is not great at working offline on PRs and so reviews won't get done". I think this TOC, especially with the newly elected members coming in, has the opportunity to model behavior. In my experience TOC group time is at a premium and I think, like you have done for new contributions, one TOC member could easily take the lead review on the PR and corral a majority of TOC members to review. Then ask @TheJuanAndOnly99 to invite to a standing meeting meeting as needed. We can definitely do the scheduling part, I think tho having the TOC eyes on the reports BEFORE the meeting is valuable.

[rocketstack-matt]

@eddie-knight the PR of the presentation was already a requirement.

All this proposal really does is provide optionality for the TOC as to whether we also need the maintainers to present in person.

It could be that we always request a presentation but at least we have the option not to need to if we believe the report gives sufficient information.

It sounds like you're suggesting in the prior setup we would not review the health check before, just wait for the presentation. In that model every member of the TOC must sit through every presentation and hope there are no questions else there is no way it would only take 10 minutes anyway.

[psmulovics]

@psmulovics Where is the 60 number coming from? Even if we split up projects like FDC3 and count every SIG on the landscape, I'm only seeing 50 listed. And that's a really liberal way to count already.

I just looked at the growth rate and the actual repo count (356 between finos and finos-labs).

[eddie-knight]

Adding this as a later thought, but moving to asynchronous engagement is also removing our plan to stimulate strategic cross-project alignment by scheduling projects topically.

[eminty69]

My preference would be for a discussion in addition to the PR. I would see it as pretty central to the TOC to have a good grasp of the projects, their strengths and roadmaps, which I don't think we get enough from reading a PR. The number of projects is a concern though and I wonder if we have a rule that projects can't have more than 2(?) consecutive reviews done by PR? This would help us stick with the plan to schedule projects topically, but give us a little more room

[maria-mcparland]

I think it would be worth starting the process and seeing how it works in practice.

We’ve talked about it over the last few meetings, and it feels like we’re at the point where trying it out would give us a much better sense of the value and any adjustments we might need to make.

From my perspective, project health checks are an important part of what the TOC can contribute. While reviewing PRs is valuable, the health checks provide a different kind of insight and engagement with project teams.

Would it make sense to kick off the presentation process and then review it after we’ve completed a few? We could learn from the experience and decide how best to proceed.

Perhaps we could aim to organise the first few in July.

[awaiken]

I know I'm chiming in late but my vote is to give this process a shot. I agree with both Elspeth and Maria's perspective. I like having the "optionality" and I think we'll understand fairly quickly if we're going to lose any of the human touch, but I doubt it. +1

[psmulovics]

Tried the process with #292 and #296 today. Looking forward to comments on this issue from @finos/technical-oversight-committee on whether the process seems to be sustainable and whether we are OK to merge this PR.