Github pull requests

I recently read A plea for better opensource etiquette. Its basically a whinge about github pull requests and issues getting ignored. This is a really hard topic, because opensource work is mostly volunteer work, and everyone gets precious about their contributions. But most people have no idea what its actually like to run an opensource project. Dealing with mountains of patches and bug requests is this awful time sink deluge. Every time someone submits a new pull request, I have three bad options:

  • I can stop what I'm doing several times to triage the patch (best case). About 2/3rds of the time, people just forget about their patches when I do this and they hover around and bother me.
  • I can accept the patch with its (often unknown) faults
  • I can ignore it and deal with it later, or hope someone else with commit access will find time to deal with it

As a maintainer of a project with almost 2000 stars on github, I sway back and forth between being allowing patches ("Just submit code to get what you want done. We can fix it once its in the repository") and being a stickler for details ("I don't want your change until you give me tests."). I really wish I could just give everyone who submits patches commit access and let them at the repository. It would save me time. It would save you time. It would make my project better. I certainly don't write opensource software because I enjoy being a policeman; I hate it. I hate saying no to real work that solves real problems.

But the sad, unfortunate truth is the majority of pull requests aren't very good.

  • Many do not understand the project's conventions (eg, if my project is written in coffeescript, so your code needs to be in coffeescript too). Example: . After I insisted on the code being ported to coffeescript, several users whinged on the project's mailing list about my language choice.
  • Most pull requests don't have tests. Submitters usually don't even run the unit tests before submitting, and their pull requests often break the tests we do have. I understand that you don't write tests in your application, but the rules are different in an infrastructure project that many people rely on. I don't trust myself to write bug free code without tests, and I understand my project way better than you do.
  • People often have extra modifications in their PR that have nothing to do with the patch. For example, this pull request has good parts near the top of the diff, but right down the bottom it makes some unrelated changes that make my code uglier in the name of 'optimization'. Quotes because benchmarks weren't actually run. The changes didn't improve performance, they just made my project ugly and broke my whitespace convensions.
  • Some bug reports exist only to waste my time (what is a javascript?) or and complain about my programming language choices. This is what I was doing instead of triaging your bug. I'm sorry, ok?

I usually err on the side of allowing changes and fixing stuff later, but my projects have suffered for this several times. I've had maintainers accept pull requests that break the unit tests (and leave them broken for weeks). I've had otherwise normal code suddenly sprout extra levels of indentation. I've had mountains of bugs appear, filed against a feature I didn't write, don't understand and I never use, who's author has disappeared. I've been burned enough that I can totally understand maintainers who ignore patches and bug reports.

I still love everyone who cares about my projects enough to submit a bug report or takes the time to make a pull request. I need contributors to make good software, but it breaks my heart when nice people submit slightly bad code, and I need to either whinge at you or stop working on my own pet feature to clean up your mess. I'm sorry to everyone who's patches gets ignored, but sometimes I get tired too.

In short, its fun to complain about The Man because your precious donation of code is being ignored. But its just as thankless running a project, only we shoulder way more responsibility and burn way more time doing it. If you want me to look at more of your bug reports, help triage my other pending bugs and pull requests. If you want me to stay excited about the project, email me to say how much you like it, and tell me about the cool things you're doing with my code. If you want commit access, ask for it. Finally, if you think you can do a better job running a project, use the fork button and do something about it.