Re: [ga] "Moderating" the GA list.
I think that censoring a list, particularly when targeted at certain
individuals, is a bad policy.
In particular, individual targeting will inevitably be challenged as
inappropriate and the lack of solid substantiation will create
uncertainty, mistrust and martyrs. Moreover, even if the monitor was
willing to spend the time necessary to copiously document
justification for the targeted monitoring or censorship, what the
monitor considers as justification will most probably not be
universally shared as such by others.
This assembly, I thought, was a forum where individuals could openly
share their views relevant to the DNS, ICANN, etc. Sometimes, we may
consider another person's post to be nonsense, idle chatter, noise,
off-topic or offensive (as I did yesterday), but that's the nature of
open lists, in my experience.
I suggest that a better alternative is to come up with a method where
the members of the list can collectively police it. For instance, I
think that all list members would be in favor of blocking someone who
spammed the list. However, on an individual basis and in particular
cases, my definition of what is spam, may be different from your
definition. In that case, and in all cases, I think it better for the
list members to decide the course of action.
Sunday, June 23, 2002, 7:51:40 AM, Thomas Roessler <firstname.lastname@example.org> wrote:
TR> Any "moderation" of the GA list will have to meet some basic
TR> requirements, besides improving readability and reducing noise.
TR> In particular, every posting sent to a General Assembly mailing list
TR> MUST be available to the public. That's what we currently achieve
TR> by having ga-full on the one hand and the monitored GA list on the
TR> other. The effect of this kind of transparency is this: While undue
TR> censorship becomes provable, unproven assertions of such censorship
TR> become moot.
TR> Also, it MUST be possible for members of the GA to get quick access
TR> to postings. This may be considered solved by having a ga-full list
TR> on the one hand, and a moderated main GA list on the other - but I
TR> believe that we can do better.
TR> A possible improved approach would be to make a traditionally
TR> moderated version of the list available IN ADDITION to what we have,
TR> and look if people would actually accept it. One of the problems
TR> with this approach is that it adds considerably to the complexity of
TR> the whole GA thing - possibly beyond the point where it's still
TR> reasonable. Also, it would duplicate some of the list monitoring
TR> efforts we already have.
TR> The interesting question is, of course, what the list coming out of
TR> this would look like. I've made an experiment and taken the GA
TR> traffic from weeks 22 and 23 of this year (the first two weeks of
TR> June). I have then deleted the things I'd probably have rejected as
TR> far as a moderated list is concerned (and, of course, all the things
TR> I'd have just ignored for a summary). The result is available in
TR> web archive form at
TR> When I did this, I noticed that there were some list members whose
TR> postings (and even threads they started) I collectively deleted.
TR> With some other list members, I frequently deleted postings because
TR> they were off-topic or idle chatting. Finally, there were many
TR> members of the list whose postings I collectively approved.
TR> Thus, a very similar result could have been obtained by making the
TR> list unmoderated by default, but turning on moderation for a couple
TR> of individuals.
TR> If you want to put it like this, this would mean that list
TR> monitoring would intervene much more quickly, and, for instance,
TR> "block" people for mere off-topic posting. This "blocking" would,
TR> however, be soft (as opposed to what we currently do): It wouldn't
TR> imply that messages don't go to the list at all, it would only mean
TR> that the individuals in question would be subject to some kind
TR> "adult supervision" - after having proven that they can't do
TR> Actually, I'd like to give this approach a try immediately after
TR> Bucharest - it's not clear to me that it will actually work as
TR> intended, in particular given the fact that the approach will
TR> probably require frequent changes to list filter definitions, and
TR> will have to withstand the usual attempts to game the system by
Don Brown - Dallas, Texas USA Internet Concepts, Inc.
PGP Key ID: 04C99A55 (972) 788-2364 Fax: (972) 788-5049
Providing Internet Solutions Worldwide - An eDataWeb Affiliate
This message was passed to you via the email@example.com list.
Send mail to firstname.lastname@example.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html