It's my first time maintaining an open source project, and I've been sent a ton of pull requests, issues, and feature requests. How do you maintain all of them? And, more importantly, how do you say no? There are some PRs that I've gotten that are great, and some that are good but I just don't like what they do with the app, and I'm not sure what the etiquette is there.
Cassidy Williams
Posted on
What is the proper etiquette for declining PRs on open source projects you own?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (8)
I'd add a note in the README that indicates that PRs will only be merged if they fit the project's direction. Let people know to open an issue to discuss a contribution beforehand if they don't want to "waste time" on PRs that will not be merged.
As for the currently-open PRs that do not fit the project's direction. I'd politely close them with some constructive feedback. It will be easier going forward if your expectations become more clear and documentable.
I don't have all that much experience in this area, though. Would love to hear from others about the nuance and etiquette of this kind of stuff.
A key is to be honest. Don't reject a PR on artificial grounds, such as bad style, or missing tests, if you just don't like it. The submitted might correct the problems and submit again, thereby wasting a lot of time. If something doesn't fit with your vision then just say it directly, or perhaps ask them why they think it fits.
Feature requests are pretty easy to ignore. Just give it a priority, or tag, and move on. Nobody expects them to be done in a timely fashion.
Defects should be prioritized if you have the time. Base this on the quality of the issue report. A clear report, clear description/reproduction/etc. should be looked at sooner. Anything which doesn't seem clear can just be marked as needing details, then closed after a period of time.
In the end it's your project. Realistically you'll onyl have a tiny few good contributors. Cater to them since they'll be the most productive. don't waste time following up with people that are only partially interested, or unwilling to adapt to your style. Don't be a dick either, otherwise you'll chase everybody away.
In addition to the excellent tips already suggested, I'd include a section in the README on "how to PR" that outlines the following:
"Please only submit pull requests corresponding to an issue. Check if an issue exists for what you want to do before submitting. If it does exist, write a comment with your proposed solution and wait for my response before starting work. If an issue doesn't already exist, create one." (Paraphrase and tweak this to make sense in the context of your project)
If you have a broad outline of what does and doesn't fit with where you want to go with the project, give some info on that, but emphasize that people should still use/create issues to determine if their PR is needed before doing any work.
Then don't accept any PRs that don't follow 1). If someone submits a PR with no issue attached, link them to the section of the README that explains 1) and ask them to link to a ticket before you'll look at it.
I would recommend including at minimum a roadmap, either a separate doc or in ReadMe, outlining any expected direction the project is/will/should take and what is in scope or out of scope. That sort of a thing, especially with examples of scope, will likely grow over time based on such occurrences, but can help stave off further headaches.
In the event of a PR with a lot of work and just not aligning with the project's direction, thank them for their work. Then let them know what it would take for the PR to be accepted. They're trying to help, quite possibly on a project they care about, but are just going a different direction. If it's too different, there's a reason forks occur in open source.
Polite but firm. I just say "no thanks, that doesn't fit the scope of the project" and then try to give some brief flavor of my vision for the project (just enough that it doesn't seem arbitrary)
Welp, someone already wrote mostly what I came to write. "Sorry. it doesn't fit our vision / roadmap, here's why... Please come back because your work was still greatly appreciated." I think explaining why and then showing gratitude for the contribution increases the likelihood they'll return.
Jessie Frazelle wrote some smart words about this a while ago. I recommend checking it out!
About the issues management I written this some time ago medium.com/@FezVrasta/how-to-maint...