As I understand, there are currently no real guidelines for this, even though AI is currently a big topic in FOSS.
In my opinion, AI can be quite dangerous for free software and that's why we really need to discuss how we can address this issue. Here are some of the reasons for that:
- Poor quality, insecure code: AI still produces hard to maintain code, that is often severely insecure. Even if you check every line of code carefully, there is a good chance you overlook something, because you won't fully understand the code, you haven't written yourself
- Licensing issues: AI often reproduces code from it's training material, which could be incompatible with this codes license
- Legal trouble: The legality of the copyright about AI is not yet really settled, so it could be a big legal risk to have AI-code in your codebase
- Ethics: AI systematically exploits the work of all open source contributors for the profit of big companies. We as part of the free software movement should reject this more openly
My idea for this policy was, that we should definetely demand for AI generated code to be marked as such (you have to disclose in your commits, if you have used AI for that). I think we should also ban entirely AI-generated PRs aswell, because they produce more work for the maintainers than they actually help with anything. Were I am not quite sure yet, is how we handle the case when someone used AI just as autocomplete, but wrote most of the code themselves? You should probably also have to disclose that, do you think we should ban something like that?
Looking forward to hear what you think about this!
The problem with just sending the request to the developers is that often times requests for improvements are dismissed as an annoyance. I have discussed many issues with the way the fediverse works over many years, and many responses are "just build the feature yourself if you want to see it". After years of never seeing these changes made, when you can just prompt an agent in an IDE to make the changes you want, it is hard not to take that route. Granted, if you are doing it for yourself or a small group of people who may be interested in using the changes you made, that is different from submitting AI generated code to an existing project. But I don't see anything inherently wrong with vibe coding solutions to problems, as long as you have a general understanding of what you're doing and how things work.
Since before PieFed was officially released, the code was available so that an instance admin could modify it and run as they pleased. Nobody is talking about taking that functionality away. So modify to your heart's content.
Also, while it might not be obvious from all of the comments, the OP was also not talking about forbidding all PRs containing AI generated code either.
Just labeling them is all. So that the devs have a better sense of what they are getting into. 1k lines of code that was 100% vibe-coded, not tested in the slightest, and for a new feature that nobody has asked for? Yeah that's going to be at the bottom of the pile.
Previously, it would have been really difficult to get 1k lines of code unless someone has at least a rudimentary knowledge of programming concepts - if() statements, for() loops, understanding whether array indices begin at 1 or 0, and so on. However now with LLMs, that is no longer a barrier, so people are discussing how to adapt to the new landscape.
You can still do whatever you want - same as before - this post is just talking about clarifying the expectations so that the developers who want to contribute to this project can all work together more smoothly, with fewer miscommunications due to false assumptions.
Yeah, I've had that as well. Some developers/maintainers are a bit elitist. Or have weird social skills. Or they're overstrained or aren't really motivated to include other people... And it tends to have a chilling effect and make people feel bad. I've also been told before, just send a PR. And I know this would have been a job of 5 minutes for them to fix some easy thing to make me and some more users happy. And I now get to invest an hour in setting up some development environment, learn how the project is laid out. Learn about their frameworks and libraries, maybe my Rust skills are bad and I'm just poking at random things... And it's just annoying.
I think it's a bit of a non-issue with PieFed. All I've seen here is constructive people. And a positive tone and atmosphere.
And I believe what you describe is a bit of a tricky situation. It's what I'd call a "drive-by PR". The people who send it in are not really familiar with the codebase so there's likely issues in there. And they're also not willing to maintain it, as it's an one-off thing for them. So it ends up being one of two things for you as a project maintainer. Either it's a small and straightforward fix and you accept it. Or someone is customizing your software to their needs and they sent in some larger thing. Now you get a lot of stuff on your plate. You have to understand all the new code. See if it's tied into the rest of the project. Check the code quality. See if they or someone ran the test cases, broke something else in the grand picture. You're gonna be the one who will maintain that code in the future... And it takes quite some skill to stay calm, use your social skills and maintain focus on what's important for the project. And that's the old-school way with human contributions. It gets yet more complicated once they arrive in larger numbers by coding assistants, with quality all over the place. I think it's first and foremost a communication thing (in good projects). If there's a human on the other end, you better respect them in some way and explain to them why some decisions are being made.
It's some delicate balance. It's generally easier if you have some core developer base in your Free Software project and you know the people who wrote the PR. On the flipside I also often send in PRs when something is broken or I can contribute some smaller things to the various Free Software I use. I learned to make it as easy for the developers as possible. Read up on the coding standards before, test what I'm doing on my machine first. Add a good description of what I'm changing and why. And usually they'll say thanks and bother with incorporating my requests.
And with feature requests (without code being sent in), it's a communication skill as well. There isn't an infinite amount of time available. Developers can't do everything simultaneously, so things have to be prioritized in some way. And sometimes it's really hard for a layman to judge the amount of complexity of some requests. I've seen people request easier improvements to the Fediverse, and impossibly hard things that require the entire protocol and all software be changed. And I'm not exempt. I also have some of my own pet peeves with the Fediverse.
(Just my opinion as a software developer. I'm not too involved with the Fediverse in specific or in a position to speak for other developers.)