Community Management?

Today is a weird day. First thing is a friend asking about help with community management. And next thing is Fefe reiterating his longstanding fallacy (Rant in German ) that programmers are able to do anything just because they are able to do one thing (here: Community Management). The TL;DR is that he rants against non-programmers showing interest into programming projects because they like the software, thereby ruining everything by not being programmers.

Dabei ist es so einfach, sich in einem Projekt Respekt zu erarbeiten. Leiste einfach was. Erwarte nichts als Gegenleistung. Problem: Jede Minute über dich oder deine Leistungen reden macht 10 Minuten tatsächliche Leistung kaputt.

But it is easy to get respect in a project: Just show something useful. Don’t expect a return. Problem: Every minute speaking about yourself or your results ruins ten minutes of actual useful work.

That is, of course, nonsense. It just shows, like his example about the closed umatrix bug tracker, a complete lack of understanding of the communication situation and a failure to organise the the communication efficiently.

The dclp experience

Back in late 1999, early 2000, I started a USENET newsgroup, de.comp.lang.php. As the name suggests, it was a german language newsgroup about the PHP programming language. It wasn’t the first communication project I started, and I also had been online and in USENET quite some time, and so I did it with an agenda and a plan (longer article ) with German introduction and english language content about this).

At that point in time the German Linux newsgroups (and the German Firewall newsgroups) were good counterexample to community management. There was demand for drive-by support by newbies, but instead of dealing with the demand, flamewars were the rule, and the spillover from the flamewars was drowning the useful content of the group. Even with filters, the group was impossible to read.

It was my intention to actively discourage such a development in the newly instantiated de.comp.lang.php. This was done by writing short, well researched articles answering typical newbie questions, following a specific short form recipe with a certain order of events. These answers were collected, refined into a slightly more general form, and the reused to answer recurring topical questions even faster. I set myself an arbitrary time limit (no more than 60 minutes a day), and fell into a rote quickly.

The assumption was that people flaming noobs in the group were trying to generate Karma by grabbing attention. By being able to usefully answer the questions using short, well written articles with tested, reusable answers and a recognisable form I would publicly grab more Karma and generate envy, encouraging people to imitate me.

That worked.

The other assumption was that the newbies are actually friendly, so if you are perceived as friendly and helpful, you earn respect and authority, which you can spend immediately to inject a second answer to a question they had better asked, but didn’t, into their cognitive stream.

That did work, too.

The short form was always a quote of the actual problem the noob had, an optional rephrasing of the question into something clearer (“I understand that as …”) and then building a short, specific bridge pointing to a specific answer in the FAQ, explaining in a single sentence why the FAQ answer is relevant and how reading the answer will help in the context of the actual question. If the noob showed behaviour unsuitable for USENET regulars, I then often appended a sentence or two explaining the problem and how it could be fixed to avoid future problems, or how to ask better questions or similar improvements. The deal was “Remove their block, enable them to continue, and then shove additional info into their mind that improves ’them’ in a way that is useful to ‘us’.”

Using the proper tools and sticking to the form enables highly efficient article generation: Within the allocated hour, I could generate easily 30-60 friendly, actually helpful, well tested answers and use the Karma to educate noobs. I was also carpet bombing the group with useful content, drowning out the flamers - the opposite of the Linux groups. And because I was emotionally disengaged, professionally friendly all the time, I was able to sustain that virtually infinitely.

I did not invent that form - it was pre-existing and shown to work in a slightly different way in comp.lang.c for a long time. Unlike the de.comp.lang.php FAQ, the comp.lang.c FAQ also experienced a second compression from FAQ to actual book by Peter van der Linden - I never found the time to do that (Read Peter’s books, he’s an awesome explainer).

Other examples

This is not the only way to manage communities, or maintain order in online forums. I have an older talk about “Flames - Online Communication Breakdowns” (German video recording ) which touches on experiences with de.comp.lang.php, but also on different approaches chosen for de.rec.spiele.rpg.misc (drsrm FAQ in German ) and de.talk.bizarre (don’t look at dtb , that dtb is not the dtb you are looking for). I also explain why these things require different approaches.

There is even more help available online, and some of it is even useful for programmer-type minds. Building Successful Online Communities: Evidence-Based Social Design is a collection of articles and case studies that shows different possible approaches and what their applicability and usefulness is.

If you have a programmer-type mind, Pieter Hintjens Social Architecture: Building Online Communities might be more useful for you. It just highlights how misguided, helpless/clueless and badly implemented things like the umatrix bugtracker shutdown or Fefe’s rant are:

There are useful tools to handle this, efficiently, out there, you just don’t know them and you are making things worse with what you are doing right now. So stop doing that, and learn what works, then follow that. And fast, before you break it completely."

Also,no, this is not about not at all about SJW inclusionists or project maintainer privilege abuse. It’s about programmer-type persons not having an appropriate repertoire of possible reactions to an influx of newcomers, and then frustration, change-averseness and panic kicking in in this order.

That’s also a normal thing, and there are ways to deal with this appropriately as well - these are things that can be taught and learned, to anyone who is willing to stop, understand that they are out of their depth and then to listen.