I've had to refuse some merge requests, I did it by mostly ignoring them, or explaining that it looks like a very large patch for a something that isn't necessarily wanted...
Also I factor in the fact /I/ will have to maintain that patch in the future, as the contributor will likely disappear to other interests sooner or later, so if I don't like it, ultimately it's /my/ choice, even if it doesn't come down to a technical point...
A good 'test' of a merge request is to see if the author is willing to make changes that you request.. It is a very good filter for 'motivation'; if the author doesn't reply, well, that's a merge request I'll close it 6 month next time I go down the list...
Comments
"you got the source, feel free to send a merge request, thanks!"
Problem sorted?
Sometimes the issue is that somebody's merge request has been rejected, so not necessarily.
I'm the author/maintainer of simavr: https://github.com/buserror/simavr
I've had to refuse some merge requests, I did it by mostly ignoring them, or explaining that it looks like a very large patch for a something that isn't necessarily wanted... Also I factor in the fact /I/ will have to maintain that patch in the future, as the contributor will likely disappear to other interests sooner or later, so if I don't like it, ultimately it's /my/ choice, even if it doesn't come down to a technical point...
A good 'test' of a merge request is to see if the author is willing to make changes that you request.. It is a very good filter for 'motivation'; if the author doesn't reply, well, that's a merge request I'll close it 6 month next time I go down the list...
Well, that someone is free to fork the project if he/she isn't happy with the current maintainers.