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!
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.)