The First Patch

February 25, 2010

This post is part of the Editorial Calendar Plugin for WordPress team series. We take a first-hand look at a far-flung open source team as it forms, communicates, resolves problems, and (hopefully) succeeds. Stay up to date with the whole series.


The editorial calendar project has gone on for a couple of weeks now. We’ve had meetings and made sure everyone is on the same page, but now it’s time to get real. We’re ready for the first patch.

Computer programs are made up of a very large number of very small pieces. The business of writing computer software is figuring out how to organize and manage all of those little pieces. When a developer says, “it worked on my machine,” they’re probably right, but that doesn’t mean it’s ready for anyone else.

So far my wife and I have have written all the code. Not it’s time Bob to make the first code contribution and submit it as a patch. This is a little scary because up till now I’ve never seen his code. I know he’s a chef, but I haven’t tasted his cooking. This first taste makes a large impression.

Bob’s first patch is more an appetizer than a three course dinner. He’d worked on one of the small pieces I’d suggested as a good way for new programmers to get started with the project. When the patch came in it had some good signs and some bad.

Good signs

He did it quickly. The tasks were all easy and small so a quick response was perfect.

He made a real patch. Unix defines a diff and patch process for submitting code and he used it well.

Bad signs

He wrote a very short email. The first patch is crucial and you expect even more documentation than usual. His email was terse to say the least.

Bob didn’t test it. Developers call this throwing shit over the wall.

Let’s remember that nobody on the team has met Bob face-to-face. We don’t really know what to expect from him, first impressions matter and this is a good time for Bob to make it easy for us to give him an A. In this case the easy A is showing us his work and making sure it works.

Human problems are complex problems

Someone submitting a bad patch on a typical open source project would receive a small rebuke and be given a second chance. Maybe even two or three second chances. But this wasn’t a typical project.

Bob was getting paid by Justin and Colin. That makes this a human problem. They were using this project to test him out. I called Colin and explained the problem to him. He called Bob. Colin put it well, “no bad news over email.”

This is the trickiest part of the relationship. We can’t ignore Bob’s bad patch, but we can’t villify him for it either. In person we’d have a talk, but remotely the system can break down with bad actors. It’s too easy to ignore problems.

So was Bob a bad guy, just a little careless, or the victim or a misunderstanding? We didn’t know. Bob gets a second chance. If the next patch is good we’ll forget the first one. If it’s bad we have a real problem. We’ll just wait and see.

The picture in this article was created by californiaAmy and is used in accordance with the Creative Commons license

Previous post:

Next post: