1 |
On Mon, Mar 26, 2018 at 10:38 PM, kuzetsa <kuzetsa@×××××.com> wrote: |
2 |
> |
3 |
> I think this may be a misunderstanding? no? there might be some mailing |
4 |
> list jargon term: "moderation" which I was unaware of: |
5 |
> |
6 |
|
7 |
Historically moderation meant having list traffic held prior to |
8 |
distribution for approval from a moderator. |
9 |
|
10 |
> I've never used mailing list software which has that feature (I think |
11 |
> that may be what you're referring to) - I mostly meant someone (or a |
12 |
> team) with the specific duty to hold people accountable for their posts |
13 |
> (since the list is public-facing, this should include @gentoo.org devs |
14 |
> too because it sets a weird precedent to have disparate enforcement) |
15 |
|
16 |
Well, ultimately the question is whether unverified members of the |
17 |
community can post or not. If they can, then there is no way to hold |
18 |
anybody accountable for anything, because they can just create a new |
19 |
email address to continue posting. |
20 |
|
21 |
If you require verification prior to posting it gives everybody a |
22 |
reputation to have to be concerned about. |
23 |
|
24 |
> the "require whitelist / default deny" version of having a closed list |
25 |
> seems the same - expecting users to contact a dev to relay messages, or |
26 |
> go through the dubiously [un]documented process of getting whitelisted. |
27 |
|
28 |
The process is simple, and certainly could be documented on the wiki |
29 |
(it was already described in emails). Get a dev to whitelist you. It |
30 |
can be any dev, and it is up to that dev to agree to the request or |
31 |
not. |
32 |
|
33 |
> unless that process has a standardized format, it seems worse than the |
34 |
> greylist because individual developers have the autonomy to [not] |
35 |
> sponsor people for whitelist, or approve posting on a user's behalf. |
36 |
|
37 |
I'd consider that a feature, not a bug. Gentoo has well over 100 |
38 |
developers. All it takes is the approval of any one of them to be |
39 |
whitelisted. That is a very permissive system. If every single one |
40 |
of them is unwilling to whitelist somebody, is it really necessary to |
41 |
have every single one of them make some kind of case for their |
42 |
individual decisions? Who would even judge such a case, considering |
43 |
that all of comrel and the council (and even the current Trustees) are |
44 |
all developers who presumably could have done the whitelisting |
45 |
themselves? |
46 |
|
47 |
You could still layer something like the proctors or comrel on top of |
48 |
this, and they would presumably be a bit more formalized in how they |
49 |
operate. (The typical conception is that Proctors would have a lot of |
50 |
discretion but would generally only enforce short-term "punishments" |
51 |
like bans of a few days, warnings, and so on. On the other hand |
52 |
comrel would be much more formalized but would be able to take |
53 |
long-term action. The goal of course would be for Proctors to defuse |
54 |
situations before they ever get to Comrel.) |
55 |
|
56 |
-- |
57 |
Rich |