<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Stefano, Russ and everyone,<br>
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.<br>
<br>
Stefano Zacchiroli wrote:<br>
<blockquote type="cite">
<pre>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?</pre>
</blockquote>
<br>
There are many more approaches possible, and they can be combined.<br>
<br>
<h1>Improving what we write (educating)<br>
</h1>
<p>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.<br>
</p>
<h2>General advice</h2>
This consists in writing guidelines which should be read by
participants (for example "don't feed the troll").
<h2>Specific advice</h2>
<p>This is about offering customized advice to specific participants
in need.<br>
</p>
<h1>Improving what we end up reading (filtering)<br>
</h1>
Here, we assume that problematic content will come and improve the
discussion system to deal with it.<br>
<br>
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).<br>
<br>
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).<br>
Custom approaches can then be hierarchical (team dedicated to
moderation) or collaborative (all readers can participate to
moderation).<br>
<br>
Coercive approaches (in particular) can use strong of soft security.
Whitelisting people is preventive, while banning/blacklisting people
is reactive.<br>
<br>
<hr size="2" width="100%"><br>
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.<br>
<br>
In terms of education, Debian has some general advice with its
mailing lists code of conduct:
<a class="moz-txt-link-freetext" href="http://www.debian.org/MailingLists/index.en.html#codeofconduct">http://www.debian.org/MailingLists/index.en.html#codeofconduct</a><br>
As far as I know, any efforts to provide specific advice are not
official or systemized.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
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.<br>
Both solutions were discussed in this thread:
<a class="moz-txt-link-freetext" href="https://lists.debian.org/debian-project/2008/12/msg00089.html">https://lists.debian.org/debian-project/2008/12/msg00089.html</a><br>
<br>
<br>
Lars Wirzenius recently posted "<span><span class="title">Quality of
discussion in free software development" to his blog: </span></span><a class="moz-txt-link-freetext" href="http://blog.liw.fi/posts/quality-of-discussions/">http://blog.liw.fi/posts/quality-of-discussions/</a><br>
</body>
</html>