distributed moderation of mailinglist

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

distributed moderation of mailinglist

Geert Stappers

Hi,

I looking for ways to moderate a mailinglist distributed.
Distributed as: serveral people do the job (not a job
for a single person)

Goal is a healthy (mailinglist) community.


Vision I have for a healthy ML is like  nice village
that is becoming a nice town. Citizens are aware it
is their own habitat and it is their interrest to keep
in a good shape.


Normal situation is lively communication on the ML.

In abnormal situations gets toxic into the ML.
That is what should be prevented.


ML software can easily block non-subscriber postings.

Software I'm looking for can delay postings based
upon reputation from a subscriber. The delay allows
the pool of moderators to review such posting.

Posting of subscriber with establish repuation
go through without a delay. It skips "review queue"

New subcribers will recieve postings. Their first
posting gets a delay  of N minutes.

The delay has a time-out. If no-one approved a posting
from the review queue, the posting goes through the ML.
Such "time-out-expired posting" tells that the pool of
moderators is too small.


Please share your idea of such mailinglist features.


Regards
Geert Stappers
--
Silence is hard to parse

Reply | Threaded
Open this post in threaded view
|

Re: distributed moderation of mailinglist

Geert Stappers
>
> Hi,
>
> I looking for ways to moderate a mailinglist distributed.
> Distributed as: serveral people do the job (not a job
> for a single person)
>
> Goal is a healthy (mailinglist) community.
>
>
> Vision I have for a healthy ML is like  nice village
> that is becoming a nice town. Citizens are aware it
> is their own habitat and it is their interrest to keep
> in a good shape.
>
>
> Normal situation is lively communication on the ML.
>
> In abnormal situations gets toxic into the ML.
> That is what should be prevented.
>
>
> ML software can easily block non-subscriber postings.
>
> Software I'm looking for can delay postings based
> upon reputation from a subscriber. The delay allows
> the pool of moderators to review such posting.
>
> Posting of subscriber with establish repuation
> go through without a delay. It skips "review queue"
>
> New subcribers will recieve postings. Their first
> posting gets a delay  of N minutes.
>
> The delay has a time-out. If no-one approved a posting
> from the review queue, the posting goes through the ML.
> Such "time-out-expired posting" tells that the pool of
> moderators is too small.
>
>
> Please share your idea of such mailinglist features.
>

Foo is a placeholder

We are familiar with a mailinglist like   [hidden email]

Subscribe, Unsubscribe
and other user requests go to [hidden email]

For the pool of moderators there is [hidden email]
where they can sent there approval (or disapproval) of postings
that need review.

Q: Which postings need review?
A: Postings of subscribers without a established reputation.


Q: How will moderators be informed about a posting needing review?
A: By email from the mailinglist software at server.


The moderator sends her/his judgement as a reply
to [hidden email]
ML S/W then distributes the posting to the whole ML
(or drops the posting (like spam))


Moderators volunteer themself for the task  and listmaster
configures that at ML S/W.  These are human actions by design.


Q: Will a moderator see postings  twice?
A: Mostly no. Some, yes, the postings of reputation below threshold.


Q: What about the regular ML subscribers?
A: Yes, regular citizens.


Regards
Geert Stappers
--
Silence is hard to parse

Reply | Threaded
Open this post in threaded view
|

Re: distributed moderation of mailinglist

Holger Wansing-4
In reply to this post by Geert Stappers
Hi,

Geert Stappers <[hidden email]> wrote:

> Posting of subscriber with establish repuation
> go through without a delay. It skips "review queue"
>
> New subcribers will recieve postings. Their first
> posting gets a delay  of N minutes.
>
> The delay has a time-out. If no-one approved a posting
> from the review queue, the posting goes through the ML.
> Such "time-out-expired posting" tells that the pool of
> moderators is too small.
>
>
> Please share your idea of such mailinglist features.

The delay has to be something like 24h, not "N minutes".
Otherwise this is a too high burden for the moderators.

If such 24h delay is not acceptable, the list should be
moderated without such time-out (mails from non-subscribers
are only going through to the list when a moderator accepts
it), as it is widely common in the internet these days.

Such was already proposed for the debian-www list by Steve
McIntyre in december to deal with spam, and today I noticed
that this is really needed:
when I read that posting in december, it was not clear to
me, but today I realized that my mail provider silently
filters out most of the spam for me, so the amount of spam
was hidden for my eyes. Until today, where I scrolled through
the mailinglist archive and saw, how much spam the list gets!
This should be considered unacceptable!


So, yes, an infrastructure and team for list moderation
should be created!


If we accept spam and terror/harassment on our lists, we
risk that too many people are ignoring the lists completely,
and lower their Debian work to a minimum.



Holger

--
Holger Wansing <[hidden email]>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Reply | Threaded
Open this post in threaded view
|

Re: distributed moderation of mailinglist

Stephen Frost
Greetings,

* Holger Wansing ([hidden email]) wrote:
> Geert Stappers <[hidden email]> wrote:
> > Posting of subscriber with establish repuation
> > go through without a delay. It skips "review queue"

Sure.

> > New subcribers will recieve postings. Their first
> > posting gets a delay  of N minutes.
> >
> > The delay has a time-out. If no-one approved a posting
> > from the review queue, the posting goes through the ML.
> > Such "time-out-expired posting" tells that the pool of
> > moderators is too small.

Interesting idea..

> > Please share your idea of such mailinglist features.
>
> The delay has to be something like 24h, not "N minutes".
> Otherwise this is a too high burden for the moderators.

Yeah, that doesn't strike me as a great approach either.

The way this is handled in pglister (which is what the PostgreSQL.Org
mailing lists use, and we throw quite a bit of mail around) is that
non-subscribers and/or non-whitelisted folks do go to moderation, but we
have a number of moderators and we more-or-less randomly pick the first
moderator to email, if the mail isn't moderated after 5 minutes or so,
we randomly pick a different moderator to email, and so on.  We don't
have any "automatically let the email through" option today, and we're
pretty successfully able to moderate a lot of mail, let a lot of mail
through, and have very very little spam get through (the little it does
happen is almost always due to a mistake by a moderator, which does
happen from time to time, of course).

Thanks,

Stephen

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: distributed moderation of mailinglist

Miles Fidelman-3
In reply to this post by Geert Stappers
On 2/23/20 6:48 AM, Geert Stappers wrote:

>> Hi,
>>
>> I looking for ways to moderate a mailinglist distributed.
>> Distributed as: serveral people do the job (not a job
>> for a single person)
>>
>> Goal is a healthy (mailinglist) community.
>>
>>
>> Vision I have for a healthy ML is like  nice village
>> that is becoming a nice town. Citizens are aware it
>> is their own habitat and it is their interrest to keep
>> in a good shape.
>>
>>
>> Normal situation is lively communication on the ML.
>>
>> In abnormal situations gets toxic into the ML.
>> That is what should be prevented.
>>
>>
>> ML software can easily block non-subscriber postings.
>>
>> Software I'm looking for can delay postings based
>> upon reputation from a subscriber. The delay allows
>> the pool of moderators to review such posting.
>>
>> Posting of subscriber with establish repuation
>> go through without a delay. It skips "review queue"
>>
>> New subcribers will recieve postings. Their first
>> posting gets a delay  of N minutes.
>>
>> The delay has a time-out. If no-one approved a posting
>> from the review queue, the posting goes through the ML.
>> Such "time-out-expired posting" tells that the pool of
>> moderators is too small.
>>
>>
>> Please share your idea of such mailinglist features.
>>
> Foo is a placeholder
>
> We are familiar with a mailinglist like   [hidden email]
>
> Subscribe, Unsubscribe
> and other user requests go to [hidden email]
>
> For the pool of moderators there is [hidden email]
> where they can sent there approval (or disapproval) of postings
> that need review.
>
> Q: Which postings need review?
> A: Postings of subscribers without a established reputation.
>
>
> Q: How will moderators be informed about a posting needing review?
> A: By email from the mailinglist software at server.
>
>
> The moderator sends her/his judgement as a reply
> to [hidden email]
> ML S/W then distributes the posting to the whole ML
> (or drops the posting (like spam))
>
>
> Moderators volunteer themself for the task  and listmaster
> configures that at ML S/W.  These are human actions by design.
>
>
> Q: Will a moderator see postings  twice?
> A: Mostly no. Some, yes, the postings of reputation below threshold.
>
>
> Q: What about the regular ML subscribers?
> A: Yes, regular citizens.
>
>
> Regards
> Geert Stappers

Pretty much any mailing list manager will let you do this.  I personally
swear by Sympa, but it tends to be overkill unless you're managing
multiple lists.  Mailman, ezmlm, etc.  It all depends on how you set
things up, and whether you put multiple names behind aliases like
"listmaster."  And then there are services like groups.io.

Miles Fidelman



--
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In our lab, theory and practice are combined:
nothing works and no one knows why.  ... unknown

Reply | Threaded
Open this post in threaded view
|

Re: distributed moderation of mailinglist

Geert Stappers
In reply to this post by Stephen Frost
On Sun, Feb 23, 2020 at 08:55:18AM -0500, Stephen Frost wrote:

> Greetings,
>
> * Holger Wansing ([hidden email]) wrote:
> > Geert Stappers <[hidden email]> wrote:
> > > Posting of subscriber with establish repuation
> > > go through without a delay. It skips "review queue"
>
> Sure.
>
> > > New subcribers will recieve postings. Their first
> > > posting gets a delay  of N minutes.
> > >
> > > The delay has a time-out. If no-one approved a posting
> > > from the review queue, the posting goes through the ML.
> > > Such "time-out-expired posting" tells that the pool of
> > > moderators is too small.
>
> Interesting idea..
>
> > > Please share your idea of such mailinglist features.
> >
> > The delay has to be something like 24h, not "N minutes".
> > Otherwise this is a too high burden for the moderators.
>
> Yeah, that doesn't strike me as a great approach either.

 :-)

When I wrote 'N minutes', I was thinking "configuration item
in the manual page".  Yes, delays will typically be
a multiple of  60 minutes.


>
> The way this is handled in pglister (which is what the PostgreSQL.Org
> mailing lists use, and we throw quite a bit of mail around)

I found https://gitlab.com/pglister/pglister 

> is that non-subscribers and/or non-whitelisted folks do go to
> moderation, but we have a number of moderators and we more-or-less
> randomly pick the first moderator to email, if the mail isn't moderated
> after 5 minutes or so, we randomly pick a different moderator to email,
> and so on.

Nice algoritme,  nice load-balancer.


> We don't have any "automatically let the email through" option today,
> and we're pretty successfully able to moderate a lot of mail, let a
> lot of mail through,

I do read "Many volunteers on guarding duty".
Yes, that is truely distributed moderation.


> and have very very little spam get through (the little it does
> happen is almost always due to a mistake by a moderator, which does
> happen from time to time, of course).

Yes, human touch preferred.

 
> Thanks,
> Stephen



Regards
Geert Stappers
--
Silence is hard to parse

Reply | Threaded
Open this post in threaded view
|

Re: distributed moderation of mailinglist

Stephen Frost
* Geert Stappers ([hidden email]) wrote:

> On Sun, Feb 23, 2020 at 08:55:18AM -0500, Stephen Frost wrote:
> > Greetings,
> >
> > * Holger Wansing ([hidden email]) wrote:
> > > Geert Stappers <[hidden email]> wrote:
> > > > Posting of subscriber with establish repuation
> > > > go through without a delay. It skips "review queue"
> >
> > Sure.
> >
> > > > New subcribers will recieve postings. Their first
> > > > posting gets a delay  of N minutes.
> > > >
> > > > The delay has a time-out. If no-one approved a posting
> > > > from the review queue, the posting goes through the ML.
> > > > Such "time-out-expired posting" tells that the pool of
> > > > moderators is too small.
> >
> > Interesting idea..
> >
> > > > Please share your idea of such mailinglist features.
> > >
> > > The delay has to be something like 24h, not "N minutes".
> > > Otherwise this is a too high burden for the moderators.
> >
> > Yeah, that doesn't strike me as a great approach either.
>
>  :-)
>
> When I wrote 'N minutes', I was thinking "configuration item
> in the manual page".  Yes, delays will typically be
> a multiple of  60 minutes.
Yeah, these things often need configuration. :)

> > The way this is handled in pglister (which is what the PostgreSQL.Org
> > mailing lists use, and we throw quite a bit of mail around)
>
> I found https://gitlab.com/pglister/pglister 

Yup, that's it, and it's actively being used and developed.

> > is that non-subscribers and/or non-whitelisted folks do go to
> > moderation, but we have a number of moderators and we more-or-less
> > randomly pick the first moderator to email, if the mail isn't moderated
> > after 5 minutes or so, we randomly pick a different moderator to email,
> > and so on.
>
> Nice algoritme,  nice load-balancer.

Thanks.

> > We don't have any "automatically let the email through" option today,
> > and we're pretty successfully able to moderate a lot of mail, let a
> > lot of mail through,
>
> I do read "Many volunteers on guarding duty".
> Yes, that is truely distributed moderation.

More-or-less.

> > and have very very little spam get through (the little it does
> > happen is almost always due to a mistake by a moderator, which does
> > happen from time to time, of course).
>
> Yes, human touch preferred.

Yup.

Thanks!

Stephen

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: distributed moderation of mailinglist

Felix Lechner-4
In reply to this post by Geert Stappers
Hi Geert,

On Sun, Feb 23, 2020 at 1:56 AM Geert Stappers <[hidden email]> wrote:
>
> Vision I have for a healthy ML is like  nice village
> that is becoming a nice town. Citizens are aware it
> is their own habitat and it is their interrest to keep
> in a good shape.

One person's vision often turns out to be another's horror.

> Posting of subscriber with establish repuation
> go through without a delay.

A review process after someone's posting received complaints would be
better. It should be public.

Kind regards
Felix Lechner

Reply | Threaded
Open this post in threaded view
|

Re: distributed moderation of mailinglist

Colin Watson
On Sun, Feb 23, 2020 at 07:13:55AM -0800, Felix Lechner wrote:
> On Sun, Feb 23, 2020 at 1:56 AM Geert Stappers <[hidden email]> wrote:
> > Posting of subscriber with establish repuation
> > go through without a delay.
>
> A review process after someone's posting received complaints would be
> better. It should be public.

This does nothing to protect against somebody who's willing to create an
arbitrarily large number of throwaway email addresses.

--
Colin Watson                                       [[hidden email]]

Reply | Threaded
Open this post in threaded view
|

Re: distributed moderation of mailinglist

Philip Hands
In reply to this post by Felix Lechner-4
Felix Lechner <[hidden email]> writes:

> Hi Geert,
>
> On Sun, Feb 23, 2020 at 1:56 AM Geert Stappers <[hidden email]> wrote:
>>
>> Vision I have for a healthy ML is like  nice village
>> that is becoming a nice town. Citizens are aware it
>> is their own habitat and it is their interrest to keep
>> in a good shape.
>
> One person's vision often turns out to be another's horror.
>
>> Posting of subscriber with establish repuation
>> go through without a delay.
>
> A review process after someone's posting received complaints would be
> better. It should be public.
Are you upset by the fact that quite a lot of spam is currently being
silently blocked, automatically?  I suspect not.

I think this should be considered to be an additional measure that can
be added to the current armoury of anti-abuse measures that are already
in place.

The thing that distinguishes this one is that a human gets to look at
the mail, rather than it being automatically rejected.

It ought to allow us to reject more abuse, without significantly
increasing the false-positive rate.

If you really think that we're going to have a problem with moderators
blocking mails from real people who want to do constructive things
related to Debian, then we could always include some sort of appeals
mechanism for people that feel that they've had mails unfairly rejected.

Do you really expect such a mechanism to be needed?

Cheers, Phil.
--
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: distributed moderation of mailinglist

Felix Lechner-4
Hi Philip,

On Sun, Feb 23, 2020 at 8:55 AM Philip Hands <[hidden email]> wrote:
>
> Are you upset by the fact that quite a lot of spam is currently being
> silently blocked, automatically?  I suspect not.

I am not upset about anything, but spam is not the problem. People
fight too much, and they forget about Debian's goals [1].

> Do you really expect such a mechanism to be needed?

Moderators have opinions. The mailing lists are our primary public
forum. Feelings may run higher, and accusations may abound.

Kind regards
Felix Lechner

[1] https://www.debian.org/doc/manuals/project-history/ap-manifesto.en.html#sA.1

Reply | Threaded
Open this post in threaded view
|

Re: distributed moderation of mailinglist

Didier 'OdyX' Raboud-5
Le dimanche, 23 février 2020, 18.29:32 h CET Felix Lechner a écrit :
> > Do you really expect such a mechanism to be needed?
>
> Moderators have opinions. The mailing lists are our primary public
> forum. Feelings may run higher, and accusations may abound.

It always seemed obvious; but for moderation to work while still standing for
our values, we need:
- traceability (which moderator took which decision, when)
- accountability (the moderators need to decide based on clear, published
guidelines, that clarify which categories to moderate, and how)
- transparency (allow senders to know if their mail is waiting for moderation,
or was rejected; also probably publish numbers)
- feedback (senders need to know _why_ their email was delayed or rejected,
and be pointed to…)
- a clear appeal process (super-moderators? review by 3 other moderators?)

The point of an efficient moderation is to rule fast on clear categories:
- allow obviously good email in;
- reject (or hold) obviously bad email.
… and to take the time needed for the non-obvious cases could require 2-3, or
$n opinions.

Email is by definition asynchronous, and some large delays (up to, say, 24h)
are IMHO clearly acceptable for our large, central lists such as -devel or -
project, if one's email address is not already known to send legitimate
content.

--
    OdyX

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: distributed moderation of mailinglist

Didier 'OdyX' Raboud-5
Le dimanche, 23 février 2020, 18.48:44 h CET Didier 'OdyX' Raboud a écrit :
> Le dimanche, 23 février 2020, 18.29:32 h CET Felix Lechner a écrit :
> > > Do you really expect such a mechanism to be needed?
> >
> > Moderators have opinions. The mailing lists are our primary public
> > forum. Feelings may run higher, and accusations may abound.
>
> It always seemed obvious; but for moderation to work while still standing
> for our values, we need:

… I figured I'd clarify. All of this is something we should aim for, not
request as an upfront condition.

What we need now is basically _any_ moderation, to put a halt to the ongoing
abuse of our infrastructure. Frankly, I don't care the slightest if the system
ends up blocking too many users or emails: it's not a free speech issue and
there are tons of other avenues available to people with good intentions to
reach out and discuss things about Debian.

--
    OdyX

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: distributed moderation of mailinglist

Jacob Lifshay
In reply to this post by Geert Stappers
On Sun, Feb 23, 2020, 06:37 Geert Stappers <[hidden email]> wrote:
On Sun, Feb 23, 2020 at 08:55:18AM -0500, Stephen Frost wrote:
> Greetings,
>
> * Holger Wansing ([hidden email]) wrote:
> > Geert Stappers <[hidden email]> wrote:
> > > Posting of subscriber with establish repuation
> > > go through without a delay. It skips "review queue"
>
> Sure.

One thing that would be useful is to share a subscriber's reputation between mailing lists, that avoids the problem of having a high reputation on one list but still being delayed on another just because they didn't yet subscribe to the second list. This is similar to how stackexchange.com gives you 100 reputation when joining a site if you have sufficient reputation on another site.

Jacob
Reply | Threaded
Open this post in threaded view
|

Re: distributed moderation of mailinglist

Charles Plessy-12
In reply to this post by Didier 'OdyX' Raboud-5
Le Sun, Feb 23, 2020 at 06:48:44PM +0100, Didier 'OdyX' Raboud a écrit :
>
> Email is by definition asynchronous, and some large delays (up to, say, 24h)
> are IMHO clearly acceptable for our large, central lists such as -devel or -
> project, if one's email address is not already known to send legitimate
> content.

I sometimes wonder if adding a random delay of 1 to 24 h for every
message (I mean: rolling the dice again for each message) on -project,
-devel, -vote and similar lists could help to make us more resilient to
trolling and at the same time more likely to have more constructive
discussions.

I think that it would incentive people to spend more time to write
well-thought answers, because it would reflect badly on posters of
half-backed messages to have them delivered after well-written ones.

As a consequence I also hope that it would also increase the diversity
of opinions and posters by reducing the audience of fast writers – who
still may end up broadcasted ~23 h after other people more lucky – and
also by reducing time zone effects.  There may be redundant answers but
they might have the merit to present the same argument with a different
point of view or a different background or vocabulary, and since they
would be written independantly and without the purpose of supporting
each other by sheer number, the redundancy would facilitate consensus
building.

Although the measure would not prevent trolls from posting, it would
limit their capacity to induce heated ping-pong discussions in which
upset people write things that they regret later because it irreversibly
hurt others.

Have a nice day,

Charles

(The idea of random delays is taken from the R posting guide
https://www.r-project.org/posting-guide.html)

--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Akano, Uruma, Okinawa, Japan

Reply | Threaded
Open this post in threaded view
|

Re: distributed moderation of mailinglist

Anthony DeRobertis


On February 26, 2020 3:05:22 PM UTC, Charles Plessy <[hidden email]> wrote:
>
>I sometimes wonder if adding a random delay of 1 to 24 h for every
>message (I mean: rolling the dice again for each message) on -project,
>-devel, -vote and similar lists could help to make us more resilient to
>trolling and at the same time more likely to have more constructive
>discussions.

An interesting idea, but I fear it'd also lead to a lot of confusion. Delays would only apply to copies going through the list, in particular CCs to personal addresses would arrive immediately. Which means the people cc'd would get an early chance to reply (probably encouraging use of CCs). And those replies get sent to the list, also with a random delay, which could turn out to be shorter than the original message. That is, the reply could be "posted" before the replied-to.

There would also be weird things like posts showing up past deadlines. If you want to be sure your post arrives by the end of the discussion period, need to send it 24h early.

Making the list digest-only would accomplish some of the same things. (With all the well-known advantages and disadvantages of email digests, of course).