Moleski: Created page with '

 From: Jim Riley  Subject: RFD (Policy): removing extremely-low-traffic unmoderated groups Newsgroups: news.announce.newgroups, news.groups, news.group…'

2010-07-10T02:22:33Z

Created page with '<pre> From: Jim Riley <jimrtex@pipeline.com> Subject: RFD (Policy): removing extremely-low-traffic unmoderated groups Newsgroups: news.announce.newgroups, news.groups, news.group…'

New page

<pre>
From: Jim Riley <jimrtex@pipeline.com>
Subject: RFD (Policy): removing extremely-low-traffic unmoderated groups
Newsgroups: news.announce.newgroups, news.groups, news.groups.proposals
Followup-To: news.groups.proposals
Date: Tue, 12 Jun 2007 12:48:28 -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:

Voting

Nobody liked the idea. Some were concerned that the ballots would be
considered cancelable spam, since they would be posted to dozens of
newsgroups. Others were concerned that there would be a risk of
fraudulent voting or voting by 3rd parties not interested in a
particular newsgroup. Others thought it would be inconsistent to have
voting to retain groups, while voting is no longer used for creating
groups. Others did not understand why the use of STV was proposed.
And finally, it appeared that there would be no volunteers to act as
votetaker.

Conclusion

This revised proposal does not include voting. However, it does
include a process by which the candidate groups for removal will be
notified, so that users of the groups, if any, will be given an
opportunity to provide feedback. I believe this is an imperative of
any group removal policy.

The final decision on the removal of each group will be made by the
B8MB.

============================================================================

Feedback Mechanism

The original proposal had a number of mechanisms that would control
how many groups, and which groups were subject to removal:

(1) Percentage of groups subject to removal. This would vary based on
hierarchy, so that in comp.* and sci.* a lower threshold of activity
would be used, and also over time, so that if more groups were
retained, fewer groups would be proposed for removal next year.

(2) Relative level of support for retention. Which groups were
retained would be based on which received the most support for being
kept. This was intended to protect groups even if there were less
than 10 persons interested in keeping a group.

(3) Protection of groups from repeated attempts at removal.

Most felt that the feedback mechanisms were too complex, or perhaps
expose too many groups to removal.

Conclusion:

This revised proposal has simpler feedback mechanisms, that will
mostly operate informally under control of the B8MB.

============================================================================

Identification of Groups Proposed For Removal

The original proposal proposed selection of groups for possible
removal based on the number of non-cross-posted on-topic articles over
the previous 12 months. Though no specific traffic level was stated,
the effect of the percentage of groups under consideration would have
had the result of only considering groups with well under 50 articles
per year.

Other have suggested removing only groups that are "structurally dead"
(ie not only don't they have any traffic, but a plausible reason can
be constructed for their not having any traffic). Others have
suggested excluding groups that aren't "expected" to have much
traffic.

Another suggestion is to take in account replies, since this might
indicate at least one person might be lurking in the newsgroup.

Conclusion:

Basing the initial identification of groups on the level of traffic is
simple and straightforward. When the groups are proposed for removal,
interested persons may present information about other factors that
they may wish to have the B8MB consider. If there are actual lurkers
in the groups, they may come forward when the group is proposed for
removal.

============================================================================

New Groups

The original proposal would have required groups that had been
recently created to also pass a vote if they were to be retained. This
would allow these groups to demonstrate that they had at least a
minimal level of readership.

Conclusion:

Since voting will not be included in the next proposal, there will
be no special treatment of newly created groups. New groups should
not be considered for removal until they have been in existence for
12 months.

============================================================================

Notification of Groups Considered for Removal

The original proposal would have used voting when groups are
considered for removal. This would have meant that the CFV would
have served as notification to the groups. Some have expressed
concern that mass-posting of the CFV would be considered spam.

Some have suggested simply posting a list to news.groups.proposals,
news.announce.newgroups, or even news.groups, and seeing if anyone
responds.

Conclusion:

The experience with the former Inet removals in 2006 demonstrate that
notices to each individual group notice is expected, and that these
notices should also be cross-posted to news.announce.newgroups to
indicate that there is an actual consideration of the groups being
removed.

Posting a long list to news.groups alone amounts to stealth removal.

There is no indication that the various RFD's for the Inet removals
were considered spam, even though the substantive reason for their
being posted was the same (ie the groups didn't have much, if any
traffic).

============================================================================

System Overload

There have been concerns that merely considering removal of groups
would amount to spam, unless spread out over a long period of time.
But if spread out over time, it could give the impression that
news.groups.proposals only considers group removals.

Conclusion:

This revised proposal proposes the creation of a new unmoderated
group, news.groups.removals, and that there be an annual process of
considering removal low-traffic groups. This can be timed
to occur in the fall, avoiding summer and Christmas-New Years
vacations. By considering all the groups in a short period of time,
it will demonstrate that individual groups aren't being targeted, and
may allow the B8MB a chance to compare the response among the groups
being considered for removal.

An unmoderated group avoids the need for the moderators of
news.groups.proposals to screen articles which might simply quote an
entire RFD, and will facilitate those who wish to cross-post to
a group that may be removed.

news.group.proposals can continue to be used for new group proposals,
and news.groups for meta-discussion, etc. The rest of the year,
news.groups.removals can be used for discussion of proposals to
remove long inactive moderated newsgroups.

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:

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. In future years, the B8MB may
adjust the percentage based on experience from previous years.

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.

Groups that have been in existence less than 12 months, or that were
given a reprieve the previous year may not be included.

The B8MB will choose the groups to be considered for removal. They
may propose removal of up to 5% of all unmoderated groups.

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.

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 - one of deciding the candidate
groups, and 2 preparation of 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.

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
news.groups.proposals
news.groups

PROPONENT:

Jim Riley <jimrtex@pipeline.com>

CHANGE HISTORY:

2007-05-06 1st RFD
2007-06-12 2nd RFD (entirely new procedure)
</pre>

Nan:2007-06-12-low-traffic-rfd2 - Revision history

Moleski: Created page with '
From: Jim Riley Subject: RFD (Policy): removing extremely-low-traffic unmoderated groups Newsgroups: news.announce.newgroups, news.groups, news.group…'