Rayner Lucas
2024-02-23 22:46:17 UTC
Every now and then someone brings up the idea of converting a moderated
group to unmoderated. Someone else then replies that this must never be
done: some news servers would fail to honour the requisite control
message, leaving the group in an inconsistent state and leading to
unwanted effects such as some servers rejecting valid posts or messages
being directed to non-existent moderators. Fair enough.
However, in the past, changing a group's moderation status has been
considered a viable option, and occasionally such changes have actually
been implemented.
In October 2009, Moderator Vacancy Investigations posted by the Big-8
Management Board started to include the boilerplate text:
"This investigation will attempt to verify the reasons for non-function,
and may result in the removal of the group or the selection and instal-
lation of a new moderator. In practice, the Big-8 Management Board
considers the third alternative--changing the status of the group from
moderated to unmoderated--as likely to cause more harm than good."[1]
However, the moderator vacancy announcements/investigations immediately
preceding this (in April 2009) all retain demoderation as an option.
These were for the groups:
news.admin.announce [2]
comp.lang.asm.x86 [3]
news.admin.net-abuse.bulletins [4]
news.admin.net-abuse.policy [4]
news.admin.net-abuse.sightings [4]
And the charter of news.admin.moderation (Mar 2007) states that suitable
topics for discussion include: "whether it would be appropriate to
propose demoderating a specific group (the actual proposal, if made,
would be to the appropriate configuration newsgroup)"[5]
Some searching of the ISC archives[6] shows that there were several
cases of a moderated group being changed to unmoderated prior to this,
including:
comp.society (June 2004)
comp.soft-sys.business.sap (November 2004)
soc.culture.galiza (June 2006)
If any of the groups that were demoderated from 2004-2006 had become
irretrievably broken, it seems likely that the MVI template would have
been changed immediately to remove demoderation as an option, and the
charter for news.admin.moderation would not have included it as a
suitable topic for discussion.
Did something happen in 2009 to cause a change of mind? Or was "likely
to cause more harm than good" intended specifically in the context of
the comp.ai.jair.* groups, which were announcement groups relating to
the Journal of AI Research, and it's been copied into subsequent MVIs
ever since?
It is also interesting to note that RFC 5537 (unlike its predecessor,
RFC 1036) explicitly allows for a change of moderation status:
"The newgroup control message requests that the specified group be
created or, if already existing, that its moderation status or
description be changed."[7]
RFC 5537 was published in November 2009, not long after the MVI that had
declared such changes impractical.
So, the big question is, does anyone remember how well demoderating a
moderated group *actually worked in practice*? Were there major
problems, or did it all get worked out in some reasonable timeframe? And
would any attempt nowadays be more likely to succeed now that it's
explicitly permitted by the standard and Usenet itself is smaller, or
less likely because nobody's had to deal with such a thing in the Big 8
for years?
Regards,
Rayner
[1] "Moderator Vacancy Investigation: comp.ai.jair.*", 25th October 2009
https://groups.google.com/g/news.groups.proposals/c/1Lzg6vn6NaM
[2] "Moderator Vacancy Announcement: news.admin.announce", 18th April
2009
https://groups.google.com/g/news.groups.proposals/c/2Cld9IlyqB8
[3] "Moderator Vacancy Announcement/Investigation: comp.lang.asm.x86",
19th April 2009
https://groups.google.com/g/news.groups.proposals/c/EGrYSTxDe1M
[4] "Moderator Vacancy Announcement: news.admin.net-abuse.*", 27th April
2009
https://groups.google.com/g/news.groups.proposals/c/0r_-JEbQ5Ws
[5] "RESULT: news.admin.moderation will be created", 31st March 2007
https://groups.google.com/g/news.groups.proposals/c/o1gC1lsYin0
[6] https://ftp.isc.org/usenet/news.announce.newgroups/
[7] https://www.rfc-editor.org/rfc/rfc5537.html#section-5.2.1
group to unmoderated. Someone else then replies that this must never be
done: some news servers would fail to honour the requisite control
message, leaving the group in an inconsistent state and leading to
unwanted effects such as some servers rejecting valid posts or messages
being directed to non-existent moderators. Fair enough.
However, in the past, changing a group's moderation status has been
considered a viable option, and occasionally such changes have actually
been implemented.
In October 2009, Moderator Vacancy Investigations posted by the Big-8
Management Board started to include the boilerplate text:
"This investigation will attempt to verify the reasons for non-function,
and may result in the removal of the group or the selection and instal-
lation of a new moderator. In practice, the Big-8 Management Board
considers the third alternative--changing the status of the group from
moderated to unmoderated--as likely to cause more harm than good."[1]
However, the moderator vacancy announcements/investigations immediately
preceding this (in April 2009) all retain demoderation as an option.
These were for the groups:
news.admin.announce [2]
comp.lang.asm.x86 [3]
news.admin.net-abuse.bulletins [4]
news.admin.net-abuse.policy [4]
news.admin.net-abuse.sightings [4]
And the charter of news.admin.moderation (Mar 2007) states that suitable
topics for discussion include: "whether it would be appropriate to
propose demoderating a specific group (the actual proposal, if made,
would be to the appropriate configuration newsgroup)"[5]
Some searching of the ISC archives[6] shows that there were several
cases of a moderated group being changed to unmoderated prior to this,
including:
comp.society (June 2004)
comp.soft-sys.business.sap (November 2004)
soc.culture.galiza (June 2006)
If any of the groups that were demoderated from 2004-2006 had become
irretrievably broken, it seems likely that the MVI template would have
been changed immediately to remove demoderation as an option, and the
charter for news.admin.moderation would not have included it as a
suitable topic for discussion.
Did something happen in 2009 to cause a change of mind? Or was "likely
to cause more harm than good" intended specifically in the context of
the comp.ai.jair.* groups, which were announcement groups relating to
the Journal of AI Research, and it's been copied into subsequent MVIs
ever since?
It is also interesting to note that RFC 5537 (unlike its predecessor,
RFC 1036) explicitly allows for a change of moderation status:
"The newgroup control message requests that the specified group be
created or, if already existing, that its moderation status or
description be changed."[7]
RFC 5537 was published in November 2009, not long after the MVI that had
declared such changes impractical.
So, the big question is, does anyone remember how well demoderating a
moderated group *actually worked in practice*? Were there major
problems, or did it all get worked out in some reasonable timeframe? And
would any attempt nowadays be more likely to succeed now that it's
explicitly permitted by the standard and Usenet itself is smaller, or
less likely because nobody's had to deal with such a thing in the Big 8
for years?
Regards,
Rayner
[1] "Moderator Vacancy Investigation: comp.ai.jair.*", 25th October 2009
https://groups.google.com/g/news.groups.proposals/c/1Lzg6vn6NaM
[2] "Moderator Vacancy Announcement: news.admin.announce", 18th April
2009
https://groups.google.com/g/news.groups.proposals/c/2Cld9IlyqB8
[3] "Moderator Vacancy Announcement/Investigation: comp.lang.asm.x86",
19th April 2009
https://groups.google.com/g/news.groups.proposals/c/EGrYSTxDe1M
[4] "Moderator Vacancy Announcement: news.admin.net-abuse.*", 27th April
2009
https://groups.google.com/g/news.groups.proposals/c/0r_-JEbQ5Ws
[5] "RESULT: news.admin.moderation will be created", 31st March 2007
https://groups.google.com/g/news.groups.proposals/c/o1gC1lsYin0
[6] https://ftp.isc.org/usenet/news.announce.newgroups/
[7] https://www.rfc-editor.org/rfc/rfc5537.html#section-5.2.1