21

Note that when you say it's "unnecessary", you mean unnecessary for you. That's not the right way to collaborate: if you want others to contribute then they should have the same conveniences as you (build files in the repo for their preferred build tools). I think you can politely reject the patch, with a remark that you would accept a patch that contained ...


17

Reject it with a message. Don't accept it; accepting it sends the signal that this is a good contribution and you want more of them. If that's not what you want, don't accept it. What you should do is reject it with a note explaining why, for example: Thanks for your contribution. Your patch was rejected because it simply replaced config files. Since I ...


13

Some guidelines that may be of use: Always thank the submitter for their patch (unless you really don't want them to submit any patches anymore, which could be possible) Establish guidelines for patches, and make sure contributors can easily find them. If you don't want IDE config changes, put it in your contributing.md (or equivalent). Let submitters know ...


7

Reject the change and add some contribution guidelines You should explain that the contribution whilst not without its own technical merit isn't strictly a contribution that adds anything to the project goals. Explain that this is what forks are great for and encourage the contributor to maintain their own fork. Thank them for their time and add some ...


6

Reject the patch if it doesn't have a tangible benefit - does it help compilation on other platforms, etc? If not, if you have no reason to accept it, you have no reason to accept it. If it's some compilation helper that could work alongside your method then that adds value, otherwise it doesn't move things forward (and using it could hold you up, at least ...


3

There are at least two competing interests in how open source maintainers run their projects: a desire to foster and accept outside contributions developer bandwidth Developers have limited time to review outside contributions, especially if the project isn't a full time job (but even if it is). Combine this with the occasional entitled user, and some open ...


3

Having been on both sides of this situation I'm going recommend that you accept it(with some caveats). When a project is opensource the goal is to have community collaboration and ultimately a tool that will be useful to a large portion of the community. There are two, relatively, equally used tools in your community for accomplishing a similar goal. This ...


2

Linus Torvalds has famously stated that his primary job when maintaining the Linux kernel was to reject patches. Unless you want to get buried in features growing each which way, and ending up with an unmaintainable mess in your hands, you have to put down your foot. But (as other answers state) make sure what kinds of contributions are and aren't welcome (...


Only top voted, non community-wiki answers of a minimum length are eligible