Gentoo Archives: gentoo-dev

From: R0b0t1 <r030t1@×××××.com>
To: gentoo-dev@l.g.o
Cc: gentoo-project <gentoo-project@l.g.o>
Subject: Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists
Date: Sun, 03 Dec 2017 01:33:21
Message-Id: CAAD4mYgwHPppONUS2gZkaa0gq8mQnb2AbUHSK4WsZncx1XrMmw@mail.gmail.com
In Reply to: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists by "Michał Górny"
1 Hello,
2
3 In every mailing list conversation, there are at least three people:
4 the two conversing, and the future reader. I point this out as I think
5 it important that everyone realize that not all posts are written for
6 those immediately participating in the conversation.
7
8 Some time ago I was offered some equipment due to my history of
9 open-source contributions to a variety of projects. I asked the donor
10 to forward it (or money) to the Gentoo foundation, but they declined,
11 citing a general distaste for the management of software projects in
12 general and specific issues they believed existed within Gentoo.
13
14
15 On Sat, Dec 2, 2017 at 5:18 PM, Michał Górny <mgorny@g.o> wrote:
16 > Hello, everyone.
17 >
18 > This is something that's been talked about privately a lot lately but it
19 > seems that nobody went forward to put things into motion. SO here's
20 > a proposal that aims to improve the condition of our mailing lists
21 > and solve some of the problems they are facing today.
22 >
23
24 If you have in fact discussed this off list with people who agree, I
25 think it is important that you invite them to comment. Not only will
26 it show support for what you have detailed, it will allow them to
27 explain the problems they have in greater detail, so that perhaps a
28 solution that does not involve restricting list access could be found.
29
30 It may be that I am misunderstanding your language, but what you have
31 presented does not leave many things open for discussion. It seems
32 like what you have presented is to be either accepted or rejected as
33 is. Seeing as my opinion does not matter, it further seems like it
34 will simply be accepted as is.
35
36 >
37 > Problems
38 > ========
39 >
40 > Currently the developer-oriented mailing lists gentoo-dev and gentoo-
41 > project are open to posting by everyone. While this has been generally
42 > beneficial, we seem to be having major problems with some
43 > of the posters for more than a year. Off hand, I can think of three:
44 >
45 > 1. Repeating attacks against Gentoo and/or Gentoo developers (including
46 > pure personal attacks). While it is understandable that some people may
47 > be frustrated and need to vent off, repeating attacks from the same
48 > person are seriously demotivating to everyone.
49 >
50
51 No one has any right to not be offended. If Gentoo developers are
52 receiving criticism for their behavior, then perhaps it would be best
53 that they critically analyze their actions and the effect that they
54 have on other people.
55
56 As far as I am aware most developers never get harassed and go quietly
57 on about their business. I have even asked some questions similar to
58 the questions I have asked on this list that people have felt were
59 adversarial. However, these developers didn't seem to mind my
60 questions and spent 5 minutes or so of their time on a response.
61
62 > 2. Frequent off-topics, often irrelevant to the thread at hand.
63 > I understand that some of those topics are really interesting but it is
64 > really time-consuming to filter through all the off-topic mails
65 > in search of data relevant to the topic at hand. What's worst, sometimes
66 > you don't even get a single on-topic reply.
67 >
68
69 Does the list have a digest subscription option? I find that extremely
70 helpful for one list I am subscribed to (Perl6 development) which is
71 very high volume. On the other hand, lots of offtopic chatter would
72 still be hard to sort through, but I think it needs to be considered
73 whether the chatter the list currently receives is truly off topic.
74 What if it is simply concerns or subjects that the OP did not want to
75 consider? Does that make it off topic? Is the problem more involved
76 than previously thought?
77
78 > 3. Support requests. Some of our 'expert users' have been abusing
79 > the mailing lists to request support (because it's easier to ask
80 > everyone than go through proper channels) and/or complain about bug
81 > resolutions. This is a minor issue but still it is one.
82 >
83
84 In the case of actual support requests, it might be worth taking some
85 kind of action against the user, but the general level of competence
86 of Gentoo users makes me wary that this may be a mischaracterization
87 of the intent of the email. If something like a "support request"
88 percolates to gentoo-dev, it may be of a similar vein as a complaint
89 about a bug resolution. Complaining about bug resolutions seems valid,
90 especially if questions on the tracker have been ignored.
91
92 Some developers in particular seem to not appreciate being held
93 accountable for their actions. In most notable cases, all anyone ever
94 does is ask for an explanation as to why something occurred - and in
95 most notable cases, that question is ignored, with no recourse left to
96 the user or contributor.
97
98 Personally, I tried to ask why eix's "optimizations" flag was removed,
99 when other packages *do the exact same thing.* Still no response. How
100 am I supposed to interpret this?
101
102 >
103 > All of those issues are slowly rendering the mailing lists impossible to
104 > use. People waste a lot of time trying to gather feedback, and get
105 > demotivated in the process. A steadily growing number of developers
106 > either stop reading the mailing lists altogether, or reduce their
107 > activity.
108 >
109 > For example, eclass reviews usually don't get more than one reply,
110 > and even that is not always on-topic. And after all, getting this kind
111 > of feedback is one of the purposes of the -dev mailing list!
112 >
113
114 It may be that this is separate from the content of the mailing list.
115 Do some of the developers simply not like the format of a mailing
116 list? A lot of projects are now using Slack and Discourse in addition
117 to IRC. I personally do not like either of those services, but some
118 people think they allow reduce response times, aid in comprehension,
119 allowing greater involvement of developers.
120
121 As it is, it seems to me like a lot of development happens on IRC and off list.
122
123 >
124 > Proposal
125 > ========
126 >
127 > Give the failure of other solutions tried for this, I'd like to
128 > establish the following changes to the mailing lists:
129 >
130 > 1. Posting to gentoo-dev@ and gentoo-project@ mailing lists will be
131 > initially restricted to active Gentoo developers.
132 >
133 > 1a. Subscription (reading) and archives will still be open.
134 >
135 > 1b. Active Gentoo contributors will be able to obtain posting access
136 > upon being vouched for by an active Gentoo developer.
137 >
138 > 2. A new mailing list 'gentoo-expert' will be formed to provide
139 > a discussion medium for expert Gentoo users and developers.
140 >
141 > 2a. gentoo-expert will have open posting access like gentoo-dev has now.
142 >
143 >
144 > Rationale
145 > =========
146 >
147 > I expect that some of you will find this a drastic measure. However, I
148 > would like to point out that I believe we've already exhausted all other
149 > options to no avail.
150 >
151
152 There is an option that has not been discussed, and that is
153 questioning why the gentoo-dev list receives offtopic replies,
154 personal attacks, and trolling.
155
156 > The problems of more abusive behavior from some of the mailing list
157 > members have been reported to ComRel numerous times. After the failure
158 > of initial enforcement, I'm not aware of ComRel doing anything to solve
159 > the problem. The main arguments I've heard from ComRel members were:
160 >
161 > A. Bans can be trivially evaded, and history proves that those evasions
162 > create more noise than leaving the issue as is.
163 >
164 > B. People should be allowed to express their opinion [even if it's pure
165 > hate speech that carries no value to anyone].
166 >
167 > C. The replies of Gentoo developers were worse [no surprise that people
168 > lose their patience after being attacked for a few months].
169 >
170
171 People only ever do things that make sense. Again, I invite the people
172 who are being attacked to consider why someone cares enough to bother
173 to do that. Bored teenagers go to #archlinux to have pissing contests,
174 not #gentoo.
175
176 >
177 > The alternative suggested by ComRel pretty much boiled down to 'ignore
178 > the trolls'. While we can see this is actually starting to happen right
179 > now (even the most determined developers stopped replying), this doesn't
180 > really solve the problem because:
181 >
182
183 To me this sounds like ComRel realized it is too easy to turn good
184 intentions into fascism.
185
186 > I. Some people are really determined and continue sending mails even if
187 > nobody replies to them. In fact, they are perfectly capable of replying
188 > to themselves.
189 >
190 > II. This practically assumes that every new mailing list subscriber will
191 > be able to recognize the problem. Otherwise, new people will repeatedly
192 > be lured into discussing with them.
193 >
194 > III. In the end, it puts Gentoo in a bad position. Firstly, because it
195 > silently consents to misbehavior on the mailing lists. Secondly, because
196 > the lack of any statement in reply to accusations could be seen
197 > as a sign of shameful silent admittance.
198 >
199
200 It is also entirely possible that a new user will see the troll, agree
201 with the troll, and not want to contribute to Gentoo because they
202 think the troll is right.
203
204 >
205 > Yet another alternative that was proposed was to establish moderation of
206 > the mailing lists. However, Infrastructure has replied already that we
207 > can't deploy effective moderation with the current mailing list software
208 > and I'm not aware of anyone willing to undergo all the necessary work to
209 > change that.
210 >
211 > Even if we were able to overcome that and be able to find a good
212 > moderation team that can effectively and fairly moderate e-mails without
213 > causing huge delays, moderation has a number of own problems:
214 >
215 > α) the delays will make discussions more cumbersome, and render posting
216 > confusing to users,
217 >
218 > β) they will implicitly cause some overlap of replies (e.g. when N
219 > different people answer the same question because they don't see earlier
220 > replies until they're past moderation),
221 >
222 > γ) the problem will be solved only partially -- what if a reply contains
223 > both valuable info and personal attack?
224 >
225
226 I agree with this logic, but please be careful - it states a problem,
227 presupposes a single solution, and then concludes that there is only
228 one course of action based on the critique applied to that one
229 solution. This is partly why I see the proposal as something which
230 does not seem to be accommodating to alternate viewpoints. It makes
231 addressing this section with an alternate viewpoint difficult, and if
232 I ignore it then it looks like I ignored part of your argument.
233
234 >
235 > Seeing that no other effort so far has succeeded in solving the problem,
236 > splitting the mailing lists seems the best solution so far. Most
237 > notably:
238 >
239 > а. Developer mailing lists are restored to their original purpose.
240 >
241 > б. It is 'fair'. Unlike with disciplinary actions, there is no judgment
242 > problem, just a clear split between 'developers' and 'non-developers'.
243 >
244 > в. 'Expert users' are still provided with a mailing list where they can
245 > discuss Gentoo without being pushed down into 'user support' channels.
246 >
247 > г. Active contributors (in particular recruits) can still obtain posting
248 > access to the mailing lists, much like they do obtain it to #gentoo-dev
249 > right now. However, if they start misbehaving we can just remove that
250 > without the risk of evasion.
251 >
252
253 I feel this is still a fairly large barrier to involvement. Getting
254 people to the point they want to contribute or have the knowledge to
255 contribute is the hard part, and what this will make harder to do.
256
257
258 Respectfully,
259 R0b0t1

Replies