Re: [gentoo-project] Call for agenda items - Council meeting 2019-07-21

[Raymond Jennings <shentino@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5377 bytes --]

On Sat, Jul 20, 2019 at 4:48 PM Andrew Savchenko <bircoph@gentoo.org> wrote:

> Hi all!
>
> On Sun, 07 Jul 2019 23:00:01 +0200 Michał Górny wrote:
> > On Sun, 2019-07-07 at 21:30 +0200, Ulrich Mueller wrote:
> > > In two weeks from now, the newly elected Council will have its
> > > constituent meeting. This is the time to raise and prepare items that
> > > the Council should put on the agenda to discuss or vote on.
> > >
> > > Please respond to this message with agenda items. Do not hesitate to
> > > repeat your agenda item here with a pointer if you previously
> > > suggested one (since the last meeting).
> > >
> >
> > My second agenda item is: removing posting restrictions from gentoo-dev
> > mailing list.
> >
> > I was on the Council that made those changes, and from retrospective I
> > believe the decision to be a mistake.  It was made to workaround
> > a problem with inefficiency of ComRel, and we should have focused
> > on fixing ComRel instead.  I don't believe it serves its purpose well
> > and IMO it causes more problems than it solves.
>
> We had the problem of the lists becoming unusable. Since person
> involved actively avoided bans, the only working technical mean
> available was to whitelist the gentoo-dev mail list. Other
> technical means like targeted banning apparently have had failed.
>

Deliberate evasion of a ban is a serious infraction of the CoC in my
opinion because it's tantamount to trespassing and harassment.

Are there any stronger measures that can be taken against people who defy
bans?  For example, on irc, evading a channel ban or an ignore is often a
violation of the hosting irc network's AUP and can result in escalations to
network level bans, which from my observation are aggressively enforced.
In such situations I've observed that the ops of the channel in question
wind up getting the miscreant out of their hair once they escalate to
network authorities, and for the offender in question the channel ban
becomes the least of their worries once they start racking up points on
their network rap sheet.

Social means were also ineffective as someone usually supported a
> flame by replying to provocative posts due to one reason or another.
>
> So the only reliable solution was to whitelist. Is this solution
> good? No, it isn't. But when choosing between bad and worst, bad
> solution is preferable. I'm grateful to the council of that term
> for having guts to take responsibility and make uneasy, arguable
> but necessary decision.
>

I would prefer to minimize collateral damage.

>
> > Notably:
> >
> > 1. People (including developers) workaround it via posting to -project.
> > As a result, the correct split on topic of those two mailing lists is
> > disturbed.
>
> This had happened before the whitelisting and will happen even if
> it will be lifted.
>
> > 2. The majority of 'blocked' -dev posters are helpful *users*.  We ought
> > not to put unnecessary obstacles because of few harmful entities.
>
> 1. All proxied maintainers were whitelisted automatically.
>
> 2. Everyone willing to participate in the discussion is free to
> contact any dev and be whitelisted if a dev will vouch for them.
> I whitelisted some people myself per requests.
>
> > 3. Some processes, in particular ebuild, user/group addition review etc.
> > require posting to -dev.  This makes it unnecessarily painful to proxied
> > maintainers who need to request adding it.
>
> All proxied maintainers were whitelisted and the time when
> whitelisting was activated. It is the responsibility of their peers
> to whitelist any new proxied maintainers. Probably the proxy
> maintainers team can manage this on a regular scheme.
>
> > 4. In fact, I ended up as top committer to whitelist repo, and that's
> > because I've been adding proxied maintainers to it.  The sole fact that
> > so few people are being added shows that people resign from posting
> > rather than request being added.
>
> Yes, this is a drawback of current solution, but we have nothing
> better available. And as a side effect we now know the most
> tenacious contributors.
>
> > All that considered, I don't that the whitelist approach works.  It
> > only:
> >
> > a. discourages helpful people from posting,
>
> But without whitelisting much more people will be discouraged from
> posting. And not just posting. The way the gentoo-dev list was just
> before the whitelisting, it discouraged existing people from
> contributions and discouraged many potential contributors due to
> highly toxic and unproductive atmosphere.
>
> > b. adds unnecessary work on developers who have to update the list,
>
> It's not that much of a work. For proxied maintainer the
> appropriate team may engage some scripting for this task.
>
> > c. breaks list topic separation.
>
> This problem exists, but within a tolerance level and it was
> present even before the whitelisting, so it will exist even if the
> whitelisting will be removed, since this is a multifactor issue.
>
> > Therefore, I would like to request the Council to vote on removing
> > the whitelist and reopening the list to public posting.
>
> And I kindly ask the Council to review all pros and cons before
> changing the current state.
>
> Best regards,
> Andrew Savchenko
>

[-- Attachment #2: Type: text/html, Size: 6381 bytes --]