| 1 |
On 05/11/2017 03:17 AM, Matthias Maier wrote: |
| 2 |
> Hello all, |
| 3 |
> |
| 4 |
> On Sat, Apr 29, 2017, at 12:00 CDT, "Anthony G. Basile" <blueness@g.o> wrote: |
| 5 |
> |
| 6 |
>> Hi everyone, |
| 7 |
>> |
| 8 |
>> The Gentoo Council will be meeting in two weeks. If anyone has any |
| 9 |
>> issues we need to discuss, please let me know and I'll put it on the |
| 10 |
>> agenda. Thanks. |
| 11 |
> |
| 12 |
> I would like to make a last minute proposal. |
| 13 |
> |
| 14 |
> Proposal: |
| 15 |
> |
| 16 |
> I ask the council to establish a procedure / team to moderate the |
| 17 |
> gentoo-project@ and gentoo-dev@ mailing lists: |
| 18 |
> |
| 19 |
> - In general the amount of moderation shall as minimal as possible |
| 20 |
> (in particular developers and long-time contributors |
| 21 |
> unconditionally green-lighted), |
| 22 |
> - but for non-developers abusing the mailing lists for their own |
| 23 |
> agenda their contributions shall be moderated. |
| 24 |
> - Similar to irc operators there shall be a decicated moderator team |
| 25 |
> to ensure a quick and timely response. |
| 26 |
> - The moderator team shall be different from council members, and |
| 27 |
> ideally also comrel, such that these groups can act as a check and |
| 28 |
> balance. |
| 29 |
> |
| 30 |
> Rationale: |
| 31 |
> |
| 32 |
> The gentoo-dev@ and gentoo-project@ mailing lists nowadays serve |
| 33 |
> an important role for Gentoo development (e.g. mandatory announcement, |
| 34 |
> RFCs, PATCH reviews). This function is currently severly impeded due |
| 35 |
> to the high level of noise and unrelated personal agenda [1]. |
| 36 |
> |
| 37 |
> Best, |
| 38 |
> Matthias |
| 39 |
> |
| 40 |
> [1] https://archives.gentoo.org/gentoo-project/ |
| 41 |
> |
| 42 |
|
| 43 |
I'm going to second the proposal. |
| 44 |
|
| 45 |
As an aside, in considering this, I'd like a priori moderation |
| 46 |
(whitelist+manual passthrough) to be weighed against a posteriori |
| 47 |
moderation (automatic passthrough+reactionary blacklisting), assuming |
| 48 |
that both are feasible with our ML system. |
| 49 |
|
| 50 |
A priori moderation certainly reduces the amount of messages that need |
| 51 |
to be filtered from getting through, but requires significantly more |
| 52 |
effort from a moderation team. Anyone not on the (semi)permanent |
| 53 |
whitelist must be reviewed before their message gets through which might |
| 54 |
be more effort than our moderators are willing or able to deal with. |
| 55 |
|
| 56 |
A posteriori moderation means that the moderation team doesn't prevent |
| 57 |
any messages from going through to begin with, reacting to messages that |
| 58 |
are considered abusive by adding a user to a temporary (or in worst case |
| 59 |
scenario, permanent) blacklist. This means that an abusive user will |
| 60 |
get some of their messages before being classified as needing moderation |
| 61 |
through, because the moderation is reactionary. However, this |
| 62 |
significantly reduces the moderation burden. |
| 63 |
|
| 64 |
-- |
| 65 |
NP-Hardass |
Archives