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