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

Wed May 16 23:25:53 UTC 2012

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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/mailvoting-devel/attachments/20120516/de07a495/attachment.html>