2nd RFD: management_consolidation

[Mark Goodge]

-----BEGIN PGP SIGNED MESSAGE-----

2ND REQUEST FOR DISCUSSION (RFD)

This is a formal Request For Discussion (RFD) for the following changes
in the uk.* Usenet hierarchy:

delete newsgroup uk.net.news.management
delete newsgroup uk.net.news.config
create moderated newsgroup uk.net.news.admin

Changes from previous RFD:

This is the second version of this RFD, following feedback on the
previous version. There are three changes to the RFD from the previous
version:

1) This version includes an alternate version of the Moderation
Policy, as suggested by contributors to that discussion. Version 1 is
the original policy from the 1st RFD. Version 2 is a new, shorter and
simpler policy.

2) The mandatory clause prohibiting binaries has been added to the
charter, and references to plain text removed from version 1 of the
moderation policy (as this clause renders that redundant).

3) A clause prohibiting advertising has been added to the charter.

Newsgroup line:
uk.net.news.admin Management of the uk.* hierarchy (Moderated)


*** ALL DISCUSSION MUST TAKE PLACE IN UK.NET.NEWS.CONFIG ***

This is not a Call for Votes (CFV); you cannot vote at this time.
Further procedural details are given below.

RATIONALE: management_consolidation

There currently exists two groups where discussion of changes to the
uk.* hierarchy are discussed: uk.net.news.config and
uk.net.news.management.

The second of these groups was created at a time when Usenet usage was
at a peak. The rationale at the time was to separate proposals for
changes to the guidelines, for which the new group,
uk.net.news.management, was created, separating them from proposals
for new groups (which continued to be discussed in
uk.net.news.config).

In retrospect, this change was probably unnecessary. It was a response
to a perceived overload of uk.net.news.config at a time when both new
group proposals and guidelines changes were taking place. The
expectation at the time was that this would continue. In reality, it
has not.

Usenet, while by no means in terminal decline, does appear to have
passed its peak. More pertinently, the number of new group proposals
is now far lower, with the vast majority of topics that could need a
group now having one. Equally, there seems to be less of an appetite
for continual tinkering with the guidelines. Reverting to a single
group for these purposes will minimise confusion.

However, a separate issue has arisen which needs to be addressed.
Several recent new group proposals have involved the creation of
moderated groups, in response to a perceived need to have a "safe
space" where trolls and wreckers cannot operate freely. These
proposals, by their nature, have been controversial.

A consequence of the successful forming of these groups has been that
those who made their formation necessary have taken their disputes
into the management groups. The vast majority of material currently
posted to both uk.net.news.management and uk.net.news.config is off
topic.

This RFD proposes a solution to both of these problems at the same
time, by removing both of the current managementment groups and
replacing them with a single, moderated management group:
uk.net.news.admin.


CHARTER: uk.net.news.admin

This newsgroup is for the discussion of the management of the uk.*
news hierarchy, the committee appointed to oversee the management of
said hierarchy, the creation, modification or removal of groups within
the hierarchy, and the guidelines which document the processes
applicable in managing the hierarchy.

Matters which are on topic include:

* Discussion and debate about the UK Usenet Committee and officers
* RFDs and informal discussion of changes to groups within uk.*
* RFDs and informal discussion of changes to the UK Usenet Guidelines
* Other discussion relevant to the management of the UK Usenet
hierarchy

Formal RFDs to change any aspect of the hierarchy, including group
creation, renaming, rechartering and removal, as well as changes to
the UK Usenet Guidelines, shall be discussed in this group.

For the purposes of the guidelines, this group shall be the definitive
record of the discussion. All RFDs should indicate where the
definitive discussion should take place.

This group is moderated to ensure that all discussions remain on topic
and do not become unduly drawn out.

Advertising

Advertising is forbidden.

Binaries and Formatting

Encoded binaries (e.g. pictures, compressed files, etc.) are
forbidden. Such material belongs on a web or FTP site to which a
pointer may be posted. Cryptographic signatures (e.g. PGP) may be used
where authentication is important and should be as short as possible.

Posts must be readable as plain text. HTML, RTF and similarly
formatted messages are prohibited.

MODERATION POLICY:

[Version 1]

For the purposes of this policy, the following definitions are used:

Thread Starter: An article posted to the group which has no
References headers.

Thread Member: An article posted to the group which contains
References headers to previous articles.

The following will always be accepted for posting to the group:

1. Thread Starters consisting of a valid RFD or CFV crossposted
to uk.net.news.announce (and, where appropriate, any other group).

2. Thread Starters consisting of formal statements issued by the UK
Usenet Committee or UKVoting, crossposted to uk.net.news.announce
(and, where appropriate, any other group). This includes, but is
not limited to, CFV results, statements relating to appeals and
notices regarding either organisation.

3. Thread Members which meet ALL of the following criteria:
a) MUST contain at least one References header to a
previously approved article,
b) MUST NOT be crossposted to any group that the Thread Starter
was not crossposted to,
c) MUST NOT have a Follow-ups header to any group not in the
Newsgroups header,
d) MUST NOT contain a References header to a topic which has been
closed by the moderators,
e) MUST retain the same Subject line as the Thread Starter, other
than prepending the standard reply indicator "Re:"

Other Thread Starters will be accepted at the discretion of the
moderators, where it appears that the thread is sufficiently on-topic
for the group. Discretionary Thread Starters MUST NOT be crossposted
to any other group.

With the exception of discretionary thread starters, it is not the
intention that moderation should be on the basis of content. Once a
topic has been accepted for discussion, users of the group may post
freely to it as long as it remains open, provided that their posts
meet the technical criteria, above. There will be no whitelisting or
blacklisting of contributors.

The moderators may, at their discretion, allow an alteration to a
Subject line in a Thread Member where the change is reasonable and
does not affect the meaning (eg, to correct spelling, or to truncate
an excessively long Subject). Changes which signify a change of topic
should not be allowed.

The moderators may, at their discretion, close a thread to further
discussion. RFD/CFV threads may only be closed after the discussion
period specified within the RFD/CFV has expired. Non-RFD/CFV threads
may be closed at any time.

It is envisaged that, insofar as it is possible, the majority of
moderation decisions will be made automatically by software. The
moderators may use any tools at their disposal to facilitate manual
decisions.

[End Version 1]

[Version 2]

The following will always be accepted for posting to the group:

1) A valid RFD or CFV crossposted to uk.net.news.announce (and, where
appropriate, any other group).

2) Formal statements issued by the UK Usenet Committee or UKVoting,
crossposted to uk.net.news.announce (and, where appropriate, any
other group). This includes, but is not limited to, CFV results,
statements relating to appeals and notices regarding either
organisation.

3) Posts in any thread started by either of the above, provided that
a) the Subject line remains unchanged (other than prepending the
standard reply indicator "Re:"),
b) no newsgroups are included in either the Newsgroups or
Follow-ups headers that were not present in the original post,
c) the content of the post remains on-topic for the stated
subject of the thread, and
c) the content of the post is not abusive, defamatory, unduly
repetitive or otherwise disruptive to the group.

Other posts may be accepted at the discretion of the moderators.

Moderators may use whatever tools they feel appropriate to ensure the
smooth running of the group.

[End Version 2]

MODERATOR INFO:

The moderators shall include Control, in his capacity as moderator of
uk.net.news.announce and therefore as authorised to crosspost to
uk.net.news.admin.

Other moderators shall be appointed by the UK Usenet Committee. The
number of other moderators and their term of office shall be entirely
at the discretion of the Committee.

With the exception of Control when cross-posting to
uk.net.news.announce, moderators may not approve their own posts.

END CHARTER

PROCEDURE:

This is a request for discussion, not a call for votes. In this phase of
the process, any potential problems with the proposal should be raised
and resolved. The discussion period will continue for a minimum of 10
days, starting from when this RFD is posted to uk.net.news.announce
(i.e. until June 7th) after which a Call For Votes (CFV) may be
posted by a neutral vote taker if the discussion warrants it.
Alternatively, the proposal may proceed by the fast-track method. Please
do not attempt to vote until this happens.

This RFD attempts to comply fully with the "Guidelines for Group Creation
within the UK Hierarchy" as published regularly in uk.net.news.announce
and is available from http://www.usenet.org.uk/guidelines.html (the UK
Usenet website). Please refer to this document if you have any questions
about the process.

DISTRIBUTION:

This RFD has been posted to the following newsgroups:
uk.net.news.announce
uk.net.news.config

Proponent:
Mark Goodge <***@good-stuff.co.uk>

[c***@mailserv.netunix.com]

Post by Mark Goodge
-----BEGIN PGP SIGNED MESSAGE-----
2ND REQUEST FOR DISCUSSION (RFD)
This is a formal Request For Discussion (RFD) for the following changes

Good idea, do it.

[Matthew Vernon as Control]

Hi,

Sorry about the subject line - my fault. I don't think it's worth
re-issuing the RFD over. It should have said:

Subject: 2nd RFD: Consolidate uk.* management groups

Regards,

Matthew

[John Hall]

In message

Post by Mark Goodge
2ND REQUEST FOR DISCUSSION (RFD)
This is a formal Request For Discussion (RFD) for the following changes
delete newsgroup uk.net.news.management
delete newsgroup uk.net.news.config
create moderated newsgroup uk.net.news.admin

Combining the two groups seems very sensible, but I'm not so sure about
the moderation. I know that without it those who misuse the existing
groups will continue to misuse the new group, but I think it's a price
worth paying. Moderation will inevitably slow down the cut and thrust of
discussion.

[Huge]

Post by John Hall
In message

Post by Mark Goodge
2ND REQUEST FOR DISCUSSION (RFD)
This is a formal Request For Discussion (RFD) for the following changes
delete newsgroup uk.net.news.management
delete newsgroup uk.net.news.config
create moderated newsgroup uk.net.news.admin

Combining the two groups seems very sensible, but I'm not so sure about
the moderation.

Quite.

Post by John Hall
I know that without it those who misuse the existing
groups will continue to misuse the new group, but I think it's a price
worth paying. Moderation will inevitably slow down the cut and thrust of
discussion.

And be grist to the conspiracy theorists mill. The management groups are
the very last ones that should be moderated.

[Bernie]

On 27 May 2019 17:47:01 GMT

Post by Huge

Post by John Hall
In message

Post by Mark Goodge
2ND REQUEST FOR DISCUSSION (RFD)
This is a formal Request For Discussion (RFD) for the following
delete newsgroup uk.net.news.management
delete newsgroup uk.net.news.config
create moderated newsgroup uk.net.news.admin

Combining the two groups seems very sensible, but I'm not so sure
about the moderation.

Quite.

Post by John Hall
I know that without it those who misuse the existing
groups will continue to misuse the new group, but I think it's a
price worth paying. Moderation will inevitably slow down the cut
and thrust of discussion.

And be grist to the conspiracy theorists mill. The management groups
are the very last ones that should be moderated.

+1

Also, what would Wan do with no follow-ups to set? He loves his 'FUs
Set' posts, does Wan.

[Kathy Starke]

How to vote multiple times in the uk.* hierarchy - a step-by-step
guide.

1. Prepare in advance.

You are going to set up multiple identities, and each one must have
enough substance that the vote-taker (hereinafter VT) will take them
as coming from a different person. It's possible that despite your
precautions the VT will rumble one or more of your votes as being
invalid, so if you plan on voting, say, ten times, set up a few extra
identities.

Each identity must have an email address that is different, and it
must be one at which you can both send and receive email. Further,
the emails you send must NOT have anything in their headers which can
be matched to another address. The simplest way to achieve this is
to use a web-based email, but even so you must do a bit of checking
first.

To check, what you do is send yourself an email from the new address.
You need to send all your test emails to an address which will show
you ALL the "headers" - this is where extra tracking information is
added to your email. You may need to figure out how to get your
email client to show them to you as they are usually hidden. The,
open each one and look at the headers (your web-based email provider
should have a link or preference setting that says something like
"show headers" or "show original"). You are looking for two Bad
Things:

a) an IP address (something like 80.254.146.36) which matches what
you are using; and
b) a path which is sufficiently detailed to show that the emails came
from the same computer (yours).

If a) shows, you can only get (safely) one ballot via that email
address.

a) Is less of a worry if your IP changes (many dial-up accounts will
be like this - when you connect to the interweb, it can be through
any of a number of different IPs that your provider has available.
To find out what your IP is, there are many services on the web that
will tell you (just googling "whats my IP" works). Every time you
start to set up a new email address, check this first and write it
down.

b) The path will be in the Recieved: header(s). Look at them ALL for
your IP, and if you are setting up more than one email from the same
provider at (about) the same time, copy the headers and compare them.
It may be that they are the same - if so, send yourself more email a
little later and check. Providers may have multiple possible paths
(multiple mail servers) and if you get a different path the next time
that is a Good Thing. Even if the path is the same, you can try
using the email, as of course if yours is the same many others from
other legitimate users could also have that path. In this case all
you need do is avoid being stupid (see below) when requesting
ballots.

Once you have a set of working, untraceable emails you will need some
supporting usenet histories. For each email choose a few newsgroups,
groups in which you already post, or perhaps have some
knowlege/interest, and if possible close to but not necessarily
matching the group for which you expect a relevant vote.

For posting, get a free account at aioe.org or eternal-september.org
or any of a number of free newservers (google will help you find
others). It is ok to get multiple accounts at ther same newserver,
each tied to one of your new email addresses - but if you like,
spread them around a bit. Check the privacy policy to make sure that
the operator won't give out your email or logs without a court order;
although I happen to know this can be done it is a tremendous amount
of work and stress, and the VT is very unlikely, perhaps even unable
(for an off-shore based server) to want to go through this even once.


Next you need a newsreader, preferrably more than one. Many
newsreaders are free, or have free versions, and if you can have
several it will help cloak who you are. Good ones will allow
"profiles" or something similar in which you can set the name and
reply-to email, and you can use those to keep all the posting names
and newsgroups matched up (but a sheet of A4 with notes made as you
go is still probably a good idea). More than one is a Good Thing
because newsreaders add headers with various things - version,
organization, and so on, if these are all the same because you use
the same reader it could attract the attention of the VT.

MAKE A TEST POST FIRST. Pick an innocuous group (I use
uk.rec.gardening) and post something innocent and mildly worthy of
reply (for example, do not use "test" as your subject). Replying to
an existing thread is better than starting one - you'll be less
noticable. You want something to which others can reply without a
"who-the-hell-are-you" comment (a dead-giveaway), and one which you
can examine the headers. Your newsreader will have some sort of
option to "show all headers", and what you are looking for is the
same sort of identifying information that you checked for in the
email headers. If, for instance, there is an "NNTP-Posting-Host"
header and your IP (as determined above) does not change you can only
use this news-server for one identity.

If your test post shows no problems, go ahead and start posting - not
too much, and not all at once. What you want to to is simulate
someone who is new to usenet, getting involved gradually, and slowly
getting closer to the topic/newsgroup where you expect the vote to
focus. It is not actually necessary to post in order to get a ballot
sent when the Call For Votes occurs, but doing so is better because
it will attract less attention from the VT. Try to assume a
different personality for each identity - make some consistent
speeling erorrs, or use different stock phrases, or make a reference
to different locales as being where you live, and so on. Keep track
or who says what in which way from where, and be consistent within
each identity.

2. The RFD.

There will be an Request For Discussion (RDF) first, perhaps more
than one. This part of the process starts in uk.net.news.announce,
so monitor that. When the discussion starts, don't join in all at
once with all of your identities. If you have an identity that has
shown absolutely no interest in the group/topic before, you may be
better off not contributing at all with that identity. With those
identities who do participate, feel free to disagree with others,
each other, and even about which way you intend to vote. Carried
well, you can even announce that you've changed you mind as a result
of some particularly (un)persuasive point another poster (yourself?
who knows?) has made.

3. The CFV.

After a while there will be a Call For Votes - actually two. When
that happens, start asking for ballots. Do this gradually, the CFV
takes some time and if you spread your requests over this period it
will be less noticable. The requests likely follow a U-shaped curve,
so a few early, some in the middle and the remainder nearer the end
of the period will blend in better. If the VT emails you asking for
extra details, DO NOT REPLY. You've been rumbled, and trying to fix
it is not worth it. The VT will probably expect a few to try it on,
so let him think he has found one. A cat with a dead mouse may not be
so eager to try to catch another, and you will have allowed for this
eventuality by making extra identities, no?

After you get your ballot, don't always send it right back. If
possible, make your response time match your assumed identity's
personality - strident campaigners know right away how they will
vote, and lurkers may leave it until the last minute.

4. The results.

Be patient. The calculation of the results of one recent vote took
from early August to late September, so do not expect anything to
happen quickly. There is nothing you can do at this point anyway to
affect the results directly, but it is probably a good idea to keep
posting from the various identities (excepting any that the VT has
spotted) so that questions from others of the form "Who is <name>"
when they see the results can be avoided.


5. Should you worry?

No.

There is nothing legally wrong with doing any of the above.

There is nothing the VT can easily (or even likely) do (assuming you
have been sufficiently careful) to be sure any email is not genuine;
although they mutter sometimes about secret ways to check it's all
just TV-detector-van mumbo-jumbo - they have no extra powers to
demand logs etcetera from ISP or news-servers and all they have to go
on is the same stuff you check for.

There is nothing morally wrong with any of the above either - after
all, it's only Usenet, no-one dies; you want what you want, and...

...rest assured, the other side *is* doing this already.

[Brian Gaff]

Well in my view most moderators tend to become little hitlers after a while.
Brian
--
--
From the sofa of Brian Gaff -
***@blueyonder.co.uk
Blind user, so no pictures please!
Today is Yesterdays Tomorrow.

Post by Bernie
On 27 May 2019 17:47:01 GMT

Post by Huge

Post by John Hall
In message

Post by Mark Goodge
2ND REQUEST FOR DISCUSSION (RFD)
This is a formal Request For Discussion (RFD) for the following
delete newsgroup uk.net.news.management
delete newsgroup uk.net.news.config
create moderated newsgroup uk.net.news.admin

Combining the two groups seems very sensible, but I'm not so sure
about the moderation.

Quite.

Post by John Hall
I know that without it those who misuse the existing
groups will continue to misuse the new group, but I think it's a
price worth paying. Moderation will inevitably slow down the cut
and thrust of discussion.

And be grist to the conspiracy theorists mill. The management groups
are the very last ones that should be moderated.

+1
Also, what would Wan do with no follow-ups to set? He loves his 'FUs
Set' posts, does Wan.

[Spike]

Post by Brian Gaff
Well in my view most moderators tend to become little hitlers after a while.

Some are Little Hitlers before they start their career in 'moderation'.

[Tone]

Post by Spike

Post by Brian Gaff
Well in my view most moderators tend to become little hitlers after a while.

Some are Little Hitlers before they start their career in 'moderation'.

Lots of folks are okay in moderation.

Tone

[Richard Kettlewell]

Post by John Hall

Post by Mark Goodge
2ND REQUEST FOR DISCUSSION (RFD)
This is a formal Request For Discussion (RFD) for the following
delete newsgroup uk.net.news.management
delete newsgroup uk.net.news.config
create moderated newsgroup uk.net.news.admin

Combining the two groups seems very sensible,

Agreed.

Post by John Hall
but I'm not so sure about the moderation. I know that without it those
who misuse the existing groups will continue to misuse the new group,
but I think it's a price worth paying.

I don’t consider it worth paying, if someone is willing to operate the
machinery necessary to stop the idiots from wasting everyone else’s time
then I welcome that.

Post by John Hall
Moderation will inevitably slow down the cut and thrust of discussion.

The discussions are not time critical. Although I expect that most
moderation decisions would be automated meaning that the extra latency
would be negligible.

[Stephen Thomas Cole]

Post by Mark Goodge
-----BEGIN PGP SIGNED MESSAGE-----
2ND REQUEST FOR DISCUSSION (RFD)
This is a formal Request For Discussion (RFD) for the following changes
delete newsgroup uk.net.news.management
delete newsgroup uk.net.news.config
create moderated newsgroup uk.net.news.admin
This is the second version of this RFD, following feedback on the
previous version. There are three changes to the RFD from the previous
1) This version includes an alternate version of the Moderation
Policy, as suggested by contributors to that discussion. Version 1 is
the original policy from the 1st RFD. Version 2 is a new, shorter and
simpler policy.
2) The mandatory clause prohibiting binaries has been added to the
charter, and references to plain text removed from version 1 of the
moderation policy (as this clause renders that redundant).
3) A clause prohibiting advertising has been added to the charter.
uk.net.news.admin Management of the uk.* hierarchy (Moderated)
*** ALL DISCUSSION MUST TAKE PLACE IN UK.NET.NEWS.CONFIG ***
This is not a Call for Votes (CFV); you cannot vote at this time.
Further procedural details are given below.
RATIONALE: management_consolidation
There currently exists two groups where discussion of changes to the
uk.* hierarchy are discussed: uk.net.news.config and
uk.net.news.management.
The second of these groups was created at a time when Usenet usage was
at a peak. The rationale at the time was to separate proposals for
changes to the guidelines, for which the new group,
uk.net.news.management, was created, separating them from proposals
for new groups (which continued to be discussed in
uk.net.news.config).
In retrospect, this change was probably unnecessary. It was a response
to a perceived overload of uk.net.news.config at a time when both new
group proposals and guidelines changes were taking place. The
expectation at the time was that this would continue. In reality, it
has not.
Usenet, while by no means in terminal decline, does appear to have
passed its peak. More pertinently, the number of new group proposals
is now far lower, with the vast majority of topics that could need a
group now having one. Equally, there seems to be less of an appetite
for continual tinkering with the guidelines. Reverting to a single
group for these purposes will minimise confusion.
However, a separate issue has arisen which needs to be addressed.
Several recent new group proposals have involved the creation of
moderated groups, in response to a perceived need to have a "safe
space" where trolls and wreckers cannot operate freely. These
proposals, by their nature, have been controversial.
A consequence of the successful forming of these groups has been that
those who made their formation necessary have taken their disputes
into the management groups. The vast majority of material currently
posted to both uk.net.news.management and uk.net.news.config is off
topic.

Point of order; whilst this RFD is open, all abusive off-topic postings to
the management groups are actually on-topic, so “currently” above is
inaccurate. I don’t think that your error here is fatal to the RFD but I
suggest you consult The Committee for a ruling. HTH.

Post by Mark Goodge
This RFD proposes a solution to both of these problems at the same
time, by removing both of the current managementment groups and
uk.net.news.admin.
CHARTER: uk.net.news.admin
This newsgroup is for the discussion of the management of the uk.*
news hierarchy, the committee appointed to oversee the management of
said hierarchy, the creation, modification or removal of groups within
the hierarchy, and the guidelines which document the processes
applicable in managing the hierarchy.
* Discussion and debate about the UK Usenet Committee and officers
* RFDs and informal discussion of changes to groups within uk.*
* RFDs and informal discussion of changes to the UK Usenet Guidelines
* Other discussion relevant to the management of the UK Usenet
hierarchy
Formal RFDs to change any aspect of the hierarchy, including group
creation, renaming, rechartering and removal, as well as changes to
the UK Usenet Guidelines, shall be discussed in this group.
For the purposes of the guidelines, this group shall be the definitive
record of the discussion. All RFDs should indicate where the
definitive discussion should take place.
This group is moderated to ensure that all discussions remain on topic
and do not become unduly drawn out.
Advertising
Advertising is forbidden.
Binaries and Formatting
Encoded binaries (e.g. pictures, compressed files, etc.) are
forbidden. Such material belongs on a web or FTP site to which a
pointer may be posted. Cryptographic signatures (e.g. PGP) may be used
where authentication is important and should be as short as possible.
Posts must be readable as plain text. HTML, RTF and similarly
formatted messages are prohibited.
[Version 1]
Thread Starter: An article posted to the group which has no
References headers.
Thread Member: An article posted to the group which contains
References headers to previous articles.
1. Thread Starters consisting of a valid RFD or CFV crossposted
to uk.net.news.announce (and, where appropriate, any other group).
2. Thread Starters consisting of formal statements issued by the UK
Usenet Committee or UKVoting, crossposted to uk.net.news.announce
(and, where appropriate, any other group). This includes, but is
not limited to, CFV results, statements relating to appeals and
notices regarding either organisation.
a) MUST contain at least one References header to a
previously approved article,
b) MUST NOT be crossposted to any group that the Thread Starter
was not crossposted to,
c) MUST NOT have a Follow-ups header to any group not in the
Newsgroups header,
d) MUST NOT contain a References header to a topic which has been
closed by the moderators,
e) MUST retain the same Subject line as the Thread Starter, other
than prepending the standard reply indicator "Re:"
Other Thread Starters will be accepted at the discretion of the
moderators, where it appears that the thread is sufficiently on-topic
for the group. Discretionary Thread Starters MUST NOT be crossposted
to any other group.
With the exception of discretionary thread starters, it is not the
intention that moderation should be on the basis of content. Once a
topic has been accepted for discussion, users of the group may post
freely to it as long as it remains open, provided that their posts
meet the technical criteria, above. There will be no whitelisting or
blacklisting of contributors.
The moderators may, at their discretion, allow an alteration to a
Subject line in a Thread Member where the change is reasonable and
does not affect the meaning (eg, to correct spelling, or to truncate
an excessively long Subject). Changes which signify a change of topic
should not be allowed.
The moderators may, at their discretion, close a thread to further
discussion. RFD/CFV threads may only be closed after the discussion
period specified within the RFD/CFV has expired. Non-RFD/CFV threads
may be closed at any time.
It is envisaged that, insofar as it is possible, the majority of
moderation decisions will be made automatically by software. The
moderators may use any tools at their disposal to facilitate manual
decisions.
[End Version 1]
[Version 2]
1) A valid RFD or CFV crossposted to uk.net.news.announce (and, where
appropriate, any other group).
2) Formal statements issued by the UK Usenet Committee or UKVoting,
crossposted to uk.net.news.announce (and, where appropriate, any
other group). This includes, but is not limited to, CFV results,
statements relating to appeals and notices regarding either
organisation.
3) Posts in any thread started by either of the above, provided that
a) the Subject line remains unchanged (other than prepending the
standard reply indicator "Re:"),
b) no newsgroups are included in either the Newsgroups or
Follow-ups headers that were not present in the original post,
c) the content of the post remains on-topic for the stated
subject of the thread, and
c) the content of the post is not abusive, defamatory, unduly
repetitive or otherwise disruptive to the group.
Other posts may be accepted at the discretion of the moderators.
Moderators may use whatever tools they feel appropriate to ensure the
smooth running of the group.
[End Version 2]
The moderators shall include Control, in his capacity as moderator of
uk.net.news.announce and therefore as authorised to crosspost to
uk.net.news.admin.
Other moderators shall be appointed by the UK Usenet Committee. The
number of other moderators and their term of office shall be entirely
at the discretion of the Committee.
With the exception of Control when cross-posting to
uk.net.news.announce, moderators may not approve their own posts.
END CHARTER
This is a request for discussion, not a call for votes. In this phase of
the process, any potential problems with the proposal should be raised
and resolved. The discussion period will continue for a minimum of 10
days, starting from when this RFD is posted to uk.net.news.announce
(i.e. until June 7th) after which a Call For Votes (CFV) may be
posted by a neutral vote taker if the discussion warrants it.
Alternatively, the proposal may proceed by the fast-track method. Please
do not attempt to vote until this happens.
This RFD attempts to comply fully with the "Guidelines for Group Creation
within the UK Hierarchy" as published regularly in uk.net.news.announce
and is available from http://www.usenet.org.uk/guidelines.html (the UK
Usenet website). Please refer to this document if you have any questions
about the process.
uk.net.news.announce
uk.net.news.config

I will vote in favour of this proposal.

[Dr. Sandringham]

Post by Stephen Thomas Cole
I will vote in favour of this proposal.

Will that be under your own name, or your brother's?

Or, as in the last vote, both?

[Charles Lindsey]

Post by Stephen Thomas Cole

Post by Mark Goodge
-----BEGIN PGP SIGNED MESSAGE-----

Umpteeen lines of stuff which have already been seen umpteen times snipped.

Post by Stephen Thomas Cole
I will vote in favour of this proposal.

Which will probably be its death knell. Nobody else would be willing to be seen
in your company,

[Stephen Thomas Cole]

Post by Charles Lindsey

Post by Stephen Thomas Cole

Post by Mark Goodge
-----BEGIN PGP SIGNED MESSAGE-----

Umpteeen lines of stuff which have already been seen umpteen times snipped.

Post by Stephen Thomas Cole
I will vote in favour of this proposal.

Which will probably be its death knell. Nobody else would be willing to be seen
in your company,

What a peculiar outburst, from the man who recently held the hierarchy to
ransom because he was throwing a tantrum.

[Spike]

Post by Charles Lindsey

Post by Stephen Thomas Cole

Post by Mark Goodge
-----BEGIN PGP SIGNED MESSAGE-----

Umpteeen lines of stuff which have already been seen umpteen times snipped.

Post by Stephen Thomas Cole
I will vote in favour of this proposal.

Which will probably be its death knell. Nobody else would be willing to be seen
in your company,

Echoes from the last Committee Election...

[Brian Morrison]

On Mon, 27 May 2019 14:10:00 +0100

Post by Mark Goodge
-----BEGIN PGP SIGNED MESSAGE-----
2ND REQUEST FOR DISCUSSION (RFD)
This is a formal Request For Discussion (RFD) for the following
delete newsgroup uk.net.news.management
delete newsgroup uk.net.news.config
create moderated newsgroup uk.net.news.admin
This is the second version of this RFD, following feedback on the
previous version. There are three changes to the RFD from the previous
1) This version includes an alternate version of the Moderation
Policy, as suggested by contributors to that discussion. Version 1 is
the original policy from the 1st RFD. Version 2 is a new, shorter and
simpler policy.
2) The mandatory clause prohibiting binaries has been added to the
charter, and references to plain text removed from version 1 of the
moderation policy (as this clause renders that redundant).
3) A clause prohibiting advertising has been added to the charter.
uk.net.news.admin Management of the uk.* hierarchy (Moderated)
*** ALL DISCUSSION MUST TAKE PLACE IN UK.NET.NEWS.CONFIG ***

Opposed. Do not want open groups to be replaced by moderated groups.

[Brian Reay]

Post by Mark Goodge
-----BEGIN PGP SIGNED MESSAGE-----
2ND REQUEST FOR DISCUSSION (RFD)
This is a formal Request For Discussion (RFD) for the following changes
delete newsgroup uk.net.news.management
delete newsgroup uk.net.news.config
create moderated newsgroup uk.net.news.admin
This is the second version of this RFD, following feedback on the
previous version. There are three changes to the RFD from the previous
1) This version includes an alternate version of the Moderation
Policy, as suggested by contributors to that discussion. Version 1 is
the original policy from the 1st RFD. Version 2 is a new, shorter and
simpler policy.
2) The mandatory clause prohibiting binaries has been added to the
charter, and references to plain text removed from version 1 of the
moderation policy (as this clause renders that redundant).
3) A clause prohibiting advertising has been added to the charter.
uk.net.news.admin Management of the uk.* hierarchy (Moderated)
*** ALL DISCUSSION MUST TAKE PLACE IN UK.NET.NEWS.CONFIG ***
This is not a Call for Votes (CFV); you cannot vote at this time.
Further procedural details are given below.
RATIONALE: management_consolidation
There currently exists two groups where discussion of changes to the
uk.* hierarchy are discussed: uk.net.news.config and
uk.net.news.management.
The second of these groups was created at a time when Usenet usage was
at a peak. The rationale at the time was to separate proposals for
changes to the guidelines, for which the new group,
uk.net.news.management, was created, separating them from proposals
for new groups (which continued to be discussed in
uk.net.news.config).
In retrospect, this change was probably unnecessary. It was a response
to a perceived overload of uk.net.news.config at a time when both new
group proposals and guidelines changes were taking place. The
expectation at the time was that this would continue. In reality, it
has not.
Usenet, while by no means in terminal decline, does appear to have
passed its peak. More pertinently, the number of new group proposals
is now far lower, with the vast majority of topics that could need a
group now having one. Equally, there seems to be less of an appetite
for continual tinkering with the guidelines. Reverting to a single
group for these purposes will minimise confusion.
However, a separate issue has arisen which needs to be addressed.
Several recent new group proposals have involved the creation of
moderated groups, in response to a perceived need to have a "safe
space" where trolls and wreckers cannot operate freely. These
proposals, by their nature, have been controversial.
A consequence of the successful forming of these groups has been that
those who made their formation necessary have taken their disputes
into the management groups. The vast majority of material currently
posted to both uk.net.news.management and uk.net.news.config is off
topic.
This RFD proposes a solution to both of these problems at the same
time, by removing both of the current managementment groups and
uk.net.news.admin.
CHARTER: uk.net.news.admin
This newsgroup is for the discussion of the management of the uk.*
news hierarchy, the committee appointed to oversee the management of
said hierarchy, the creation, modification or removal of groups within
the hierarchy, and the guidelines which document the processes
applicable in managing the hierarchy.
* Discussion and debate about the UK Usenet Committee and officers
* RFDs and informal discussion of changes to groups within uk.*
* RFDs and informal discussion of changes to the UK Usenet Guidelines
* Other discussion relevant to the management of the UK Usenet
hierarchy
Formal RFDs to change any aspect of the hierarchy, including group
creation, renaming, rechartering and removal, as well as changes to
the UK Usenet Guidelines, shall be discussed in this group.
For the purposes of the guidelines, this group shall be the definitive
record of the discussion. All RFDs should indicate where the
definitive discussion should take place.
This group is moderated to ensure that all discussions remain on topic
and do not become unduly drawn out.
Advertising
Advertising is forbidden.
Binaries and Formatting
Encoded binaries (e.g. pictures, compressed files, etc.) are
forbidden. Such material belongs on a web or FTP site to which a
pointer may be posted. Cryptographic signatures (e.g. PGP) may be used
where authentication is important and should be as short as possible.
Posts must be readable as plain text. HTML, RTF and similarly
formatted messages are prohibited.
[Version 1]
Thread Starter: An article posted to the group which has no
References headers.
Thread Member: An article posted to the group which contains
References headers to previous articles.
1. Thread Starters consisting of a valid RFD or CFV crossposted
to uk.net.news.announce (and, where appropriate, any other group).
2. Thread Starters consisting of formal statements issued by the UK
Usenet Committee or UKVoting, crossposted to uk.net.news.announce
(and, where appropriate, any other group). This includes, but is
not limited to, CFV results, statements relating to appeals and
notices regarding either organisation.
a) MUST contain at least one References header to a
previously approved article,
b) MUST NOT be crossposted to any group that the Thread Starter
was not crossposted to,
c) MUST NOT have a Follow-ups header to any group not in the
Newsgroups header,
d) MUST NOT contain a References header to a topic which has been
closed by the moderators,
e) MUST retain the same Subject line as the Thread Starter, other
than prepending the standard reply indicator "Re:"
Other Thread Starters will be accepted at the discretion of the
moderators, where it appears that the thread is sufficiently on-topic
for the group. Discretionary Thread Starters MUST NOT be crossposted
to any other group.
With the exception of discretionary thread starters, it is not the
intention that moderation should be on the basis of content. Once a
topic has been accepted for discussion, users of the group may post
freely to it as long as it remains open, provided that their posts
meet the technical criteria, above. There will be no whitelisting or
blacklisting of contributors.
The moderators may, at their discretion, allow an alteration to a
Subject line in a Thread Member where the change is reasonable and
does not affect the meaning (eg, to correct spelling, or to truncate
an excessively long Subject). Changes which signify a change of topic
should not be allowed.
The moderators may, at their discretion, close a thread to further
discussion. RFD/CFV threads may only be closed after the discussion
period specified within the RFD/CFV has expired. Non-RFD/CFV threads
may be closed at any time.
It is envisaged that, insofar as it is possible, the majority of
moderation decisions will be made automatically by software. The
moderators may use any tools at their disposal to facilitate manual
decisions.
[End Version 1]
[Version 2]
1) A valid RFD or CFV crossposted to uk.net.news.announce (and, where
appropriate, any other group).
2) Formal statements issued by the UK Usenet Committee or UKVoting,
crossposted to uk.net.news.announce (and, where appropriate, any
other group). This includes, but is not limited to, CFV results,
statements relating to appeals and notices regarding either
organisation.
3) Posts in any thread started by either of the above, provided that
a) the Subject line remains unchanged (other than prepending the
standard reply indicator "Re:"),
b) no newsgroups are included in either the Newsgroups or
Follow-ups headers that were not present in the original post,
c) the content of the post remains on-topic for the stated
subject of the thread, and
c) the content of the post is not abusive, defamatory, unduly
repetitive or otherwise disruptive to the group.
Other posts may be accepted at the discretion of the moderators.
Moderators may use whatever tools they feel appropriate to ensure the
smooth running of the group.
[End Version 2]
The moderators shall include Control, in his capacity as moderator of
uk.net.news.announce and therefore as authorised to crosspost to
uk.net.news.admin.
Other moderators shall be appointed by the UK Usenet Committee. The
number of other moderators and their term of office shall be entirely
at the discretion of the Committee.
With the exception of Control when cross-posting to
uk.net.news.announce, moderators may not approve their own posts.
END CHARTER
This is a request for discussion, not a call for votes. In this phase of
the process, any potential problems with the proposal should be raised
and resolved. The discussion period will continue for a minimum of 10
days, starting from when this RFD is posted to uk.net.news.announce
(i.e. until June 7th) after which a Call For Votes (CFV) may be
posted by a neutral vote taker if the discussion warrants it.
Alternatively, the proposal may proceed by the fast-track method. Please
do not attempt to vote until this happens.
This RFD attempts to comply fully with the "Guidelines for Group Creation
within the UK Hierarchy" as published regularly in uk.net.news.announce
and is available from http://www.usenet.org.uk/guidelines.html (the UK
Usenet website). Please refer to this document if you have any questions
about the process.
uk.net.news.announce
uk.net.news.config
-----BEGIN PGP SIGNATURE-----
Version: 1.4.21
Charset: noconv
iQCVAwUBXOviE2OfGXkh8vHZAQiyvAQAjWAsBIAXAIakgUSLzgVNGgA2BUYg2Sgy
NsiMD3R3iEO89k8KYF75hFAYulKgmuA/jpl3+xbkFp4mK8CWyr+q5RQ3VqaY+Mcw
aAuV/n/2E/0/QBKFrmDmvxdSQ/lPiEvQp7Es4zH2XY+f3jzUKibCCJ9iaTfVtfJp
xXEaYPtYqBA=
=wR3p
-----END PGP SIGNATURE-----

Looks like an necessary evil, due to the influx of trouble makers from
uk.ra who oppose moderation but by their behaviour, make it necessary
and those who aspire to committee positions.

[Mike Fleming]

In article

Post by Mark Goodge
1) This version includes an alternate version of the Moderation
Policy, as suggested by contributors to that discussion. Version 1 is
the original policy from the 1st RFD. Version 2 is a new, shorter and
simpler policy.

I'm in favour, preferably with V2 policy.

[Judith]

On Mon, 27 May 2019 14:10:00 +0100, Mark Goodge wrote:

[fuckwittery snipped]

Moderation = censorship

Censorship of management groups = evil

[Tim Jackson]

On Mon, 27 May 2019 14:10:00 +0100, Mark Goodge wrote...

Post by Mark Goodge
-----BEGIN PGP SIGNED MESSAGE-----
2ND REQUEST FOR DISCUSSION (RFD)
This is a formal Request For Discussion (RFD) for the following changes
delete newsgroup uk.net.news.management
delete newsgroup uk.net.news.config
create moderated newsgroup uk.net.news.admin

Is there a technical problem with the idea that there will be cross-
posting between the proposed moderated group and uk.net.news.announce
(and possibly other groups)? Moderated groups usually do not allow
cross-posting.

I don't know that there will be a problem; just asking.

[Mark Goodge]

On Tue, 28 May 2019 00:11:40 +0100, Tim Jackson

Post by Tim Jackson
On Mon, 27 May 2019 14:10:00 +0100, Mark Goodge wrote...

Post by Mark Goodge
-----BEGIN PGP SIGNED MESSAGE-----
2ND REQUEST FOR DISCUSSION (RFD)
This is a formal Request For Discussion (RFD) for the following changes
delete newsgroup uk.net.news.management
delete newsgroup uk.net.news.config
create moderated newsgroup uk.net.news.admin

Is there a technical problem with the idea that there will be cross-
posting between the proposed moderated group and uk.net.news.announce
(and possibly other groups)? Moderated groups usually do not allow
cross-posting.
I don't know that there will be a problem; just asking.

No, there's no technical problem.

Moderated groups usually don't allow crossposting, at least as a
general rule, partly because of the risk of indavertently approving a
post in a different moderated group and partly because a thread
crossposted between a moderated and unmoderated group makes
parcitiapnts in the thread via the unmoderated group subject to the
moderation of the moderated group. Both of these are generally
considered a Bad Thing from a policy perspective. But it's not a
technical limitation.

When it comes to crossposting between the new group and
uk.net.news.announce, that won't be a problem, though. Every post in
uk.net.news.announce is crossposted to at least one other group, even
if that group is moderated, as that's a requirement of the guidelines.
For example, if there was to be an RFD to change the charter of
uk.legal.moderated, that RFD would have to be crossposted between unna
and ulm. And ditto for any other moderated group that was the subject
of an RFD.

In practice, I would expect that the moderators of the new group would
not permit crossposting except where necessary. But I haven't written
that into the charter because I think that's best left as a policy
decision rather than being enshrined in the rules.

Mark

[Owen Rees]

On Tue, 28 May 2019 08:07:45 +0100, Mark Goodge

Post by Mark Goodge
On Tue, 28 May 2019 00:11:40 +0100, Tim Jackson

Post by Tim Jackson
On Mon, 27 May 2019 14:10:00 +0100, Mark Goodge wrote...

Post by Mark Goodge
-----BEGIN PGP SIGNED MESSAGE-----
2ND REQUEST FOR DISCUSSION (RFD)
This is a formal Request For Discussion (RFD) for the following changes
delete newsgroup uk.net.news.management
delete newsgroup uk.net.news.config
create moderated newsgroup uk.net.news.admin

Is there a technical problem with the idea that there will be cross-
posting between the proposed moderated group and uk.net.news.announce
(and possibly other groups)? Moderated groups usually do not allow
cross-posting.
I don't know that there will be a problem; just asking.

No, there's no technical problem.
Moderated groups usually don't allow crossposting, at least as a
general rule, partly because of the risk of indavertently approving a
post in a different moderated group and partly because a thread
crossposted between a moderated and unmoderated group makes
parcitiapnts in the thread via the unmoderated group subject to the
moderation of the moderated group. Both of these are generally
considered a Bad Thing from a policy perspective. But it's not a
technical limitation.
When it comes to crossposting between the new group and
uk.net.news.announce, that won't be a problem, though. Every post in
uk.net.news.announce is crossposted to at least one other group, even
if that group is moderated, as that's a requirement of the guidelines.
For example, if there was to be an RFD to change the charter of
uk.legal.moderated, that RFD would have to be crossposted between unna
and ulm. And ditto for any other moderated group that was the subject
of an RFD.
In practice, I would expect that the moderators of the new group would
not permit crossposting except where necessary. But I haven't written
that into the charter because I think that's best left as a policy
decision rather than being enshrined in the rules.

As was discussed in response to the first RFD, there is a technical
issue quite separate from whatever policy the various moderated groups
adopt.

The mechanisms by which the various moderated groups process posts must
adopt a compatible way of handling crossposted messages. There is a
generally accepted technical solution that is implemented in the
software used by at least some of the moderated groups in the uk.*
hierarchy.

In the discussion of the first RFD the proponent was asked to verify
that all moderated groups in the uk.* hierarchy implement this mechanism
for handling crossposts and that all groups of moderators were aware of
how this case would be handled, There was no explicit confirmation that
this had been done or would be done as far as I can find.

Messages posted to uk.net.news.announce do not contain the headers that
I would expect to see if that software, or any equivalent, were in use
there. There is potentially a relatively simple process to work around
that for messages crossposted between the proposed new group,
unn.announce and unmoderated groups but if another moderated group is
involved it is not clear that the message would be passed to the
moderation systems in the correct sequence. I suspect that even the
simple case would require modifications to the tools used by Control.

Since we already have the issue of crossposting between moderated groups
in a small way, there was also a request for information about any
previous instances. IIRC the only response based on actual experience
was that things had not gone well on the one known occasion.

Whatever the merits of the proposal, the technical issues must be
addressed and resolved.

[Huge]

On 2019-05-29, Owen Rees <***@hotmail.com> wrote:

[snip]

Post by Owen Rees
The mechanisms by which the various moderated groups process posts must
adopt a compatible way of handling crossposted messages.

Oh, really? And who died and left you in charge?

[Owen Rees]

Post by Huge
[snip]

Post by Owen Rees
The mechanisms by which the various moderated groups process posts must
adopt a compatible way of handling crossposted messages.

Oh, really? And who died and left you in charge?

It is not a matter of being in charge, it is a matter of knowledge and
experience.

The knowledge is of the news protocols and the way in which messages
posted to moderated groups are routed to the moderation mechanisms. The
various independently managed servers must interoperate and adopt a
routing strategy that ensures that any message posted to multiple
moderated groups reaches all the required moderation systems and does
not get lost or end up in an endless loop.

The experience is that people who have never had to make things work
will assume that all problems either do not exist or that someone else
will solve them despite being the target of ridicule and abuse.

[Huge]

Post by Owen Rees

Post by Huge
[snip]

Post by Owen Rees
The mechanisms by which the various moderated groups process posts must
adopt a compatible way of handling crossposted messages.

Oh, really? And who died and left you in charge?

It is not a matter of being in charge, it is a matter of knowledge and
experience.

And yet here you are issuing orders. "*Must* adopt ..."

[Owen Rees]

Post by Huge

Post by Owen Rees

Post by Huge
[snip]

Post by Owen Rees
The mechanisms by which the various moderated groups process posts must
adopt a compatible way of handling crossposted messages.

Oh, really? And who died and left you in charge?

It is not a matter of being in charge, it is a matter of knowledge and
experience.

And yet here you are issuing orders. "*Must* adopt ..."

See RFC2119 section 6. I believe that having a compatible way of handling
crossposted messages is required for interoperation and therefore the
imperative “must” is appropriate.

It is not a matter of issuing orders but a technical opinion that the
proposed system will not work otherwise.

[Roger Hayter]

Post by Owen Rees

Post by Huge
[snip]

Post by Owen Rees
The mechanisms by which the various moderated groups process posts must
adopt a compatible way of handling crossposted messages.

Oh, really? And who died and left you in charge?

It is not a matter of being in charge, it is a matter of knowledge and
experience.
The knowledge is of the news protocols and the way in which messages
posted to moderated groups are routed to the moderation mechanisms. The
various independently managed servers must interoperate and adopt a
routing strategy that ensures that any message posted to multiple
moderated groups reaches all the required moderation systems and does
not get lost or end up in an endless loop.
The experience is that people who have never had to make things work
will assume that all problems either do not exist or that someone else
will solve them despite being the target of ridicule and abuse.

AFAICS all that is required is for one set of moderators to acquiesce in
another set of moderators cross posting to their group. No new
technical arrangements seem to be required.

[Roger Hayter]

Post by Roger Hayter

Post by Owen Rees

Post by Huge
[snip]

Post by Owen Rees
The mechanisms by which the various moderated groups process posts must
adopt a compatible way of handling crossposted messages.

Oh, really? And who died and left you in charge?

It is not a matter of being in charge, it is a matter of knowledge and
experience.
The knowledge is of the news protocols and the way in which messages
posted to moderated groups are routed to the moderation mechanisms. The
various independently managed servers must interoperate and adopt a
routing strategy that ensures that any message posted to multiple
moderated groups reaches all the required moderation systems and does
not get lost or end up in an endless loop.
The experience is that people who have never had to make things work
will assume that all problems either do not exist or that someone else
will solve them despite being the target of ridicule and abuse.

AFAICS all that is required is for one set of moderators to acquiesce in
another set of moderators cross posting to their group. No new
technical arrangements seem to be required.

To put it more (perhaps excessively) clearly, if a moderation team
accepts a post cross posted to another moderated group then news servers
throughout the world will show that post in the second moderated group.

[Mark Goodge]

Post by Roger Hayter

Post by Owen Rees
The experience is that people who have never had to make things work
will assume that all problems either do not exist or that someone else
will solve them despite being the target of ridicule and abuse.

AFAICS all that is required is for one set of moderators to acquiesce in
another set of moderators cross posting to their group. No new
technical arrangements seem to be required.

Yes, that's correct.

In fact, the default is that no technical measures are necessary at
all to make crossposting between multiple moderated groups work. As
designed, a post approved in one moderated group is automatically
approved for all other moderated groups in the crosspost.

However, that is, obviously, open to a certain amount of abuse, as it
allows a potential abuser to disrupt one moderated group by
crossposting to another moderated group where the rules are different,
and relyng on their posts being approved by that group's moderation
system. So some (not all) moderated groups implement a further layer
of controls to ensure that only posts approved by their own moderators
may appear in the group[1]. Groups which have this layer of protection
in place cannot be automatically crossposted into from any other
moderated group.

That does not, though, prevent crossposts being manually approved.
And, if all the moderated groups in the crosspost use the same system,
it can be configured to provide mutual recognition on a temporary or
permanent basis.

So, while it's possibly not as slick as it could be, there's no
overriding technical reason why crossposting between moderated groups
is difficult or impossible.

[1] The most common of these is pgpmoose, which is used in, inter
alia, uk.legal.moderated.

Mark

[Roger Hayter]

Post by Mark Goodge

Post by Roger Hayter

Post by Owen Rees
The experience is that people who have never had to make things work
will assume that all problems either do not exist or that someone else
will solve them despite being the target of ridicule and abuse.

AFAICS all that is required is for one set of moderators to acquiesce in
another set of moderators cross posting to their group. No new
technical arrangements seem to be required.

Yes, that's correct.
In fact, the default is that no technical measures are necessary at
all to make crossposting between multiple moderated groups work. As
designed, a post approved in one moderated group is automatically
approved for all other moderated groups in the crosspost.
However, that is, obviously, open to a certain amount of abuse, as it
allows a potential abuser to disrupt one moderated group by
crossposting to another moderated group where the rules are different,
and relyng on their posts being approved by that group's moderation
system. So some (not all) moderated groups implement a further layer
of controls to ensure that only posts approved by their own moderators
may appear in the group[1]. Groups which have this layer of protection
in place cannot be automatically crossposted into from any other
moderated group.
That does not, though, prevent crossposts being manually approved.
And, if all the moderated groups in the crosspost use the same system,
it can be configured to provide mutual recognition on a temporary or
permanent basis.
So, while it's possibly not as slick as it could be, there's no
overriding technical reason why crossposting between moderated groups
is difficult or impossible.
[1] The most common of these is pgpmoose, which is used in, inter
alia, uk.legal.moderated.
Mark

Clearly the injecting news server should honour the cryptographic check,
but it would be quite easy to bypass this on one's own news server. If
the other group's moderators were happy for this to happen there would
not be any automatic repercussions What proportion of public news
servers honour this system? Mine shows all messages to a group
regardless of moderation approval but this is clearly not the norm. How
prevalent is it to reject or not forward a message from a peer if it is
ostensibly approved but the PGPMoose information does not match?

[Mark Goodge]

Post by Roger Hayter
Clearly the injecting news server should honour the cryptographic check,
but it would be quite easy to bypass this on one's own news server. If
the other group's moderators were happy for this to happen there would
not be any automatic repercussions What proportion of public news
servers honour this system? Mine shows all messages to a group
regardless of moderation approval but this is clearly not the norm. How
prevalent is it to reject or not forward a message from a peer if it is
ostensibly approved but the PGPMoose information does not match?

PGPMoose runs on the injecting server. Other servers (transit servers
and leaf servers) don't run it. If they get a valid post, they pass it
on. The only thing other servers look for is the approval; they make
no attempt to validate it.

The way PGPMoose works is that if it sees a post that it hasn't
authorised, it issues a cancel for it. So it's a reactive,
retrospective system rather than a preventative one.

There is no technical means to prevent unauthorised approvals being
issued in the first place. All that can be done is to cancel (or hide
via a NoCeM) the offending posts. Some may see that as a weakness in
the Usenet protocols. Which, in some cases, it may be. But, in
practice, it isn't really an issue.

Mark

[Roger Hayter]

Post by Mark Goodge

Post by Roger Hayter
Clearly the injecting news server should honour the cryptographic check,
but it would be quite easy to bypass this on one's own news server. If
the other group's moderators were happy for this to happen there would
not be any automatic repercussions What proportion of public news
servers honour this system? Mine shows all messages to a group
regardless of moderation approval but this is clearly not the norm. How
prevalent is it to reject or not forward a message from a peer if it is
ostensibly approved but the PGPMoose information does not match?

PGPMoose runs on the injecting server. Other servers (transit servers
and leaf servers) don't run it. If they get a valid post, they pass it
on. The only thing other servers look for is the approval; they make
no attempt to validate it.
The way PGPMoose works is that if it sees a post that it hasn't
authorised, it issues a cancel for it. So it's a reactive,
retrospective system rather than a preventative one.

Thanks. That must be the problem Owen Rees is talking about. For the
very few cross posts to groups not usually cross-posted to using
PGPMoose or similar that would probably require ad hoc arrangements with
the moderators, or multi-posting but is surely easily surmountable for
groups which are regularly getting crossposts.

Post by Mark Goodge
There is no technical means to prevent unauthorised approvals being
issued in the first place. All that can be done is to cancel (or hide
via a NoCeM) the offending posts. Some may see that as a weakness in
the Usenet protocols. Which, in some cases, it may be. But, in
practice, it isn't really an issue.
Mark

[Mark Goodge]

Post by Roger Hayter

Post by Mark Goodge

Post by Roger Hayter
Clearly the injecting news server should honour the cryptographic check,
but it would be quite easy to bypass this on one's own news server. If
the other group's moderators were happy for this to happen there would
not be any automatic repercussions What proportion of public news
servers honour this system? Mine shows all messages to a group
regardless of moderation approval but this is clearly not the norm. How
prevalent is it to reject or not forward a message from a peer if it is
ostensibly approved but the PGPMoose information does not match?

PGPMoose runs on the injecting server. Other servers (transit servers
and leaf servers) don't run it. If they get a valid post, they pass it
on. The only thing other servers look for is the approval; they make
no attempt to validate it.
The way PGPMoose works is that if it sees a post that it hasn't
authorised, it issues a cancel for it. So it's a reactive,
retrospective system rather than a preventative one.

Thanks. That must be the problem Owen Rees is talking about. For the
very few cross posts to groups not usually cross-posted to using
PGPMoose or similar that would probably require ad hoc arrangements with
the moderators, or multi-posting but is surely easily surmountable for
groups which are regularly getting crossposts.

Yes, indeed. FWIW, as far as I'm aware all the moderated groups in
uk.* either use PGPMoose or have no additional protection at all. If
that is, indeed, the case, then there isn't really a problem in
practice - if the new group uses PGPMoose it can be configured to
cooperate with the other groups using it, and the groups not using it
won't cause any issues.

In any case, this isn't a new problem. Any time it is necessary to
post an RFD, CFV or other formal notice involving a moderated group,
it needs to be crossposted between that group and
uk.net.news.announce, which is also moderated. This doesn't happen
very often, and it's uncommon enough for it not to be a problem to
make the necessary arrangements manually. Making the new admin group
moderated won't change that - it adds another moderated group into the
Newsgroups line, but adding another one on top of an existing two is
not a significant change. And, in such cases, follow-ups for the
resulting discussion can be pointed to the admin group alone (which,
again, is currently the norm anyway), so the crosspost will just be a
one-off that will happen no more often than it already does.

And those are the only circumstances in which a crosspost to any other
group - mmoderated or not - is likely to be appropriate. While the
proposed charter doesn't prohibit crossposts, nor explicitly seek to
minimise them, I would expect the moderators to adopt a working policy
of not permitting them unless necesary. And "necessary" won't happen
often enough to be a burden.

Mark

[Owen Rees]

On Sat, 01 Jun 2019 21:12:12 +0100, Mark Goodge

Post by Mark Goodge
PGPMoose runs on the injecting server. Other servers (transit servers
and leaf servers) don't run it. If they get a valid post, they pass it
on. The only thing other servers look for is the approval; they make
no attempt to validate it.

It is easy to configure innd to run a filter on incoming messages on
peer connections - the INN Perl Filtering and Authentication Hooks
documentation says "Whenever an article is received from a peer, via
either IHAVE or TAKETHIS, filter_art() is called if Perl filtering is
turned on."

It is very easy to connect this to the PGPMoose checking code.

Using cryptographic signatures on X-Auth headers is a probably mostly a
waste of time unless some news server checks them on incoming messages
from peer connections. It is much easier just to use an nnrpd posting
filter to reject messages that claim to be approved unless then are from
some specific account that is authorised to post such messages. My
reading of the code suggests that [web]stump which is used by several
uk.* moderated groups hooks into the news server at a deeper level than
that.

Post by Mark Goodge
The way PGPMoose works is that if it sees a post that it hasn't
authorised, it issues a cancel for it. So it's a reactive,
retrospective system rather than a preventative one.

That is one of a number of things that PGPMoose can do. When hooked into
INN filtering it can be used to reject incoming messages so that they do
not appear on the server that runs the filter and will not be propagated
by that server to its peers.

I do not know whether or not any servers involved in moderation in uk.*
use any filtering on peer connections that would catch missing or
incorrect X-Auth headers. That is why I asked whether of not the people
who will know have been asked.

[Roger Hayter]

Post by Owen Rees
On Sat, 01 Jun 2019 21:12:12 +0100, Mark Goodge

Post by Mark Goodge
PGPMoose runs on the injecting server. Other servers (transit servers
and leaf servers) don't run it. If they get a valid post, they pass it
on. The only thing other servers look for is the approval; they make
no attempt to validate it.

It is easy to configure innd to run a filter on incoming messages on
peer connections - the INN Perl Filtering and Authentication Hooks
documentation says "Whenever an article is received from a peer, via
either IHAVE or TAKETHIS, filter_art() is called if Perl filtering is
turned on."
It is very easy to connect this to the PGPMoose checking code.
Using cryptographic signatures on X-Auth headers is a probably mostly a
waste of time unless some news server checks them on incoming messages
from peer connections. It is much easier just to use an nnrpd posting
filter to reject messages that claim to be approved unless then are from
some specific account that is authorised to post such messages. My
reading of the code suggests that [web]stump which is used by several
uk.* moderated groups hooks into the news server at a deeper level than
that.

Post by Mark Goodge
The way PGPMoose works is that if it sees a post that it hasn't
authorised, it issues a cancel for it. So it's a reactive,
retrospective system rather than a preventative one.

That is one of a number of things that PGPMoose can do. When hooked into
INN filtering it can be used to reject incoming messages so that they do
not appear on the server that runs the filter and will not be propagated
by that server to its peers.
I do not know whether or not any servers involved in moderation in uk.*
use any filtering on peer connections that would catch missing or
incorrect X-Auth headers. That is why I asked whether of not the people
who will know have been asked.

I think for most (if not all) uk.* moderating groups the injecting
servers are fully in the control of people who can and will prevent
anyone likely to introduce inappropriate messages getting near the
server. So no automation is necessary at this stage. Apart from sanity
filters to help the moderators, like rejecting cross posts at the
webstump stage before the moderation queue.

[Ian Jackson]

Post by Huge

Post by Owen Rees
The mechanisms by which the various moderated groups process posts must
adopt a compatible way of handling crossposted messages.

Oh, really? And who died and left you in charge?

Owen was not making a diktat. He was describing an actual system.
If the approach taken is not compatible, then things will go wrong.

In practice I doubt this will be much of a problem because we will
probably not very often want crossposting to other moderated groups,
but if it does turn out to be needed then we can implement the
semi-standard solution, or we can just do without.

[Richard Kettlewell]

Post by Tim Jackson
On Mon, 27 May 2019 14:10:00 +0100, Mark Goodge wrote...

Post by Mark Goodge
2ND REQUEST FOR DISCUSSION (RFD)
This is a formal Request For Discussion (RFD) for the following changes
delete newsgroup uk.net.news.management
delete newsgroup uk.net.news.config
create moderated newsgroup uk.net.news.admin

Is there a technical problem with the idea that there will be cross-
posting between the proposed moderated group and uk.net.news.announce
(and possibly other groups)? Moderated groups usually do not allow
cross-posting.

There is no technical problem; the extent to which moderated groups
allow crossposting or not is purely a matter of policy.

[Molly Mockford]

I'm in favour of this. Normally I am very dubious about moderated
groups, and tend to feel that the judicious use of a killfile can render
just about any group usable. However, the idea of the management groups
is that, when a change to another group is proposed, or (though now
rarely) a new group is proposed, the people affected by the proposal
should come here to discuss it; and it is a bit much to expect them to
set up brand-new killfiles in order to be able to follow and contribute
to the discussion without distraction from the trolls who have infested
the place. On that basis, therefore, I support the proposal.

[Wm]

Post by Molly Mockford
I'm in favour of this. Normally I am very dubious about moderated
groups, and tend to feel that the judicious use of a killfile can render
just about any group usable. However, the idea of the management groups
is that, when a change to another group is proposed, or (though now
rarely) a new group is proposed, the people affected by the proposal
should come here to discuss it; and it is a bit much to expect them to
set up brand-new killfiles in order to be able to follow and contribute
to the discussion without distraction from the trolls who have infested
the place. On that basis, therefore, I support the proposal.

Usenet is a classless society, Molly.

I thought you were above such distinctions.

[kat]

Post by Molly Mockford
I'm in favour of this. Normally I am very dubious about moderated
groups, and tend to feel that the judicious use of a killfile can render
just about any group usable. However, the idea of the management groups
is that, when a change to another group is proposed, or (though now
rarely) a new group is proposed, the people affected by the proposal
should come here to discuss it; and it is a bit much to expect them to
set up brand-new killfiles in order to be able to follow and contribute
to the discussion without distraction from the trolls who have infested
the place. On that basis, therefore, I support the proposal.

Also, even the trolls have the right to discuss the proposals etc. so it could
be unfair to killfile them in the group.

[Richard Kettlewell]

Post by kat

Post by Molly Mockford
I'm in favour of this. Normally I am very dubious about moderated
groups, and tend to feel that the judicious use of a killfile can render
just about any group usable. However, the idea of the management groups
is that, when a change to another group is proposed, or (though now
rarely) a new group is proposed, the people affected by the proposal
should come here to discuss it; and it is a bit much to expect them to
set up brand-new killfiles in order to be able to follow and contribute
to the discussion without distraction from the trolls who have infested
the place. On that basis, therefore, I support the proposal.

Also, even the trolls have the right to discuss the proposals etc. so
it could be unfair to killfile them in the group.

I’m not wading through their endless off-topic rubbish just on the off
chance that one of them says something useful in an RFD discussion. If
they want an audience here they know perfectly well how to achieve that.

[Molly Mockford]

Post by kat

I'm in favour of this.  Normally I am very dubious about moderated
groups, and tend to feel that the judicious use of a killfile can render
just about any group usable.  However, the idea of the management groups
is that, when a change to another group is proposed, or (though now
rarely) a new group is proposed, the people affected by the proposal
should come here to discuss it;  and it is a bit much to expect them to
set up brand-new killfiles in order to be able to follow and contribute
to the discussion without distraction from the trolls who have infested
the place.  On that basis, therefore, I support the proposal.

Also, even the trolls have the right to discuss the proposals etc. so it
could be unfair to killfile them in the group.

This is true. During the discussion of any RFD I would always empty my
killfile, even unto TLLC Allen Hughes, and then re-populate it when the
discussion was over. However, people arriving temporarily to discuss a
proposal which affects them should not be confronted with the choice
between creating a killfile and struggling to follow the discussion;
and this proposal would certainly resolve that problem. I also approve
of combining the two groups, since there is nothing like the on-topic
traffic that there used to be.

[Bernie]

On Wed, 29 May 2019 16:14:16 +0100

Post by Molly Mockford

Post by kat

I'm in favour of this.  Normally I am very dubious about moderated
groups, and tend to feel that the judicious use of a killfile can
render just about any group usable.  However, the idea of the
management groups is that, when a change to another group is
proposed, or (though now rarely) a new group is proposed, the
people affected by the proposal should come here to discuss it;
and it is a bit much to expect them to set up brand-new killfiles
in order to be able to follow and contribute to the discussion
without distraction from the trolls who have infested the place.
On that basis, therefore, I support the proposal.

Also, even the trolls have the right to discuss the proposals etc.
so it could be unfair to killfile them in the group.

This is true. During the discussion of any RFD I would always empty
my killfile, even unto TLLC Allen Hughes, and then re-populate it
when the discussion was over. However, people arriving temporarily
to discuss a proposal which affects them should not be confronted
with the choice between creating a killfile and struggling to follow
the discussion; and this proposal would certainly resolve that
problem. I also approve of combining the two groups, since there is
nothing like the on-topic traffic that there used to be.

Are there any uk.*.moderated groups (apart from announce) that don't
have an unmoderated alternative? Forcing people to accept moderation or
fuck off seems wrong, to me.

[Molly Mockford]

Post by Bernie
Are there any uk.*.moderated groups (apart from announce) that don't
have an unmoderated alternative? Forcing people to accept moderation or
fuck off seems wrong, to me.

The moderated groups listed at www.usenet.org.uk are:

uk.announce
uk.answers
uk.gay-lesbian-bi
uk.legal.moderated
uk.net.news.announce
uk.org.bcs.announce
uk.people.bdsm.personals
uk.radio.amateur.moderated
uk.rec.cycling.moderated

Of those, I think that only those with .moderated in their names were
formed to parallel already-existing unmoderated groups.

[Mark Goodge]

On Wed, 29 May 2019 18:08:39 +0100, Molly Mockford

Post by Molly Mockford

Post by Bernie
Are there any uk.*.moderated groups (apart from announce) that don't
have an unmoderated alternative? Forcing people to accept moderation or
fuck off seems wrong, to me.

uk.announce
uk.answers
uk.gay-lesbian-bi
uk.legal.moderated
uk.net.news.announce
uk.org.bcs.announce
uk.people.bdsm.personals
uk.radio.amateur.moderated
uk.rec.cycling.moderated

Also uk.religion.christian and uk.religion.jewish, although the latter
seems moribund at the moment.

Post by Molly Mockford
Of those, I think that only those with .moderated in their names were
formed to parallel already-existing unmoderated groups.

Indeed.

FWIW, the Big 8 went through a similar scenario in 2006, creating the
moderated news.groups.proposals to become the official record of RFD
threads. They left news.groups in place as a general unmoderated
discussion group, but I'm not convinced we need that here. It wouldn't
be a major change to my proposal to leave one of the old groups in
place, though, so I'd have no objection to incorporating that if
there's enough support for it.

Mark

[Bernie]

On Wed, 29 May 2019 18:08:39 +0100

Post by Molly Mockford

Post by Bernie
Are there any uk.*.moderated groups (apart from announce) that don't
have an unmoderated alternative? Forcing people to accept
moderation or fuck off seems wrong, to me.

uk.announce
uk.answers
uk.gay-lesbian-bi
uk.legal.moderated
uk.net.news.announce
uk.org.bcs.announce
uk.people.bdsm.personals
uk.radio.amateur.moderated
uk.rec.cycling.moderated
Of those, I think that only those with .moderated in their names were
formed to parallel already-existing unmoderated groups.

Ha! I can see why I've overlooked a couple of those.

[kat]

Post by Molly Mockford

Post by kat

I'm in favour of this.  Normally I am very dubious about moderated
groups, and tend to feel that the judicious use of a killfile can render
just about any group usable.  However, the idea of the management groups
is that, when a change to another group is proposed, or (though now
rarely) a new group is proposed, the people affected by the proposal
should come here to discuss it;  and it is a bit much to expect them to
set up brand-new killfiles in order to be able to follow and contribute
to the discussion without distraction from the trolls who have infested
the place.  On that basis, therefore, I support the proposal.

Also, even the trolls have the right to discuss the proposals etc. so it
could be unfair to killfile them in the group.

This is true. During the discussion of any RFD I would always empty my
killfile, even unto TLLC Allen Hughes,

Dear old Allen, he was such a nice man in the places where he behaved, a
different person entirely.

Post by Molly Mockford
and then re-populate it when the
discussion was over. However, people arriving temporarily to discuss a
proposal which affects them should not be confronted with the choice
between creating a killfile and struggling to follow the discussion;
and this proposal would certainly resolve that problem.

It would. I tend not to bother with a kilfile, just a glance and a quick Ignore
thread or mark the group read.

Post by Molly Mockford
I also approve
of combining the two groups, since there is nothing like the on-topic
traffic that there used to be.

Combining the groups is, I think, a no-brainer.

[Roger Hayter]

Post by kat

Post by Molly Mockford

On 28/05/2019 14:16, Molly Mockford wrote: > I'm in favour of this.
Normally I am very dubious about moderated > groups, and tend to feel
that the judicious use of a killfile can render > just about any group
usable. However, the idea of the management groups > is that, when a
change to another group is proposed, or (though now > rarely) a new
group is proposed, the people affected by the proposal > should come
here to discuss it; and it is a bit much to expect them to > set up
brand-new killfiles in order to be able to follow and contribute > to
the discussion without distraction from the trolls who have infested >
the place. On that basis, therefore, I support the proposal. >
Also, even the trolls have the right to discuss the proposals etc. so it
could be unfair to killfile them in the group.

This is true. During the discussion of any RFD I would always empty my
killfile, even unto TLLC Allen Hughes,

Dear old Allen, he was such a nice man in the places where he behaved, a
different person entirely.

Post by Molly Mockford
and then re-populate it when the
discussion was over. However, people arriving temporarily to discuss a
proposal which affects them should not be confronted with the choice
between creating a killfile and struggling to follow the discussion;
and this proposal would certainly resolve that problem.

It would. I tend not to bother with a kilfile, just a glance and a quick
Ignore thread or mark the group read.

I agree. Surely there is really only a trolling problem during relevant
discussions. It is fairly easy to ignore trolling when there is no
relevant management discussion going on.

Post by kat

Post by Molly Mockford
I also approve
of combining the two groups, since there is nothing like the on-topic
traffic that there used to be.

Combining the groups is, I think, a no-brainer.

[Mark Goodge]

Post by Roger Hayter

Post by kat

Post by Molly Mockford
and then re-populate it when the
discussion was over. However, people arriving temporarily to discuss a
proposal which affects them should not be confronted with the choice
between creating a killfile and struggling to follow the discussion;
and this proposal would certainly resolve that problem.

It would. I tend not to bother with a kilfile, just a glance and a quick
Ignore thread or mark the group read.

I agree. Surely there is really only a trolling problem during relevant
discussions. It is fairly easy to ignore trolling when there is no
relevant management discussion going on.

But it's during the relevant discussions when it matters. If people
are put off participating in discussions related to new groups, or
changes to existing groups, because they see more noise than signal,
that's bad for the hierarchy as a whole.

Marking individual threads read isn't really a solution, partly
because not all news software implements that facility, and partly
because one of the most common forms of disruptive posting is to
repeatedly add the management groups into discussions elsewhere, thus
generating new off-topic threads regularly.

Mark

[Brian]

On Thu, 30 May 2019 22:52:52 +0100, Mark Goodge

Post by Mark Goodge

Post by Roger Hayter
I agree. Surely there is really only a trolling problem during relevant
discussions. It is fairly easy to ignore trolling when there is no
relevant management discussion going on.

But it's during the relevant discussions when it matters. If people
are put off participating in discussions related to new groups, or
changes to existing groups, because they see more noise than signal,
that's bad for the hierarchy as a whole.
Marking individual threads read isn't really a solution, partly
because not all news software implements that facility, and partly
because one of the most common forms of disruptive posting is to
repeatedly add the management groups into discussions elsewhere, thus
generating new off-topic threads regularly.

For example:
Message-ID:
<1122862649.579953490.288171.usenet-***@news.individual.net>

which was followed by
Message-ID: <1o7tyoo.1m2tt0d1dw6a0wN%***@hayter.org>

[Bernie]

On Thu, 30 May 2019 22:52:52 +0100

Post by Mark Goodge

Post by Roger Hayter

Post by kat

Post by Molly Mockford
and then re-populate it when the
discussion was over. However, people arriving temporarily to
discuss a proposal which affects them should not be confronted
with the choice between creating a killfile and struggling to
follow the discussion; and this proposal would certainly resolve
that problem.

It would. I tend not to bother with a kilfile, just a glance and
a quick Ignore thread or mark the group read.

I agree. Surely there is really only a trolling problem during
relevant discussions. It is fairly easy to ignore trolling when
there is no relevant management discussion going on.

But it's during the relevant discussions when it matters. If people
are put off participating in discussions related to new groups, or
changes to existing groups, because they see more noise than signal,
that's bad for the hierarchy as a whole.
Marking individual threads read isn't really a solution, partly
because not all news software implements that facility, and partly
because one of the most common forms of disruptive posting is to
repeatedly add the management groups into discussions elsewhere, thus
generating new off-topic threads regularly.
Mark

KF anything x-posted to the cesspit.

[Chronos]

On Wed, 29 May 2019 08:08:58 +0100

Post by kat
Also, even the trolls have the right to discuss the proposals etc. so
it could be unfair to killfile them in the group.

This is my reasoning nudging me toward supporting the proposal. Right
now, if there's any cross-posting from certain groups, I don't see
entire sub-threads, which may mean I miss valid points. That, however,
is a small price to pay to not have the drivel and bitterness displayed
on my screen and I suspect no sensible person would ever suggest those
who make the rulesets and kill files necessary are totally blameless
for the situation where they're free to post and we're free to not even
notice.

Consolidation is non-contentious. The ambivalence lies in moderation.
Weighing the pros of not having to filter the management groups and the
attendant rise in SNR with the cons of loss of liberty and potential
accusations of stifling dissent is difficult.

I'm personally of the opinion that if any group needs moderation it's
this one but the first link forged chains us all irrevocably¹. At the
risk of slippery slope fallacy, it's not a giant leap from here to any
problem with trolling and kookery, which candour compels us to admit
will always be a part of 'net life², being answered by "slap it with
moderation" with little aforethought to the baby sloshing about in the
discarded bathwater.

Usenet is one of the few precious resources we have these days that
remains decentralised, fairly anonymous, non-monopolistic and isn't
infested with trackers, marketers and busybodies. Our custodianship of
it should speak to the future so that, if the masses ever realise just
how much power they're handing to Facebook, Google et al, it's still
here, open, free and ready to expand to support diverse interests
and people.

[Brian]

On Mon, 27 May 2019 14:10:00 +0100, Mark Goodge
<***@good-stuff.co.uk> wrote:

<all snipped>

I have two issues with the moderation aspects of this proposal. Taking
them in reverse order:
(a) the Mods are to be appointed by the Committee. In the event of
the need to discuss a MONC in the Committee, this would have the
effect that the discussion would be moderated by nominees of the
target of the MONC. I would be easier with what is proposed if there
was some kind of carve-out to address this;
and
(b) I am still concerned that this is a sledgehammer to crack a nut.
The majority of off-topic materal in unn.config and unn.man consists
of material cross-posted from elsewhere. The majority of this
crossposting seems to originate with a single individual who currently
injects through n.i.n. Has the newsadmin there been asked for a view
as to whether this use of their facilities is in accordance with their
AUP?

(I continue to think that amalgamation of unn.config and unn.man is a
good idea).

[Stephen Thomas Cole]

Post by Judith
On Mon, 27 May 2019 14:10:00 +0100, Mark Goodge
<all snipped>
I have two issues with the moderation aspects of this proposal. Taking
(a) the Mods are to be appointed by the Committee. In the event of
the need to discuss a MONC in the Committee, this would have the
effect that the discussion would be moderated by nominees of the
target of the MONC. I would be easier with what is proposed if there
was some kind of carve-out to address this;

Fret ye not, I have already volunteered to set up and manage the moderation
team, independent of The Committee.

Post by Judith
and
(b) I am still concerned that this is a sledgehammer to crack a nut.
The majority of off-topic materal in unn.config and unn.man consists
of material cross-posted from elsewhere. The majority of this
crossposting seems to originate with a single individual who currently
injects through n.i.n. Has the newsadmin there been asked for a view
as to whether this use of their facilities is in accordance with their
AUP?

The nin FAQ suggests that you employ a killfile. HTH.

Post by Judith
(I continue to think that amalgamation of unn.config and unn.man is a
good idea).

Thanks.

[Ian Jackson]

I support this proposal. I have some detailed comments:


In article <rfd2-management_consolidation-20190527131000$***@weathertop.principate.org.uk>,
Mark Goodge <***@good-stuff.co.uk> wrote:
...

Post by Mark Goodge
CHARTER: uk.net.news.admin

...

Post by Mark Goodge
[Version 1]

...

Post by Mark Goodge
[End Version 1]
[Version 2]

...

Post by Mark Goodge
[End Version 2]
The moderators shall [ include and be ... ]
END CHARTER

The positioning of the moderation policy as part of the charter is IMO
incorrect.

The moderators should have the complete freedom to change the
moderation policy in the light of experience. Whereas the primary
charter text, and method of appointment of the moderators, must be
part of the charter and changeable by RFD only.

So the moderation policy must be the *initial* moderation policy only.

Supposing this bug is corrected, I prefer the more detailed moderation
policy. IMO it is generally better if moderators explain more
precisely how they do their work. If the details turn out to be
awkward, they can be changed (or even removed).

I don't necessarily think everything in the more detailed initial
policy is completely right but it should be workable. I do have one
detailed comment about it that I will make in a separate posting.

[Mark Goodge]

Post by Ian Jackson
...

Post by Mark Goodge
CHARTER: uk.net.news.admin

...

Post by Mark Goodge
[Version 1]

...

Post by Mark Goodge
[End Version 1]
[Version 2]

...

Post by Mark Goodge
[End Version 2]
The moderators shall [ include and be ... ]
END CHARTER

The positioning of the moderation policy as part of the charter is IMO
incorrect.

Yes, sorry, you're right. I realised that myself after posting it. The
'END CHARTER' is in the wrong place, it should be before the
'MODERATION POLICY'.

I will correct this in the CFV. I don't think it's a significant
enough change to require a thrd RFD.

Mark

[Ian Jackson]

Post by Mark Goodge

Post by Ian Jackson
The positioning of the moderation policy as part of the charter is IMO
incorrect.

Yes, sorry, you're right. I realised that myself after posting it. The
'END CHARTER' is in the wrong place, it should be before the
'MODERATION POLICY'.

That is not quite right, because the appointment of moderators needs
to be *within* the charter.

[Ian Jackson]

Post by Mark Goodge
[Version 1]

If this version is adopted,

Post by Mark Goodge
The moderators may, at their discretion, close a thread to further
discussion. RFD/CFV threads may only be closed after the discussion
period specified within the RFD/CFV has expired. Non-RFD/CFV threads
may be closed at any time.

the moderators ought to be entitled to close a *subthread* on the
grounds that it has become off-topic, while leaving the bulk of the
thread untouched.

That will allow the moderators to deal with the problem that any
attempt at a serious on topic discussion eventually devolves into
off-topic tit-for-tat drivel.

[Mark Goodge]

Post by Ian Jackson

Post by Mark Goodge
[Version 1]

If this version is adopted,

Post by Mark Goodge
The moderators may, at their discretion, close a thread to further
discussion. RFD/CFV threads may only be closed after the discussion
period specified within the RFD/CFV has expired. Non-RFD/CFV threads
may be closed at any time.

the moderators ought to be entitled to close a *subthread* on the
grounds that it has become off-topic, while leaving the bulk of the
thread untouched.
That will allow the moderators to deal with the problem that any
attempt at a serious on topic discussion eventually devolves into
off-topic tit-for-tat drivel.

I take your point, but I'm inclined to think this isn't really
necessary. Assuming version one of the moderation policy is adopted,
then a thread will be identifiable from its subject line (as changing
it is against policy). So it's also easy to see, visually, whether a
thread is closed or not, as any part of a closed thread is closed and
any part of an open thread is open. Allowing subthreads to be closed
may make this less clear.

In any case, I suspect that, once the trolling is eliminated, it will
be a pretty low traffic group anyway. So a certain amount of thread
drift is unlikely to be an issue.

Mark

[Roger Hayter]

Post by Mark Goodge

Post by Mike Fleming
In article

Post by Mark Goodge
[Version 1]

If this version is adopted,

Post by Mark Goodge
The moderators may, at their discretion, close a thread to further
discussion. RFD/CFV threads may only be closed after the discussion
period specified within the RFD/CFV has expired. Non-RFD/CFV threads
may be closed at any time.

the moderators ought to be entitled to close a *subthread* on the
grounds that it has become off-topic, while leaving the bulk of the
thread untouched.
That will allow the moderators to deal with the problem that any
attempt at a serious on topic discussion eventually devolves into
off-topic tit-for-tat drivel.

I take your point, but I'm inclined to think this isn't really
necessary. Assuming version one of the moderation policy is adopted,
then a thread will be identifiable from its subject line (as changing
it is against policy). So it's also easy to see, visually, whether a
thread is closed or not, as any part of a closed thread is closed and
any part of an open thread is open. Allowing subthreads to be closed
may make this less clear.
In any case, I suspect that, once the trolling is eliminated, it will
be a pretty low traffic group anyway. So a certain amount of thread
drift is unlikely to be an issue.
Mark

Outside of genuine management discussions I think moderation can easily
reduce the traffic from quite low to none. But it is during a
discussion that the question of closing subthreads arises. Presumably
when there is a management topic being discussed traffic will be
somewhat higher.

This is why I will vote against the proposal, as I don't think
moderation should be used to sanitise an important discussion.

[Ian Jackson]

Post by Mark Goodge

Post by Ian Jackson
That will allow the moderators to deal with the problem that any
attempt at a serious on topic discussion eventually devolves into
off-topic tit-for-tat drivel.

I take your point, but I'm inclined to think this isn't really
necessary. Assuming version one of the moderation policy is adopted,
then a thread will be identifiable from its subject line (as changing
it is against policy). So it's also easy to see, visually, whether a
thread is closed or not, as any part of a closed thread is closed and
any part of an open thread is open. Allowing subthreads to be closed
may make this less clear.

That is a disadvantage of my suggestion but I don't think it will be a
problem in practice. A subthread will only be closed if it has
devolved into the usual off-topic point scoring, which no reasonable
poster will want to part of.

If people posting on-topic messages as descendants of tit-for-tat
drivel turns out to be a significant problem then closed-subthread
messages could be referred to manual moderation instead of simply
being rejected.

Post by Mark Goodge
In any case, I suspect that, once the trolling is eliminated, it will
be a pretty low traffic group anyway. So a certain amount of thread
drift is unlikely to be an issue.

My point is that your proposal will not eliminate trolling. It will
simply confine it to existing threads. That is in some respects
worse.

See for example
<***@mid.individual.net>
<412924348.580798762.459426.usenet-***@news.individual.net>
<***@mid.individual.net>
in this very thread. (That was just the first example I came across.)

Someone who comes to the management group to discuss things that
affect their local patch of uk.* should not have to wade through this
kind of nonsense.

And no descendant of <***@mid.individual.net> is at all
likely to be on-topic or indeed of any value whatsoever. (Of course
now I have said this someone will make an "on-topic" point there just
to "prove me wrong"...)