Xavier Borderie sent me a series of questions via email about managing an open source project. My responses are primarily from the perspective of managing WP-CLI.
How do you organize daily/weekly schedules so that community PRs are not forgotten?
Call me a glutton for punishment, but I receive email notifications for all the GitHub activity of projects I manage. I use email because:
- Email is easy to quickly process with keyboard shortcuts.
- Email keeps track of read/unread state for me.
- As needed, I can create filters to help manage my information flow.
Ultimately, this means I see a pull request as soon as it comes in (or, at least, when I check my email).
When I see the pull request come in, I take some form of action on it. This action is either:
- Make a judgement as to whether the pull request will be able to land — yes without additional changes, yes with additional changes, or no.
- Determine I’ll need to set aside dedicated time to review (and make a judgement).
In both cases, I respond to the contributor accordingly. In the latter case, I add the code review to my task management tool, and come back to it when I have the bandwidth.
All of this hopefully underscores I think it’s important to communicate well, and handle contributions in a timely, effective manner.
How do you manage with contributions which need rebasing, amending and/or tweaking — and the contributor is silent for months?
WP-CLI has a two-week abandonment policy. If we don’t hear from you in two weeks, then we consider the pull request is abandoned.
Usually around day 10, I’ll reach out on the thread and as the contributor if they’ll be coming back to finish up. They respond most of the time, with either “yes, just need another day or two” or “no, I’m too busy now.”
When a pull request is abandoned and I want to land the code anyway, I’ll fork their branch so they still get credit for the work they’ve done and finish it up.
Does every team member manages her/his own time, or do you clock community-related work?
My dba, Hand Built, actually just a business of me, myself, and I. In 2015 (the last year I calculated it), I spent 12.26% of my time contributing to open source.
This year, things are bit different. Not only do I get paid (on a part-time basis) to maintain WP-CLI, but I have the budget to eventually hire a couple more part-time maintainers. The first is ramping up right now.
The expectation is that each of us commits an average of five to ten hours per week towards project. The theory is this is enough time to make regular, substantial contributions to the project, while also having enough of a foot in the real world to focus our effort on what’s most important. Each person is expected to manage her/his own time, balancing WP-CLI with the rest of their life as they see fit.
What was the impact of 5 For the Future for you when it was launched, and do you feel the 5FF campaign is still relevant/followed today?
For those who aren’t in the loop, “5 For The Future” was/is a call by Matt Mullenweg for companies to dedicate 5% of their people towards the WordPress project:
I think a good rule of thumb that will scale with the community as it continues to grow is that organizations that want to grow the WordPress pie (and not just their piece of it) should dedicate 5% of their people to working on something to do with core — be it development, documentation, security, support forums, theme reviews, training, testing, translation or whatever it might be that helps move WordPress mission forward.
Personally, I’m not sure how much of an impact 5FF specifically had on increasing the labor pool for the WordPress project. It seemed to be more of a one-time rallying cry than anything else.
I don’t mean to discount the intent, though. While the WordPress project could certainly benefit from more labor capacity, it certainly has a lot already from a healthy variety of companies. Furthermore, introducing more labor to the project also requires scaling up capacity to direct the labor.
On the other side, five percent of people seems to be a very challenging goal for many companies. If I were to put a number to it, it seems like most companies engaged with open source would be in the one to two percent range.
Which isn’t to say it’s not important for companies to more effectively support the open source projects they depend on. Contributing to open source is still hard: it’s a lot of overhead to stay regularly engaged with a project, and difficult to account for the benefit of the contributions.