Sometimes a bad patch is better than no patch

by @edent | # # | 1 comment | Read ~162 times.

Cunningham’s Law states “the best way to get the right answer on the internet is not to ask a question; it’s to post the wrong answer.”

Edent’s 7th Law (My blog; my rules!) states “the best way to get an open source project to fix an issue is to send a slightly wrong Pull Request.”

Let me explain…

Two years ago, I noticed an annoying bug in the markdown parser of WordPress’s JetPack plugin. I did what every good open sorcerer is supposed to do – I wrote out a comprehensive bug report, including screenshots, and posted it in the wrong place.

I didn’t know it was the wrong place, but they kindly directed me to the right place.

A year later and no-one had taken a look at the bug. I get it. It’s low priority and they have hundreds of bugs coming in. So I added a reproduceable test case.

Another year went by, and I asked for help. I am not an expert in JetPack’s baroque structure and didn’t fancy spending a few days trying to understand it. With a bit of guidance, I found the correct file and submitted a patch.

I knew the PR wasn’t brilliant. It had no tests, only handled a limited subset of the problem, it didn’t quite conform to the project style, and was done in a bit of a rush. But, crucially, it worked. I could demonstrate that this problem could be fixed – even if I hadn’t fixed it in the right way.

To be clear – this wasn’t a malicious PR. I just didn’t have the time or energy to dedicate to writing something perfect. I knew from experience that it’s easier to fix a bug in the right way if you’ve seen it fixed the wrong way.

And that’s what happened. The talented folks in the project – seeing that it was possible – are now creating a patch which works properly.

I’ve done this a few times. Spotted a bug, written an almost-working fix, and let people more clever than me worry about the details.

Don’t spam open source projects with crappy PRs. Take your time to do something which works. Show that the issue is solvable. Let others with more experience finesse your code into something beautiful.

One thought on “Sometimes a bad patch is better than no patch

  1. Really like this. Even with my little open source projects, sometimes the biggest contribution a community member can give is their mental capacity – that effort to context switch and attack the problem isn’t always available and is hugely appreciated.

Leave a Reply

Your email address will not be published. Required fields are marked *