[ You could have used the followup-to feature of your newsreader to
disallow
excessive cross-post. ]
En <news:5gji711mt7mke7ei926vmets2papctvp8q@[EMAIL PROTECTED]
>, Paul Davis va
escriure:
> Our concern at this stage is to determine whether or not the existing,
> or potential, reader****p of comp.compilers is adversely affected by
> the latency issue. If you have any opinions on this matter, and
> whether an unmoderated group would better serve the reader****p, please
> reply to this message, with your concerns or opinions.
I do not read comp.compilers all the time. I do know about it, and I even
posted to it. I certainly referred more than once to its archives, and
always find them very worthwhile.
At any rate, it was always in a quiet environment (not in a hurry), and
the
latency was certainly not a problem.
> Some concerns have already been raised, which I have briefly covered
> below:
>
> (1) It would be more usual to use the names 'comp.compilers' and
> 'comp.compilers.moderated' for an unmoderated and a moderated group,
> respectively. However, this change would require the consent of the
> c.c moderator, who is not in favor of an unmoderated group.
You can easily go over this argument with another name.
'comp.compilers.discussions' might be an option (which put emphasis on the
lower latency, as well as it announces lower S/N ratio), and I am sure
there
are others.
> (2) An unmoderated group would, of course, have its share of
> irrelevant and spam postings;
and flamebaits, and please-do-my-homework-for-me too.
> However, it should be noted that the c.c moderation policy requires
> that posters use verifiable email addresses, which are displayed in
> cleartext. It could be argued that this policy simply moves the
> burden of spam from the group to the individual posters themselves.
I do not believe you will win a vote for a creation based only on this
argument: the solution here is quite easy, and goes with the obfuscation
of
the addresses when posted (I understand John requires the address to be
able
to discuss with the poster; but perhaps this can be lifted too): it is
just
a technical point to be discussed with John; given John's long experience
with Usenet, my guess is that it could be pretty easy to solve. Fighting
spam is an open issue that goes much wider than comp.compilers and even
moderation, and I cannot believe the creation of a group might be a
solution.
I understand the menace of a creation of a new group might be seen as a
political weapon toward such an aim; but I feel it show much more the bad
relations between John and you than anything else.
And this is a problem in my eyes. If there is cooperation, John can easily
redirect discussions he feel innappropriate (like "please enumerate the
top
three best advantages of compiler A over compiler B", for example) to the
unmoderated group. And he also could monitor the unmoderated group (I
remember there is or was a similar mechanism between comp.lang.c,
unmoderated, and comp.lang.c++, moderated, because if not the cross-posts
were a nightmare to handle.)
> Finally, it should be noted that the RFD does not, in any way, reduce
> the usefulness or utility of c.c itself.
Certainly.
> Anyone who would prefer to post to a moderated group will still have
> that option.
I do not believe the usefulness of comp.compilers could be restricted to
the
fact it is a moderated group ;-). I think its reader****p is another
valuable
asset, and furthermore I do not think the creation of a high-rotation
group
will significantly decrease the value of this asset.
Antoine
|
