How to react to unhelpful contributions to otherwise unnoticed projects

Question

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 A¹. 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: ¹As 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.

Answer 1

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 config files for B provided it did not remove the config files for A. If it's an oversight on the patcher's part then they'll understand the need to support A. If they are actively hoping to remove support for A from the project then they can forget about it, obviously you aren't going to accept a patch that prevents you working on the project in future.

Is this the kind of thing where every tool added to the project needs to be added to the config file(s)? If so then you have a potential reason not to accept it (you can't test the file yourself), but also a basis for this contributor to remain active (to maintain the tool B config). You could in that case say that you will accept the file for as long as "someone" is responsible for testing it, and that you will remove it if at any point in the future it becomes apparent that nobody is doing this.

I suppose ultimately it depends on your attitude to "use at your own risk" files in your repo. Ideally someone should actively maintain it, but if it's just a "nice to have", you could take the attitude that you'll include it as a minor courtesy to users of B, but that if it doesn't work you unfortunately can't fix it and will have to rely on a patch from a user of B.

Finally, you (rightly IMO) don't want the discussion here to be about A vs B. But the discussion with your contributor potentially might be about A vs B, in which case you should have that discussion. In particular supposing that B were a free tool and A is not, then this contributor might have a very good point about the direction your project(s) should take in this respect, to avoid the error of being "pseudo-open" as you fear! Or supposing that A is free and B is not, then you would have a very good reason for privileging A as the assumed build tool for the project, with B as a marginal case that you support only if it's "easy".

Answer 2

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 use config files of the original format, it would have made extra work for me, which isn't ideal as I'm sure you understand.

Be nice to them about it and they'll understand. Any reasonable person gets the fact that you don't want extra work if it's not necessary.

As a side note, it's a good idea to exclude IDE config files from your repository. If you're using Git as a version control system, you can use .gitignore to do this.

Answer 3

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 what is wrong with the patch, and point to the guidelines. If it can be fixed, it leaves the submitter open to fixing it (tell them that it would be appreciated!) If it's a config only change, reject it. You could open a ticket in your tracker with the issue of how to deal with different IDE configs, or how to share them. A main repo might not be the best thing, but, if the config is really complicated, separate config repos could be useful. Or you could distribute static config files (that are not part of the repo).

• If it's all the same to you, you could consider accepting the patch, even if you don't really like it. If there is truely no harm (there might be, and there might be hidden costs and maintenance problems), why not accept it, even if you don't really like it?

Answer 4

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 in the short term, as you have to learn how to use and manipulate their system now; and even if it could live beside your method, you have to keep their method in sync with yours...).

Thank the submitter, but explain that you don't feel that this patch benefits the project (with your explanation as given). If you have a features roadmap on your project, even if its just an informal wishlist, that would help. You could direct the submitter to that (or a bug tracker) and say that these are the areas that you are currently working on.

I wouldn't dwell on it too much, the submitter possibly has integrated your project into some system of their own and thought it would be nice to share their changes.

Answer 5

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 contribution guidelines so next time (whenever that may be) you can refer the contributor to the guidelines.

If someone submits a contribution that doesn't match the guidelines, it's a less personal rejection as they haven't met some known criteria they were already aware of before investing their time in something.

Answer 6

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 contributor has submitted a pull request because they want to use your project but found they had to make modifications(to use a different toolset) to do so. Modifications that a good portion of the community also using that tool would have to do.

If this really is as simple as providing additional configs to do so - what do you lose by including these configs? If half the community(to pull some SWAG here) uses tool B and you provide direct examples using tool A... providing the configurations required for tool B just doubled your potential audience, increased the number of people who can use the tool out of the box and encouraged someone who obviously cares enough about your project to make contributions that expand the influence and reach of the project. It's win win win as far as being open source and the relationship of contributor and owner goes.

The caveat, however, is that this should be done in a way that doesn't replace the configurations that are provided but extends them. Perhaps they should go somewhere else(an 'example' directory is pretty common in a lot of opensource projects). Perhaps this should be added as a sort of plugin to the project or a new option in the project(depending on the kinds and amounts of changes required.)

I get that it's inconvenient for you if this changes because you have a very specific pipeline(which is a conversation fraught with opinions for an entirely different venue). I also get that you want to decline this PR. But I think your two goals of "Please contribute" and "Only contribute the things I want" are at odds with one another. Further more I think "Only contribute the things I want" when combined with a small project owned by a single person is a sign that this project probably isn't all that opensource.

Yes, you can decline this PR. It's entirely within your rights. I don't think you can decline this PR with the state of your project as it is without discouraging this user from contributing in the future(and potentially other contributors) .

The reasonable solution would be to decline to merge the PR as it is with suggestions on what would need to be done to support both the current configuration and the proposed additional configuration. The onus is then on the contributor to make those changes or abandon them.

Answer 7

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 it is clear what kinds of contributions are and aren't welcome (roughly, you can't write down each minute detail). State e.g. programming standards, overview of configuration file formats, tools used for building, types of platforms considered for porting.

As things stand today, if your project is on a public platform (and license allowing), if I post a patch and you don't like it, I can create my own fork. Time will tell if mine survives, can keep up with yours, or even become more popular.