|
| 1 | +- Start Date: 2025-10-15 |
| 2 | +- Reference Issues: https://github.com/nf-core/proposals/issues/91 |
| 3 | +- Implementation PR: [https://github.com/nf-core/website/pull/3367](https://github.com/nf-core/website/pull/3705) |
| 4 | + |
| 5 | +# Summary |
| 6 | + |
| 7 | +nf-core should have a clear policy on when it is OK/not OK, and how to use LLMS for generating new code and PRs. |
| 8 | + |
| 9 | +# Champion |
| 10 | + |
| 11 | +[@jfy133](https://github.com/jfy133) |
| 12 | + |
| 13 | +# Background & Motivation |
| 14 | + |
| 15 | +Derived from the proposal here: https://github.com/nf-core/proposals/issues/61, some members of the core team and community were not comfortable to immediately start 'blindly' allowing LLM associated code within the nf-core ecosystem, primarily due to: |
| 16 | + |
| 17 | +- Quality of code in some PRs |
| 18 | +- Concerns about the legality/lack of attribution |
| 19 | +- Adding a lot of extra cruft to the template purely to try and make sure AI agents 'do the right thing' being a bad thing |
| 20 | + |
| 21 | +with particularly the first point ending up putting more work on community coordinators/managers. |
| 22 | + |
| 23 | +Generally there was an agreement that LLMs are here to stay, and we cannot avoid them. |
| 24 | + |
| 25 | +But there was a feeling we need to at least make a statement on our stance on them and possibly a policy document. |
| 26 | + |
| 27 | +# Goals |
| 28 | + |
| 29 | +- Make clear when LLM code or related things are (generally) acceptable within nf-core |
| 30 | +- Make clear what the consequences of abusing these guidelines are |
| 31 | + |
| 32 | +# Non-Goals |
| 33 | + |
| 34 | +- To enforce AI usage on the community |
| 35 | +- To ban AI usage |
| 36 | +- To implement mechanisms for the use of AI |
| 37 | + |
| 38 | +# Detailed Design |
| 39 | + |
| 40 | +The discusson on the initial RFC issue pointed towards a general statement as a blog post, that can be called out in various documents - where required. |
| 41 | + |
| 42 | +A blog post acts as a position piece, but also allows a bit of flexibility as a non-static thing (can change over time), as new blog posts can be made with justification about changing stances (if required). |
| 43 | + |
| 44 | +# Drawbacks |
| 45 | + |
| 46 | +None noted. |
| 47 | + |
| 48 | +# Alternatives |
| 49 | + |
| 50 | +None noted. |
| 51 | + |
| 52 | +# Adoption strategy |
| 53 | + |
| 54 | +- [x] Made a blog post statement: https://github.com/nf-core/website/pull/3705 |
| 55 | +- [x] Link to contribution documentation (e.g.: https://nf-co.re/docs/contributing/how_to_contribute_to_nf-core, and `CONTRIBUTING.md` on github repo): https://github.com/nf-core/website/pull/4166 |
| 56 | + |
| 57 | +# Unresolved Questions |
| 58 | + |
| 59 | +- Any other places we should link to in the documentation? |
| 60 | + |
| 61 | +# References |
| 62 | + |
| 63 | +- https://github.com/nf-core/proposals/issues/61 |
| 64 | +- https://github.com/nf-core/website/pull/3705 |
0 commit comments