Nan:2007-08-02-low-traffic-lcc2
From Usenet Big-8 Management Board
From: The Big-8 Management Board <board@big-8.org>
Subject: 3rd RFD: remove-low-traffic (LAST CALL FOR COMMENTS)
Newsgroups: news.announce.newgroups, news.groups, news.groups.proposals
Followup-To: news.groups.proposals
Date: Thu, 02 Aug 2007 15:26:38 -0500
Organization: http://www.big-8.org/
REQUEST FOR DISCUSSION (RFD)
remove-low-traffic
This is a formal Request For Discussion (RFD) to discuss a policy change
in the Big-8 Usenet newsgroups. For more information, see the proposed
policy, listed below.
PROCEDURE:
The B8MB plans to begin voting on this proposal after five days. Please
offer any final discussion or comments before the end of this waiting
period. Voting may take up to one week (7 days); a result will be posted
following the end of the voting period.
All discussion of this proposal should be posted to news.groups.proposals.
(More information to come!)
SUMMARY OF DISCUSSION:
The RFD for creation of news.groups.removals was posted separately.
Issues related specifically to news.groups.removals are discussed in
that RFD.
Comments were primarily related to not having any removal policy at
all.
I think that the proposal is sound and straightforward. To summarize:
(1) Low traffic groups identified.
(2) Notice posted to the groups that they might be removed. This
will be repeated twice over a 6-week comment period. Discussion
of the removal will occur in the group that might be removed and
news.groups.removals.
(3) B8MB will decided whether or not to remove each group based on
feedback (or lack thereof) received for each group.
There was a misapprehension by some that groups with 1000s of posts
per month might be subject to removal. This would only happen if such
groups were among the lowest 5% of groups in traffic for that year.
But to alleviate these concerns an absolute traffic cap has been
added.
RATIONALE: remove-low-traffic
A process for removing unused or little-used newsgroups can give
better definition to the process of creating new groups. Without such
a process, the canonical list of newsgroups simply becomes a list of
newsgroups that were created according to whatever process was current
at the time, whether by a vote of potential users, by fiat of the
backbone cabal or Inet organizer, or by decision of the B8MB.
With a removal procedure, the list becomes one of groups that are
currently used. New groups can be added on the belief that they will
also be used.
When Usenet was young, a news admin would notice that some groups were
empty, and propose their removal. If there weren't too many
complaints or undue amounts of wailing, the groups would be removed.
At the time, retention times were short, perhaps three weeks, so the
above procedure meant that groups without any messages over the
previous three weeks might be considered for removal.
Later, when the group creation process was being codified, there was
discussion about a complementary process for group removal. But a
system of Yes-No voting did not work as well for group removal as it
did for group creation. A Yes vote could be considered to at least
nominally measure interest in participating in a proposed newsgroup,
while No votes were typically low enough in number to not derail too
many ordinary newsgroup creations.
But a Yes vote for a group removal doesn't measure interest or
disinterest in the group. In effect, a Yes vote measured how many
people wanted to disregard any complaints or wailing from those who
wanted to keep the group and voted No. On rare occasions, the group
creation process was used to remove groups, usually as part of a
hierarchy re-organization. In those circumstances, a Yes vote might
be cast by those who favored other aspects of the re-organization and
would vote Yes on all items on the ballot. In some cases, a Yes vote
was confusing, as when a Yes vote for a group meant the voter favored
removal, when ordinarily it meant they favored creation.
In 1997, Jani Patokallio proposed a two-step process for removing low
traffic groups. The first step would identify low traffic groups, and
the second step would hold a CFV to determine whether the group would
be kept or not. There would be no Yes or No votes, but only Keep
votes. If 50 persons favored keeping a group, it would be kept. In
e-mail discussion between Patokallio and Tale, Tale suggested that the
threshold for Keep votes be the same as for group creations, that is
100. In other words, a low traffic group would have to re-establish
that it had the same level of support as a proposed new group had.
The process proposed in this RFD is similar to that proposed by Jani
Patokallio. It would have a first step to identify low-traffic
groups. Instead of a public vote, there would be a feedback period in
which those who wanted a group to be retained could raise their
objections. The B8MB would make the final decision on removal based
on any feedback received.
The system avoids making a determination of the worthiness of a
newsgroup, or even worse, the worthiness of its topic. It simply
measures whether there is a modest level of interest in maintaining
the newsgroup. This is consistent with the criteria that has been
used in the creation of almost all Big 8 newsgroups: "is there a
sufficient level of interest in the proposed newsgroup."
PROPOSED POLICY:
Policy for Removing Extremely Low-Traffic Unmoderated Newsgroups.
Each year, up to 5% of unmoderated newsgroups will be considered for
removal. Currently, this is 99 groups, and these lowest volume groups
have 0, 1, or 2 articles per 12 months.
The B8MB will announce the 12-month measurement period, and request
interested persons to submit lists of low-traffic groups. For each
group, the following information must be included: (1) Name of the
group; (2) Traffic data; (3) History of the group; (4) Charter of the
group; (5) 0 to 2 other related groups that an RFD can be
cross-posted to.
The B8MB will choose the groups to be considered for removal. They
may propose removal of up to 5% of all unmoderated groups.
Groups that have been in existence less than 12 months, or that were
given a reprieve the previous year, or had 50 or more
non-cross-posted, on-topic articles in the previous 12 months must be
excluded.
An individual RFD for each group will be cross-posted to each group
proposed for removal, news.announce.newgroups, news.groups.removals,
and up to 2 related groups; with followups set to news.groups.removals
and the group proposed for removal.
Note: news.groups.removals will be an unmoderated group. When not
being used for consideration of low-traffic unmoderated groups, it can
be used for discussion about long inactive moderated groups. This
would allow news.groups.proposals to concentrate on new group
proposals and formal policy proposals.
The B8MB will determine the rate at which RFDs will be posted.
Individual board members may be assigned to watch for any discussion
that occurs in individual groups being considered for removal.
Two followup RFD's will be posted at intervals of 14 and 28 days.
Based on feedback received, the B8MB may decide to keep a group before
the 42-day feedback period is completed, and will announce their
decision in the group that had been proposed for removal.
At the end of the 42 days, the B8MB will decide which, if any, groups
are to be removed.
Hypothetical Schedule.
news.groups.removals is created, and may be used for consideration of
removals of long inactive moderated newsgroups.
B8MB announces traffic measurement period of August 1, 2006 through
July 31, 2007, and requests submissions of low traffic groups by
August 31, 2007.
During September, B8MB decides on candidate groups, and prepares RFDs.
This might be a two step process - first deciding the candidate
groups, and second preparing the RFD's.
Note, the B8MB can archive all the low-traffic removal RFD's for a
single year in a single folder in the NAN archive.
October 1, 2007. 1st RFD's posted.
October 15, 2007. 2nd RFD's posted.
October 29, 2007. 3rd RFD's posted.
November 13, 2007, B8MB decides which groups are to be removed.
DISTRIBUTION:
This document has been posted to the following newsgroups:
news.announce.newgroups (moderated)
news.groups.proposals (moderated)
news.groups
PROPONENT:
Jim Riley <jimrtex@pipeline.com>
CHANGE HISTORY:
2007-05-06 1st RFD
2007-06-12 2nd RFD
2007-08-02 3rd RFD/LCC
