If you follow the Jekyll community, you might have noticed that I haven’t been as active in the last year or two. Part of this is due to life events usurping my free time, and part of this is something else entirely: paralysis. I want to discuss today the paralysis.
Ask any open source maintainer what their job description is, and you’ll likely hear about reviewing patches sent from community contributors as a major responsibility of a maintainer. Maintainers are gatekeepers: they decide what code makes it into the project and what code doesn’t. Part of this is flat-out rejecting proposals (“This feature will not be accepted because it does not fit into the philosophy of the project.”) and part of this is working with contributors to get the functionality proposed up to code style, functionality, and testing standards of the rest of the project. Maintainers are making decisions non-stop about the product, style, functionality, and testing quality of a contribution.
Decision fatigue is defined as:
the deteriorating quality of decisions made by an individual after a long session of decision making.
When I first heard of this, I immediately related to it. Decision fatigue affects me greatly as a maintainer and has become a bigger problem for me since I began working as a programmer full-time.
In college, my primary focus was on doing homework and studying. The decisions I made were essentially around scheduling when to study. My free time seemed endless in some ways, since I didn’t have a particularly rigid schedule. Rehearsals, classes, studying, socializing. I wasn’t making qualitative decisions about whether what I was learning deserved to be in my brain; school doesn’t really give you that choice once you’ve selected which classes to take. I worked on Jekyll in between classes and in the evenings. It was an escape from the monotonous work of completing problem sets.
After graduation, I took a great job at VSCO, a start-up near and dear to my heart. I had used VSCOCam since the early days of the Grid and was really excited to be joining the start-up world. Jekyll was experiencing a renaissance. We were merging contributions, releasing more often, and growing the project to meet the evolving needs of web developers. It was in a good place, so I focused on making sure I could be successful at VSCO. As my focus shifted, I began reviewing fewer issues and contributions and I found myself punting on discussions all the time. I would save the link somewhere and “get back to it later.” Issues and pull requests started hanging for weeks, then months. It was getting harder and harder to determine the merits of a contribution. Every holiday, when I had a few days off work, reviews would start feeling a bit easier and I would chug through some contributions, feeling guilty that I had let them stall for so long. Once I met my girlfriend, my holidays were spent with her instead of on my computer. Slowly, I spent less and less time on Jekyll.
When I began working at GitHub on Pages, we were turning Ben Balter’s 20% project back into a full product with a full-time staff. We were cleaning up old technical debt, we made massive architectural changes, and started working on a roadmap for new features. I had been hired with the understanding that I’d be able to dedicate some of my time to Jekyll. It was an integral part of Pages after all, and I could continue building on the renaissance with more resources behind me. I put some more work into Jekyll, but the problems I could solve within GitHub beckoned. Brad Fitzpatrick wrote about this about people joining Google:
Prior to joining Google I always joked that Google was the black hole that swallowed up open source programmers. I’d see awesome, productive hackers join Google and then hear little to nothing from them afterwards. … Many open source programmers are just programmers. They like working on fun, hard problems, whether on open source or otherwise. … The Google development environment is so nice. … It’s very easy to hack on anything, anywhere and submit patches to anybody …
All this goes to say: fun, hard, new-to-me problems existed at work and I got to work on them with some of the best minds in the start-up world. The development environment at GitHub is really nice. Building a feature into the main app is easy, testing is full of niceties I never had elsewhere, and deployment is just 1 command to Hubot. I began to slowly disappear from Jekyll into this wonderland of Ruby and smart people at GitHub. When I was in college, I didn’t know a single person who was familiar with the command-line until Senior year. Students learn to program Java & Python in IDE’s, and even our classes about net infrastructure revolved around the AWS web UI. Joining the Jekyll community my Freshman year helped me learn practical development skills (like source control!) from really smart people. GitHub was that, but full-time, Chat, and great centralized tooling. The things I had joined the Jekyll community to learn I had learned, and was spending all my time soaking up the nuggets of wisdom from my colleagues, disappearing from the open source community for long lengths of time.
Some wisdom I have picked up has come in the form of advice from Ben Balter and Mike McQuaid pertaining to running an open source community. Ben had the idea of affinity teams & affinity team captains and the idea of setting up a philosophy document as guiding principles for the development of Jekyll. Mike suggested I write maintainer-focused documentation for existing and future Jekyll maintainers. I did that too. Clearly, communication and delegation were two aspects of running an open source community that I still hadn’t learned well.
Every time I take a look at the list of PR’s, I want to just close the vast majority of them because they don’t seem useful to me. I have lost my broader lens of users’ needs, and we haven’t documented our core use-cases anywhere. When I see a contribution, I don’t know how to evaulate it. We have process docs, but nothing stating how to evaluate feature requests. Do you ask the user to ship it as a plugin? How do you know if it should be in Jekyll core? Should we ship a new plugin with this functionality? Does this break a relied-on behavior? This laundry-list of questions spirals out of control until I close my browser tab.
Recently, I have been considering what it would look like to pass on the torch of lead maintainer to another member of the Jekyll community. Our affinity team captains are really excellent and are passionate about making Jekyll great. But I’m afraid if I leave, the new maintainers won’t feel like they can make decisions because they’ll feel the same paralysis.
Is this paralysis, coupled with the pressure of a project that needs work if it will survive, the first step in burning out?
I don’t know the answers here, and I don’t know when I’ll find them. All I know is that I need to start asking myself how I can reduce decision fatigue. The Jekyll community deserves better than an absentee lead maintainer. If you have any ideas or resources for dealing with decision fatigue, feel free to email me. Or, if you also suffer from this and just want to reach out to commiserate, I’m all ears. I’d be really curious to hear your thoughts.