19

In the answers of What's the canonical retort to "it's open source, submit a patch"?, many people voiced the opinion that simply asking people to submit a patch is arrogant and rude.

But it seems to me that as a developer on any open source project, you will see many more feature requests on the mailing list than you could possibly implement. So when a user says, "I would like to see feature X", the truth of the matter is usually that the chances of it getting implemented are pretty slim unless they submit a patch themselves. Also, sometimes a little encouragement might be all that's needed to turn a user into a contributor.

On the other hand, you don't want to scare (potential) contributors away by coming off as rude.

So how would you say "please submit patches instead of asking for features" in a friendly manner?

Update: Thanks for all the suggestions! I see most of them require pretty lengthy explanations. But since I'd rather avoid either (a) explaining the same thing every other day (it just takes too much time), or (b) using snippets that I paste into email (it gets impersonal real quick), I wonder: Has anyone written this up in a document that I can link to?

(Project-specific things like how to write tests, compile the code, and submit the patch still need to be documented of course, but I think those technical issues should go into CONTRIBUTING.txt anyway.)

Improve this question
4
  • 12
    Very important, if you don't intend on accepting patches don't request it! That is, if you say "Submit a patch" then you must be willing to accept a clean, well-written patch.
    – edA-qa mort-ora-y
    Commented Jun 11, 2011 at 13:54
  • 1
    @edA-qa - not necessarily every clean, well-written patch - but if you are likely to veto new features, you should probably have a way people can propose those features to you for a probably/probably not answer before they invest lots of time developing them.
    – user8709
    Commented Jun 11, 2011 at 19:31
  • @Steve, I don't mean unsolicited patches, those are a different story. I mean specifically as in the question, if you tell somebody to submit a patch.
    – edA-qa mort-ora-y
    Commented Jun 14, 2011 at 6:53
  • It's only arrogant and rude when you really mean "that may or may not be a good idea, go away". If you honestly mean that it's a bad idea, say so. If you mean it's a genuinely good idea that you don't have time to implement, say so. And indicate that you would be willing to accept a patch that implemented that feature. (That way, maybe someone actually will submit a patch.) The problem with just saying "submit a patch" is that's vague and dismissive.
    – David Schwartz
    Commented Aug 21, 2011 at 21:23

8 Answers 8

Reset to default
9

You don't.

In so far as I've been experiencing it, candidate contributors are tinkerers, and won't submit a feature request by merely requesting it. They'll typically request it with some level of participation already:

  • Wouldn't it be sweet if [...]? It might be possible doing A, B and C. (That's bait for: I don't have time but here's an spec'd out idea in case you do.)
  • Here's a patch to do/here's a fix for [...].
  • I'm thinking of writing a patch to do [...] and could use feedback/is anyone interested in helping out.
  • Etc.

Coders who submit a feature request outright usually do so for a reason. Some of them include (and I know for a fact that the last two happen in WordPress, for instance):

  • They're neck deep in other open source projects, i.e. have no time.
  • They're free-riders and intend to keep things that way.
  • It's way beyond their skill level/written in a language they know nothing about.
  • They use the software from lack of a better option, and don't want to be dealing with a smelly pile of batsh*t^\b code.
  • They can no longer be bothered because their prior patches got ignored/rejected, i.e. think they'd be wasting their time.

More typically, feature requests will be coming from end-users who couldn't contribute the patch even if they wanted to. Especially when submitted outside of the ticketing system.

I think your most important priority should be to not put off potential/existing contributors, rather that trying to actively recruit new ones. It's hugely important, and I say this from experience. I've a weird way of picking up a new code base, which involves cursory reading of the code to get some level of understanding of it, jumping into the ticketing system, and fixing easy looking bugs to learn the internals in depth (and filing new ones as I test). Over the years I've flooded a few projects with dozens of tickets and patches. Many times these tickets will get little to no timely attention (not even an acknowledgement, e.g. keep it up!) -- including when they come with documented diagnosing steps and unit tests attached.

Improve this answer
1
  • 2
    I couldn't agree more. There seems to be a general sentiment among F/OSS projects that anyone who submits a feature request is just lazy and could submit a patch/modify their own install if they really wanted that feature. It's extremely off-putting to anyone who simply doesn't know how to program, or doesn't have the time because they're involved in other projects. It's not the words "submit a patch" that's rude, but the assumption that the user has nothing else on their plate.
    – Shauna
    Commented Jul 8, 2011 at 15:11
10

In short, you explain you don't have unlimited time to do their work for free. (You can skip the 'for free' bit), and that they can contribute any time they like, it's not "your" project, its everyone's project.

so you say "We're really sorry, that's a great idea but we're just too busy with all the other work going on, we'll add it to the list, but if you'd really like to get this in, and you'd like to help us out by contributing to the project then that'd be wonderful. We have some documentation to help guys get into making changes to the project, they're here, so if you have the skills and the time and want to help us, then please have a go and send us a patch with your changes. We might have to make some mods to it when we get it so it fits in with the project's standards, but you'll be doing us a great favour by at least giving us a leg-up for this work and we'll love you for helping us out".

Of course, once you start asking for patches, you can never, ever, leave them lying on your ticket system for too long, if you get a lot, you'll be integrating them more than doing the work you used to. You may not like that, but it's necessary if you want patches to keep coming.

Improve this answer
3
  • I like this. Perhaps this is actually something best put into the documentation so you don't have copy-and-paste it every time you need to explain this. And then you just say "Would you like to contribute a patch? http://.../#contributing"
    – Jo Liss
    Commented Jun 24, 2011 at 15:43
  • @JoLiss: You were critical of my answer for sounding impersonal; how do you figure that copy-and-pasting a hyperlink to a FAQ is better? If you're going to use a canned response, then use one that either shows empathy or sounds professional (or both). This idea for a shortcut is neither; in fact it's precisely the kind of rudeness that the original question was complaining about.
    – Aaronaught
    Commented Jun 24, 2011 at 17:40
  • Huh, interesting. I didn't realize that people would necessarily find it rude if you post a link. On the other hand, I find that canned responses come off as very impersonal. So perhaps it's best to just type out these kinds of explanation when they come up.
    – Jo Liss
    Commented Jun 24, 2011 at 17:46
6

Stay polite, and explain the situation clearly. What about something like:

Thank you for your feedback. We find your feature very interesting, but despite our efforts to implement most requested features in our product, we do not have enough time to implement them all. If you're a developer, you can join us by contributing to the project, since it's open source.

See, you can't just say "Why are you bothering me with your requests? I'm not here to work for you for free; if you want this feature, go and implement it yourself". The person may be a non-developer, may not know the language used to develop the product, etc.

So instead of being rude, you may suggest to participate to the project, and also explain why you may be unable to implement the feature yourself.

Another way to not being rude is to not have to say anything. If you have a website where the users of your application may suggest new features and report bugs, you may want to sort the items by their priority: for example if a feature is requested by 10 000 users, and another one is requested by only 10, there are chances that the first one will be implemented first.

On such website, you can always put a "implement it yourself" suggestion for the features which, after a few days or weeks, haven't received enough upvotes from other users.

Improve this answer
5

Thank you for your request. We have added it to our project backlog and will be reviewing it shortly.

Please note that due to the volume of requests, we cannot guarantee that every one will be implemented. We rely on volunteers, so if you are a developer, please consider donating some of your time and submitting a patch. Otherwise, please know that we are all working hard to get through the backlog and will get to your request as soon as possible.

Really, was that so hard?

Improve this answer
6
  • +1 excellent; nice, professional response. @Jo Liss: bear in mind that most people simply want to use the software, not dedicate their lives to it.
    – Steven A. Lowe
    Commented Jun 12, 2011 at 15:34
  • I like the essence of it, but I personally think the tone is a bit too impersonal. You are usually not a company doing customer service, you are just a developer talking to a peer. Even the folks at 37signals avoid this type of language.
    – Jo Liss
    Commented Jun 24, 2011 at 15:48
  • @JoLiss You are doing customer service, whether you want to believe it or not. And you didn't say anything about "peers". It's possible that the person you're speaking to is a developer, but unless you know that for a fact, I don't think it's an appropriate assumption to make (unless you're working on developer tools, but you didn't specify that in the question). Finally, the guys at 37 signals talking about what constitutes bullsh*t is... ironic, to say the least.
    – Aaronaught
    Commented Jun 24, 2011 at 17:36
  • Hm. I'm not sure I'd want to give the impression that I'm doing customer service... Your point that users are not necessarily peers is well-taken though. Re 37signals, here is another blog post that talks about tone -- I think the point is not so much that you should not bullshit, but that you shouldn't come off like a faceless corporation. In my view this is a good strategy, and it's even more true for open source projects.
    – Jo Liss
    Commented Jun 24, 2011 at 17:42
  • 2
    @JoLiss: If you want to be more personal than this, great, all the power to ya - this, to me, is the minimum standard you should be meeting in terms of courtesy. Don't just say "submit a patch" - explain that you're busy, not lazy or disinterested; acknowledge that they might not actually be able to submit a patch, and that even if they are, they would still be doing you a favour by obliging.
    – Aaronaught
    Commented Jun 24, 2011 at 18:12
4

Well instead of just saying "submit a patch", you should elaborate a little more.

  • Make clear, that you don't have the time for it right now or in the foreseeable future, so if others want it implemented soon, there is no way but providing a patch.
  • Take the time to assess the feature. If you sincerely like it, there's no harm in saying that. Encourage people. Or if you think the feature is actually bad, then take the time of explaining that.
  • Provide some starting help. Nobody knows the code base like you do. You don't have the time to do it, but you probably know exactly how you'd do it and where you'd start. Within 5-10 minutes you can share knowledge that others would need hours to figure out. Also this helps your big picture to prevail. Instead of having alien features bolted on to your project, you can guide contributors to a nice integeration.
Improve this answer
1
  • I agree with this, but I would add that you need very clear guidelines on what you expect from a patch. (e.g. conforming to code standards, unit tested, documented). This is important, because it is very likely that you will be the one who has to support the feature - patch submitters very rarely stay around to fix their bugs or offer support to other users of your library.
    – Mark Heath
    Commented Jul 8, 2011 at 13:42
3

Here's what I typically say...

"That's an interesting suggestion and it would be cool if FooBarLib could do that. Unfortunately, FooBarLib is just a spare time project for me so it is unlikely that I will get round to doing that in the near future. I welcome submissions to FooBarLib, so if you are able to implement this yourself, then feel free to submit a patch (make sure you read our "how to contribute to FooBarLib" guidelines first)."

Improve this answer
2

In addition to the nice ways to say "Submit a patch", also provide developer oriented documentation so that others why really want the feature can get up to speed on your project easy. Many projects aren't developer friendly and require days at a minimum of reading thousands of lines of code and tons of small test cases poking at different parts of the system to get right.

If you provide help to the possible developers, they will be more than willing to provide help. This means good code documentation, good wiki pages explaining the flow (or a good UML/whiteboard diagram), and an easy way to get patches accepted.

Improve this answer
-2

I really love the way github encourages others to fork the project. Multiple versions of the same project can exist under different user accounts. If you don't like the direction I am taking the project than please fork it. You can easily submit pull requests but are not stuck waiting for me to accept it.

So my answer is often, just fork it.

Improve this answer

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.