Pull requests are not conversations Saturday, 05 February 11

I don't remember anything that changed my work flow in a so big way as git did in the latest two years. I will not argue too much about that, as you probably experimented the effects yourself if you are reading this blog post, or perhaps you are among the guys I should say thanks for the fact I started using git.

But if git is cool, Github makes it cooler for sure. Github is like a market for git, where code gets exchanged, shared, publicly hacked. In short I love git and github. Still I think that github pull requests are posing a problem in the open source development world, and this post is all about this.

How it used to work

Before git and pull requests the obvious way to contribute to a large enough open source project was to write a message in the mailing list of the project, asking about what the feelings are about adding a given feature.

It was possible to start the discussion providing also a patch, but not required. When I say also I mean, along with all the rationale for adding the features, what the problems and complexities are, what the gains, and so forth.

Like a painting uses colors but is not, after all, about colors, so a software project uses code, but is after all, about design. Code can be used to prove your point, to show a way to obtain the effect you are seeking, but the most important point is the design of a new feature. The ability to resist to the temptation of adding things that are not useful but just appear to be useful, because perhaps there is a defect in some other part of the design, or because there is a not so obvious but simple way to get the same effect. And where to discuss this kind of things if not in the project mailing list?

As github is a market for code, the project mailing list is a market for the project design (more and more together with Twitter, in my experience).

So that is how contributions used to work, and how most of the Linux kernel itself was built. But I've the feeling that github pull requests are bringing a new way of thinking to the table, that is preventing a lot of interesting discussions from happening, and at the same time is wasting a lot of coding resources.

Pull requests

My point so far has been that contributing to code should be a conversation about design, with some code in order to support that conversation or to finally implement what seems a good design in a tangible form.

In this conversation pull requests are the stage when a developer asks another one: "Hey, let's merge that". In github pull requests this happens in a very private way. This should be the very, very final stage of a contribution, but guess what, now most of the time is the first stage of a contribution, that directly starts with a pull request, about a feature not publicly discussed, possibly not needed, or that is actually related to something else that is already a work in progress, and so forth. In the end this means that most of pull requests are not going to get merged. At least this is what happens with Redis.

Pull requests used in this way are removing value from a conversation, that should otherwise be very different and public. Like: We still take advantage of github that allows to make our topic branches explorable and testable. But the whole process is now sane and design centric. And since the discussion does not start with a "let's merge" there is no need to provide a perfectly finished code, or code at all.

Please if you have comments use hacker news instead of the blog comments.

5 comments
home