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