Balancing incoming tasks in volunteer projects

Open source (and other volunteer-driven) communities are often made up of a “team of equals.” Each member of the group is equally empowered to act on incoming tasks. But balancing the load is not easy. One of two things happens: everyone is busy with other work and assumes someone else will handle it, or a small number of people immediately jump on every task that comes in. Both of these present challenges for the long-term health of the team.

Bystander effect

The first situation is known as the “bystander effect.” Because every member of the team bears an equal responsibility, each member of the team assumes that someone else will take an incoming task. The sociological research is apparently mixed, but I’ve observed this enough to know that it’s at least possible in some teams. You’ve likely heard the saying “if everyone is responsible then no one is.”

The Bystander effect has two outcomes. The first is that the team drops the task. No one acts on it. If the task happens to be an introduction from a new member or the submission of content, this demoralizes the newcomer. If the team drops enough tasks, the new tasks stop coming.

The other possibility is that someone eventually notices that no one else is taking the task, so they take it. In my experience, it’s generally the same person who does this every time. Eventually, they begin to resent the other members of the team. They may burn out and leave.

Oxygen theft

Sometimes one or two team members jump on new tasks before anyone else does. Like the delayed version in the bystander effect scenario, this can lead to burn out. But worse, it can drive away team members who want to take tasks. If they’re constantly missing work because they weren’t able to immediately jump on it, they’ll go find other places to contribute. I call this “oxygen theft” because it’s like sucking all of the oxygen out of the room: it puts out the flames.

I have been an oxygen thief myself. Shortly after I started as the Fedora Program Manager, I became an editor on the Fedora Community Blog. I was publishing regular posts and I happen to be a decent editor, so it made sense to give me that privilege. But because Fedora was my day job, I was often the first to notice new submissions. Over time, I eventually became the only editor working on posts. By accident, the editorial team became a team of one. That’s on my list to fix in the near future.

Solving the problem

Letting either the bystander effect or oxygen theft cases go for too long harms the team. But with volunteers, it’s hard to balance the work. Team members may not have consistent availability. For example, if one of the team members dayjob schedule varies from week. They probably don’t have evenly distributed availability, either. Someone who is paid to be on a project will likely have a lot more time available than someone volunteering.

One way to solve the problem is to take turns being in charge of the incoming tasks for a period of time. This addresses “if everyone is responsible then no one is” by making a single person responsible. But by making it a rotating duty, you can spread the load.

After learning my lesson with the Fedora Community Blog, I was hesitant to be too aggressive with taking tasks as an editor of the Fedora Magazine. But the Magazine team was definitely suffering from the bystander effect.

To fix this, I proposed having an Editor of the Week. Each week, one person volunteers to be responsible for making sure new article pitches got timely responses and the comments were moderated. Any of the editors are free to help with those tasks, but the Editor of the Week is the one accountable for them.

It’s not a perfect system. The Editor of the Week role is taken on a volunteer basis, so some editors serve more frequently than others. Still, it seems to work well for us overall. Pitches get feedback more quickly than in the past, and we’re not putting all of the work on one person’s plate.

[If you are intrigued by this half-baked post, you’ll enjoy my book on program management for open source projects, coming from The Pragmatic Bookshelf in 2022.]

How helpful is helpful enough?

I have a confession: I am a compulsive favor-doer. When someone asks for my help, I have a hard time saying “no”. Since there’s only so much Ben to go around, this gives me a tendency to over-commit.  I recognize this as a problem, but I can’t help myself.  It’s in my nature to be helpful.

So how helpful should I be?  My wife works at the county library, and last week a gentleman was checking out a book about Linux.  In the course of small talk it came up that he’s trying to dual-boot Ubuntu and Windows 7.  Angie mentioned that I run Linux at home and he wrote down his phone number and e-mail address for her to give to me.  I’m not mad at her for it, she hasn’t committed me to anything, but it got me wondering.

My initial reaction was to e-mail the guy and introduce myself.  After all, I’m a nice guy and that’s what I do.  Then I realized that this would probably make me his go-to support.  I don’t mind helping people, but an open-ended commitment isn’t exactly what I’m in the market for.  I already do a fair bit of free work for strangers.  I answer questions in the #fedora IRC room, on LinuxForums.com and on Serverfault.  Additionally, I write this blog, and I write documentation for the Fedora Project.  Maybe I don’t do as much as others, but I’m definitely contributing back to the community.

So maybe, I thought, I should set a rate and charge him for help.  That seems like too much effort, though. I’m not really interested in doing enough consulting/contract work to make it worth the trouble of filing the appropriate paperwork.  Besides, I have such a hard time asking for a reward for being nice.

Where does that leave me then?  I have no idea.  In the meantime, I’ve gone with the head-in-sand approach.  I’ll just pretend like this never happened.  Perhaps someday I’ll be able to solve this quandary.