Nan:2007-09-20-low-traffic-lcc
From Usenet Big-8 Management Board
From: The Big-8 Management Board <board@big-8.org>
Subject: RFD: removing extremely-low-traffic unmoderated groups (LAST CALL FOR COMMENTS)
Newsgroups: news.announce.newgroups, news.groups, news.groups.proposals
Followup-To: news.groups.proposals
Date: Thu, 20 Sep 2007 08:59:17 -0500
Organization: http://www.big-8.org/
REQUEST FOR DISCUSSION (RFD)
removing extremely-low-traffic unmoderated groups
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:
There was very little discussion.
David Ross had a question about which summer was intended. This was
clarified to be the Northern Hemisphere.
In addition, a 2nd paragraph was added to Stage 1c permitting the B8MB
tp break the candidate groups into subsets. This would permit them to
test procedures before applying them to all the candidate groups.
RATIONALE: removing extremely-low-traffic unmoderated groups
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:
Note, I have included clarifying comments in brackets.
Policy for Removing Extremely Low-Traffic Unmoderated Newsgroups.
[What information if any, is placed in the NAN archive, the Big-8
Wiki, the Big-8 newsgroup queue. etc., is at the discretion of the
B8MB]
Stage 1: Determine Candidate Groups
Stage 1a: Once per year, the B8MB will make a call in
news.announce.newgroups for traffic data on low traffic groups.
Interested individuals may submit lists of low traffic groups. For
each group, the following information shall be provided:
(1) Name of group.
(2) Traffic data.
The B8MB may specify additional information that is to be provided for
each group, such as group charters, history, and related groups.
The B8MB may prescribe the format for the information to simplify its
transformation into announcements, reports, RFD's, informal notices,
or other articles.
[The above procedure does not require the B8MB to collect traffic
data, or determine which groups are considered for removal. They will
simply screen material submitted by others.
Besides specifying the traffic measurement period, the B8MB should set
a schedule for submitting traffic data.
When a call is made is up to the B8MB. They might wish to do so when
someone indicates that they would be interested in submitting traffic
data. I would suggest a summer-to-summer (Northern hemisphere)
measurement period. This means that the feedback period would be
during the academic fall. Usenet remains somewhat seasonal, with drop
off in participation over the summer and over the Christmas/New Years
period.
Whether the B8MB requires information such as group charters, group
history, and related groups, is totally a matter of what information
they wish to provide in notices to the various groups.]
Stage 1b: Interested individuals may respond to the call.
Stage 1c: B8MB determines which groups shall be considered in
subsequent stages. They shall exclude groups that have been in
existence less than 12 months, group which received a reprieve the
previous year; or had more than 50 on-topic, non-cross-posted
articles. The number of groups considered shall not exceed 5% of the
total number of unmoderated newsgroups.
[The B8MB has total discretion in deciding which groups are the
candidate groups, subject to the specified constraints.]
The B8MB may break the list into subsets. If they do so, Stage 1d and
subsequent stages should be conducted separately for each subset.
[This is is intended to permit the B8MB to rest and refine their
procedures. For example, they might announce a first subset of groups
along with its procedure. After they have executed the procedure for
the first subset, they may adjust the procedure for the other
subset(s).]
Stage 1d: B8MB posts an announcement to news.announce.newgroups and
news.groups.proposals, containing a list of the groups to be
considered for removal; and the details of the procedure to be used in
Stages 2 and 3. The list and procedure will be discussed for at least
7 days in news.groups.proposals, after which the B8MB may remove
groups from the list, or modify their proposed procedure.
[The procedure should specify where discussion will occur, what
cross-posting will be used for notices and discussion, the time frame,
the format of notices, etc. That is, all the details of the parts of
Stage 2 that are discretionary to the B8MB.]
Stage 2: User Feedback for Candidate Groups.
Stage 2a: B8MB posts an article to each candidate group. The content
and form of the article is at the discretion of the B8MB. The article
may indicate that the group might be removed, and the manner in which
persons interested in the group may respond.
[The use of "article" is deliberate, and simply refers to a Usenet
article. The content and form of this article is totally up to the
B8MB. Whether an initial article indicates that the group might be
removed, or simply asks whether anyone is using the group, is up to
the B8MB to decide.]
The rate at which groups shall be considered is at the discretion of
the B8MB.
[The B8MB may do all groups at one time, or may initiate a few each
week. Doing all at once may give the board the ability to compare the
relative level of response among the groups. Doing all at once may
overwhelm the capacity of the B8MB to monitor the discussions.]
The B8MB may cross-post the article to additional groups such as
news.announce.newgroups, news.groups, news.groups.proposals, or other
newsgroups.
[Posting of an article to each group that may be removed is required,
all other cross-posting is at the discretion of the B8MB]
The article shall specify where feedback is to be given (eg.
news.groups.proposals, news.groups, the candidate group, e-mail to the
B8MB), and the Followup-To header should be set to facilitate the
specified method of feedback.
Stage 2b: The B8MB shall monitor any feedback, and may provide
additional information about the process, answer questions, etc.
[The B8MB may designate individual members to monitor particular
groups, and may use non-board members as well.]
Stage 2c: The feedback period shall last at least 21 days, but no more
than 42 days. The B8MB may post additional articles to the candidate
groups during the feedback period.
Stage 2d: The B8MB may remove candidate groups from consideration
during the feedback process. They shall notify the candidate group of
their decision.
Stage 3: The B8MB Determines Which Groups Are to be Removed.
Stage 3a: The B8MB shall determine which groups are to be removed.
[The method for making this decision is up to the B8MB. For example,
they might permit members to request a separate vote on specific
individual groups, and then do a single vote on the others.]
Stage 3b: B8MB posts an announcement containing a list of the groups
to be removed to news.announce.newgroups and news.groups.proposals.
The list and procedure will be discussed for at least 5 days in
news.groups.proposals, after which the B8MB may exclude groups from
the list (ie. decide not to remove some of the candidate groups).
Stage 4: The B8MB Executes Their Decision.
The B8MB shall issue rmgroup control messages and remove the groups
from checkgroups and other lists of Big 8 groups.
[It is fully understood that a rmgroup control message acts more in
accord with the USEPRO (draft) section 5.2.2; than in the manner
specified in RFC 1036 section 3.4]
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 (withdrawn)
2007-08-15 4th RFD
2007-09-17 5th RFD
2007-09-17 6th RFD/LCC
