Time and again, it is noted how frustrating it seems to contributors when their contributions are rejected (e.g. here, here, or here). That is why I am somewhat undecided about how to handle a situation where someone has provided a rather not so helpful patch to one of my projects (let's call it X for now) without burning any bridges.
The issue I am seeing is composed as follows:
- I am not talking about a large, well-known project, but about one of the zillions of largely unnoticed projects, which has accumulated a few hundred downloads in the course of several years and never before received a contribution from someone else.
- The patch in question is not "wrong" per se, I simply see it as unnecessary. So far, the build process invokes a tool A (one of the wide-spread tools for its task for the technology in question) for the project, and hence some config files come in the format compatible with tool A1. The patcher decided to replace these config files with config files compatible with a different tool B, which is equally wide-spread in the community (but which I do not use).
- With no previous contributions from the outside, I fear rejecting this contribution will convey the impression to the contributor that project X is among those pseudo-open projects that reject all patches with some kind of a better-than-thou attitude. While the concrete effect on my project(s) would be negligible (and I am aware it is impossible to always acommodate everyone in life, so alienating the contributor in question may be unavoidable), I would hate if the one lasting effect to the realm of open source software caused by my projects is that I have provided yet another example of projects that do not accept any input from the outside.
Hence, my question is: How can unnecessary (even though not explicitly incorrect) patches be rejected in a diplomatic way, especially by small projects with little to no other contribution activity?
EDIT: 1As there seems to be some kind of confusion about why tool-specific configuration files can be necessary, I am going to add a short explanation:
With various modern programming languages, the source code of a program is not merely a bunch of uniform source code files, but a heterogenous collection of files that need to be treated in different ways. Moreover, unlike it was the case with languages like C, these files are not necessarily integrated into one another by a preprocessor; rather than that, project files define what files to integrate into which compiled artifact. These project files are not necessarily a part of the language standard; instead, there are various tools that consume such project files, with different expectations to the exact format and contents project files.
In my open source projects, I generally follow the philosophy that whoever pulls the contents from a VCS repository should immediately be able to build the same artifact that I can build myself, and deploy it the same way. The more automated this works, the better. (The "immediately" comes with the sole restriction that sometimes, access credentials have to be configured, and a few tools expected by the build/deployment process may need to be placed on the search path. To reduce the obstacles to this as far as possible, I choose these tools based on how wide-spread and freely available they are.) Hence, I need to supply the project files along with the plain sources, for otherwise, a considerable amount of work would be required to first assemble the source files in the expected way before any artifacts can be compiled.
The practice to integrate such tool-specific files in the VCS when they are essential to building etc. seems to be common practice, as implied by another question (thanks to Martijn for digging up that question).
EDIT2: To those confused by the discussions - while the discussions have become a bit technical, this question is still entirely focused on the communication between two humans, project leader and contributor.