GitHub hosted the “Wontfix Cabal” last week in San Francisco, and I was lucky enough to attend, thanks to a pointer from a friend. The organizers, led by Jess Frazelle, conceived the gathering as a chance for people maintaining open source projects to discuss their particular difficulties and some strategies for addressing them. About 100 maintainers took them up on it and convened in San Francisco. At the beginning of the day, we compiled dozens of sticky notes worth of problems that come up in our various projects. These ranged from tips for maintainers who had received the classic question “Is this project still maintained?” to “Ethics and Exploitation in Open Source.” In a common unconference pattern, attendees voted on those topics. The most popular topics were chosen to become discussion groups, and we split up for a morning session and an afternoon session.
In the morning, I joined the “Code Review” discussion group. At OTS, we frequently advise clients who aren’t familiar with the ins and outs of accepting and reviewing contributions from outside parties. This group confirmed our best practices around code review, and reaffirmed its importance. Much of this particular discussion was about projects with an overabundance of pull requests (PRs), which is of course a good problem to have.
A few themes emerged:
- Encourage contributors to start a conversation before putting in too much time and effort. The discussion phrased this as “open an issue before submitting a PR,” but really the goal is to avoid a situation where a contributor puts a lot of work and time into a pull request that the maintainers don’t want to accept. If the person opens an issue for their proposed change, that gives project maintainers an opportunity to respond with reasons why they wouldn’t accept a PR with that change. For small changes, opening a PR might be enough to start the conversation, and making a separate issue could be too much overhead. The important thing to communicate to contributors is that they should be checking in with the project’s maintainers on the direction of their work when they begin.
- Use GitHub’s templates for PRs and issues. These save time by giving contributors a clear idea of what kind of information the project expects, like a DCO (Developer Certificate of Origin), tests for any new functionality, and updates to the documentation. Templates also allow projects to use bots for initial review and response to new contributions.
- Automate initial responses. Responding to PRs and issues with bots saves time for the maintainers while still ensuring that contributors get a response (to retain contributors, it’s crucial to engage with them — that attention is their reward for contributing). Another discussion group pointed out that contributors might take more kindly to being corrected by a bot than by a person. Robots aren’t judging, so the embarrassment of getting something wrong is much reduced when it’s a bot pointing out the mistake.
In the afternoon, I joined a group on “internal versus external contributions.” That is, what happens if an open source project is primarily sponsored by just one company? For one thing, sometimes that company’s priorities will not line up with those of the community. See the full notes here. Some of the main points were relatively straightforward: make clear to contributors what kind of governance your project has, or if it has none. Determine early whether this is primarily a community-driven or a company-driven project, and indicate that to everyone involved. Overall, make sure that the decision-making process is clear.
One part of this discussion that surprised me was how few of the long-lived, well-known projects represented in the group had any kind of formal governance procedure. Kubernetes was mentioned as an example of a project that does have explicit governance. Many others, though, do not. One recommendation that came out of this session was to research and adopt governance practices in more of these single-company-led projects. This calls back to the determination to “be clear about the decision-making process.” It’s fine if internal contributors have outsize influence on project direction, so long as that is communicated at the outset.
I was glad to see that this is consistent with the advice OTS typically gives our clients: don’t worry about governance too soon! Our clients are frequently concerned about how to set up their governance structures before they have a single outside contributor. The fact that many successful and widely used projects don’t have formal governance until their lack of it becomes a problem is just more evidence in favor of deferring these structures, which can quash early project momentum. There is little need to worry about governance until conflicting priorities between contributor groups become apparent. Later in a project’s life, however, more explicit governance is crucial in order to avoid forks.
Most of the conference went on outside these specific sessions. We spent twelve hours together, talking about current projects, aspirations for our communities, opportunities for mentoring, and more. I’m thrilled that I was able to attend — meeting the other attendees was fascinating, as was hearing about different approaches to maintainership. Many thanks to the organizers and sponsors for making this possible. I don’t yet know if there’ll be a follow-up next year, but if so, count me in.