1 |
On Sat, Jul 20, 2019 at 4:48 PM Andrew Savchenko <bircoph@g.o> wrote: |
2 |
|
3 |
> Hi all! |
4 |
> |
5 |
> On Sun, 07 Jul 2019 23:00:01 +0200 Michał Górny wrote: |
6 |
> > On Sun, 2019-07-07 at 21:30 +0200, Ulrich Mueller wrote: |
7 |
> > > In two weeks from now, the newly elected Council will have its |
8 |
> > > constituent meeting. This is the time to raise and prepare items that |
9 |
> > > the Council should put on the agenda to discuss or vote on. |
10 |
> > > |
11 |
> > > Please respond to this message with agenda items. Do not hesitate to |
12 |
> > > repeat your agenda item here with a pointer if you previously |
13 |
> > > suggested one (since the last meeting). |
14 |
> > > |
15 |
> > |
16 |
> > My second agenda item is: removing posting restrictions from gentoo-dev |
17 |
> > mailing list. |
18 |
> > |
19 |
> > I was on the Council that made those changes, and from retrospective I |
20 |
> > believe the decision to be a mistake. It was made to workaround |
21 |
> > a problem with inefficiency of ComRel, and we should have focused |
22 |
> > on fixing ComRel instead. I don't believe it serves its purpose well |
23 |
> > and IMO it causes more problems than it solves. |
24 |
> |
25 |
> We had the problem of the lists becoming unusable. Since person |
26 |
> involved actively avoided bans, the only working technical mean |
27 |
> available was to whitelist the gentoo-dev mail list. Other |
28 |
> technical means like targeted banning apparently have had failed. |
29 |
> |
30 |
|
31 |
Deliberate evasion of a ban is a serious infraction of the CoC in my |
32 |
opinion because it's tantamount to trespassing and harassment. |
33 |
|
34 |
Are there any stronger measures that can be taken against people who defy |
35 |
bans? For example, on irc, evading a channel ban or an ignore is often a |
36 |
violation of the hosting irc network's AUP and can result in escalations to |
37 |
network level bans, which from my observation are aggressively enforced. |
38 |
In such situations I've observed that the ops of the channel in question |
39 |
wind up getting the miscreant out of their hair once they escalate to |
40 |
network authorities, and for the offender in question the channel ban |
41 |
becomes the least of their worries once they start racking up points on |
42 |
their network rap sheet. |
43 |
|
44 |
Social means were also ineffective as someone usually supported a |
45 |
> flame by replying to provocative posts due to one reason or another. |
46 |
> |
47 |
> So the only reliable solution was to whitelist. Is this solution |
48 |
> good? No, it isn't. But when choosing between bad and worst, bad |
49 |
> solution is preferable. I'm grateful to the council of that term |
50 |
> for having guts to take responsibility and make uneasy, arguable |
51 |
> but necessary decision. |
52 |
> |
53 |
|
54 |
I would prefer to minimize collateral damage. |
55 |
|
56 |
> |
57 |
> > Notably: |
58 |
> > |
59 |
> > 1. People (including developers) workaround it via posting to -project. |
60 |
> > As a result, the correct split on topic of those two mailing lists is |
61 |
> > disturbed. |
62 |
> |
63 |
> This had happened before the whitelisting and will happen even if |
64 |
> it will be lifted. |
65 |
> |
66 |
> > 2. The majority of 'blocked' -dev posters are helpful *users*. We ought |
67 |
> > not to put unnecessary obstacles because of few harmful entities. |
68 |
> |
69 |
> 1. All proxied maintainers were whitelisted automatically. |
70 |
> |
71 |
> 2. Everyone willing to participate in the discussion is free to |
72 |
> contact any dev and be whitelisted if a dev will vouch for them. |
73 |
> I whitelisted some people myself per requests. |
74 |
> |
75 |
> > 3. Some processes, in particular ebuild, user/group addition review etc. |
76 |
> > require posting to -dev. This makes it unnecessarily painful to proxied |
77 |
> > maintainers who need to request adding it. |
78 |
> |
79 |
> All proxied maintainers were whitelisted and the time when |
80 |
> whitelisting was activated. It is the responsibility of their peers |
81 |
> to whitelist any new proxied maintainers. Probably the proxy |
82 |
> maintainers team can manage this on a regular scheme. |
83 |
> |
84 |
> > 4. In fact, I ended up as top committer to whitelist repo, and that's |
85 |
> > because I've been adding proxied maintainers to it. The sole fact that |
86 |
> > so few people are being added shows that people resign from posting |
87 |
> > rather than request being added. |
88 |
> |
89 |
> Yes, this is a drawback of current solution, but we have nothing |
90 |
> better available. And as a side effect we now know the most |
91 |
> tenacious contributors. |
92 |
> |
93 |
> > All that considered, I don't that the whitelist approach works. It |
94 |
> > only: |
95 |
> > |
96 |
> > a. discourages helpful people from posting, |
97 |
> |
98 |
> But without whitelisting much more people will be discouraged from |
99 |
> posting. And not just posting. The way the gentoo-dev list was just |
100 |
> before the whitelisting, it discouraged existing people from |
101 |
> contributions and discouraged many potential contributors due to |
102 |
> highly toxic and unproductive atmosphere. |
103 |
> |
104 |
> > b. adds unnecessary work on developers who have to update the list, |
105 |
> |
106 |
> It's not that much of a work. For proxied maintainer the |
107 |
> appropriate team may engage some scripting for this task. |
108 |
> |
109 |
> > c. breaks list topic separation. |
110 |
> |
111 |
> This problem exists, but within a tolerance level and it was |
112 |
> present even before the whitelisting, so it will exist even if the |
113 |
> whitelisting will be removed, since this is a multifactor issue. |
114 |
> |
115 |
> > Therefore, I would like to request the Council to vote on removing |
116 |
> > the whitelist and reopening the list to public posting. |
117 |
> |
118 |
> And I kindly ask the Council to review all pros and cons before |
119 |
> changing the current state. |
120 |
> |
121 |
> Best regards, |
122 |
> Andrew Savchenko |
123 |
> |