From f7944f8a21a6e41d1ddfb0011c1b00c32870e38a Mon Sep 17 00:00:00 2001 From: Giacomo Peru Date: Mon, 13 Jul 2026 09:29:14 +0100 Subject: [PATCH 1/4] Update July 13 agenda: Guido/EU ESC context, webinar timing, Barker contact status Co-Authored-By: Claude Sonnet 5 --- meetings/tf2-rolling-notes.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meetings/tf2-rolling-notes.md b/meetings/tf2-rolling-notes.md index 2f2da63..2361513 100644 --- a/meetings/tf2-rolling-notes.md +++ b/meetings/tf2-rolling-notes.md @@ -12,7 +12,7 @@ Repository: ## A. AI position -No agreed EVERSE position on AI. Feeds Fotis's policy brief, due February 2027. +No agreed EVERSE position on AI. Feeds Fotis's policy brief, due February 2027, and Guido's EU ESC (Brussels) talk — asked for messaging, not yet provided. ## B. Michael Sparks document @@ -33,7 +33,7 @@ Hugo's prototypes (TeSS metadata agent, RSQKit chatbot) — blocked on compute a ## E. AI webinar -Joint with ReSA (Michelle Barker), target October/November. Contact not yet made. +Joint with ReSA — Carlos contacted Michelle Barker, awaiting outcome. Target early November, after the October industry survey webinar. ## F. RF section reviews From 153318b45532743721ebb2b6ac6d1da5d3ca3979 Mon Sep 17 00:00:00 2001 From: Giacomo Peru Date: Mon, 13 Jul 2026 14:31:11 +0100 Subject: [PATCH 2/4] Fill in TF2 minutes for 13 July 2026 Co-Authored-By: Claude Sonnet 5 --- meetings/tf2-rolling-notes.md | 53 +++++++++++++++++++++++++++++++++-- 1 file changed, 50 insertions(+), 3 deletions(-) diff --git a/meetings/tf2-rolling-notes.md b/meetings/tf2-rolling-notes.md index 2361513..3884d20 100644 --- a/meetings/tf2-rolling-notes.md +++ b/meetings/tf2-rolling-notes.md @@ -2,13 +2,13 @@ Repository: -# TF2 Meeting Agenda — 13 July 2026 +# TF2 Meeting Minutes — 13 July 2026 **Date:** Monday, 13 July 2026 **Time:** 11:00 UK / 12:00 CET **Location:** -**Attending:** Fotis, Carlos (from 11:15) +**Attending:** Giacomo Peru, Neil Chue Hong, Fotis, Caterina Doglioni, Michael Sparks, Natalia (new OpenAIRE contact, replacing Stefania), Hugo Bacard, Shoaib Sufi -**Apologies:** +**Apologies:** Carlos did not appear to join (not audible in the transcript, despite being expected from 11:15) ## A. AI position @@ -43,8 +43,55 @@ PR #26 (sustainability) and PR #30 (Three-Tiers View) open, unreviewed. #12–#1 Mattermost → CERN migration. Helmholtz read-only 15 July. +## Discussion — 13 July call + +The call was almost entirely about AI; RF section reviews and Mattermost were not discussed live. + +**Fotis's five-point draft AI statement.** Fotis shared five initial points he intends to feed into the policy brief, already used informally as input for Guido's EU ESC talk and discussed briefly at MARB. Not finalised, offered for comment: +1. Software must be recognised as the necessary substrate for AI — without software, AI is just files/weights. +2. Track and flag when code is AI-generated vs human-authored/curated. +3. Frame explainability/traceability as a software-quality dimension; fund tooling/infrastructure that can audit AI-generated code. +4. Fund software maintenance as a centrally-funded activity in its own right ("the hill Fotis will die on") — code generation is now cheap, maintaining and supporting it is not, and requires human judgement. +5. Define governance for AI agents acting as "software authors" before the line between machine- and human-authored code becomes too blurred to draw. + +Feedback on the five points: +- Neil supports point 4 but flagged a risk: funding for maintenance shouldn't come with an implicit obligation to maintain everything AI generates. Suggested TF2 needs to work out how point 4 ties to point 1 and to software quality more broadly, not just maintenance. +- Caterina agreed funding is central but said point 4 needs very careful wording — funders (especially in the UK) are already primed to believe software is disposable/regenerable, so the statement needs to make the real cost of AI-generated code visible before asking for money. She rated point 5 as equally important from a training/culture angle: she is seeing students on Google Summer of Code effectively delegating tasks to AI rather than learning, which she sees as damaging to open-source contributor culture. Suggested point 5 could work as a no-cost policy recommendation (e.g. aimed at a body like OECD) since it doesn't require funding, just guidance. +- Michael Sparks made a broader point: as AI produces more code, the domain- and software-engineering expertise needed to check correctness becomes scarcer relative to output volume, not more abundant — the opposite of the usual "AI creates abundance" framing. Argued the discussion should focus on people and roles in the process (who reads the paper, who checks the spec, who verifies the code against it) rather than just "human in the loop"; some of these roles can be automated when reproducing known work, but extending into new work still needs people, so throughput is capped by people, not machines. +- Giacomo pushed back gently on how widespread the "software is free now" belief actually is, at least in his own environment, and drew on RSMF experience: funding decisions should follow research-software impact and user base rather than lines of code, since code volume alone is now cheap to produce. +- Fotis's own synthesis: most current AI-related problems trace back to poor software quality; the throughline across all five points is that we need to distinguish fully-AI-generated code from code that has been curated/reviewed by humans, and fund the curation/maintenance effort directly rather than just the initial creation. +- Shoaib raised a gap: the whole statement assumes a baseline level of AI knowledge and practice that most people don't have. Proposed adding an explicit capacity-building element — training material and a commitment to raising the general skill level so people can actually engage with the position once published. + +**Timeline and ownership.** Fotis said the policy brief deadline is "February... March will probably be the deadline" (transcript unclear which is authoritative — worth confirming, since prior planning assumed Feb 2027). Plan: iterate through the summer and into Sept/Oct via whatever channels are available (weekly management meetings, etc.), aim for a reasonably mature version by the November stakeholder event to gather wider external feedback, then two more months to finalise. He is also planning to add non-AI-related points to the same brief (e.g. European software sovereignty). For now he is the sole owner/editor; document lives on SharePoint/Mattermost boards, not yet in the ai-everse GitHub repo — he had no strong objection to moving it there, just hasn't done so. + +**Infrastructure question (local vs frontier models).** Shoaib asked whether EVERSE has (or should have) a position on local vs frontier AI models — relevant to privacy, equity, and MCP-enabled tooling — and suggested this belongs in the policy document rather than RSQKit. Caterina agreed it's a policy-level, equity issue (not everyone can afford frontier-model compute) but also wants practical RSQKit content on setting up and reviewing local coding models, and offered to share her own experience. Fotis was cautious about committing to any specific infrastructure position given how fast the landscape moves (his example: MCP-to-agent tooling has changed significantly in the last 3-4 months); prefers treating this as caveated "good practice" pointers/reading list rather than firm policy. He also flagged a related EOSC-funded project, informally referred to as "GenAI" and led by someone whose name did not transcribe clearly, pursuing a different AI-infrastructure approach to EOSC/AI4EOSC — worth keeping an eye on as a possible parallel/competing effort. + +**Guido's EU ESC (Brussels) talk.** Already happened by the time of this call, so nothing further needed from EVERSE for it. Fotis will try to obtain any slides/recording shared by the organisers or Commission. The session Guido led was specifically on "AI and software"; Fotis is mainly interested in what input/feedback came out of it. + +**Michael Sparks document — walkthrough.** Michael talked through the AI Intensity Spectrum diagram. He deliberately rejected framing this as a "ladder" or numbered "steps" (implies one level is inherently better, which he doesn't think is true or useful) in favour of a spectrum/classification by intensity — where higher intensity means more tokens, more resources, more review burden, not more merit. Traditional coding sits at one end; no-GenAI-use is a legitimate position at the other (compliance, risk, or practical reasons). Each level carries its own risks (e.g. ownership confusion, over-trusting high-quality-looking output leading to real incidents — dropped databases, deleted email archives, bad production pushes). Scope is larger than a single RSQKit page — it will become a page collection (similar to the existing CI/CD or citation collections), with the diagram as the top-level orientation page; Michael is currently splitting the long source document into smaller pieces. + +Feedback: +- Caterina liked it overall, minor tweaks suggested. Flagged a risk that AI-sceptical readers may dismiss it purely because it visually reads as AI-generated (styling/fonts); suggested using Michael's draft as raw input/a first pass, then having the group produce a distinct "final" human-edited version, to avoid losing part of the audience. Liked that it preserves the three broad categories (traditional / assisted / generated) also used in the "Ten Rules for Research Software" reference cited in the document. +- Neil strongly endorsed the framing as a way to stop different audiences talking past each other about "AI use" — likes both the three broad categories and the per-level risk mapping. Suggested applying the same framework to human-only vs mixed human/AI collaborative development, to extend into how EVERSE talks about quality in mixed teams. Shares Caterina's audience-loss concern but isn't worried about it yet at this exploratory stage, as long as it's addressed before wider release. +- Natalia (attending for the first time) hadn't read the full document but asked for it to be made more actionable — e.g. clicking through to a listed risk should surface concrete guidance on what to actually do, and each risk/practice should be tied to a specific audience (RSE, lab PI, funder, etc.). +- Giacomo agreed an actionable/tool-like implementation would be valuable and offered to put Michael's document on a future TF2 agenda if people want to keep discussing it. + +**Hugo: RSQKit chatbot and TeSS metadata agent.** Recap: the RAG-based RSQKit chatbot demo raised the question of how to improve it, particularly having it follow links out from RSQKit pages rather than just the pages themselves. Separately, the TeSS metadata-extraction agent (built with Kenneth Rioja, ~May) works but is constrained by available LLM/compute resources. Hugo said he doesn't know how to prioritise next steps given the resource constraints and the still-unresolved authorisation/policy questions, and asked for a collective steer. +- Shoaib recapped an earlier RSQKit editorial-board discussion: the chatbot should ideally index RSQKit pages plus one level of outbound links ("pages plus one"), since some pages are conceptual overviews pointing to deeper external material — not a hard requirement, but a worthwhile experiment; would enlarge the RAG index. +- A further stretch goal was raised (Michael/Hugo): turning RSQKit task pages into "skills" that could act directly on a user's own codebase (e.g. "improve this code against this practice") rather than only answering questions about RSQKit content. +- Discussion paused for time; there are open questions about hosting and compute implications of enabling this kind of search/agent behaviour. Deferred to the 17 August call — though Hugo will be on leave and unable to attend (back 24 August). + +**Caterina: HSF/ESCAPE "responsible coding with AI" event, 29 July.** EVERSE (via Caterina) is informally connected to an HSF/ESCAPE event on responsible AI coding, in two weeks. Framed as a community-of-practice session (people sharing real experience) rather than a heavily promoted event; limited engagement expected given short notice and timing. Michael and Caterina will personally contribute; there's a security-policy angle too (e.g. not leaking tokens). Caterina's proposal: keep the two efforts largely separate rather than presenting the full EVERSE policy discussion there — bring back a summary of EVERSE's work into HSF/ESCAPE instead. Note: HSF has been asked by its computing committee for practical AI-contribution guidelines on a Sept/Oct timescale, which is faster than EVERSE's own policy timeline — a timeline mismatch worth being aware of. +- Agreed content for 29 July: mainly practical/demonstrable material (RSQKit, Hugo's prototype work), not the unfinished policy brief; a brief mention that policy work is in progress is enough, no detail needed. Fotis will attend but wants Michael to lead the EVERSE presentation. Caterina asked Hugo to send her a short written summary of his work to fold in — kept deliberately lightweight. + +**Next meeting.** Confirmed for **17 August**. Note Hugo is on leave from end of July, back 24 August, so will miss this one — his chatbot/TeSS discussion will need to pick up without him or be held over again. + ## Key actions +- Giacomo: organise a separate follow-up meeting after 24 August with Hugo, Fotis, Shoaib, and Michael on chatbot/skills/AI-tooling direction +- Michael Sparks document — agenda item for 17 August call to continue the discussion +- Giacomo: PR #26 review — still pending, carried forward again + --- # TF2 Meeting Minutes — 22 June 2026 From cfd8f2933a277df8b9ccc3014a97088abf4c9da4 Mon Sep 17 00:00:00 2001 From: Giacomo Peru Date: Mon, 13 Jul 2026 14:37:01 +0100 Subject: [PATCH 3/4] Merge Fotis's real AI-statement text and HSF/ESCAPE Indico link into 13 July minutes Co-Authored-By: Claude Sonnet 5 --- meetings/tf2-rolling-notes.md | 37 ++++++++++++++++++++++++++--------- 1 file changed, 28 insertions(+), 9 deletions(-) diff --git a/meetings/tf2-rolling-notes.md b/meetings/tf2-rolling-notes.md index 3884d20..bc3ab40 100644 --- a/meetings/tf2-rolling-notes.md +++ b/meetings/tf2-rolling-notes.md @@ -12,7 +12,29 @@ Repository: ## A. AI position -No agreed EVERSE position on AI. Feeds Fotis's policy brief, due February 2027, and Guido's EU ESC (Brussels) talk — asked for messaging, not yet provided. +No agreed EVERSE position on AI. Feeds Fotis's policy brief, due February 2027, and Guido's EOSC (Brussels) talk — asked for messaging, not yet provided. + +Fotis's initial thoughts, shared ahead of the call: + +1. We need to make sure that research software is treated as the substrate AI runs on and fund it accordingly. + - This directly builds on ReSA's 2024 position paper "Research software is critical to the future of AI-driven research" (DOI 10.5281/zenodo.13350748), which argues AI strategies wrongly treat models as extensions of data and exclude the underlying software. The additional element here is to (ideally) have EOSC budget in software and open-source dependency layer explicitly for AI models, not just compute (aka EOSC EU Node, among others). + +2. Mandate machine-readable provenance for AI-generated research software, before the attribution window closes. + - The goal here is to extend our EVERSE recognition framework and existing software-metadata standards (CodeMeta, CITATION.cff) to record what was human-authored, AI-assisted, or agent-generated. Agent contributions are currently still traceable, but that "signature" will likely disappear as agents integrate more seamlessly, so provenance should be captured now as a funding condition. + +3. Reframe the AI reproducibility crisis as a software-quality failure, and fund leakage-auditing tools as infrastructure. + - Building on RSQKit: extend software-quality frameworks to ML-specific failure modes (leakage, pipeline determinism, data/model versioning), using this as a mechanism to safeguard at the software level. + +4. Make software maintenance the central funded activity, because AI generates code far faster than maintainers. + - Effectively building on the Amsterdam Declaration, ADORE, and ReSA's maintenance and personnel recommendations: as agentic coding collapses the cost of writing code, the cost of maintaining it rises sharply (maintenance here means code review, curation, stewardship). Funding by default should go to the scarce, high-value human work, not "new software." + +5. Build governance for autonomous agents as research-software authors now, not after they're ubiquitous. + - A gap not currently discussed: a clearly defined governance standard for agent contributions, including disclosures, human-review thresholds, accountability, and provenance. + +6. Capacity building and direct skill training for humans (not AI). + - Training people in this area rather than relying fully on AI. De-skilling is a clear emerging challenge. + +Michael Sparks's addition: across all of this, domain and software-engineering experience becomes an even scarcer resource relative to the volume of content being created — and that experience is a human quality necessary for correctness. The framing should be "people in the process," not just "human in the loop." ## B. Michael Sparks document @@ -25,6 +47,8 @@ Local copy: `~/Desktop/Desktop2026_07_07/task_How_do_you_use_AI_to_develop_quali Caterina Doglioni: HSF/ESCAPE AI-assisted-coding guidelines, lighter-weight than RSQKit, proposed co-organised with EVERSE. +Event: + ## D. What do we build No model training. Guidance and skills/prompts. MCPs undecided. @@ -47,20 +71,15 @@ Mattermost → CERN migration. Helmholtz read-only 15 July. The call was almost entirely about AI; RF section reviews and Mattermost were not discussed live. -**Fotis's five-point draft AI statement.** Fotis shared five initial points he intends to feed into the policy brief, already used informally as input for Guido's EU ESC talk and discussed briefly at MARB. Not finalised, offered for comment: -1. Software must be recognised as the necessary substrate for AI — without software, AI is just files/weights. -2. Track and flag when code is AI-generated vs human-authored/curated. -3. Frame explainability/traceability as a software-quality dimension; fund tooling/infrastructure that can audit AI-generated code. -4. Fund software maintenance as a centrally-funded activity in its own right ("the hill Fotis will die on") — code generation is now cheap, maintaining and supporting it is not, and requires human judgement. -5. Define governance for AI agents acting as "software authors" before the line between machine- and human-authored code becomes too blurred to draw. +**Fotis's draft AI statement.** Fotis shared the six points now recorded under item A above — intended to feed the policy brief, already used informally as input for Guido's EOSC talk and discussed briefly at MARB. Not finalised, offered for comment. -Feedback on the five points: +Feedback on the points: - Neil supports point 4 but flagged a risk: funding for maintenance shouldn't come with an implicit obligation to maintain everything AI generates. Suggested TF2 needs to work out how point 4 ties to point 1 and to software quality more broadly, not just maintenance. - Caterina agreed funding is central but said point 4 needs very careful wording — funders (especially in the UK) are already primed to believe software is disposable/regenerable, so the statement needs to make the real cost of AI-generated code visible before asking for money. She rated point 5 as equally important from a training/culture angle: she is seeing students on Google Summer of Code effectively delegating tasks to AI rather than learning, which she sees as damaging to open-source contributor culture. Suggested point 5 could work as a no-cost policy recommendation (e.g. aimed at a body like OECD) since it doesn't require funding, just guidance. - Michael Sparks made a broader point: as AI produces more code, the domain- and software-engineering expertise needed to check correctness becomes scarcer relative to output volume, not more abundant — the opposite of the usual "AI creates abundance" framing. Argued the discussion should focus on people and roles in the process (who reads the paper, who checks the spec, who verifies the code against it) rather than just "human in the loop"; some of these roles can be automated when reproducing known work, but extending into new work still needs people, so throughput is capped by people, not machines. - Giacomo pushed back gently on how widespread the "software is free now" belief actually is, at least in his own environment, and drew on RSMF experience: funding decisions should follow research-software impact and user base rather than lines of code, since code volume alone is now cheap to produce. - Fotis's own synthesis: most current AI-related problems trace back to poor software quality; the throughline across all five points is that we need to distinguish fully-AI-generated code from code that has been curated/reviewed by humans, and fund the curation/maintenance effort directly rather than just the initial creation. -- Shoaib raised a gap: the whole statement assumes a baseline level of AI knowledge and practice that most people don't have. Proposed adding an explicit capacity-building element — training material and a commitment to raising the general skill level so people can actually engage with the position once published. +- Shoaib raised a gap: the statement assumes a baseline level of AI knowledge and practice that most people don't have, and proposed an explicit capacity-building element — training material and a commitment to raising the general skill level so people can actually engage with the position once published. (Now point 6 above.) **Timeline and ownership.** Fotis said the policy brief deadline is "February... March will probably be the deadline" (transcript unclear which is authoritative — worth confirming, since prior planning assumed Feb 2027). Plan: iterate through the summer and into Sept/Oct via whatever channels are available (weekly management meetings, etc.), aim for a reasonably mature version by the November stakeholder event to gather wider external feedback, then two more months to finalise. He is also planning to add non-AI-related points to the same brief (e.g. European software sovereignty). For now he is the sole owner/editor; document lives on SharePoint/Mattermost boards, not yet in the ai-everse GitHub repo — he had no strong objection to moving it there, just hasn't done so. From dd82841f9f38a8b239a16b07348e727118ddac0e Mon Sep 17 00:00:00 2001 From: Giacomo Peru Date: Thu, 16 Jul 2026 16:52:11 +0100 Subject: [PATCH 4/4] Shorten 13 July minutes and fold in chat context (Daniel Garijo, authorship debate) Co-Authored-By: Claude Sonnet 5 --- meetings/tf2-rolling-notes.md | 114 +++++++--------------------------- 1 file changed, 22 insertions(+), 92 deletions(-) diff --git a/meetings/tf2-rolling-notes.md b/meetings/tf2-rolling-notes.md index bc3ab40..b1a36d8 100644 --- a/meetings/tf2-rolling-notes.md +++ b/meetings/tf2-rolling-notes.md @@ -4,112 +4,42 @@ Repository: # TF2 Meeting Minutes — 13 July 2026 -**Date:** Monday, 13 July 2026 **Time:** 11:00 UK / 12:00 CET **Location:** +**Date:** Monday, 13 July 2026 **Time:** 11:00 UK / 12:00 CET -**Attending:** Giacomo Peru, Neil Chue Hong, Fotis, Caterina Doglioni, Michael Sparks, Natalia (new OpenAIRE contact, replacing Stefania), Hugo Bacard, Shoaib Sufi +**Attending:** Giacomo Peru, Neil Chue Hong, Fotis, Caterina Doglioni, Michael Sparks, Natalia (new OpenAIRE contact), Hugo Bacard, Shoaib Sufi, Daniel Garijo -**Apologies:** Carlos did not appear to join (not audible in the transcript, despite being expected from 11:15) +**Apologies:** Carlos (didn't join) -## A. AI position +The whole call was about AI. RF section reviews and the Mattermost migration were not discussed — status only, tracked on GitHub (PR #26, PR #30 still open and unreviewed). -No agreed EVERSE position on AI. Feeds Fotis's policy brief, due February 2027, and Guido's EOSC (Brussels) talk — asked for messaging, not yet provided. +**1. Fotis's draft AI statement** (feeds his policy brief, due early 2027) -Fotis's initial thoughts, shared ahead of the call: +Six points, shared for feedback, not finalised: +1. Fund research software properly — AI can't work without it. +2. Track who/what wrote code (human vs AI) before that becomes impossible to tell. +3. Treat AI-generated code problems as a software-quality issue — fund tools that check it (builds on RSQKit). +4. Fund maintenance, not just new code — AI made writing code cheap, but someone still has to look after it. +5. Set rules now for AI agents as "authors" — before it's too late to define this properly. +6. Train people, not just AI — added after Shoaib pointed out most people don't know enough about AI yet to engage with any of this. -1. We need to make sure that research software is treated as the substrate AI runs on and fund it accordingly. - - This directly builds on ReSA's 2024 position paper "Research software is critical to the future of AI-driven research" (DOI 10.5281/zenodo.13350748), which argues AI strategies wrongly treat models as extensions of data and exclude the underlying software. The additional element here is to (ideally) have EOSC budget in software and open-source dependency layer explicitly for AI models, not just compute (aka EOSC EU Node, among others). +General agreement, with pushback: Neil worried point 4 shouldn't force projects to maintain everything AI creates. Caterina wants the "software is free" myth debunked before asking funders for money, and is separately worried about students leaning on AI instead of learning. Michael's counterpoint: as AI writes more code, the humans able to check it become the bottleneck, not the machines. Daniel and Caterina suggested two more angles worth adding: responsibility/accountability, and environmental sustainability (link to RSQKit's green software page) — not yet folded in. -2. Mandate machine-readable provenance for AI-generated research software, before the attribution window closes. - - The goal here is to extend our EVERSE recognition framework and existing software-metadata standards (CodeMeta, CITATION.cff) to record what was human-authored, AI-assisted, or agent-generated. Agent contributions are currently still traceable, but that "signature" will likely disappear as agents integrate more seamlessly, so provenance should be captured now as a funding condition. +**2. Who "owns" AI-written code?** Live debate, unresolved: Shoaib says AI can't be an author — a human must stay accountable (cited a study showing journals agree). Daniel disagreed — he already gets PRs and emails from AI agents. Neil noted that legally, accountability can sit with a company, not just a person. Feeds back into points 2/5 above. -3. Reframe the AI reproducibility crisis as a software-quality failure, and fund leakage-auditing tools as infrastructure. - - Building on RSQKit: extend software-quality frameworks to ML-specific failure modes (leakage, pipeline determinism, data/model versioning), using this as a mechanism to safeguard at the software level. +**3. Michael's "AI Intensity" document** — a diagram showing a spectrum from no-AI to heavy-AI use (deliberately not a "ladder" — more AI isn't automatically better). Well received. Ask: a human-edited final version (so it isn't dismissed as AI-written) and make it more actionable — what to actually do at each level. -4. Make software maintenance the central funded activity, because AI generates code far faster than maintainers. - - Effectively building on the Amsterdam Declaration, ADORE, and ReSA's maintenance and personnel recommendations: as agentic coding collapses the cost of writing code, the cost of maintaining it rises sharply (maintenance here means code review, curation, stewardship). Funding by default should go to the scarce, high-value human work, not "new software." +**4. Hugo's chatbot/TeSS tool** — still stuck on compute and sign-off. Paused for time, picked up in a separate meeting after 24 August. -5. Build governance for autonomous agents as research-software authors now, not after they're ubiquitous. - - A gap not currently discussed: a clearly defined governance standard for agent contributions, including disclosures, human-review thresholds, accountability, and provenance. +**5. HSF/ESCAPE event, 29 July** — Caterina and Michael giving a talk on responsible AI coding, using RSQKit material, not the unfinished policy brief. -6. Capacity building and direct skill training for humans (not AI). - - Training people in this area rather than relying fully on AI. De-skilling is a clear emerging challenge. - -Michael Sparks's addition: across all of this, domain and software-engineering experience becomes an even scarcer resource relative to the volume of content being created — and that experience is a human quality necessary for correctness. The framing should be "people in the process," not just "human in the loop." - -## B. Michael Sparks document - -"How do you use AI to develop quality research software" — Spectrum of AI Intensity framework. RSQKit split targeted for today. - -Google Doc: -Local copy: `~/Desktop/Desktop2026_07_07/task_How_do_you_use_AI_to_develop_quality_research_software.docx` - -## C. HSF/ESCAPE collaboration - -Caterina Doglioni: HSF/ESCAPE AI-assisted-coding guidelines, lighter-weight than RSQKit, proposed co-organised with EVERSE. - -Event: - -## D. What do we build - -No model training. Guidance and skills/prompts. MCPs undecided. - -Hugo's prototypes (TeSS metadata agent, RSQKit chatbot) — blocked on compute and authorisation, no change since April. - -## E. AI webinar - -Joint with ReSA — Carlos contacted Michelle Barker, awaiting outcome. Target early November, after the October industry survey webinar. - -## F. RF section reviews - -PR #26 (sustainability) and PR #30 (Three-Tiers View) open, unreviewed. #12–#15 unowned. Status only — tracked on GitHub. - -## G. AOB - -Mattermost → CERN migration. Helmholtz read-only 15 July. - -## Discussion — 13 July call - -The call was almost entirely about AI; RF section reviews and Mattermost were not discussed live. - -**Fotis's draft AI statement.** Fotis shared the six points now recorded under item A above — intended to feed the policy brief, already used informally as input for Guido's EOSC talk and discussed briefly at MARB. Not finalised, offered for comment. - -Feedback on the points: -- Neil supports point 4 but flagged a risk: funding for maintenance shouldn't come with an implicit obligation to maintain everything AI generates. Suggested TF2 needs to work out how point 4 ties to point 1 and to software quality more broadly, not just maintenance. -- Caterina agreed funding is central but said point 4 needs very careful wording — funders (especially in the UK) are already primed to believe software is disposable/regenerable, so the statement needs to make the real cost of AI-generated code visible before asking for money. She rated point 5 as equally important from a training/culture angle: she is seeing students on Google Summer of Code effectively delegating tasks to AI rather than learning, which she sees as damaging to open-source contributor culture. Suggested point 5 could work as a no-cost policy recommendation (e.g. aimed at a body like OECD) since it doesn't require funding, just guidance. -- Michael Sparks made a broader point: as AI produces more code, the domain- and software-engineering expertise needed to check correctness becomes scarcer relative to output volume, not more abundant — the opposite of the usual "AI creates abundance" framing. Argued the discussion should focus on people and roles in the process (who reads the paper, who checks the spec, who verifies the code against it) rather than just "human in the loop"; some of these roles can be automated when reproducing known work, but extending into new work still needs people, so throughput is capped by people, not machines. -- Giacomo pushed back gently on how widespread the "software is free now" belief actually is, at least in his own environment, and drew on RSMF experience: funding decisions should follow research-software impact and user base rather than lines of code, since code volume alone is now cheap to produce. -- Fotis's own synthesis: most current AI-related problems trace back to poor software quality; the throughline across all five points is that we need to distinguish fully-AI-generated code from code that has been curated/reviewed by humans, and fund the curation/maintenance effort directly rather than just the initial creation. -- Shoaib raised a gap: the statement assumes a baseline level of AI knowledge and practice that most people don't have, and proposed an explicit capacity-building element — training material and a commitment to raising the general skill level so people can actually engage with the position once published. (Now point 6 above.) - -**Timeline and ownership.** Fotis said the policy brief deadline is "February... March will probably be the deadline" (transcript unclear which is authoritative — worth confirming, since prior planning assumed Feb 2027). Plan: iterate through the summer and into Sept/Oct via whatever channels are available (weekly management meetings, etc.), aim for a reasonably mature version by the November stakeholder event to gather wider external feedback, then two more months to finalise. He is also planning to add non-AI-related points to the same brief (e.g. European software sovereignty). For now he is the sole owner/editor; document lives on SharePoint/Mattermost boards, not yet in the ai-everse GitHub repo — he had no strong objection to moving it there, just hasn't done so. - -**Infrastructure question (local vs frontier models).** Shoaib asked whether EVERSE has (or should have) a position on local vs frontier AI models — relevant to privacy, equity, and MCP-enabled tooling — and suggested this belongs in the policy document rather than RSQKit. Caterina agreed it's a policy-level, equity issue (not everyone can afford frontier-model compute) but also wants practical RSQKit content on setting up and reviewing local coding models, and offered to share her own experience. Fotis was cautious about committing to any specific infrastructure position given how fast the landscape moves (his example: MCP-to-agent tooling has changed significantly in the last 3-4 months); prefers treating this as caveated "good practice" pointers/reading list rather than firm policy. He also flagged a related EOSC-funded project, informally referred to as "GenAI" and led by someone whose name did not transcribe clearly, pursuing a different AI-infrastructure approach to EOSC/AI4EOSC — worth keeping an eye on as a possible parallel/competing effort. - -**Guido's EU ESC (Brussels) talk.** Already happened by the time of this call, so nothing further needed from EVERSE for it. Fotis will try to obtain any slides/recording shared by the organisers or Commission. The session Guido led was specifically on "AI and software"; Fotis is mainly interested in what input/feedback came out of it. - -**Michael Sparks document — walkthrough.** Michael talked through the AI Intensity Spectrum diagram. He deliberately rejected framing this as a "ladder" or numbered "steps" (implies one level is inherently better, which he doesn't think is true or useful) in favour of a spectrum/classification by intensity — where higher intensity means more tokens, more resources, more review burden, not more merit. Traditional coding sits at one end; no-GenAI-use is a legitimate position at the other (compliance, risk, or practical reasons). Each level carries its own risks (e.g. ownership confusion, over-trusting high-quality-looking output leading to real incidents — dropped databases, deleted email archives, bad production pushes). Scope is larger than a single RSQKit page — it will become a page collection (similar to the existing CI/CD or citation collections), with the diagram as the top-level orientation page; Michael is currently splitting the long source document into smaller pieces. - -Feedback: -- Caterina liked it overall, minor tweaks suggested. Flagged a risk that AI-sceptical readers may dismiss it purely because it visually reads as AI-generated (styling/fonts); suggested using Michael's draft as raw input/a first pass, then having the group produce a distinct "final" human-edited version, to avoid losing part of the audience. Liked that it preserves the three broad categories (traditional / assisted / generated) also used in the "Ten Rules for Research Software" reference cited in the document. -- Neil strongly endorsed the framing as a way to stop different audiences talking past each other about "AI use" — likes both the three broad categories and the per-level risk mapping. Suggested applying the same framework to human-only vs mixed human/AI collaborative development, to extend into how EVERSE talks about quality in mixed teams. Shares Caterina's audience-loss concern but isn't worried about it yet at this exploratory stage, as long as it's addressed before wider release. -- Natalia (attending for the first time) hadn't read the full document but asked for it to be made more actionable — e.g. clicking through to a listed risk should surface concrete guidance on what to actually do, and each risk/practice should be tied to a specific audience (RSE, lab PI, funder, etc.). -- Giacomo agreed an actionable/tool-like implementation would be valuable and offered to put Michael's document on a future TF2 agenda if people want to keep discussing it. - -**Hugo: RSQKit chatbot and TeSS metadata agent.** Recap: the RAG-based RSQKit chatbot demo raised the question of how to improve it, particularly having it follow links out from RSQKit pages rather than just the pages themselves. Separately, the TeSS metadata-extraction agent (built with Kenneth Rioja, ~May) works but is constrained by available LLM/compute resources. Hugo said he doesn't know how to prioritise next steps given the resource constraints and the still-unresolved authorisation/policy questions, and asked for a collective steer. -- Shoaib recapped an earlier RSQKit editorial-board discussion: the chatbot should ideally index RSQKit pages plus one level of outbound links ("pages plus one"), since some pages are conceptual overviews pointing to deeper external material — not a hard requirement, but a worthwhile experiment; would enlarge the RAG index. -- A further stretch goal was raised (Michael/Hugo): turning RSQKit task pages into "skills" that could act directly on a user's own codebase (e.g. "improve this code against this practice") rather than only answering questions about RSQKit content. -- Discussion paused for time; there are open questions about hosting and compute implications of enabling this kind of search/agent behaviour. Deferred to the 17 August call — though Hugo will be on leave and unable to attend (back 24 August). - -**Caterina: HSF/ESCAPE "responsible coding with AI" event, 29 July.** EVERSE (via Caterina) is informally connected to an HSF/ESCAPE event on responsible AI coding, in two weeks. Framed as a community-of-practice session (people sharing real experience) rather than a heavily promoted event; limited engagement expected given short notice and timing. Michael and Caterina will personally contribute; there's a security-policy angle too (e.g. not leaking tokens). Caterina's proposal: keep the two efforts largely separate rather than presenting the full EVERSE policy discussion there — bring back a summary of EVERSE's work into HSF/ESCAPE instead. Note: HSF has been asked by its computing committee for practical AI-contribution guidelines on a Sept/Oct timescale, which is faster than EVERSE's own policy timeline — a timeline mismatch worth being aware of. -- Agreed content for 29 July: mainly practical/demonstrable material (RSQKit, Hugo's prototype work), not the unfinished policy brief; a brief mention that policy work is in progress is enough, no detail needed. Fotis will attend but wants Michael to lead the EVERSE presentation. Caterina asked Hugo to send her a short written summary of his work to fold in — kept deliberately lightweight. - -**Next meeting.** Confirmed for **17 August**. Note Hugo is on leave from end of July, back 24 August, so will miss this one — his chatbot/TeSS discussion will need to pick up without him or be held over again. +**Next meeting: 17 August** — not everyone's first choice (some wanted the 24th) but the best available compromise. Hugo will miss it either way (on leave). ## Key actions -- Giacomo: organise a separate follow-up meeting after 24 August with Hugo, Fotis, Shoaib, and Michael on chatbot/skills/AI-tooling direction -- Michael Sparks document — agenda item for 17 August call to continue the discussion -- Giacomo: PR #26 review — still pending, carried forward again +- Giacomo: organise a follow-up meeting after 24 Aug with Hugo, Fotis, Shoaib, Michael on the chatbot +- Giacomo: review PR #26 (overdue) +- Michael: bring his document back to the 17 Aug agenda +- Fotis: consider adding the responsibility/sustainability points and Shoaib's citation to the AI statement ---