Policy on LLM usage for bids-specification and bids-discussion

78 views
Skip to first unread message

Chris Markiewicz

unread,
May 8, 2026, 11:29:30 AM (8 days ago) May 8
to bids-di...@googlegroups.com
Hi all,

I would like to start a discussion about LLM usage in BIDS community spaces. I wrote up an issue at https://github.com/bids-standard/bids-specification/issues/2423, which I will repeat below. Note: This is my personal position, I'm not speaking for any larger group.

Because there are community members who engage on the mailing list and not GitHub, and vice versa, I will try to periodically summarize discussion points from each on the other. I hope this will not end up being too noisy.

---

I don't know that we're getting specification text proposals written by LLMs, but I have started to see issue/discussion comments written by LLMs, and I think it is important that we set a policy that affirms the value of contributors' time.

I think we need to consider LLM usage in three contexts for this repository:

  1. Specification text drafting
  2. Communications (issues, discussions, pull request comments)
  3. Code generation

Each can be decided on independently, but I would suggest we adopt Ziglang's Strict No LLM / No AI Policy for the BIDS specification repository (https://github.com/bids-standard/bids-specification) and the bids-discussion mailing list (https://groups.google.com/g/bids-discussion):

No LLMs for issues.

No LLMs for pull requests.

No LLMs for comments on the bug tracker, including translation. English is encouraged, but not required. You are welcome to post in your native language and rely on others to have their own translation tools of choice to interpret your words.

BIDS as a standard values human legibility, and people generously contribute their time reading and commenting on the specification, BEPs, issues, comments and PRs. Posting large blocks of text that need to be evaluated for dubious claims feels to me an abuse of that generosity and risks disengagement. Large blocks of text written by humans already get relatively little engagement, despite the obvious effort the contributors put in.

The code in bids-specification is written in Python and small enough that it should be legible to any interested contributor, even if it takes more time than siccing Claude on it. I am personally willing to pair program with anybody who finds it too forbidding to get started.

This is not yet a large problem (as far as I can see), and my goal here is not to call anybody out, but to have this discussion before it becomes a problem and people start silently walking away. Ultimately, I think this will need a decision from steering.

Best,
Chris

‪‪Dr Cyril Pernet‬‬

unread,
May 8, 2026, 1:10:01 PM (8 days ago) May 8
to Chris Markiewicz, bids-di...@googlegroups.com
Hi Chris

Considering your 3 points, I am a little more lenient on usage.

1. Spec drafting - I'm sure you agree that rewording and typo fixes by an LLM is useful
2. Communication - In general yes I agree, although PR LLM comments can be good (I guess we don't want fully agent driven, as oppose to a human Doug a PR and having CoPilot help, right?) and copilot reviews and fixes on PR does work too, i.e. accept proposed corrections.
3. Code (well we know how we code these days)

Cyril 

--
We are all colleagues working together to shape brain imaging for tomorrow, please be respectful, gracious, and patient with your fellow group members.
---
You received this message because you are subscribed to the Google Groups "bids-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bids-discussion/CAJqDEcGd58bmsRoOJyFUd2jr22pGUsov0v_Agu2O2-LJ5MWFdA%40mail.gmail.com.

Chris Gorgolewski

unread,
May 8, 2026, 8:03:37 PM (7 days ago) May 8
to bids-discussion, Chris Markiewicz
You are absolutely right!

Jokes aside (3) seems pretty drastic. What is the problem this is solving? Is it having too many PRs to review from impatient people you do not know and don't trust?

Best,
Chris

Robert Smith

unread,
May 10, 2026, 9:01:16 PM (5 days ago) May 10
to bids-discussion
Been thinking a lot about this lately as I try to shake off my own Clankophobia(TM).
The tools are indeed powerful and could be of considerable utility in this ecosystem in myriad ways; but only if used with integrity.
Suitable rules of engagement might be slightly different for a specification project like BIDS than for strictly software engineering, given one cannot always rely on the "well the code compiles and the tests pass" rationalisation.

To my mind, the manifest issues with widespread LLM availability are, once stripped to their most fundamental core:
  1. False attribution / responsibility / credit.
  2. Disproportionate expectations of few maintainers / reviewers to carefully critique content relative to many investing minimal effort in producing voluminous content.
For which mitigating strategies could be:
  1. Attribution:
    1. All discussion content copy-pasted from an LLM are to be block-quoted and explicitly attributed to the generating LLM.
    2. LLM-generated content posted in a discussion must be accompanied with a description of why / how that content is suitable / insightful, not just dumped with expectation of others to interpret.
      "Hey, what do you think of this LLM-generated answer?" isn't a valuable community contribution; the person at the receiving end could have generated such themselves.
    3. All commits to which an LLM contributed are to be explicitly tagged as such in the commit footer.
      Personally I'm going one step further and (automatically) quoting all LLM prompts in commit bodies—given that's what constitutes my "contribution" & they could be insightful when back-tracing issues in the future—but understand that's overkill for most.
  2. Disproportionate expectations:
    Consider a hypothetical individual who wishes to take advantage of LLMs & goodwill of maintainers to generate maximal credit to self for minimal personal investment by passing off LLM-generated content as their own.
    This individual would be in violation of either the Ziglang policy or my suggestions.
    The difference being that:
    • If outright forbidden, there's always an underlying scepticism that others in the community are nevertheless getting away with exploiting these tools, thereby rationalising oneself doing the same;
    • If there's prevalent precedent for how to use them in a community-acceptable way, conformity to those rules is implicitly encouraged.
Just the ramblings of a recovering neo-Luddite, take or reject as you choose
Rob



P.S. The em dashes are my own.

Paola Di Maio

unread,
May 11, 2026, 2:04:47 AM (5 days ago) May 11
to bids-di...@googlegroups.com
For me, engaging with BIDS ecosystem as an end  user does not relate to coding BIDs apps at all

Once the apps are released, what to make of them? 

LLMs can be used to help sense making, discoverability, learning and generally
revisiting the ecosystem according to one's view of the world

It is not that one uses LLM for coding, but as a research assistant to have intelligent interactions about the universe in general
when other people, especially seniors and experts, do not have time to spare.

- from the simplest questions of what is x and why is it so? to writing user interfaces that
work for others *could we have it some other way?
 and making generally neuroscience accessible and comprehensible
to those who may not want to spend their life speaking python and docker code

etc etc etc

There is much more to BIDs beyond a list of app code released without documentation and pedagogy,
 I intend to leverage the whole thing and sling it across my small world  (teaching and learning) with the least possible effort.

 LLMs are like
trampolines to help me to do and I do not intend to make disclosure of all my trade secrets every other word I say

Look forward to be engaging with BIDs fully now that I have the tools to support me in that endeavor


Tibor Auer

unread,
May 11, 2026, 3:14:09 AM (5 days ago) May 11
to bids-di...@googlegroups.com
I sense some over-reliance on LLMs and a tendency to use them as substitute (rather than accelerators) for domain-specific knowledge, where the domain can be software engineering as well as neuroscience. The uncritical use of AI tools can lead to unstable and unsafe solutions. More importantly, it also increases the risk of data breaches and malicious exploitation due to the lack of transparency and an uncontrolled supply chain. Adversaries can exploit AI systems and tools to inject malicious prompts and establish persistence in information systems.

One must cautiously explore and critically evaluate (domain-specific) solutions and apply them when appropriate to stay ahead of the competition. However, they cannot be substitute for domain-specific knowledge, because we still need it (and AI literacy!) for proper evaluations.

I admit I do not fully understand LLMs (or the domain of my work), which also makes me cautious. Therefore, I fully support transparency and disclosure of AI use, so that we can better assess risks and how to mitigate them.
Moreover, transparency is also one of BIDS' main motivations, so it makes perfect sense to encourage it in all related activities.

Tibor


Dr Tibor Auer, MD, PhD, FHEA

tibor...@gmail.com

LinkedIn: tibor-auer


From: bids-di...@googlegroups.com <bids-di...@googlegroups.com> on behalf of Paola Di Maio <paola....@gmail.com>
Sent: 11 May 2026 08:04
To: bids-di...@googlegroups.com <bids-di...@googlegroups.com>
Subject: Re: [bids-discussion] Policy on LLM usage for bids-specification and bids-discussion
 

Chris Markiewicz

unread,
May 11, 2026, 10:34:10 AM (5 days ago) May 11
to bids-di...@googlegroups.com
Hi all,

As mentioned, I will shuttle comments between GitHub and the mailing list.

On GitHub, @satra recommends considering the accessibility implications of a blanket ban, and proposes that the goal should be more about whether humans evaluated the content before posting it, rather than policing its origin. @yarikoptic is +1 on clear policy, and prefers clear provenance to any limits on usage, but any policy should be clearly stated on the project landing page.

@Chris RE "(3) seems pretty drastic." Was this in response to my 3rd category "Code generation" and the proposed blanket ban or the ziglang policy language "No LLMs for comments on the bug tracker, including translation. ..."?

I appreciate people's comments here. I'm not surprised that many (most?) would prefer a less strict policy, and fair enough. Overall, there seems to be agreement that it should be an explicit policy, and some consensus that disclosure is an appropriate standard.

I have no objection to disclosure in general, but I'm not satisfied with it as a standard for two reasons:

1) What is the appropriate response to garbage that comes with an AI-usage disclosure? What's the standard for garbage with or without a disclosure?
2) In code, disclosure for many people means adding a "Co-authored-by" line, which to me feels more like advertising than provenance.

The first is the more serious concern for me; LLM-generated text can be a serious drag on people's time and motivation. To take a recent example, I saw an LLM-generated suggestion that a proposal adopt a controlled vocabulary, where two minutes of research demonstrated the unsuitability of the vocabulary. Those two minutes should have been spent by the poster, not every reader. As a moderator, I don't want to see contributors subjected to hallucinated reviews. I think it makes BIDS a less welcoming place if posts make clear that the poster has neither read what they are responding to nor fully comprehends what they are responding with.

As to the second, I can live with it, although I don't think it would do our reputation good for people to see AI tools as "committers" in our repositories. The tools people use are their own affair, but if they're unwilling to claim full responsibility for the content, I am skeptical of the value of that content. I think the AI policy that most resonates with me for code is https://github.com/python-attrs/attrs/blob/main/.github/AI_POLICY.md.

And I don't see a strong distinction between comments and code. Echoing Paola's "I do not intend to make disclosure of all my trade secrets every other word I say", while I wouldn't call my tool usage a trade secret, if I'm not willing to sign my name to a comment and take any reputational consequence for writing something wrong, then I'm wasting my time and yours.

Finally, I just want to make clear that I am not proposing a blanket ban for all repositories under bids-standard; each project's maintainer/team can make their own decisions. In many cases, the technical correctness of a PR stands on its own, while the value of BIDS is that it's a consensus document, established among humans to meet the needs of humans. So to my mind, any policy where LLM-generated responses to LLM-generated posts/PRs are not moderated will be a failure.

Best,
Chris


Hao-Ting Wang

unread,
May 11, 2026, 11:11:18 AM (5 days ago) May 11
to bids-di...@googlegroups.com
Hi everyone,

I started writing this before Chris's reply. 

I don't have a solution. It's just my 2c.

Re code:

LLM use made "passing all tests / the code can run" less of a reliable indicator of whether a contributor's understanding of the problem/code base. It turns the workload of digesting things back to the reviewer/maintainer.
This case happens regardless of the existence of LLM, but now it is mixed with more slop/more band-aid solutions to make the code pass, which makes it extremely hard to read and often doesn't fix the problem at its core. 
An AI disclosure policy is only useful for responsible users who are willing to potentially go into the AI-generated content themselves. The question is what is/isn't responsible usage when we have no personal interaction/history to judge. And the only way for maintainers to build that knowledge is by forcing interactions without AI. 

Re community and culture:

I'm starting to see obvious LLM usage as an indicator of being out of depth, as compensation for productivity, or just wanting to min-max productivity. IMO these all point to fear of making a mistake or showing a lack of understanding in public-ish setting. In an in-person work setting, it's easier to notice that (e.g. someone produces code that would take more time to digest / poor explanation of how things work); but it can become a challenge for async work/collaboration when an individual's capacity is not obvious. I understand that making the community/culture more welcoming is always going to be what people push for, but it begs the same question as LLM-driven contribution: at one point, does this become less of a responsibility of the maintainers to create a welcoming environment, or rather more for a contributor to be brave and accept that they will mistakes? 
We don't need more artificial-appearing intellectual interaction.

Best,
Hao-Ting


Paola Di Maio

unread,
May 11, 2026, 1:50:34 PM (5 days ago) May 11
to bids-di...@googlegroups.com

Warning:  apologies for the long post.

Short summary at the top for brevity. Just sharing reflections on disclosure

Summary

  • Appropriate use of AI is not the same as blind reliance or rejection of technology.

  • BIDS is intended as a neuroscience data standard, not only a programmer ecosystem. Is it not?

  • AI tools and LLMs can democratize access to computational capabilities previously limited to well-funded institutions.

  • Transparency discussions should include funding, infrastructure, software access, training, accommodations, and institutional privilege — not only disclosure of LLM use.

  • Are there others in the BIDs ecosystem interested  in discuss neurodegenerative disease, cognition, and brain research in plain language, not only through code and technical environments.

Over-reliance on technology is not good practice, but under-reliance may also be a problem. What should we consider “appropriate reliance”?

There is great literature ,  discuss concepts such as the “Over-reliance Rate” ((O_{wrong})), calculated as the frequency of accepting an incorrect AI suggestion. . Is this the case?

Isn’t BIDS supposed to be a data model for neuroscience, so researchers can leverage the massive amount of neuroscience data now being produced and made openly accessible?

(That is how I first came across BIDS some years ago)

Not only as a community of programmers concerned with demonstrating the integrity of their coding skills.

I do not intend to diminish the value of anything this community does, nor criticize it.

Some AI-generated output is impossible for humans to process effectively. But some AI output may genuinely extend human reasoning capability. In many cases — dare I say it — AI-generated code can be extremely good, at near-zero cost. Humans can learn a lot from AI

What we need to build into the process are learning and evaluation skills. Use AI to reason then come up with your own thing

Brain research has become so dependent on informatics that perhaps some direction may have been lost in the process. I may be wrong. If everyone understands the whole picture, perhaps they can explain it to others. Without AI it is impossible to capture. 

Emerging research suggests that mandatory disclosure of AI use may create measurable reputational and credibility penalties for researchers, even when the quality of the work itself is unchanged. Several studies describe a “transparency dilemma” or “disclosure paradox,” in which institutions encourage transparency while audiences simultaneously reduce trust in individuals who disclose AI assistance.  *see long list of scholarly sources
And the opposite may be true *that non disclosure may lead to win the best paper award , get funding and job offers *I do not have data on that

Btw anyone working on BIDS also researching the causes, prevention, and treatment of neurodegenerative disease and cognitive decline — and having conversations about these topics in plain language rather than primarily in Python?

If so, please speak to me. That is what I want to discuss.

This is not about justifying over-reliance on anything.

It is about integrating new technical capabilities that are now available to everyone into development, learning, and research workflows that were previously accessible only to a small number of people entering academic institutions or participating in funded consortia.

It is about becoming more self-reliant:

  • being able to find, understand, query, and manipulate brain research datasets,

  • leveraging new learning opportunities and technical capabilities,

  • and not depending entirely on others for access to tools or validation of whether your code “works,” whether it is “good,” or whether you wrote it “correctly.”

We are being asked how to evaluate the quality of AI-generated code.

There are already established methods, parameters, and criteria for evaluating code, software, and research outputs.

LLMs are now universally accessible. Yes, they are sometimes used unintelligently or irresponsibly — like any technology.

At the same time, expensive scientific software required to work with complex datasets is often accessible only to faculty and students at certain institutions, frequently at great public cost. They get promoted for using technology infrastructure and dont have to disclose anything. 

Meanwhile, publicly accessible LLMs can perform many useful computational functions with minimal setup.

Do we have demographic information about the BIDS developer and user community?

Do all BIDS users have to be programmers?

Have institutional access, funding, software access, and learning opportunities relating to BIDS been made transparent?

What about  accessibility?

How many people in the BIDS ecosystem may be on the autistic spectrum, or might benefit from different training approaches? How many are able to access accommodations?

Transparency is not only about disclosing the use of LLMs.

It is also about publishing information about:

  • how much funding individuals and institutions receive,

  • what infrastructure and software environments they have access to,

  • what computational capacity they possess,

  • what licenses and tools they use,

  • and who is actually able to participate meaningfully in brain research.

How many researchers truly have access to the entire suite of technical tools and expertise required to conduct modern brain research? That could be interesting to know.

Should disclosure requirements also include:

  • tools,

  • licenses,

  • computational environments,

  • computational capacity,

  • training,

  • skills,

  • and the composition of the BIDS ecosystem itself?

There is a great deal to unpack if we are genuinely interested in transparency — far beyond simply discussing LLM use.

LLMs can provide analytical and technical capabilities to anyone willing to learn how to use them.

Some of these same capabilities may already exist inside proprietary software, platforms, and institutional environments that many users will never access — or may never even know exist.

Should those LLM capabilities embedded in other technology also be disclosed?

How much LLM integration already exists within brain research platforms that the community may not currently expect to be disclosed under the rules being discussed?

When someone creates a method, then uses software tools to refine it, debug it, integrate it, and produce a clean, presentable webpage that explains the method and runs the code:

  • are developers expected to disclose every suite, tool, and function they used?

  • or only a specific category of LLM products?


Just thinking

@starborn looking for beta testers



Reply all
Reply to author
Forward
0 new messages