1 |
On Sat, Dec 2, 2017 at 6:18 PM, Michał Górny <mgorny@g.o> wrote: |
2 |
|
3 |
> Hello, everyone. |
4 |
> |
5 |
> This is something that's been talked about privately a lot lately but it |
6 |
> seems that nobody went forward to put things into motion. SO here's |
7 |
> a proposal that aims to improve the condition of our mailing lists |
8 |
> and solve some of the problems they are facing today. |
9 |
> |
10 |
> |
11 |
> Problems |
12 |
> ======== |
13 |
> |
14 |
> Currently the developer-oriented mailing lists gentoo-dev and gentoo- |
15 |
> project are open to posting by everyone. While this has been generally |
16 |
> beneficial, we seem to be having major problems with some |
17 |
> of the posters for more than a year. Off hand, I can think of three: |
18 |
> |
19 |
> 1. Repeating attacks against Gentoo and/or Gentoo developers (including |
20 |
> pure personal attacks). While it is understandable that some people may |
21 |
> be frustrated and need to vent off, repeating attacks from the same |
22 |
> person are seriously demotivating to everyone. |
23 |
> |
24 |
> 2. Frequent off-topics, often irrelevant to the thread at hand. |
25 |
> I understand that some of those topics are really interesting but it is |
26 |
> really time-consuming to filter through all the off-topic mails |
27 |
> in search of data relevant to the topic at hand. What's worst, sometimes |
28 |
> you don't even get a single on-topic reply. |
29 |
> |
30 |
> 3. Support requests. Some of our 'expert users' have been abusing |
31 |
> the mailing lists to request support (because it's easier to ask |
32 |
> everyone than go through proper channels) and/or complain about bug |
33 |
> resolutions. This is a minor issue but still it is one. |
34 |
> |
35 |
> |
36 |
> All of those issues are slowly rendering the mailing lists impossible to |
37 |
> use. People waste a lot of time trying to gather feedback, and get |
38 |
> demotivated in the process. A steadily growing number of developers |
39 |
> either stop reading the mailing lists altogether, or reduce their |
40 |
> activity. |
41 |
> |
42 |
> For example, eclass reviews usually don't get more than one reply, |
43 |
> and even that is not always on-topic. And after all, getting this kind |
44 |
> of feedback is one of the purposes of the -dev mailing list! |
45 |
|
46 |
|
47 |
> |
48 |
> Proposal |
49 |
> ======== |
50 |
> |
51 |
> Give the failure of other solutions tried for this, I'd like to |
52 |
> establish the following changes to the mailing lists: |
53 |
> |
54 |
> 1. Posting to gentoo-dev@ and gentoo-project@ mailing lists will be |
55 |
> initially restricted to active Gentoo developers. |
56 |
> |
57 |
> 1a. Subscription (reading) and archives will still be open. |
58 |
> |
59 |
> 1b. Active Gentoo contributors will be able to obtain posting access |
60 |
> upon being vouched for by an active Gentoo developer. |
61 |
|
62 |
|
63 |
> 2. A new mailing list 'gentoo-expert' will be formed to provide |
64 |
> a discussion medium for expert Gentoo users and developers. |
65 |
> |
66 |
> 2a. gentoo-expert will have open posting access like gentoo-dev has now. |
67 |
> |
68 |
> |
69 |
> Rationale |
70 |
> ========= |
71 |
> |
72 |
> I expect that some of you will find this a drastic measure. However, I |
73 |
> would like to point out that I believe we've already exhausted all other |
74 |
> options to no avail. |
75 |
> |
76 |
> The problems of more abusive behavior from some of the mailing list |
77 |
> members have been reported to ComRel numerous times. After the failure |
78 |
> of initial enforcement, I'm not aware of ComRel doing anything to solve |
79 |
> the problem. The main arguments I've heard from ComRel members were: |
80 |
> |
81 |
> A. Bans can be trivially evaded, and history proves that those evasions |
82 |
> create more noise than leaving the issue as is. |
83 |
> |
84 |
> B. People should be allowed to express their opinion [even if it's pure |
85 |
> hate speech that carries no value to anyone]. |
86 |
> |
87 |
> C. The replies of Gentoo developers were worse [no surprise that people |
88 |
> lose their patience after being attacked for a few months]. |
89 |
> |
90 |
|
91 |
A B and C would equally apply to the "gentoo-dev" list you are proposing. |
92 |
The only difference is |
93 |
that there is some 'vetting' process for people who are allowed to post. |
94 |
But lets say hyptothetically |
95 |
Alec is an active contributor and is posting spammily to the gentoo-dev |
96 |
list. If ComRel will not take any action |
97 |
(due to A B and C) what is the difference to the status quo? |
98 |
|
99 |
This isn't to say I advocate against trying, but it might just end up the |
100 |
same as today. |
101 |
|
102 |
|
103 |
> |
104 |
> The alternative suggested by ComRel pretty much boiled down to 'ignore |
105 |
> the trolls'. While we can see this is actually starting to happen right |
106 |
> now (even the most determined developers stopped replying), this doesn't |
107 |
> really solve the problem because: |
108 |
> |
109 |
> I. Some people are really determined and continue sending mails even if |
110 |
> nobody replies to them. In fact, they are perfectly capable of replying |
111 |
> to themselves. |
112 |
> |
113 |
> II. This practically assumes that every new mailing list subscriber will |
114 |
> be able to recognize the problem. Otherwise, new people will repeatedly |
115 |
> be lured into discussing with them. |
116 |
> |
117 |
> III. In the end, it puts Gentoo in a bad position. Firstly, because it |
118 |
> silently consents to misbehavior on the mailing lists. Secondly, because |
119 |
> the lack of any statement in reply to accusations could be seen |
120 |
> as a sign of shameful silent admittance. |
121 |
> |
122 |
|
123 |
So now we only silently consent to misbehavior on mailing lists besides |
124 |
'gentoo-dev'? |
125 |
|
126 |
-A |
127 |
|
128 |
|
129 |
> |
130 |
> |
131 |
> Yet another alternative that was proposed was to establish moderation of |
132 |
> the mailing lists. However, Infrastructure has replied already that we |
133 |
> can't deploy effective moderation with the current mailing list software |
134 |
> and I'm not aware of anyone willing to undergo all the necessary work to |
135 |
> change that. |
136 |
> |
137 |
> Even if we were able to overcome that and be able to find a good |
138 |
> moderation team that can effectively and fairly moderate e-mails without |
139 |
> causing huge delays, moderation has a number of own problems: |
140 |
> |
141 |
> α) the delays will make discussions more cumbersome, and render posting |
142 |
> confusing to users, |
143 |
> |
144 |
> β) they will implicitly cause some overlap of replies (e.g. when N |
145 |
> different people answer the same question because they don't see earlier |
146 |
> replies until they're past moderation), |
147 |
> |
148 |
> γ) the problem will be solved only partially -- what if a reply contains |
149 |
> both valuable info and personal attack? |
150 |
> |
151 |
> |
152 |
> Seeing that no other effort so far has succeeded in solving the problem, |
153 |
> splitting the mailing lists seems the best solution so far. Most |
154 |
> notably: |
155 |
> |
156 |
> а. Developer mailing lists are restored to their original purpose. |
157 |
> |
158 |
> б. It is 'fair'. Unlike with disciplinary actions, there is no judgment |
159 |
> problem, just a clear split between 'developers' and 'non-developers'. |
160 |
> |
161 |
> в. 'Expert users' are still provided with a mailing list where they can |
162 |
> discuss Gentoo without being pushed down into 'user support' channels. |
163 |
> |
164 |
> г. Active contributors (in particular recruits) can still obtain posting |
165 |
> access to the mailing lists, much like they do obtain it to #gentoo-dev |
166 |
> right now. However, if they start misbehaving we can just remove that |
167 |
> without the risk of evasion. |
168 |
> |
169 |
> -- |
170 |
> Best regards, |
171 |
> Michał Górny |
172 |
> |
173 |
> |
174 |
> |