Making mailing list discussions more viable (Re: Making -devel discussions more viable)

[Filipus Klutiero <chealer@gmail.com>]

Hi Stefano, Russ and everyone,
thanks for your interest in this topic. I entirely agree that we should do better in this area. Since the discussion problem is not specific to debian-devel, I'm moving this to debian-project.

Stefano Zacchiroli wrote:

On Mon, Apr 30, 2012 at 10:11:23AM -0700, Russ Allbery wrote:
> Given recent experiences, I'm also coming around to Ian's position that
> aggressive and confrontational contributions from people who don't
> otherwise seem to be contributing to Debian are part of the problem and
> are not useful, and possibly should be banned.  I think that's been a
> significant factor in the deterioration of the init system threads.

I agree that's a problem too and I share your feeling that it has been
particularly bad in recent discussions like the init system ones. To
look on the bright side, the problem seems concentrated in a few
specific topics rather than widespread to all discussions. But it is
still probably enough to keep some people from participating
constructively on -devel, which is a pretty serious problem.

> I want our technical discussions to be welcoming to anyone who has
> information to share and who can bring additional clarity and insight to
> the discussion.  But once things start getting heated or people start
> throwing around accusations or verge towards personal attacks, there's a
> real psychological difference between people who are contributing to
> Debian and people who aren't.
<snip>

Agreed also on your reasoning about the psychological effects of non
constructive participation by non contributors.  Unfortunately, there
aren't many viable solutions to this kind of issues and all have
drawbacks.

1) our current solution: "don't feed the troll"

   (even though the list participations we're talking about are not,
   strictly speaking, trolling", that's basically our strategy)

It just doesn't work at this scale.

Sure, those who do respect the principle do reduce the noise (as
Bernhard pointed out), but you'll always have someone who will reply ---
maybe because they're new and accustomed to the list culture --- and it
is enough to have a few who do the feeding to make a discussion explode
and drive away people from it and, ultimately, decisions.

2) "don't feed the troll" + report abuses to listmasters and act
   accordingly

I think we basically agree on the principle of this and IIRC we've even
discussed this about ~1 year ago without finding much opposition. But
either we're not doing this or it is not working.

Some of problems with this have been highlighted by Raphael. The
proposed fix, specifically for the "I don't know if I'm alone doing this
or not" part, sounds interesting.  But even with that fix, you still
have the social awkwardness problem: the feeling is that of "censoring"
someone and it's a hard to ignore feeling, because the act of doing that
is much more concrete than the perception of the long term benefits of
doing so. I've the impression that the bar for silencing someone will
always remain high, higher than what would be needed to avoid the
behavior we're discussing.

Another problem you'll have with this "solution" is that it consumes a
lot of community energy (the people reporting bad behavior, who will do
that only after reaching some high frustration level; and the
listmasters who'll need to put time and emotions in judging the
behavior, implementing and probably explaining the "sanction").

3) public, but contributors-only list

This has been implemented by other FOSS projects. A notable example is
Ubuntu who have a split between ubuntu-devel (project members only +
whitelisting) and ubuntu-devel-discuss (free for all). I've never asked,
but I have always suspected that they've done so in an attempt to
improve over the experience of debian-devel participants.

The obvious drawback of this "solution" is that non-contributors will
need someone to vouch for them to be whitelisted.

----------

Each solution have advantages and disadvantages, but all in all I don't
think there aren't many other options. The question is blunt then: what
are we willing to give up of the current model in order to improve over
its defects?

There are many more approaches possible, and they can be combined.

Improving what we write (educating)

The idea here is to help people avoid posting problematic content and/or to help people avoid posting content which tends to trigger problematic replies.

General advice

This consists in writing guidelines which should be read by participants (for example "don't feed the troll").

Specific advice

This is about offering customized advice to specific participants in need.

Improving what we end up reading (filtering)

Here, we assume that problematic content will come and improve the discussion system to deal with it.

Approaches can be coercive or advisory. For example, excluding unapproved people from participating is coercive. Featuring messages from approved people as recommended reads, or warnings for rejected messages is advisory (junk tag on spam, Slashdot comments system). The ubuntu-devel vs ubuntu-devel-discuss approach is, according to what you describe, a hybrid approach (looking just at ubuntu-devel, the approach is coercive, but since readers can also access ubuntu-devel-discuss, ubuntu-devel could be considered as a list of recommended reads).

Approaches can be heuristic (limits of 1 message per day, for example) or customized (for example, excluding a specific message). There can be hybrid approaches on that front too (excluding all messages from a specific user).
Custom approaches can then be hierarchical (team dedicated to moderation) or collaborative (all readers can participate to moderation).

Coercive approaches (in particular) can use strong of soft security. Whitelisting people is preventive, while banning/blacklisting people is reactive.

---

All of these variations combine into a plethora of possible approaches, and countless possible combinations of these. Some approaches are preferable in some contexts, and some are more expensive to implement.

In terms of education, Debian has some general advice with its mailing lists code of conduct: http://www.debian.org/MailingLists/index.en.html#codeofconduct
As far as I know, any efforts to provide specific advice are not official or systemized.

In terms of filters, the vast majority of our lists are officially open (except to spam, of course). In reality, some people are blacklisted from all or some mailing lists. So our de facto approach is semi-heuristic, coercive and reactive.

Our code of conduct is mostly technical. Giving it some love and advertising it better could help, but I doubt this would help as much as we'd like. I believe adopting an official form of filtering is the way to go to make a real difference.

Some filtering solutions have already been proposed. Anthony Towns proposed "posting credits", a heuristic approach which is not quite coercive, based on the assumption that posting frequency is inversely proportional to utility.
Jurij Smakov proposed "mailvoting", an advisory, customized and collaborative approach very similar to one used for Slashdot comments. This solution is attractive, but expensive to implement.
Both solutions were discussed in this thread: https://lists.debian.org/debian-project/2008/12/msg00089.html


Lars Wirzenius recently posted "Quality of discussion in free software development" to his blog: http://blog.liw.fi/posts/quality-of-discussions/