“Please send a patch”

There’s a frequent pattern in the Debian community where someone would suggest an improvement to some package or service, and the person responsible for it would reply with “please send a patch”.

Of course, there are cases where it’s perfectly reasonable to ask for a patch: when the task is expected to take hours, or when the result is of limited interest to everybody except the demander.
But often, it would be much more efficient for the person responsible for the service to take 5 or 10 minutes to make the change, than for the demander to spend half an hour learning how to contribute to this service, writing an untestable patch, and sending it back to the person responsible for the service for integration.

It is important to see this problem as the issue of maximizing the usefulness of the resources we have. Often, we are in a situation where we could either:

  • spend 30 minutes on a service we don’t know, just to push one change
  • spend 30 minutes making three or more changes that others would like to see in a service we know

It would be much better if, instead of saying “Please send a patch”, people would say “Are you interested in contributing a patch, or should I make the change myself?”. Remember that each time you ask someone to take some time to contribute a patch in an area where he is not an efficient contributor, you take some time away from him that could be used to contribute something in an area where he is efficient.

9 thoughts on ““Please send a patch”

  1. Dear,

    dont need a patch. I need this only, if i becom a patch. First i try it self. This takes to 1 week. Then search for the Problem in the net for 2 weeks. Then i need a patch ;-)

  2. I have been thinking about this issue as well. It feels to me like some sort of a micropayment / real tangible benefit provision system needs to happen to better these situations. Instead of sort-of empty bugzilla-votes, people really interested in a feature/bugfix could vote with their wallet. Obviously this requires some sort of a tracking/result system with it, i.e. some sort of % estimate that person(s) responsible will deliver to establish trust in the system.

    I think Flattr.com is of those that I know probably the closest right now to what I’m thinking.

    I should note this particular angle of thinking comes from a small startup software development company perspective.

  3. I think you’re missing the subtext of the reply “patches welcome”. It is a hint to the requester that the developer’s time is not infinite, nor does it wait on random people dropping in with suggestions. Most developers of FOSS projects are already busy working on features, bug fixes and improvements of their own, and a feature request or bug fix from someone else does not automatically get preferential treatment.

    You’re certainly correct that it will often be much easier for the project’s developers to do the work rather than a person new to the code base. In my case I have several projects I’m interested in that are in languages that I am not familiar with and do not want to learn. And therefore ‘patches welcome’ is a little rude – it can say “we don’t care who you are, unless you’re an awesome $language developer already familiar with our code we’re going to ignore you”. Developers should take care to not drive away people interested in their project.

    Have fun,

    Paul

  4. There really are two sides to this, but I can see Lucas’ perspective. It happens a lot, to many people. “Patches welcome”, and variations on that theme, has the subtext of “the developer’s time is not infinite”, yes, but it also has a passive-aggressive subtext: it does not make clear to the requester what the maintainer’s opinion of the suggested change is, should the change be written as-is; does it fit the philosophy of the program; it doesn’t explain the maintainer’s reluctance to work on it themselves; will the patch be applied in a timely fashion, or is the maintainer too busy to do that too?

    Quite frankly, a response such as this is a lot warmer, friendlier and more professional:

    “I’m sorry, but I don’t have time to work on that issue at the moment. I agree that the suggested change is sensible. If you can put together a patch, I will be able to review the patch in the next 2 weeks. Be aware that this area of [ program ] is a bit hairy, and watch out for [ nuance ]. “

  5. Looks like you both opted for the third choice.

    Often, we are in a situation where we could either:
    spend 30 minutes on a service we don’t know, just to push one change
    spend 30 minutes making three or more changes that others would like to see in a service we know
    spend 30 minutes ranting about it online

    Not the first nor last time this will happen.

Comments are closed.