Mailing list moderation and community openness

classic Classic list List threaded Threaded
52 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Mailing list moderation and community openness

Gregory Woodbury
John Levine, author of "The Internet For Dummies," once set up a robo-moderation
process for the Usenet newsgroup soc.religion.unitarian-univ
(Unitarian Universalists).
The group, along with most of Usenet, ultimately "died" due to lack of
attention from
the moderators, who failed to curb one of their own.

However, the robo-moderator worked quite well, and still is
technically in-place. The
first post by a person generated an email to the poster to verify the
email addres,
and required the poster to reply with a confirmation. The posts then
went through
without anyone having to approve or whilelist things.  If a poster subsequently
became a "problem" their postings could be placed in a moderation
required status,
and some human would evelute the posts and handle the quelling of off-topic or
flame generating posts. In extreme cases, posters could be banned for
varying periods
of time.

The programs where quite powerful, and amazingly simple and elegant to implent.
The source is available, and should be easily adapted for practically
any system with
bash shell hook capabilities. The infra team might want to look at
that code and try
something like it.  Some addresses can be injected at setup time requiring human
action before posts are approved (Rejected posts would be sent back to the perp
requesting re-writing or abandoning.

The moderators did not have to login anywhere to work with the bot,
all interactions
were done via email.  The system is/was quite nice, and my mangled memories
should not be the deciding factors when looking at it.

Such a system might well serve as a means of allowing fully free entry into the
list, while still providing the ability to control things if it gets
out of hand.

On Wed, Mar 21, 2018 at 1:19 PM, Rich Freeman <[hidden email]> wrote:

> On Wed, Mar 21, 2018 at 12:55 PM, R0b0t1 <[hidden email]> wrote:
>>
>> I can't tell, and I suspect other people can't either.
>>
>
> This is the crux of the issue.  Decisions involving people issues are
> made behind closed doors, which means that others are not free to
> confirm for themselves whether those actions are correct.  This tends
> to lead to ongoing debate over whether those decisions were
> appropriate, with everybody arguing from their own knowledge, and the
> only ones who know the information used to make the decision are
> barred from talking about it.  This is basically a debate where
> participation is limited to the ignorant, at least as far as the
> particular details go (the general principles are debated by all).
>
> That said, even if the decisions were made in the open I wouldn't
> expect all to agree with them.
>
> Ultimately though there are pros and cons to making these kinds of
> decisions in the open, and there is not universal agreement regarding
> how these situations ought to be handled.  We can either fight about
> it until the end of time, or we can agree on some way to determine
> what approach we are going to take and then support it (perhaps
> begrudgingly).  Right now the mechanism that we have in place is the
> Council.  The only other mechanism I could see that would make any
> sense would be a referendum on the issue.  That gets unwieldy if we
> try to apply it to every little decision, but maybe for the big
> picture issues it would make sense.
>
> However, I think a lot of people would be surprised at the outcome.
> We all assume that we're all here for the same reasons, but as I
> commented on my blog Gentoo is a bit unique among distros and many of
> us are here for very different reasons, and have different priorities.
> Also, there is sometimes a tendency to assume that all FOSS projects
> work the same way.  When I was listening to a talk about how one of
> the BSDs dealt with these kinds of issues I was shocked to discover
> that much of their dev communications happens on completely closed
> lists (not just closed to posting, but to reading as well).  Gentoo
> has the gentoo-core list but it is very low traffic and it tends to be
> used for things like swapping cell phone numbers before conferences.
> When anything substantive comes up there are usually several people
> who chime in to rightly point out that this talk belongs on a public
> list.
>
> Bottom line is that there are a lot of different ways projects can
> run, and they all have their pros and cons.  A lot of the FOSS we
> depend on actually gets built or discussed behind closed doors.  I
> doubt many of us want Gentoo to go that far, but I suspect there is a
> lot of interest in taking smaller steps in that general direction.
>
> --
> Rich
>



--
G.Wolfe Woodbury
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Mailing list moderation and community openness

Chí-Thanh Christopher Nguyễn
In reply to this post by Michael Palimaka
Michael Palimaka schrieb:
> I see that in bug #650964[1] Council is pushing forward again with
> implementing user whitelisting on this mailing list (ie. anyone that is
> not "approved" will have their mail rejected).
>
> Could someone please explain how this doesn't directly contradict the
> core tenets of an open and inclusive community?

(I do not intend to single out your post, just replying to the thread in
general here)

I would like to ask people to stay respectful in their disagreement towards
the Council and their decision here. You might not agree with the decision,
but the Council is an elected body and was given these powers by the
developer community which they represent. Also I have no doubt that Council
members who voted for -dev moderation are aware of the counter arguments and
honestly expect a net positive effect from this.

If you dislike mailing list moderation, campaign and/or vote in the next
period for candidates who want to reverse this decision.


Best regards,
Chí-Thanh Christopher Nguyễn

Reply | Threaded
Open this post in threaded view
|

Re: Mailing list moderation and community openness

Chí-Thanh Christopher Nguyễn
In reply to this post by Kristian Fiskerstrand-2
Kristian Fiskerstrand schrieb:

> Switching to mailman might have some good merits on its own, but as I
> understand it it isn't necessary for the proposal at hand, that can be
> solved using access control lists in mlmmj-process?

I would advise caution that Council better not try to micro-manage Infra here.


Best regards,
Chí-Thanh Christopher Nguyễn

Reply | Threaded
Open this post in threaded view
|

Re: Mailing list moderation and community openness

Chí-Thanh Christopher Nguyễn
In reply to this post by Rich Freeman
Rich Freeman schrieb:

> 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.

And how often did it actually happen that blacklisting was evaded on -dev
mailing list?


Best regards,
Chí-Thanh Christopher Nguyễn

Reply | Threaded
Open this post in threaded view
|

Re: Mailing list moderation and community openness

Kristian Fiskerstrand-2
In reply to this post by Chí-Thanh Christopher Nguyễn
On 03/22/2018 12:56 AM, Chí-Thanh Christopher Nguyễn wrote:
> Kristian Fiskerstrand schrieb:
>
>> Switching to mailman might have some good merits on its own, but as I
>> understand it it isn't necessary for the proposal at hand, that can be
>> solved using access control lists in mlmmj-process?
>
> I would advise caution that Council better not try to micro-manage Infra here.

By all means, infra should do what they think is right, but this
particular decision doesn't force infra to switch mailing list
infrastructure. If they believe there are reasons to do so, by all
means, but the decision doesn't result in

On 03/20/2018 04:28 PM, Matthew Thode wrote:
> There are still some issues with it infra side (archiving will still
> have to use the old system) and moving mailing lists is going to be fun,
> but them the breaks.


--
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Mailing list moderation and community openness

Kristian Fiskerstrand-2
In reply to this post by Chí-Thanh Christopher Nguyễn
On 03/22/2018 12:56 AM, Chí-Thanh Christopher Nguyễn wrote:

> Michael Palimaka schrieb:
>> I see that in bug #650964[1] Council is pushing forward again with
>> implementing user whitelisting on this mailing list (ie. anyone that is
>> not "approved" will have their mail rejected).
>>
>> Could someone please explain how this doesn't directly contradict the
>> core tenets of an open and inclusive community?
>
> (I do not intend to single out your post, just replying to the thread in
> general here)
>
> I would like to ask people to stay respectful in their disagreement towards
> the Council and their decision here. You might not agree with the decision,
> but the Council is an elected body and was given these powers by the
> developer community which they represent. Also I have no doubt that Council
> members who voted for -dev moderation are aware of the counter arguments and
> honestly expect a net positive effect from this.
>
> If you dislike mailing list moderation, campaign and/or vote in the next
> period for candidates who want to reverse this decision.
+1 for this, and also note that the whitelisting approach allows for
those opposing to start a project for -dev ML moderation that is similar
to editbugs and proxy maintenance as we currently have in the project.


--
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Mailing list moderation and community openness

Kristian Fiskerstrand-2
In reply to this post by Chí-Thanh Christopher Nguyễn
On 03/22/2018 12:56 AM, Chí-Thanh Christopher Nguyễn wrote:

> Rich Freeman schrieb:
>
>> 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.
>
> And how often did it actually happen that blacklisting was evaded on -dev
> mailing list?
we are aware of at least one case of evasion like this within the
relatively near past, but it is more a matter of principle as we don't
know if there are sock-puppets etc around.

The main things is really, the bar for whiltelisting is very low, you
just need a current dev to vouch for you, which is similiar to editbugs
and the #-dev channel on IRC. Most discussion should anyways happen on
-project ML, whereby the -dev ML is technical in nature. So there isn't
any real restriction being imposed here.

Most contributions should happen via patches on b.g.o

--
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Mailing list moderation and community openness

M. J. Everitt
On 22/03/18 00:33, Kristian Fiskerstrand wrote:
> <snip>
> Most contributions should happen via patches on b.g.o
>
Who was lamenting about the every-increasing bug queue on this Very list
recently?

And what about those 5+ year old bugs that are rotting for packages long
last-rited from the tree ?


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Mailing list moderation and community openness

Duncan-42
In reply to this post by Alec Warner-2
Alec Warner posted on Wed, 21 Mar 2018 10:44:48 -0400 as excerpted:

> On Wed, Mar 21, 2018 at 1:36 AM, Eray Aslan <[hidden email]> wrote:
>
>> On Tue, Mar 20, 2018 at 10:28:48AM -0500, Matthew Thode wrote:
>> > While I personally do no agree with mailing list moderation infra has
>> > been tasked with moving forward on it.
>>
>> You can always resign from infra.
>>
>>
>> That was a somewhat tongue-in-cheek comment but not wholly.  You cant
>> cop out by saying it was an order from council.  I understand if you
>> dont but do consider it.  Fight the good fight.
>>
>>
> So when there is conflict its pretty often that you have 3 options.
>
> 1) Accept 2) Leave 3) Escalate

Wise words.

Here the context was/is infra, but they apply to general devs and users
who disagree with this as well, thus my own personal interest, altho I'm
not so much a "disagree" as a "concerned and sad it has to come to this",
as I see both sides.

[Note:  I intend this to be my only post to this thread, unless a reply
calls for further reply on my part.  It's my position of record on the
moderation/whitelisting and may also be my last to the list before it
goes moderated.  If that's not of interest to you I'd rather you skip the
rest of the post and use the time for something you consider more
constructive.  =:^) ]

> I'm not sure 3 is possible (the council is already the highest body). I
> also think that as a organization this is how we arranged it to be.

Astute observation.

> Speaking for myself, this is not the worst issue I've seen in Gentoo and
> so I thing doing 2 is probably not very effective. Its also likely I can
> only do 2 once (because maybe I would not be welcome'd back or want to
> contribute anymore.)

Also astute.

I'm ignoring my urge to point to "real world" examples as this list is
*definitely* not the place, but in the safer general realm it can simply
be observed that there's /always/ a leave/stay-and-accept (if only
temporarily/strategically) argument to be made, even in the /worst/ cases
(which must here be left to imagination and history) where arguably
"leave" is the only morally acceptable alternative.

Fortunately, I believe most will agree this isn't a "worst" case in that
regard, tho it may be bad enough that some find they must leave.

But for both users and devs there remain the practical questions:

Where else would I go?  Is that alternative actually practically viable?  
Would I be more effective there than here, hoping to eventually reverse
the decision (or for those like me more on the sad-it-came-to-this-but-I-
see-why-some-believe-it-has side, hoping a short trial is demonstration
enough of capacity and that it lowers the threat to where even those that
agree it has to come to that now feel comfortable in reverting it, tho
possibly retaining the capacity to reimpliment if necessary)?

In practice, there are certainly from-source alternatives.  However,
again practically, gentoo does seem to be the biggest, and most others
seem to either be mostly-compatible offshoots such as funtoo and exherbo
that to some degree still depend on the larger gentoo tree and community,
or to make choices that put them to one side or the other of gentoo's
"automated/scripted from-source" approach (arch's core-binary approach on
the toward-binaries side, and lfs/linux-from-scratch's much more manual-
but-still-guided, approach on the other).

There's also the very practical "but I already know and am familiar with
gentoo and how it works (both technically and socially) and would have to
learn the others" factor.

For both those reasons and I suppose others, gentooers who have been
around a few years, at least long enough to develop that familiarity,
tend to stay around as long as they remain interested in gentoo's general
automated-from-source approach (tho many ultimately lose that interest
and go binary-distro or leave the FLOSS community entirely), unless of
course forced out as incompatible with continuing community interest, in
which case, given little choice, they often land at one of those
alternatives.

> That leaves 1 and one interests me for many reasons.
>
> a) as noted earlier, decisions are not set in stone. Its possible we
> could turn on this whitelisting solution for a brief period and the
> decision is overturned at the next council meeting, or perhaps at the
> next council election once the existing council is replaced.

Agreed.  I've already mentioned what I believe would be my ideal outcome,
above.  Try the whitelisting as proposed for awhile, then having
demonstrated the capacity/threat, relax things, while maintaining the
capacity, such that hopefully the toxic people that created the initial
need will not find it worth their while to be toxic here once again, but
with the capacity to reinstitute should they do so.

(Yes, I know that unused tools fall into disrepair over time, but often,
repair, or even redo if necessary, is easier the second time around.  So
hopefully the capacity would remain available or at least easier to
implement again, if again needed.)

(Points B and C omitted as infra specific, because I've nothing to add.)

> d) Infra as a organization wields a lot of power in Gentoo and I think
> its organizationally dangerous to wield that power in this way. [...]
> e) In the past, infra *has* wielded its power in a fashion that had
> negative impacts on the distribution (e.g. arbitrarily removing commit
> rights for developers with no warning, process, or oversight).

Having lived thru much of that, I 100% agree that it's not something
gentoo should ever want to go back to.  While individuals are certainly
free to resign should they feel the need, having even infra subject to an
_elected_ council is a _good_ thing!


Meanwhile, I've already stated my position.  I'm sad to see it come to
this, and hope it to be eventually reversed, but the elected council has
spoken, I understand the events that lead to their decision, and remain
and abide is my chosen option.

And as for the effect on my own posts as a non-dev, personally...

* My posting intent on any list, including this one, is positive
contribution.  Should I ever believe my posts have ceased to be that,
I'll immediately apologize if it was one-off/short-term, or stop posting
if I don't believe my posts to be a positive contribution going forward.

(I've often spent quite some time composing a post, only to ultimately
close the window without sending, because on consideration before hitting
send, I decided it wasn't unquestionably a positive contribution to the
list/discussion in question.  Sometimes just writing it for me was what I
needed to do.  Sometimes I simply thought better of it, period.)

* I'm acutely mindful of the fact that this _is_ gentoo-*dev*, and that
as a user, not a dev, I'm but a guest here.

(And yes, that sometimes influences my "don't send it after all"
decision.)

* While there are complaints of my verbosity, I've never been /banned/
and I'm proud of that.

* I've had personal offers to whitelist, for which I am grateful.  

(The given reason was that while I'm often too wordy, I often do have a
valid point/question, that may not have been brought up by others.  I do
struggle with the wordiness, believe me, but I'm grateful that at least
some devs consider my posts a positive enough contribution to extend the
whitelisting offer.)

* For the time being, I've thanked, but turned down that whitelisting
offer.  When I'd otherwise post, I'm going to take the opportunity to
reconsider the positive contribution of my posts even more, try again to
whittle down the wordiness further, and then, if I still consider it
worth the effort, I'm going to forward the post to the person I'm
replying to or possibly to someone else (like the person who offered the
whitelisting), asking them to forward it... but *only* if they too
consider it a positive contribution to the current discussion.

Tho I may eventually request whitelisting, in the mean time I intend to
learn what I can from the forward/rejection/rejection-with-feedback on
those attempted contributions, to try to make future attempted
contributions even better! =:^)

That's keeping in mind that as a user not a dev, I /do/ consider myself a
guest on this list, and arguably, posting to it has /always/ been a
privilege, not a right.  And given the coming whitelisting, devs, thru
their elected council, have clearly expressed their desire to cut down
the outside noise from "guests", ensuring that any such "guest posts"
allowed thru are signal, not noise, or worse yet, negative signal.

As one of those guests, abiding by that expressed intent to the best of
my ability is my goal, and I intend to take the presented opportunity to
try to improve my own attempts at contribution!

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Reply | Threaded
Open this post in threaded view
|

Re: Mailing list moderation and community openness

Benda Xu
In reply to this post by Rich Freeman
Hi Rich,

Rich Freeman <[hidden email]> writes:

> 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.

Okay, I see your argument.


Just a random bikeshedding.  We might be able to require GPG signed
email to make a post.  Then we can blacklist the GPG identity?

To think of it further, the web of trust is basically a whitelist.  But
it has the flexibility to chain the trust from a Gentoo dev by several
'hops'.

Benda

Reply | Threaded
Open this post in threaded view
|

Re: Mailing list moderation and community openness

Alexander Berntsen-2
On 22/03/18 07:31, Benda Xu wrote:
> We might be able to require GPG signed email to make a post.
Almost definitely.

But before bikeshedding that, it would be advisable to find out whether
it would be a good idea in the first place. Unless you want only
prospective developers to be able to contribute to the ML (maybe you do
want that?), it seems like a poor idea to unnecessarily exclude anyone
who doesn't care (nor want to care) about OpenPGP.
--
Alexander
[hidden email]
https://secure.plaimi.net/~alexander


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Mailing list moderation and community openness

Rich Freeman
On Thu, Mar 22, 2018 at 4:30 AM, Alexander Berntsen <[hidden email]> wrote:
> On 22/03/18 07:31, Benda Xu wrote:
>> We might be able to require GPG signed email to make a post.
> Almost definitely.
>
> But before bikeshedding that, it would be advisable to find out whether
> it would be a good idea in the first place. Unless you want only
> prospective developers to be able to contribute to the ML (maybe you do
> want that?), it seems like a poor idea to unnecessarily exclude anyone
> who doesn't care (nor want to care) about OpenPGP.

That, and getting yourself whitelisted by a dev is gong to be a lower
barrier than having to meet one in-person to have a key signed.  That
is unless devs just start signing keys for people they've never met
(which honestly doesn't really bother me much as I don't put much
faith in the WoT anyway), in which case it turns into a whitelist that
only comrel can un-whitelist since I don't think you can revoke a
signature.

Plus signing emails is a pain if you don't use an MUA that has this
feature, and the web-based ones which do aren't very good.

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: Mailing list moderation and community openness

Kristian Fiskerstrand-2
On 03/22/2018 12:38 PM, Rich Freeman wrote:

> On Thu, Mar 22, 2018 at 4:30 AM, Alexander Berntsen <[hidden email]> wrote:
>> On 22/03/18 07:31, Benda Xu wrote:
>>> We might be able to require GPG signed email to make a post.
>> Almost definitely.
>>
>> But before bikeshedding that, it would be advisable to find out whether
>> it would be a good idea in the first place. Unless you want only
>> prospective developers to be able to contribute to the ML (maybe you do
>> want that?), it seems like a poor idea to unnecessarily exclude anyone
>> who doesn't care (nor want to care) about OpenPGP.
>
> That, and getting yourself whitelisted by a dev is gong to be a lower
> barrier than having to meet one in-person to have a key signed.  That
> is unless devs just start signing keys for people they've never met
> (which honestly doesn't really bother me much as I don't put much
> faith in the WoT anyway), in which case it turns into a whitelist that
> only comrel can un-whitelist since I don't think you can revoke a
> signature.
The one issuing the signature can also revoke it (see revsig in --edit-key).

That said, I'd rather focus on our own devs having WoT and requiring it
to become a developer long before we require it to be part of a mailing
list. If anything the technical complexity of verifying it doesn't make
much sense to me vs a simple whitelist.

>
> Plus signing emails is a pain if you don't use an MUA that has this
> feature, and the web-based ones which do aren't very good.
>


--
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Mailing list moderation and community openness

kuzetsa
In reply to this post by Rich Freeman
On 03/20/2018 08:08 PM, Rich Freeman wrote:

> On Tue, Mar 20, 2018 at 7:54 PM, Benda Xu <[hidden email]> wrote:
>> William Hubbs <[hidden email]> writes:
>>
>>> I do feel that this decision reflects badly on us as a community and
>>> should be reversed immediately. The proper way to deal with people who
>>> have bad behavior is to deal with them individually and not put a
>>> restriction on the community that is not necessary.
>>
>> I agree with William.  Dealing with individuals makes more sense.
>>
>> It boils down to an attitude of assuming outsiders are good (blacklist
>> to ML) or bad (whitelist to ML) by default.
>
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Mailing list moderation and community openness

Rich Freeman
On Mon, Mar 26, 2018 at 9:19 PM, kuzetsa <[hidden email]> 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.

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: Mailing list moderation and community openness

kuzetsa
On 03/26/2018 09:26 PM, Rich Freeman wrote:

> On Mon, Mar 26, 2018 at 9:19 PM, kuzetsa <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Mailing list moderation and community openness

Martin Vaeth-2
In reply to this post by Rich Freeman
Rich Freeman <[hidden email]> wrote:
> On Tue, Mar 20, 2018 at 7:54 PM, Benda Xu <[hidden email]> wrote:
>>
>> It boils down to an attitude of assuming outsiders are good (blacklist
>> to ML) or bad (whitelist to ML) by default.

++

This is the most crucial point.

It is the general attitude: Does Gentoo welcome contributions
or want to make their developers live in an ivory tower?

It is about openness vs. isolation.

> It is
> basically impossible to blacklist somebody on a mailing list, since
> all they need to do is roll up a new email address.

That may be technically true but it is not a problem the mailing list
is currently facing.  If it should eventually happen to be the case
that the mailing list is filled by tons of spam of anonymous posters
or faked identities causing serious problems, one can still think about
changing the modus operandi.

But without such an absolute need, it is very bad to restrict freedom.


Reply | Threaded
Open this post in threaded view
|

Re: Mailing list moderation and community openness

Rich Freeman
In reply to this post by kuzetsa
On Mon, Mar 26, 2018 at 10:38 PM, kuzetsa <[hidden email]> wrote:
>
> I think this may be a misunderstanding? no? there might be some mailing
> list jargon term: "moderation" which I was unaware of:
>

Historically moderation meant having list traffic held prior to
distribution for approval from a moderator.

> 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)

Well, ultimately the question is whether unverified members of the
community can post or not.  If they can, then there is no way to hold
anybody accountable for anything, because they can just create a new
email address to continue posting.

If you require verification prior to posting it gives everybody a
reputation to have to be concerned about.

> 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.

The process is simple, and certainly could be documented on the wiki
(it was already described in emails).  Get a dev to whitelist you.  It
can be any dev, and it is up to that dev to agree to the request or
not.

> 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.

I'd consider that a feature, not a bug.  Gentoo has well over 100
developers.  All it takes is the approval of any one of them to be
whitelisted.  That is a very permissive system.  If every single one
of them is unwilling to whitelist somebody, is it really necessary to
have every single one of them make some kind of case for their
individual decisions?  Who would even judge such a case, considering
that all of comrel and the council (and even the current Trustees) are
all developers who presumably could have done the whitelisting
themselves?

You could still layer something like the proctors or comrel on top of
this, and they would presumably be a bit more formalized in how they
operate.  (The typical conception is that Proctors would have a lot of
discretion but would generally only enforce short-term "punishments"
like bans of a few days, warnings, and so on.  On the other hand
comrel would be much more formalized but would be able to take
long-term action.  The goal of course would be for Proctors to defuse
situations before they ever get to Comrel.)

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: Mailing list moderation and community openness

Rich Freeman
In reply to this post by Martin Vaeth-2
On Tue, Mar 27, 2018 at 3:34 AM, Martin Vaeth <[hidden email]> wrote:
>
> It is the general attitude: Does Gentoo welcome contributions
> or want to make their developers live in an ivory tower?
>
> It is about openness vs. isolation.
>

I'm pretty sure most developers, myself included, want to welcome
contributions.

Much of the concern is that the lists have been turning into endless
arguing over things like very topic.  If a newcomer comes along and
reads your post, they're going to get the impression that the
developers live in an ivory tower.  Why would somebody want to
contribute to Gentoo in the first place if that is their first
impression?

Before it was the debate over mailing list policy it was a debate over
discipline policies.  Apparently developers live in an ivory tower and
like to kick people out of the tower as well.  In that particular
debate the people most informed about what was actually happening were
forbidden by policy from explaining what was going on, which basically
left everybody who knew nothing of the details to spin conspiracy
theories.

It is natural that people are going to disagree on some of these
issues.  The problem is when it turns into a personal attack or
hyperbole, which IMO the part I quoted falls into.

The intent isn't to stifle debate/discussion.  Whitelisting vs
blacklisting on a mailing list have obvious pros/cons, and you made a
legitimate point in the second half of your email (one that was hardly
unknown to the Council I'm sure).  The problem becomes when we try to
attach motives to everybody else's actions.  It isn't enough to point
out the pros/cons of whitelisting/blacklisting/etc.  Now we need to
talk about "ivory towers" and "attitude" and in other posts "cabals"
and so on.  This kind of language can be demotivating because it
demonizes those trying to fix things no matter what they do.  Are they
promoting "ivory towers" or are they allowing "toxic people" to attack
new contributors (which also hardly is welcoming to new contributors)?
 And then everybody feels like they have to lead some kind of
revolution to save Gentoo from itself.

A lot of this comes down to considering that most people in these
debates probably are well-intended.

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: Mailing list moderation and community openness

Martin Vaeth-2
Rich Freeman <[hidden email]> wrote:
> On Tue, Mar 27, 2018 at 3:34 AM, Martin Vaeth <[hidden email]> wrote:
>>
>> It is about openness vs. isolation.
>
> I'm pretty sure most developers, myself included, want to welcome
> contributions.

Closing of the mailing list does not sound like that.

> Much of the concern is that the lists have been turning into endless
> arguing over things like very topic.

Yes. Some people could not be stopped from continuously expressing their
opinion. Some developers do not want to hear them. So the list is being
closed.

> If a newcomer comes along and reads your post, they're going to get
> the impression that the developers live in an ivory tower.

IMHO this impression is completely right.

> Why would somebody want to
> contribute to Gentoo in the first place if that is their first
> impression?

Exactly. This is why closing the list is the absolutely wrong signal.
Sticking at least to a blacklist-only mode might mitigate the IMHO
severe damage which has already happened by the decision to close the
list.

> The problem is when it turns into a personal attack or
> hyperbole, which IMO the part I quoted falls into.

Personal animosities are always a problem. This can and will not
be solved by technical measurements. Taking all non-developers as
hostages - including those which were not involved at all in the
debate and even worse even possible future contributors - is
certainly not a solution for that type of problem.
And anyway, you can be sure that the problem will appear again,
no matter how closed the list will be.

> The intent isn't to stifle debate/discussion.

But this is exactly what is happening by closing the list
to non-developers.

> A lot of this comes down to considering that most people in these
> debates probably are well-intended.

Taking away freedom is never justified by good intention.


123