From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id DA0661382C5 for ; Tue, 27 Mar 2018 02:38:41 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 879A5E09D4; Tue, 27 Mar 2018 02:38:35 +0000 (UTC) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 2DC17E0984 for ; Tue, 27 Mar 2018 02:38:34 +0000 (UTC) Received: by mail-it0-x22c.google.com with SMTP id c1-v6so13354225itj.1 for ; Mon, 26 Mar 2018 19:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=6mBRTCBG5ury/WgvTsWbOmt6cz3xQR1y1cSs/IyUYO4=; b=ldOSVyFoiDPIEEA5EnTbuIDzTxrXp1Z71DPw+wSREWYWwDOgBi+JNJGMLpINOl4Vwx nxsOlVt2O5gBYgwgQVBzYWP2RIWGcKwDVRLsupvoOjssDgB+VGrp59w28NzwDhQjWV+A EWqhxJEqJO0Pp3gbp+gYjFvjdtDMaid/vXFXAAMtSl+eGjRoEWDu2uJGOdBAWfA49Uup w+9YeMQb6c8Mt5KHSsufaxLPzjsSooeuP61YoMYOj7a53WHalGTjnLYuxjFfthNDZ+ne b/JSTm9jOTBVZdO6rMRy93T6IuM6vlS8rvPXg6m6qkrDswm4dzBhmd8nQZxw2p/h5EwT 3QLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6mBRTCBG5ury/WgvTsWbOmt6cz3xQR1y1cSs/IyUYO4=; b=Bgw69V+rGIQtit0TBsND79p+FLOdU60TV6VUDN4jFZiGFY1Fw9Lo7XMkVFBA2hfluk SfozPF7GFSwWhCtEfpGZs+78rqRTzVjtv+WBe/KOLzfMl0RT13mSMJWlwbsz1aCpj9UA +dxcdwhsC4S6Mvi5Ujl/ClRLolEhCqZ3uXaahsZT/O00v44YjQYBfkMVczm/HcZFJcLY AO7+hyZbYLLU4MDZcFaVrkU3Qb02CCfq6It5lyYTRHfNDjF2c8kXcINKO5YZMq15sMx0 upXKOAHUV8wOJI/pR5NIxOWAcU5KRAc4S06yamVWIihrEkFKdXcsJobKS++6GV7vI3W0 RR+g== X-Gm-Message-State: AElRT7FF2SzFzIijEPJKitbv2ARKc6aZWVAWZw0NjMyiFFt1k80BEMK/ qX56xaK+9zB4qy5zzRnE0qStaT/i X-Google-Smtp-Source: AG47ELuk2TaSLLtCM15ltNJqk4GJ4vdvjLQURbKpCF9ofzUjyGaeFdHo+VCg+mWMlLfkcRJ13o39KQ== X-Received: by 2002:a24:7011:: with SMTP id f17-v6mr25648975itc.34.1522118314009; Mon, 26 Mar 2018 19:38:34 -0700 (PDT) Received: from [192.168.88.3] ([98.4.89.247]) by smtp.gmail.com with ESMTPSA id v3-v6sm234388itb.42.2018.03.26.19.38.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Mar 2018 19:38:33 -0700 (PDT) Subject: Re: [gentoo-dev] Mailing list moderation and community openness To: gentoo-dev@lists.gentoo.org References: <4aab96fa-0edb-6a28-791e-28e2103f2a30@gentoo.org> <0818a5b0-cc1e-403f-6c08-1285999de30f@gentoo.org> <20180320160316.GA5785@whubbs1.gaikai.biz> <87605qs3pi.fsf@gentoo.org> From: kuzetsa Message-ID: <637c483e-cc1a-2e38-1463-309ce7090ea1@gmail.com> Date: Mon, 26 Mar 2018 22:38:32 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Archives-Salt: 94bd5bf1-9037-4dc2-8ca2-c068219e8698 X-Archives-Hash: 3b58bf41ba369ca9b4fafea3c0f7ccae On 03/26/2018 09:26 PM, Rich Freeman wrote: > On Mon, Mar 26, 2018 at 9:19 PM, kuzetsa wrote: >> On 03/20/2018 08:08 PM, Rich Freeman wrote: >> >>> >>> Actually, I think it is more of a technical constraint. It is >>> basically impossible to blacklist somebody on a mailing list, since >>> all they need to do is roll up a new email address. >>> >>> I can think of various arguments for whitelisting or not whitelisting, >>> but it seems silly to blacklist. >>> >> >> require active stewardship (moderation, blacklisting, etc.) >> >> entry barriers to participation (default deny / require whitelist) >> >> if there are limitations on free speech, someone has to bear the burden. >> for gentoo to have list moderation (blacklist approach) which isn't >> dysfunctional, the main barrier to resources will be the human resources >> end of things, not technical constraints. The tools themselves are easy >> enough to use, but people who are willing and able to use them, and with >> a clear guideline for how it needs done is a comrel issue which the >> foundation needs to sort out. >> > > List moderation isn't the same as blacklisting. With moderation > you're effectively whitelisting because the first post anybody makes > would be held for moderation, and depending on the approach you could > moderate everything. > > If you allowed new subscribers to post without being held for > moderation, then the issues I spoke of would still apply, no matter > how much manpower you threw at it. > I think this may be a misunderstanding? no? there might be some mailing list jargon term: "moderation" which I was unaware of: I was more referring to how IRC chatrooms have an op, forums have moderators which DO NOT screen individual posts, etc. I think I know of the other version, and it might be analogous to the mechanism you meant? for example: websites which hold back all comments which are posted anonymously (non-trusted users) until a moderator can approve it. I've never used mailing list software which has that feature (I think that may be what you're referring to) - I mostly meant someone (or a team) with the specific duty to hold people accountable for their posts (since the list is public-facing, this should include @gentoo.org devs too because it sets a weird precedent to have disparate enforcement) specifically - I was referring to persons (staff) who are moderators. (active stewardship to check for problems which need addressed) I think the mechanism you describes sounds like some sort of greylist / tiered version of default deny or something like that. Interesting. the "require whitelist / default deny" version of having a closed list seems the same - expecting users to contact a dev to relay messages, or go through the dubiously [un]documented process of getting whitelisted. unless that process has a standardized format, it seems worse than the greylist because individual developers have the autonomy to [not] sponsor people for whitelist, or approve posting on a user's behalf. the lack of transparency for the process is a concern, I mean.