An open source app of mine is being "hijacked" by a contributor, and I have no idea how to handle this the right way.
In a span of 6 months, they contributed a lot. During these 6 months, I wasn't careful enough while reviewing their PR (because of personal issues), and they took the initiative to change existing features and made the codebase "messier".
Since then, I started rewriting and cleaning everything, but they keep creating PRs with feature changes, adding features without discussing them beforehand, and it's frustrating, since they are creating multiple PRs a week, with more and more changes.
Reviewing their PR is becoming harder and harder, because I feel like I'm wasting my time arguing with them, as we don't have the same "view" of how should the app work.
I feel like I can't say no to them (or I don't know how to do so) because I should be grateful as they helped with some bug fixes, yet I feel like I'm loosing my own project.
How to handle this (without blocking them) ?
Also, get over the "I might hurt their feelings" and think more like "I might have to fire this person". On the plus side, you are not impacting their finances or family, just take care to explain your position clearly, oh, and listen first.
Sharing the repo link here might help us help you better.
When giving pushback, try to avoid raising the stakes, i.e. avoid public criticism, don't issue ultimatums.
If you have a private chat, that'd be great.
If not, try to state your concerns as plainly and non-judgementally as possible, from the perspective of your project.
"Hey X, I'm glad that you are and have been contributing so much to the project. There's a few different ways I see the program and codebase evolving, and I'm keen to work together on figuring out that right path.
It looks like there are places that have different visions, and if you could split PRs into smaller PRs, we can more easily find the changes that fit both our visions."
If there truly is disagreement on some PRs, you can be polite but firm, "I can see the value in X because Y, but this compromises Z, which is a core value of the project."
You have merge access, and should also consider whether this contributor is worth the hassle of all of what I just said. (In which case, skip straight to "polite but firm").
Work with your community (which might just be this single developer at this point) to collaboratively create a style guide or a set of standards for all future code submissions. This will be an outlet for you to professionally air your grievances and allow them to see where you're coming from. Simultaneously, this might provide you with some additional context that could help you better support them.
Best of luck!