# Advice for Maintainers on Closing Unwanted Pull Requests

DevFeed: [Advice for Maintainers on Closing Unwanted Pull Requests](<https://devfeed.tech/articles/the-art-of-closing-35200.md>)

Original publisher: [Read original article](<https://blog.jessfraz.com/post/the-art-of-closing/>)

Published: 2016-06-04T15:09:26Z

Content type: opinion

Language: en

Sources: [Jessie Frazelle](<https://devfeed.tech/sources/jessie-frazelle.md>)

Topics: [Maintainers](<https://devfeed.tech/topics/maintainers.md>), [Open Source](<https://devfeed.tech/topics/open-source.md>), [Pull Request](<https://devfeed.tech/topics/pull-request.md>)

Tags: [maintainers](<https://devfeed.tech/tags/maintainers.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [patches](<https://devfeed.tech/tags/patches.md>), [pull-requests](<https://devfeed.tech/tags/pull-requests.md>)

## AI overview

An opinion article for open-source maintainers on declining and closing pull requests that they do not intend to merge. It recommends communicating appreciation, closing clearly unsuitable changes early, and leaving room for a differently implemented proposal when appropriate.

## Source excerpt

Being an open source software maintainer is hard. The following post is geared towards maintainers and not contributors. If you are a new contributor to open source I would stop reading now because I don't want you to get the wrong idea or discourage you. Tons of patch requests get merged per day, but this is going to focus on the ones that don't. I've talked to maintainers from several different open source projects, mesos, kubernetes, chromium, and they all agree one of the hardest parts of being a maintainer is saying "No" to patches you don't want. To quote some very smart people I've worked with in the past: One of the numerous examples of information asymmetry in open source: contributors put effort in a pet PR, but maintainers manage cattle. 🕒 -- Arnaud Porterie (@icecrime) May 20, 2016 Rule #1 of open-source: no is temporary, yes is forever. -- Solomon Hykes (@solomonstre) March 30, 2016 To make this rather unpleasant experience of closing someone's patch request easier I have a few ways of going about it. Now of course I am no expert in this area, but on the Docker project we have stats for just about everything. I might have used this data to make a "Ultimate Dream Killers" chart with the maintainers who closed (without merging) the most pull requests, AND I might have been #1 on this chart for some time. None of the suggestions below are going to save you from that person hate mailing you since you didn't merge their patch. But hey anything helps. The ego stroke and close. People love hearing how awesome they are. They also love hearing how awesome their code is. In this option you use this to your advantage. Here's an example: "Thanks so much for spending time on this amazing patch. We really appreciate it. However I do not think this is something we want to add right now, because of yadda yadda but in the future this can change. Thanks so much!" AAAANNNDD close. Close early. No one wants to have to do 300 rebases before learning the design of their patch