Managing Group Email Lists

I spend a lot of time in and around group email lists. I own some, participate in some, and watch some. As a result I’m often asked, or find myself, in conversations about how to manage them effectively. While I certainly can’t say I’ve mastered the domain, I can offer a few reliable tips based on my experience.

Centralized and Decentralized

The most common topic is a debate about whether there should be one list or multiple lists for an organization of many parts. The short answer is: there should be both.

This comes up with Brigade and was an issue with CityCamp. At CityCamp we started with the hypothesis that one master email list for the entire community was best. After time, our community members told us otherwise. It was counterproductive to mix local traffic with global traffic. Now there are lots of local CityCamp email forums.

But how do you know when to create local lists? I use the same rule of thumb that should be applied to managing directories in a file system or tags in a content management system: create new email lists when you are sure you need them and not before. We didn’t start creating local lists for CityCamp until the need was obvious. (Start-up time/cost to create an email group is practically zero.) When we did start creating local lists we didn’t just run off and create one for every city. New cities came online with group forums as needed. These local lists are also owned and operated by local leaders, who know their local members better. But most people in most locations use the global list. The global list is where any member can post about anything. Incidentally, there is noticeably less interaction on threads in the global list. Global lists tend to be more informational than conversational. Locals lists are where you find the action.

Public Visibility by Default

A primary downside of multiple lists is that they can become information stovepipes. People typically ask a question like, “what if information shared in Raleigh should also be shared everywhere?” Well, that’s precisely why hyperlinks exist. The key to transforming information stovepipes into cylinders of excellence is public visibility of posts. As long as anyone can link to any post on any list then the information can be shared across subnets. While some might see this as fragmentation of conversation, it is really propagation. The idea that all of the conversation can be contained to a single list is neither realistic nor demonstrably useful. In our context, the place for private discussion online is intra-personal email or anywhere besides a group forum, regardless of size or scope.

Moderated Membership by Default

Go ahead and moderate membership. It’s not done to be exclusive. It’s practical. The obvious benefit is that moderation keeps out spammers and trolls. A less obvious benefit of moderation is that it tacitly strengthens the connection of members to the group and between members and moderators. The extra step, however trivial, confirms the intent of the subscriber. Moderation also forces the moderator to pay attention to each person who joins, even if only nominally, by clicking on the approval. Really great community managers will seize that opportunity start a discussion.

Best Practices

We follow these practices with Brigade. There is a global list called Brigade-dev and there are scores of local lists. As curators, we make sure the local lists are publicly visible. If they aren’t, then they don’t belong. We tend to use Google Groups at Code for America out of convenience, but it doesn’t matter what software or service you use as long as the content is accessible. E-democracy forum, powered by GroupServer, is another good one. It powers CityCamp and CityCamp-team. One strength of e-democracy is that is publishes and follows rules of behavior. We may adopt these or similar rules for Brigade-dev and ask that they be observed by local forums. Mostly they are common sense to a well-minded community that doesn’t need to be told. But there will always be exceptions that prove the rules.

Original post