Someone has submitted a 4k-line PR to one of my projects.
The person is a long-time user and is very enthusiastic about the app. They wanted a feature they've been asking about for half a year.
Not sure what to do now. I really want to help my user, but I don't like this code in my codebase.
This morning, I received another message from another user who is about to submit one more feature.
Is there any polite way to prevent that?
But it's hard to imagine someone spending so much time coding without coordinating with the maintainer.
I think that it's bad manners for someone to submit a big PR without prior experience with the project. Someone needs to earn trust over time. They might start out with a few small PRs and gradually build up to the point where you might trust them with a larger change. But even so, a 4k-line PR is very unreasonable.
There will likely be way more PRs like the one I described in the future.
Can this person program?
---
I agree with the the other comments. Anyway, which project? language-learning-tool?
Do you like the general idea of the PR? Is it possible to split the PR in a few smaller one? Is it possible to merge one part and keep it disabled by default for most users?
> Do you like the general idea of the PR?
To be honest, I'm not a fan of the PR's general idea.
> Is it possible to merge one part and keep it disabled by default for most users?
This is exactly what I am about to do. To merge a small part of that PR into my repo. That part conducts communication between the web app and the proposed extension, so the author of the PR can use my APIs while keeping most of their code in their fork.
I am actually glad that I created this thread. Thank you for responding to it.
Every single one of my public github repositories is archived and no longer updated.
I have projects I work on, but I keep them to myself. I've just lost interest in wasting time on issues and submissions from people - which is a depressing position to be in, because most of the time people mean well, and over the years I've definitely benefited from contributions of many interested and skilled people.
Thank you for sharing your experience. I am not an open-source rockstar, and I have only had to reject PRs a few times in my life. All the times I felt terrible for people who put in some effort to build something around my code and got rejected.
latexr•1mo ago
That wouldn’t be reasonable even if it weren’t vibe coded.
> The person is a long-time user and is very enthusiastic about the app.
Be careful. Don’t let yourself be pushed into an XZ-type situation.
https://en.wikipedia.org/wiki/XZ_Utils_backdoor
> Not sure what to do now. I really want to help my user, but I don't like this code in my codebase.
If you don’t want to accept the PR, don’t. It’s still your project. Reject it politely. Tell them why you don’t feel comfortable accepting it (too many changes at once; impractical to review; general distrust of LLM code; …) but remind them that “of course, if you want to keep that in your own fork, you’re more than welcome”. I’ve been doing that for years (way before vibe coding was a thing) and was always able to keep good relations with my users.
Be polite and make sure they understand your rejection is not an indictment on their submission, while reassuring them that the effort was not wasted because they can keep it for their own use if they really want it that bad.
> This morning, I received another message from another user who is about to submit one more feature.
When you write the message for the first user, try to also make it generic enough (i.e. about the project, not their specific submission) that you can link to it for other users.
sneas•1mo ago