Nan:2007-08-15-low-traffic-rfd4
From Usenet Big-8 Management Board
From: Jim Riley <jimrtex@pipeline.com>
Subject: 4th RFD (Policy): removing extremely-low-traffic unmoderated groups
Newsgroups: news.announce.newgroups, news.groups, news.groups.proposals
Followup-To: news.groups.proposals
Date: Wed, 15 Aug 2007 15:43:10 -0500
Organization: http://www.big-8.org/
POLICY 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.
DISCUSSION:
Discussion during the LCC period indicated there was zero support for
news.groups.removals. Approval of the policy RFD, and defeat of the
newgroup proposal will result in an inconsistent policy.
It is also clear that the use of "RFD" causes the mind of many people
to freeze and ignore the rest of the proposal.
And finally, it is clearly impossible for me (or any other non-board
member) to define specific policy for the B8MB. Instead this latest
proposal simply provides a framework, and gives discretion to the B8MB
to fill in the details.
RATIONALE:
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: B8MB makes a call in news.announce.newgroups for traffic
data on low traffic groups. This will be done annually. 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 measurement period. This
means that the feedback period would be during the 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.]
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 process.
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]
PROCEDURE:
For more information on the newsgroup creation process, please see:
http://www.big-8.org/dokuwiki/doku.php?id=policies:creation
[need something better here]
Those who wish to influence the development of this RFD and its final
resolution should subscribe to news.groups.proposals and participate in the
relevant threads in that newsgroup. This is the best method of making sure
that one's comments or criticisms are heard.
All discussion of active proposals should be posted to news.groups.proposals.
To this end, the 'Followup-To' header of this RFD has been set to this group.
We urge those who would be affected by the proposed policy to make a
comment to that effect in this thread; we ask proponents to keep a list
of such positive posts with the relevant message ID (e.g., Barney Fife,
<4JGdnb60fsMzHA7ZnZ2dnUVZ_rWdnZ2d@sysmatrix.net>). Such lists of positive
feedback for the proposal may constitute good evidence that the group will be
well-used if it is created.
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 (later withdrawn)
2007-08-15 4th RFD
