Mass removal of groups: Difference between revisions

From Usenet Big-8 Management Board
m (typo)
Line 52: Line 52:
Automatic tools should be used as much as possible. The board will divide the list of groups to be inspected among its members; it is not required that every board member check every candidate group.
Automatic tools should be used as much as possible. The board will divide the list of groups to be inspected among its members; it is not required that every board member check every candidate group.


The extend of manual checks might be proportional to the found traffic in the group. For example, the rule might be that any newsgroup that has had any posting in the past 12 months should be inspected by at least two Board members.
The extent of manual checks might be proportional to the found traffic in the group. For example, the rule might be that any newsgroup that has had any posting in the past 12 months should be inspected by at least two Board members.


If a traffic tally is done the result does not need to be precise. Knowing the magnitude (e.g. more than 50, less then 100) is enough to verify the removal decision. Anyway, it is not clear how to count crossposts, and how to treat on-topic
If a traffic tally is done the result does not need to be precise. Knowing the magnitude (e.g. more than 50, less then 100) is enough to verify the removal decision. Anyway, it is not clear how to count crossposts, and how to treat on-topic

Revision as of 14:01, 1 February 2011

See also:

Motivation

As of January 2011, there are about 1000 groups that received less than one post per day in the last 18 months. It is not feasible to use the conventional procedure for such a high number.

  • There have been no independent proponents tackling this problem in the past. It is unlikely that that will change.
  • Flooding news.announce.newgroups and news.groups.proposals with hundreds of almost identical posts will do no good.
  • Flooding hundreds of groups with almost identical posts will do no good.

In 2007 the board approved a policy for removing extremely-low-traffic unmoderated groups. This policy does not address the crucial issues, though.

Overview

Stage 1

The proposal will be conducted by the board. The initial discussion to determine candidate groups will take place in private.

Stage 2

The B8MB posts an announcement containing a list of the groups to be considered for removal.

  • The announcement will be crossposted to news.announce.newgroups, news.groups.proposals and news.groups.
  • If moderated groups are affected, the announcement will also be posted to news.admin.moderation.
  • In any case the Followup-To: will be set to news.groups.proposals.
  • The announcement will not be crossposted to target groups.
  • The announcement will not contain individual rationales for each group.
  • The announcement will not contain charters.
  • Pointers to the announcement might be posted, but not to all target groups. The contents of these pointer posts should be specific to the target group. Also the subject line should be distinct.

Stage 3

User feedback for candidate groups should take place in news.groups.proposals.

  • The group lists may be revised during this stage.
  • This stage shall take at least 8 weeks, with announcements posted every 4 weeks.
  • The minimum procedure involves three announcements: 1st RFD, 2nd RFD, LCC

Stage 4

The board votes on each newsgroup individually.

  • Available options are Yes, No and Abstain.
  • The ballot will start with a summary vote at the top.
  • Followed by a list of items (one line per group) where exceptions to the summary vote can be specified.

Stage 5

The board will post the result of the vote.

Stage 6

The board will send the list of groups to be deleted to the technical team.

Open Questions

Stage 1

Groups featuring at least one post per day should not be removed. Reorganization of sub hierarchies, i.e. creating a new group where the traffic of all others should accumulate, is not the aim.

Automatic tools should be used as much as possible. The board will divide the list of groups to be inspected among its members; it is not required that every board member check every candidate group.

The extent of manual checks might be proportional to the found traffic in the group. For example, the rule might be that any newsgroup that has had any posting in the past 12 months should be inspected by at least two Board members.

If a traffic tally is done the result does not need to be precise. Knowing the magnitude (e.g. more than 50, less then 100) is enough to verify the removal decision. Anyway, it is not clear how to count crossposts, and how to treat on-topic questions that receive no on-topic response.

It is not clear how to handle *.misc groups. Of the 192 misc-groups about 130 are ripe for removal because they don't meet the traffic limit of 1 post per month.

One proposed threshold for the Great Downsizing is:

  • zero on-topic, non-crossposted threads in the past 18 months
  • threads where an on-topic question received no on-topic answer do not count

Stage 2

The format of the announcement should be straightforward: a brief preamble, perhaps with a link to a web page, followed by the list of newsgroups, one per line, perhaps including the newsgroup line.

Group charters can be found at ftp://ftp.isc.org/pub/usenet/news.announce.newgroups/

The list might include include the number of on-topic messages (determined by the board inspection) in the past 18 months.

The announcement might be posted at any *.misc newsgroups related to the target newsgroups. Warning: as of January 2011 there are 192 misc-groups. It is quite a challenge to get a high number of almost identical messages past Cleanfeed.

Because of the magnitude of the project ("Great Downsizing" in analogy to "Great Renaming") an announcement might also be posted to news.announce.important.

Template for a RFD

Newsgroups: news.announce.newgroups,news.groups.proposals,news.groups
Subject: 1st RFD: The Great Downsizing {year}/{episode}
From: Big-8 Management Board <board@big-8.org>
Followup-To: news.groups.proposals
Archive-Name: great-downsizing-{year}-{episode}

              REQUEST FOR DISCUSSION (RFD)

This is a formal Request for Discussion (RFD) to remove the following
{number-of-newsgroups} unmoderated newsgroups.

RATIONALE:

All groups listed below fulfill these conditions:
- no moderated groups
- no group names matching *.misc
- zero on-topic, non-crossposted threads in the past 18 months
- on-topic questions that received no on-topic answer do not count

DISTRIBUTION:

news.announce.newgroups
news.groups.proposals
news.groups

Because of the magnitude of the group list this proposal is not cross-
posted to target groups. In the course of these proceedings the B8MB 
will post pointers to this announcement to appropriate groups. Readers 
are encouraged to take initiative and spread the message.

PROCEDURE:

The procedure shall take at least 8 weeks, with announcements posted 
every 4 weeks: 1st RFD, 2nd RFD, and LCC. The group lists may be re-
vised during this stage. Discussion about candidate groups should take 
place in moderated group news.groups.proposals. After publication of
the LCC the board votes on each newsgroup individually. 
More details can be found here:

  http://www.big-8.org/wiki/Mass_removal_of_groups

NEWSGROUP LINES:
{insert one-line descriptions of newsgroups from checkgroups}

CHANGE HISTORY:
{Please track revisions of the RFD using yyyy-mm-dd format,
with the most recent changes at the top of the list.}

Example for a pointer

Newsgroups: comp.unix.misc,comp.unix.admin,comp.unix.programmer
From: Big-8 Management Board <board@big-8.org>
Followup-To: news.groups.proposals
Subject: The Great Downsizing of comp.unix.*

comp.unix.advocacy		Arguments for and against Unix and Unix versions.
comp.unix.cde		The Common Desktop Environment.
comp.unix.large		UNIX on mainframes and in large networks.
comp.unix.machten		The MachTen operating system and related issues.
comp.unix.pc-clone.16bit		UNIX on 286 architectures.
comp.unix.pc-clone.32bit		UNIX on 386 and 486 architectures.
comp.unix.sys3		System III UNIX discussions.
comp.unix.sys5.r3		Discussing System V Release 3.
comp.unix.xenix.sco		XENIX versions from the Santa Cruz Operation.