Add an AI policy for contributors

docs/source/conf.py

@@ -79,6 +79,7 @@
     "https://errantscience.com/",
     "https://in2scienceuk.org/our-programmes/in2research/",
     "https://www.biorxiv.org/content/10.1101/2025.03.30.645770v1",
+    "https://chatgpt.com/",
     r"https://www\.cell\.com/.*",  # Use regex pattern to match all cell.com URLs
     r"https?://(?:dx\.)?doi\.org/.*",  # Use regex pattern to match all DOI URLs
 ]

docs/source/get-involved/ai_policy.md

@@ -0,0 +1,50 @@
+# NIU policy on contributions using AI
+
+::: {admonition} TL;DR
+:class: note
+
+While we encourage, and are very grateful for, contributions to our software, we don't accept any contributions generated 
+mostly by AI.
+:::
+
+## Introduction
+Generative AI tools have developed quickly in the last few years, and have changed how many people write code. General 
+purpose tools such as [ChatGPT](https://chatgpt.com/) or specific code development tools such as 
+[Cursor](https://cursor.com/) now mean software development is quicker and more accessible than ever before. We only 
+expect these developments to continue, and AI agents to play a crucial role in the way that we create software. 
+
+Many members of the NIU use AI in their workflows, as do many of our collaborators. We are also fortunate to have a 
+large community of contributors to our tools. However, many potential contributions are low-quality and either require 
+lots of work to get them into shape, or simply need to be rejected immediately as they do not solve the problem at hand. 
+In many cases, these contributions appear to be mostly, or entirely, AI generated. 
+
+## Code contributions
+It can be very difficult to contribute to an open-source repository for the first time, and we are always happy to 
+provide assistance to anyone trying to learn. However, it is our policy that **we will not review any code contribution 
+that is, or appears to be, mostly written by AI tools**. These contributions look useful superficially, but often make 
+poor design choices, and are difficult to maintain long-term. Sometimes the AI agent creates a solution that does not 
+solve the problem in any way.
+
+While the use of AI tools to help you write code is absolutely allowed, we expect all contributors to be able to 
+understand and explain every line of code they submit (if needed, we won't interrogate you!). If you cannot 
+understand every line, it is unlikely that whoever reviews it will be able to either!
+
+If you submit some code and we incorrectly tell you that we think it's AI generated, please let us know! There are various 
+"tells" that code has been written by AI, but these are not perfect. If we've made a mistake, that's on us, and we 
+want to correct it.
+
+## Communication
+It is also tempting to use AI for general communication, whether this is in GitHub issues or pull requests, or in our 
+[Zulip Chat](https://neuroinformatics.zulipchat.com). Often LLMs add lots of unnecessary text, and may distort the
+meaning behind the message.  For many contributors, English is not their first language, and it is of course fine to 
+use tools to help correct your communication. However, **please do not use LLMs to create entire messages that you send 
+to us in any format**. We want to hear what *you* think, not what an LLM thinks!
+
+## Action
+We hope this policy will help clarify our position. If we think that a code contribution or communication is AI 
+generated, we will politely refer you to this page and close the issue or PR (if relevant). If we have made a mistake, 
+please tell us. As these tools progress, we will likely get it wrong a lot, and we want to know. The last thing we 
+want is to deter any real, human contributors!
+
+In the unlikely event that our policy is repeatedly ignored (e.g. multiple AI-generated pull requests), we may block 
+that individual from our GitHub organisation and/or Zulip.

docs/source/get-involved/development_guidelines.md

@@ -1,7 +1,8 @@
 # General development guidelines
 
 All our software is built as a team, and this means we must agree on some development conventions. This page 
-covers our internal development guidelines, which we hope are also useful to external contributors.
+covers our internal development guidelines, which we hope are also useful to external contributors. If you are a new 
+contributor, please also see our [policy on AI contributions](ai_policy).
 
 
 ## General principles

docs/source/get-involved/index.md

@@ -10,8 +10,12 @@ contributions go through a review process to make sure that they are necessary,
 but it can be _complicated_. 
 
 For this reason we have written some documents to outline the processes we use, so hopefully they aren't so opaque. 
+These include our [general development guidelines](development_guidelines) and 
+[guidelines for specific languages and frameworks](languages_frameworks).
+
 We are also happy to guide new contributors through the process. For more details please see 
-[our documentation about mentored open source contributions](mentoring).
+[our documentation about mentored open source contributions](mentoring). Please also see our 
+[policy on AI contributions](ai_policy).
 
 ## Internships
 We offer a number of paid internships each year, through established programs such as 
@@ -30,6 +34,7 @@ please <a href="mailto:adam.tyson@ucl.ac.uk ?subject=Fellowship">email Adam Tyso
 :maxdepth: 1
 development_guidelines
 languages_frameworks
+ai_policy
 mentoring
 gsoc/index
 ```