From: Andrew Savchenko <bircoph@gentoo.org>
To: gentoo-project@lists.gentoo.org
Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2019-07-21
Date: Sun, 21 Jul 2019 02:48:09 +0300 [thread overview]
Message-ID: <20190721024809.efff863a8f3a7f8ae509f24d@gentoo.org> (raw)
In-Reply-To: <0f65bce4fb95cd5340fc51f2108e4f884a0093b8.camel@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 4314 bytes --]
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.
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.
> 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: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2019-07-20 23:48 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-07 19:30 [gentoo-project] Call for agenda items - Council meeting 2019-07-21 Ulrich Mueller
2019-07-07 20:51 ` Michał Górny
2019-07-07 21:00 ` Michał Górny
2019-07-08 4:43 ` Ulrich Mueller
2019-07-08 5:36 ` Michał Górny
2019-07-08 13:50 ` Rich Freeman
2019-07-09 9:58 ` Ulrich Mueller
2019-07-12 19:56 ` Andreas K. Huettel
2019-07-21 0:22 ` Andrew Savchenko
2019-07-09 9:28 ` Lars Wendler
2019-07-10 13:55 ` William Hubbs
2019-07-10 14:07 ` Michael Everitt
2019-07-10 15:48 ` William Hubbs
2019-07-20 23:57 ` Andrew Savchenko
2019-07-20 23:48 ` Andrew Savchenko [this message]
2019-07-21 1:11 ` Raymond Jennings
2019-07-21 6:28 ` Michał Górny
2019-07-21 11:25 ` Andrew Savchenko
2019-07-21 11:52 ` Raymond Jennings
2019-07-21 13:33 ` Michael Orlitzky
2019-07-09 9:02 ` Haelwenn (lanodan) Monnier
2019-07-13 7:39 ` Ulrich Mueller
2019-07-13 10:53 ` Haelwenn (lanodan) Monnier
2019-07-13 3:28 ` desultory
2019-07-13 4:11 ` Matthew Thode
2019-07-13 6:56 ` Michał Górny
2019-07-13 7:09 ` Ulrich Mueller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190721024809.efff863a8f3a7f8ae509f24d@gentoo.org \
--to=bircoph@gentoo.org \
--cc=gentoo-project@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox