Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #11515 > unrolled thread

distributed moderation of mailinglist

Back to article view | Back to linux.debian.project

Contents

  distributed moderation of mailinglist Geert Stappers <stappers@stappers.nl> - 2020-02-23 11:00 +0100
    Re: distributed moderation of mailinglist Geert Stappers <stappers@stappers.nl> - 2020-02-23 12:50 +0100
      Re: distributed moderation of mailinglist Miles Fidelman <mfidelman@meetinghouse.net> - 2020-02-23 15:20 +0100
    Re: distributed moderation of mailinglist Felix Lechner <felix.lechner@lease-up.com> - 2020-02-23 16:20 +0100
      Re: distributed moderation of mailinglist Colin Watson <cjwatson@debian.org> - 2020-02-23 17:30 +0100
      Re: distributed moderation of mailinglist Philip Hands <phil@hands.com> - 2020-02-23 18:00 +0100
        Re: distributed moderation of mailinglist Felix Lechner <felix.lechner@lease-up.com> - 2020-02-23 18:40 +0100
          Re: distributed moderation of mailinglist Didier 'OdyX' Raboud <odyx@debian.org> - 2020-02-23 18:50 +0100
            Re: distributed moderation of mailinglist Didier 'OdyX' Raboud <odyx@debian.org> - 2020-02-23 19:10 +0100
            Re: distributed moderation of mailinglist Charles Plessy <plessy@debian.org> - 2020-02-26 16:10 +0100
              Re: distributed moderation of mailinglist Anthony DeRobertis <anthony@derobert.net> - 2020-02-26 16:40 +0100

#11515 — distributed moderation of mailinglist

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

[toc] | [next] | [standalone]

#11516

> 
> 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   foo@lists.doman.tld

Subscribe, Unsubscribe
and other user requests go to foo-request@lists.domain.tld

For the pool of moderators there is foo-review@lists.domain.tld
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 foo-review@lists.domain.list
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

[toc] | [prev] | [next] | [standalone]

#11519

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   foo@lists.doman.tld
>
> Subscribe, Unsubscribe
> and other user requests go to foo-request@lists.domain.tld
>
> For the pool of moderators there is foo-review@lists.domain.tld
> 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 foo-review@lists.domain.list
> 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

[toc] | [prev] | [next] | [standalone]

#11522

Hi Geert,

On Sun, Feb 23, 2020 at 1:56 AM Geert Stappers <stappers@stappers.nl> 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

[toc] | [prev] | [next] | [standalone]

#11523

On Sun, Feb 23, 2020 at 07:13:55AM -0800, Felix Lechner wrote:
> On Sun, Feb 23, 2020 at 1:56 AM Geert Stappers <stappers@stappers.nl> 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                                       [cjwatson@debian.org]

[toc] | [prev] | [next] | [standalone]

#11524

[Multipart message — attachments visible in raw view] — view raw

Felix Lechner <felix.lechner@lease-up.com> writes:

> Hi Geert,
>
> On Sun, Feb 23, 2020 at 1:56 AM Geert Stappers <stappers@stappers.nl> 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

[toc] | [prev] | [next] | [standalone]

#11525

Hi Philip,

On Sun, Feb 23, 2020 at 8:55 AM Philip Hands <phil@hands.com> 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

[toc] | [prev] | [next] | [standalone]

#11526

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#11527

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#11534

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

[toc] | [prev] | [next] | [standalone]

#11535

On February 26, 2020 3:05:22 PM UTC, Charles Plessy <plessy@debian.org> 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). 

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.project

csiph-web