Could OBS reconsider its policy on AI-assisted contributions?

[UlisesMilani]

I'd like to bring up something about the current policy on AI-assisted contributions.

I understand why OBS wants to avoid low-quality code, changes that contributors don't understand, and potential licensing problems. I also understand that the current policy goes further than simply discouraging careless use of AI: it requires submitted content to be written by humans.

I think that's the part worth reconsidering.

There's a difference between blindly submitting code generated by an AI tool and using AI to help with development. These tools can help people investigate problems, understand unfamiliar parts of a codebase, find possible solutions, and work on things they might not otherwise be able to tackle.

Not everyone who has something useful to contribute is an experienced developer. Someone might know a particular problem very well because they've been dealing with it for years, but not have all the programming knowledge needed to solve it. AI tools can help bridge that gap.

This is also relevant to accessibility. Users can identify problems that developers might not even be aware of. Being able to use AI as a development tool can give those users a better opportunity to participate in fixing them, rather than just reporting problems and hoping someone else has the time to address them.

I'm not suggesting that OBS should accept everything an AI produces. Contributors should be able to explain their changes, understand the decisions behind them, test their work, and take responsibility for any problems.

They should also provide reproducible test cases, explain what they changed and why, and be willing to address issues found during review. I think this is particularly important because maintainers already spend time reviewing contributions that may look correct at first but turn out to have problems.

What I'd like to suggest is changing the current policy to allow AI-assisted contributions under clear conditions: disclosure of AI usage, understanding of the submitted changes, proper testing, and full responsibility from the contributor.

The maintainers would still have the final say on whether a contribution meets OBS standards. Nothing about this proposal would require them to accept code that doesn't meet those standards.

I don't think the tool used to develop something should automatically determine whether that contribution deserves consideration. What matters is whether it works, whether it meets the project's requirements, and whether the person submitting it is willing to stand behind their work.

I'd like to see OBS reconsider this approach and discuss whether a more flexible policy could work.

[Fenrirthviti]

Our concerns around AI extend far beyond the efficacy of the code submitted. Setting aside the arguments around the environmental harm, disruption to human life, and long-term sustainability of these technologies as they currently exist, there are strong arguments around the fact that code generated by AI likely cannot be copyrighted. Nor can it be said with certainty that the code generated by an LLM isn't some proprietary (or otherwise incompatibly licensed) code that is not acceptable under the GPL license we use.

While we are watching and digesting the AI ecosystem and constantly re-evaluating our policy, we do not have any current plans to allow AI-assisted or written code.

[Warchamp7]

You can use whatever tools you want on your own time and your own computer. If you want to use LLM tools for research or analysis, that's your decision.

Once you step into the project, you are stepping into it as a human. Writing the code yourself, writing the PR yourself, interacting with other contributors yourself, means a time consuming process that serves as a self-evident demonstration of your understanding of the work and a willingness to engage with others.

If I wanted Claude to write a fix for a bug I can go do it myself. If I wanted ChatGPT to explain the changes of a pull request I can go do it myself. If I wanted Gemini's analysis of a crash log I can go do it myself.

There is nothing valuable in allowing LLM output into code, submissions, or comments except to trade a reviewers time reading it instead of the submitters time writing it.

If someone can't be bothered to write 300 words about their changes then why in the world should I use my time to read the novel some LLM spit out for them instead? If I have a question about code that is submitted and that person turns around and feeds my question into one of these systems they have already failed as a contributor. We do not need meat proxies in the project, we need people who are willing to build a mental model of the codebase they are touching and understand why a fix is or is not correct on an architectural level, not as an immediate bandaid.

[WizardCM]

Another consideration not mentioned is that if, like you say, you have a reproducible test case (reproduction steps) for an issue you're running into, a human-written issue report is invaluable to a development team, open source or not. There are so many bugs that might've been reported but without useful steps, or those same steps don't work for everyone, or have never been reported at all. Being able to coordinate with someone and try troubleshooting solutions that may not even require a code change often helps complete a puzzle that developers have been struggling with for a long time.