Last Mile Maintainership
21 Mar 2017So Daniel Compton (@danielwithmusic) is a good bloke. We’ve been co-conspirators on a number of projects at this point, and I just wanted to share a quick vignette before I pack it in for the night.
Almost a year ago, James Brennan (@jpb) was kind enough to offer up a pull request (#158) to the kibit tool which Daniel and I currently maintain. We’re both relatively inactive maintainers all things told. Kibit largely does what it’s supposed to do and is widely used for which neither of us can take much credit. We’re stewards of an already successful tool.
Between Daniel’s day job and my move out to San Francisco #158 just got lost in the shuffle. It’s an awesome feature. It enables kibit to, using the excellent rewrite-clj library, automatically refactor your code for style. If kibit can find a “preferred” replacement expression, thanks to James’s work #158 enabled kibit to make the replacement for you. While Daniel and I kinda just watched James pushed it to feature completeness and found a significant performance win which made it not just a compelling feature but fast enough that you’d want to use it.
Then a couple months passed. Daniel and I had other things to do and presumably so did James.
About 11 hours ago now, I saw a github notification about a new comment - “Feature: lein kibit fix or similar that applies all suggestions” (#177).
Cody Canning (@ccann) was suggesting exactly the feature James had offered an implementation of.
At this point James’ patch adding exactly this feature had sat idle for many months. Some other things had come in, been more active and been merged. James’ changeset now had conflicts.
Following the github help docs for how to check out a pull request (spoiler:
git fetch $UPSTREAM_REPO pull/ID/head:$NEW_LOCAL_BRANCHNAME) I had James’ patches on my laptop in less than a minute.
git merge immediately showed that there were two sources of conflict - the kibit driver namespace had had its namespace refactored for style and a docstring had been added to the main driver function which James’ patches touched.
The other was that dependencies had been bumped in the project.clj.
Fixing this took…. five minutes? Tops?
The test suite was clean and in 11 minutes Daniel merged my trivial patch to James’ awesome work done and live.
The whole process of about 10 months was overwhelmingly waiting. James finished the patch in like four days (April 20 ‘16 - April 26 ‘16). Daniel and I were just bad maintainers at getting it shipped.
Were Daniel and I worse maintainers, we could have seen #177 come in and asked either Cody or James to update the patch. It would have taken maybe five minutes tops to write that mail and maybe it would have saved me 15 minutes and Daniel 5.
After months of waiting? Why?
I’ve written before about my own thoughts on code review after working in an organization which is high trust, high ownership and sometimes it feels high process anyway. In this case and I’m sorry to say almost a year late, I went by what I’ve come to believe - that reviewers should make an effort to take responsibility for merging code rather than requiring the primary author to do all the leg work.
Sure I could probably have pinged James or suckered Cody into writing that merge commit but why? What does that buy anybody? It was so, so easy to just take James’ changes and merge myself rather than asking someone else for trivial revisions. And it makes for a better process for contributors. It’s not their fault that your project has grown merge conflicts with their changes.
If there had been a huge conflict, or James’ changes had seemed somehow deeply unreasonable it would have been a different story.
But going the last mile for your contributors is worthwhile
^d