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.

  • 6
    A free software project should not be coded for a particular IDE. It should be coded for some language, and some API. It is perfectly legitimate to contribute to your software project without using your IDE. Aug 12, 2015 at 13:09
  • 1
    Then, you could give both IDE specific build configuration, and some other way to build your project, e.g. a Makefile. There is absolutely no reason to force external contributors to use the same IDE (or even the same compiler, and perhaps the same OS) as you do. Aug 12, 2015 at 13:23
  • 3
    @BasileStarynkevitch: I fail to see why I must not expect external contributors to install and use a specific tool (IDE A), but at the same time, it seems to be ok that I am expected to install and use another specific tool (something that can process a Makefile). Additionally, for obvious reasons, I cannot (myself) maintain build configuration files that work with an IDE that I do not even have (and thus cannot test). Aug 12, 2015 at 13:26
  • 2
    ... brings me to "BTW, you should edit your question to explain what programming language & operating system & IDE your project is using." - no, I should not, because that is entirely beside the point and really not relevant for the question. This was not intended to be a technical question about project files and how to support different toolsets. That may be a good topic for another question, but this question here was supposed to focus on the inter-personal issue of communication between two humans who take the roles of project owner and contributor. Aug 12, 2015 at 13:38
  • 6
    I guess the contributor was not malicious, but simply careless. You might ask him to improve his patch to add, instead of replacing, these configuration files. My feeling is that small free software projects cannot afford to be hostile to new contributors. Getting the first dozen of contributors is hard, so you really should not appear to be rude or hostile or even careless about any of them. You need to be as gentle & kind as you can. Aug 12, 2015 at 13:39

7 Answers 7


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".

  • 1
    Well, true concerning "unnecessary" - I was thinking along the lines that the contribution does not add any end-user features, and at the same time, it doesn't quite help add any such features in the future, as the contribution does not simplify, but complicate the build process (as several files, in terms of the contained information redundant ones, have to be kept up to date now). Supporting several alternative development toolsets in a project for the convenience of possible future contributors is indeed not a negative objective, either, of course. I might ask a new question about that. Aug 13, 2015 at 9:01
  • 1
    I agree that it complicates the support for the build process: aside from updating the files you might have to worry about quirks of the build tools, or about different warnings from different compilers. Supporting an additional build environment is a significant decision for the project to take, just as supporting multiple runtime platforms is. It's more work in return for the project being more useful to more people. In this case a lower bound on the number of people is the 1 person who submitted this patch ;-) Aug 13, 2015 at 9:44
  • 1
    Also, in the context of any kind of open source development, I think people who want to build your source should be considered end-users. They might be a small minority of users, and so you might decide not to spend your time on them when it could be spent on other features, but building your source before running it (with or without modifications) is a significant use case, and doing so using their preferred tools is a beneficial feature for them. Aug 13, 2015 at 9:47
  • 3
    "in terms of the contained information redundant ones" - final point, if the information is redundant then perhaps you or this contributor could come up with a means to generate both sets of config files from a single expression of the information. You don't want to introduce more build tool dependencies to build the project files, so the repo might need to contain the generated config files too (boo!), but at least there's only one list of source files to update. As with the above, this is a significant undertaking so you'd have to discuss with the contributor whether it's worth the effort. Aug 13, 2015 at 9:53

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.

  • "good idea to exclude IDE config files from your repository" - I was a bit imprecise on this; it's the kind of IDE config files that you would want to keep in the repository. Not the kind that stores your local settings only valid for your machine, but the kind that tells the IDE where to find the files that belong to the project, how to build everything, etc. Aug 12, 2015 at 10:34
  • @O.R.Mapper In general, I exclude any IDE specific files and just keep them on my hard disk - but personal preferences differ
    – ArtOfCode
    Aug 12, 2015 at 10:43
  • 1
    "IDE specific" is tricky though. Project files and such may be good to include in the project, especially when it's non-trivial to constuct them from your build files. See also: stackoverflow.com/questions/347142/project-files-in-repository
    – Martijn
    Aug 12, 2015 at 10:59
  • 1
    Why not use a branch for the optional IDE? Theres no good excuse to enforce your preferred IDE on people, just make it clear that you are not committing to maintaining a 2nd one and the files are for use at your own risk. The first thing someone is going to do is get your project working in their preferred IDE, if you make that difficult you are just putting up a barrier to potential new contributors.
    – JamesRyan
    Aug 13, 2015 at 9:58
  • the conventions in my ecosystem are to prove config for only one command line build tool (there are three popular choices) which can generate the files of the popular IDEs. anyone can then build it with the command line tool which is the authoritive build which unit tests the code. since the popular tools maintain the capability to generate the IDE files no-one runs into such problems. only if somebody needed to add a very exotic feature which requires new build acrobatics would the question of changing the command line build to come up.
    – simbo1905
    Aug 14, 2015 at 19:10

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?

  • 2
    In this case, there clearly is harm. He has working configuration files he's using, and the patch replaces them with one he can't use, instead of adding an option to use an alternative (which would have costs, but has potential benefits for some users).
    – armb
    Aug 12, 2015 at 16:21
  • 1
    @armb to quote OP: "The patch in question is not "wrong" per se, I simply see it as unnecessary"
    – Martijn
    Aug 12, 2015 at 17:23

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.


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.


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.


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 (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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.