Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[History] The Guidelines: a preliminary revision history

8 views
Skip to first unread message

Joe Bernstein

unread,
Feb 16, 2002, 2:59:24 PM2/16/02
to
This is a preliminary revision history of the guidelines for newsgroup
creation in the Big Seven and Big Eight hierarchies.

It's possible, thanks to things like Supersedes: headers, to verify in
exquisite detail whether a collection of regularly posted posts is
complete. I haven't done that. I've basically just taken what a few
simple searches at Google gave me and downloaded the earliest example
I could find of each last-changed or last-modified line. Then I've
run diff -cw on each successive pair. The downloaded files, and the
diffs, are all at

<http://these-survive.postilion.org/newsgroups/history/guidelines/>

There have been three major drafts of the guidelines, to the best of
my knowledge: I've basically done this as a last-minute lark before
getting my home net access cut off, and don't pretend to have
researched the matter fully, but it doesn't *look* to me like there
were any formally posted group creation guidelines until Gene
Spafford's of October 31, 1987. In particular, if there were any,
they weren't posted to {net|mod|news}.announce.newusers.

This post includes extensive quotes from each of the three drafts.
The news server from which I usually post is rejecting this post,
with the bewildering error message "Too Small" (!?), so I'm having
to post it from Google, which means those quotes are quite probably
re-wrapped in unpleasant ways. My apologies.

So without further ado, on to the revision history.


GENE SPAFFORD, author

GENE SPAFFORD, reviser

October 31, 1987
Sample Message-ID: <21...@arthur.cs.purdue.edu>

This document explicitly appeals to the authority of the Backbone and
involves the Backbone in newsgroup creation, but also includes a
number of features of the modern system already. Here's its core
process:

--begin quote--

1) Determine if a new newsgroup is actually needed. Look carefully
through the lists of active newsgroups and mailing lists to be sure
there is currently no existing forum for your topic. If there is such
a group or mailing list, try using it before attempting to create a new
group -- it might be just what you want.

2) Determine an appropriate name for your proposed newsgroup -- a name
should be informative, reasonably short, and in an appropriate
top-level hierarchy. Also determine if you want the newsgroup to be
moderated or not.

3) Post an article to the newsgroup "news.groups" describing your
proposed new group. Be sure to describe why you think the group is
needed and/or interesting, and what you think it should be named. Ask
for comments to be posted and for votes to be *MAILED* to you. Be sure
to cross-post your article to any newsgroups where there might be
interest, but set the "Followup-to" header so that responses only
go to the "news.groups" group.

4) Consider carefully all comments and objections, whether posted or
mailed. Answer objections and questions in a timely fashion. Change
the name or nature of the group, if needed, based on the comments of
others. Remember that the success of the group is based on the support
and participation of the other people on the network, so listen to
their advice and concerns.

5) Collect MAILED votes on the issue of the new newsgroup. The
threshold currently set as necessary for creating a new group is 100
more "yes" votes than "no" votes in a 30 day period.
a) If you get at least 100 more "yes" votes than "no" votes,
post an article to the news.groups newsgroup including the
totals and the list of account names of people voting.
b) If you fail to get at least 100 more "yes" votes than "no"
votes, consider starting a mailing list for your topic
instead of a new group, or else think about starting the
group as an "alt" group. If a group cannot get the support
of at least 100 people in one month's time, it does not
belong on the Usenet until such time as it gains sufficient
support.
c) If you are trying to get an exisiting mailing list upgraded
to a newsgroup, consider the current subscriber list as a
set of "yes" votes of equal number, but only if they have
already agreed that they want the list turned into a
newsgroup.

6) Send mail to "back...@rutgers.edu" and ask that the group be
created. You can issue the control message yourself, but many sites
will ignore the group unless the control message originates from one of
the known backbone admins (usually one of: sp...@arthur.cs.purdue.edu,
ma...@cbosgd.att.com, ri...@uunet.uu.net, wo...@hao.ucar.edu or
fa...@ucbarpa.berkeley.edu). If the group is moderated, be sure to
include information about the moderator and submission addresses in
your mail message so that the appropriate postings and databases can be
updated. The group will likely be created at this time, but if the
members of the backbone list perceive that there are serious unanswered
questions about the group's creation, it may be postponed until those
questions are resolved.

--end quote--

The trusted sources for control messages named are Gene Spafford, Mark
Horton, Rick Adams, Greg Woods, and Erik Fair, respectively.


April 14, 1988
Sample Message-ID: <40...@medusa.cs.purdue.edu>

Expanded explanation that these are only guidelines.
Discouraged proponents of groups to which there might be objections.
Added more advice on naming in step 2.
Removed suggestion that voting should happen in step 3.
Made step 5 more tentative ("The threshold currently *suggested as*
necessary...", emphasis mine).
Added another address for Gene Spafford in step 6.


GREG WOODS, author

GREG WOODS, reviser

May 14, 1989
Sample Message-ID: <67...@medusa.cs.purdue.edu>

A completely new document.

Claims that these guidelines should apply in all cases except for
"extraordinary circumstances", a much stronger claim than in the
previous document by Gene Spafford.

This is, in essence, the current system, although there has been one
more complete rewrite of the documentation, and many smaller
revisions. Here it is in this early form. (I don't say "original
form" because I have no doubt that there were earlier drafts, which
may even have been posted, although not to news.announce.newusers.)

---begin quote---

The Discussion

1) A call for discussion on creation of a new newsgroup should be posted
to news.groups, and also to any other groups or mailing lists at all
related to the proposed topic if desired. The Followup-to: header should be
set so that the actual discussion takes place only in news.groups

2) The discussion period should last for at least two weeks (14 days),
and no more than 30 days.

3) The name and charter of the proposed group and whether it will be moderated
or unmoderated (and if the former, who the moderator will be) should be
determined during the discussion period. If there is no general consensus
on these points among the proponents of a new group at the end of 30 days
of discussion, the discussion should be taken offline (into mail instead of
news.groups) and the proponents should iron out the details among themselves.
Once that is done, a new, more specific proposal may be made, going back
to step 1) above.

The Vote

1) AFTER the discussion period, if it has been determined that a new group is
really desired, a name and charter are agreed upon, and it has been
determined whether the group will be moderated and if so who will
moderate it, a call for votes may be posted to news.groups and any
other groups or mailing lists that the original call for discussion
might have been posted to. There should be minimal delay between the
end of the discussion period and the issuing of a call for votes.
The call for votes should include clear instructions for how to cast
a vote. It must be as clearly explained and as easy to do to cast a
vote for creation as against it, and vice versa. It is explicitly
permitted to set up two separate addresses to mail yes and no votes
to provided that they are on the same machine, to set up an address
different than that the article was posted from to mail votes to, or
to just accept replies to the call for votes article, as long as it
is clearly and explicitly stated in the call for votes article how
to cast a vote.

2) The voting period should last for at least 30 days, no matter what the
preliminary results of the vote are. The exact date that the voting period
will end should be stated in the call for votes. Only votes that arrive
on the vote-taker's machine prior to this date may be counted.

3) A couple of repeats of the call for votes may be posted during the vote,
provided that they contain similar clear, unbiased instructions for
casting a vote as the original, and provided that it is really a repeat
of the call for votes on the SAME proposal (see #5 below). Partial vote
results should NOT be included; only a statement of the specific new
group proposal, that a vote is in progress on it, and how to cast a vote.

4) ONLY votes MAILED to the vote-taker will count. Votes posted to the net
for any reason (including inability to get mail to the vote-taker) and
proxy votes (such as having a mailing list maintainer claim a vote for
each member of the list) may not be counted.

5) Votes may not be transferred to other, similar proposals. A vote shall
count only for the EXACT proposal that it is a response to. In particular,
a vote for or against a newsgroup under one name shall NOT be counted as
a vote for or against a newsgroup with a different name or charter,
a different moderated/unmoderated status or (if moderated) a different
moderator.

6) Votes MUST be explicit; they should be of the form "I vote for the
group foo.bar as proposed" or "I vote against the group foo.bar
as proposed". The wording doesn't have to be exact, it just needs to
be unambiguous. In particular, statements of the form "I would vote
for this group if..." should be considered comments only and not
counted as votes.

The Result

1) At the completion of the 30 day voting period, the vote taker must post
the vote tally and the E-mail addresses and (if available) names of the
votes received to news.groups and any other groups or mailing lists to
which the original call for votes was posted.

2) AFTER the vote result is posted, there will be a 5 day waiting period
during which the net will have a chance to correct any errors in
the voter list or the voting procedure.

3) AFTER the waiting period, and if there were no serious objections that might
invalidate the vote, and if 100 more YES/create votes are received
than NO/don't create, a newgroup control message may be sent out.
If the 100 vote margin is not met, the group should not be created.

---end quote---


September 3, 1989
Sample Message-ID: <78...@medusa.cs.purdue.edu>

This is the revision that introduces news.announce.newgroups.

Replaced posting to news.groups with posting to
news.announce.newgroups, Followup-To: news.groups, in Discussion item
1. (The requirement that the CFD appear in nan was not, however,
strictly enforced for a long time to come. It was rare for a *long*
long time to cross-post CFDs between nan and news.groups.)
Added option of multiple moderators in Discussion item 3.
Replaced news.groups with news.announce.newgroups in Vote item 1. (No
CFV in nan appears to have been a serious objection much earlier than
no CFD there; while Greg Woods was moderator, he made a point of
fishing CFVs from news.groups and reposting them, but thereafter nan
posting became steadily more required. People frequently began votes
by posting the CFV everywhere else and simultaneously posting another
one to nan, in the hope that it would appear in the next semi-weekly
or weekly posting run.)
Added permission for posting of mass acks (without indications of
which way people had voted) during the vote, in Vote item 3. (Note
that the ban on partial vote results was also not strictly enforced
for a long time.)
Replaced news.groups with news.announce.newgroups in Result item 1.
(I think, but am not sure, that Results followed a trajectory
somewhere between that of CFDs and that of CFVs in their migration to
nan.)
Added detailed instructions for newgrouping to Result item 3. (Vote
taker or vote taker's admin should send newgroup if possible,
otherwise Greg Woods will. Either way, don't send a copy of the
Result, and do write to Gene Spafford to get the group added to the
List of Active Newsgroups.)


GENE SPAFFORD, reviser

October 10, 1989
Sample Message-ID: <83...@medusa.cs.purdue.edu>

Reduced minimum voting period from 30 to 21 days, in Vote item 2.


November 6, 1989
Sample Message-ID: <85...@medusa.cs.purdue.edu>

Corrected spelling of "hierarchy".
Reduced voting period from 30 to 21 days, in Result item 1.


GREG WOODS, reviser

February 16, 1990
Sample Message-ID: <97...@medusa.cs.purdue.edu>

Added the 2/3rds YES rule.


July 19, 1990
Sample Message-ID: <11...@medusa.cs.purdue.edu>

Changed Discussion item 2 to describe the voting period. (Undoubtedly
an editing error; but there is now no minimum CFD period, and there
will not be a minimum CFD/RFD period for the rest of the life of this
document.)
Specified that the 5 day waiting period begins with the Result posting
in news.announce.newgroups, in Result item 2.
Specified that there must be 100 more *valid* YES votes than NO votes,
in Result item 3.


ELIOT LEAR, reviser

September 6, 1990
Sample Message-ID: <11...@medusa.cs.purdue.edu>

Removed Discussion item 2.
Added requirement that all addresses receiving votes count both YES
and NO votes to Vote item 1. (I'm fairly certain this wasn't enforced
for some time yet; having separate YES and NO vote addresses was
common although not the norm.)
Added maximum vote length of 31 days to Vote item 2.


DAVID LAWRENCE, reviser

May 19, 1991
Sample Message-ID: <14...@ector.cs.purdue.edu>

This is a fairly major revision.

Replaced "call for discussion" with "request for discussion" in
Discussion item 1 and Vote item 1.
Changed submission address for nan in Discussion item 1. (This must
have changed before too, but I didn't catch it. Sorry.)
Added paragraph saying RFDs should be cross-posted to all groups,
including nan, not multi-posted, to Discussion item 1.
Added Discussion item 3 (the old item 3 had been item 2 since Sept. 6,
1990) offering group-advice to help proponents with the process.
Added Vote item 7, which either banned multi-group CFVs or multi-group
ballot items (what it says is "A vote should be run only for a single
group proposal.").
Revised Result item 3, removing all the material on newgroup messages,
and replaced that material with Result item 4, saying that the nan
moderator will send the newgroup and that vote takers for moderated
groups should e-mail both Gene Spafford and David Lawrence with the
submission address.
Added Result item 5, adding a six-month cooling off period for failed
proposals.


GENE SPAFFORD, reviser

September 2, 1991
Sample Message-ID: <15...@ector.cs.purdue.edu>

Changed "may be counted" to "will be counted" in Vote items 2 and 4.


November 30, 1991
Sample Message-ID: <spaf-howto...@cs.purdue.edu>

diff found no changes outside the headers, nor any new headers.


September 23, 1992
Sample Message-ID: <spaf-howto...@cs.purdue.edu>

Changed tale-related addresses significantly in Discussion items 1 and
3, and Result item 4.
Corrected "names of the vote[r]s" in Result item 1.


DAVID LAWRENCE, reviser

September 17, 1993
Sample Message-ID: <howto_7...@uunet.uu.net>

Added retrospective credit to Gene Spafford in the extra headers.
Added note promising major changes soon.
Changed nan submission address slightly, in Discussion item 1.
Stated that use of UVV is "strongly advocated for all newsgroup
proposals", giving Ron Dippold as contact, in a preface to Vote.
Removed Gene Spafford as someone to write to when a moderated group is
created, in Result item 4.


November 30, 1993
Sample Message-ID: <howto_7...@uunet.uu.net>

Removed note promising major changes soon.


February 17, 1994
Sample Message-ID: <howto_7...@uunet.uu.net>

Revised preface to Vote, saying the UVV "currently handle vote
gathering and counting for all newsgroup proposals".


November 2, 1994
Sample Message-ID: <howto_7...@uunet.uu.net>

Changed Ron Dippold's address slightly in preface to Vote.


January 18, 1995
Sample Message-ID: <howto_7...@uunet.uu.net>

Changed "USENET" to "Usenet" in preface.
Added group-mentors in preface to Discussion.
Removed Ron Dippold's name, and changed UVV contact address
significantly, in preface to Vote.
Changed tale's address slightly in Result item 4.


October 27, 1995
Sample Message-ID: <howto.n_...@uunet.uu.net>

Added reference to humanities.* in preface.
Changed UVV contact address significantly in preface to Vote.


November 11, 1995
Sample Message-ID: <howto.n_...@uunet.uu.net>

Added summary of changes.
Rewrapped. (This should have been ignored by diff -cw, that's what I
thought the -w option *did*, but I see that this is not so. Ah well.
I'm not going to hand-compare, so the rest of this is according to
tale's summary.)
Changed group-mentors address significantly in preface to Discussion.
Noted that the six-month waiting period does not apply to invalidated
or cancelled "polls" in Result item 5.


December 19, 1996
Sample Message-ID: <nan.howt...@uunet.uu.net>

Removed summary of changes.
Added requirement that RFDs be formatted according to the "How to
Format and Submit" document to Discussion item 1.
Added "ADDITIONAL REFERENCES" section pointing to that document and
also "How to Write a Good Newsgroup Proposal", the Newsgroup Creation
Companion, and "What Is Usenet?".


January 31, 1997
Sample Message-ID: <nan.howt...@isc.org>

Changed nan submission and group-advice addresses significantly in
Discussion items 1 and 3.
Corrected a typo in ADDITIONAL REFERENCES.


RUSS ALLBERY, author

RUSS ALLBERY, reviser

June 29, 1998
Sample Message-ID: <m3n2awn...@windlord.Stanford.EDU>

I'm quite certain that I don't have the entire revision history of
this document, given that I have only eight versions and we are now on
"revision 0.35", but here's an account of what I do have. This is, of
course, the existing (though officially unofficial) process.

As stated in the June 29, 1998 draft:

---begin quote---

GENERAL RULE

1. Only postings to news.announce.newgroups authorized by the n.a.n
moderator are considered official in this process. All time limits
and deadlines will be based on the Date headers of those posts.

THE DISCUSSION

2. A proposal officially begins with the posting of a Request for
Discussion (RFD) in news.announce.newgroups. A valid RFD must contain
a rationale for the proposal, charters for all newsgroups which would
be created or changed, and moderator information sections for all
created or changed groups that are proposed to be moderated. The RFD
must be crossposted to news.groups, should be crossposted to groups
likely to be affected by the proposal, and may be crossposted to other
related newsgroups. Crossposts to poorly propagated or regional
newsgroups may be disallowed at the discretion of the n.a.n moderator.
Proposals will only be posted or crossposted to moderated groups with
the explicit permission of the moderators of those groups. The total
length of the Newsgroups header in the RFD (and CFV) must not exceed
200 characters, including "Newsgroups: ". Followups will be set to
news.groups only. The RFD, after it has been posted, may be
redistributed freely.

3. A proposal must consist of one or more of the following changes to Big
Eight newsgroups: Creation of a new newsgroup, removal of a newsgroup
(by subsumption into an existing group), change in the moderation
status of a newsgroup, or renaming of a newsgroup. No other types of
proposals will be accepted, nor will proposals whose intent is to
create, change, or remove newsgroups outside the Big Eight.

4. All proposed group names must be within the Big Eight hierarchies. A
group name is made up of name components separated by '.'; each
component must consist solely of lowercase letters, digits, '+', and
'-', must contain at least one non-digit, and must be no more than
fourteen characters long.

5. A proposal may include multiple changes if they are closely related,
but each individual change (as defined in point 3) will be voted on
separately. The n.a.n moderator may require closely-related proposals
to be combined or a bundling of unrelated proposals to be separated.

6. A proposal that is substantially similar to a previous failed proposal
may not be made until at least six months after the close of vote on
the last such failed proposal.

7. A proposal that significantly affects the same groups as a previous
successful proposal may not be made until at least three months after
the implementation (point 27) of the last such successful proposal.

8. Two proposals with overlapping purposes, newsgroup names, or effects
may not proceed at the same time. Precedence is normally given to the
first group to present a formal proposal, but repeat proposals under
point 6 above may be handled differently at the discretion of the
n.a.n moderator (to prevent monopolization of a proposal).

9. Proposals that unmoderate or change the moderators of an actively
moderated group against the desires of the moderators will be
rejected.

10. Proposals may be rejected by the n.a.n moderator in the extremely rare
circumstance that the proposal would be opposed by the vast majority
of news administrators or have a sufficiently deleterious effect on
the Big Eight as a whole as to make it dangerously unworkable or
extremely ill-advised (for example, a proposal for a newsgroup where
the the act of posting on charter would be nigh universally illegal).

11. All discussion of active proposals should be posted to news.groups.
If desired by the readership of closely affected groups, it may be
crossposted to those groups, but care must be taken to ensure that all
discussion appears in news.groups.

12. Additional RFDs for a proposal may be posted as needed, as the
proposal changes in response to discussion. An additional RFD is
needed if there have been major changes to the proposal or if 60 days
have passed since the previous RFD. Examples of major changes include
any change to a group's name or moderation status or a significant
alteration to the charter. Examples of minor changes not requiring an
additional RFD include the addition or removal of a proponent or
tidying up some wording in the rationale or charter.

13. The discussion period must be a minimum of 21 days. If a proposal
remains in the RFD phase for more than four months, the proposal may
be suspended and a competing proposal allowed to go forward.

THE VOTE

14. Success or failure of a proposal will be determined by the results
of a general interest poll conducted by a member of the Usenet
Volunteer Votetakers (UVV). Before the poll begins, the proponent
must submit a Proponent Questionnaire (PQ) to the UVV. The votetaker
will post a CFV (Call for Votes) based on the PQ, generally to the
same newsgroups to which the RFD was posted. Every proposed change
from the list in point 3 above will be voted on separately and will
pass or fail independently.

15. The first CFV may be posted between 10 and 60 days after the latest
RFD for the proposal. At least 21 days must have elapsed between the
first RFD and the first CFV.

16. The voting period will last 21 days. The votetaker will post a second
CFV near the middle of that period. Only votes that arrive at the
votetaker's machine prior to the close of voting will be considered
valid.

17. The votetaker may reject votes not cast precisely according to the
instructions in the CFV.

18. Only one vote per person is permitted. If multiple votes are received
from a single account, only the last vote will be counted, even if the
account is used by more than one person. Multiple votes which are, in
the judgement of the votetaker, attempts to bypass these restrictions
may all be rejected.

19. Anonymous, forwarded, or proxy votes are not valid. Votes from
nonexistent accounts are not valid. Votes mailed by WWW/HTML/CGI
forms are considered proxy votes and are not valid. The precise
definition of anonymous is at the discretion of the votetaker but
should not be interpreted as requiring all voters to use their real
name; votes from well-established pseudonyms should be accepted.

20. The explicit voting instructions in the CFV may not be distributed, in
whole or in part, to any forum, by anyone except the votetaker.
People wishing to vote should be referred to the CFV posted in
news.announce.newgroups or told to contact the votetaker for a copy.
Violations may result in invalidation of votes by the votetaker or
long-term suspension of the proposal by the n.a.n moderator.

21. Whether or not the CFV may be sent to mailing lists is at the
discretion of the votetaker, and if done should only be done by the
votetaker directly.

22. The validity of any given vote is determined by the votetaker. Votes
may be disqualified for violation of the above points or for any other
actions seriously detrimental to the integrity of the vote, at the
discretion of the votetaker. The decision of the votetaker may be
appealed to the n.a.n moderator. The decision of the n.a.n moderator
is final.

THE RESULT

23. After the completion of the vote, the votetaker will tally the result
and post it to the same newsgroups to which the votetaker posted the
CFV. The posted result will contain the name, a form of the e-mail
address, and the vote of everyone who voted except for those people
who subsequently cancelled their vote.

24. For every separate vote in the proposal, the vote will be considered
to have passed if and only if it received at least 100 more YES than
NO votes and received at least twice as many YES as NO votes.

25. After the result posting, there will be a five day period when any
objections to the vote may be raised in news.groups. The n.a.n
moderator should also be informed (at newgroup...@isc.org) of
any objections or inaccuracies that could change the outcome.

26. At the conclusion of this waiting period, the n.a.n moderator will
either validate the results or will put the proposal on hold while
objections are considered. The final determination of whether a vote
has passed or failed will be made by the n.a.n moderator; the n.a.n
moderator may also call for a revote or take other appropriate action
to deal with severely flawed votes.

27. All portions of the proposal that passed will be implemented by
control messages issued by the n.a.n moderator. Control messages are
sent at 10:30am US Eastern time, Monday through Thursday. Ordinarily,
control messages implementing the portions of a proposal which passed
will be sent at the first such time at least five days (120 hours)
after the posting of the result. Delays may be caused by unresolved
objections from point 25, major holidays, to allow initial setup of
moderation, or for transition periods (for example, removal of an
existing group may be delayed until creation of its replacement has
had time to propagate).

---end quote---


July 18, 1998
Sample Message-ID: <yl7lu37...@windlord.stanford.edu>

Expanded preface (not quoted above), notably giving pointers to "the
FAQs" and to group-mentors (with address).


March 14, 1999
Sample Message-ID: <big-eight-faq-921421219$20...@windlord.stanford.edu>

This is "revision 0.29".

Added a couple of extra headers.
Added paragraph on the document's status to preface.
Replaced "Followups" with "The Followup-To header" in item 2, and added
a reference to item 11 there.
Changed "at least one non-digit" to "at least one letter [a-z]" in
item 4.
Clarified wording of item 24.
Removed .sig.


March 28, 1999
Sample Message-ID: <big-eight-faq-922953606$67...@windlord.stanford.edu>

This is "revision 0.31".

Removed a typo in item 10.
Changed "four months" to "120 days" in item 13, and added a sentence
saying proposals are "considered withdrawn" 120 days after their last
RFD if a PQ wasn't submitted within 60 days of their last RFD.


February 5, 2000
Sample Message-ID: <big-eight-faq-951897613$28...@windlord.stanford.edu>

This is "revision 0.32".

Changed the limit on namespace components from 14 characters to 20 in
item 4.


November 27, 2000
Sample Message-ID: <big-eight-faq-975657602$13...@windlord.stanford.edu>

This is "revision 0.33".

Replaced the sentence "Votes from nonexistent accounts are not valid."
in item 19 with a new item 19 saying that munged addresses may not
vote and that votes whose acks bounce will not be counted. (Ah. I'd
been wondering just when that happened.) The rest of the old item 19
became item 20, and subsequent items were re-numbered accordingly.


June 9, 2001
Sample Message-ID: <big-eight-faq-993970803$23...@windlord.stanford.edu>

This is "revision 0.34".

Added a sentence to item 5 saying that its previously-final sentence
did not apply to proposals already posted as RFDs, and pointing to
item 8.


November 2, 2001
Sample Message-ID: <big-eight-faq-1007193603$13...@windlord.stanford.edu>

This is "revision 0.35".

Further clarified the second sentence in item 5.

And that brings us to today.

A final note to reward anyone who's read this far.

Greg Woods's guidelines, the document most directly ancestral to the
current process, were by no means universally popular or approved
in the early years. One easy way to see this is to do searches
on the inet distribution: a favourite idea of inet's supporters
was that having trusted individuals (in this case Erik Fair) make
the decisions was the old-fashioned way to do things, whereas the
voting process was just Greg Woods's new-fangled notion. I expect,
still before getting my access cut off, to post further preliminary
results on group creation in 1981 and 1982, which should put paid to
both sides of that argument, but what I want to note here is that
news.announce.newgroups moderators have *normally* not been big
enthusiasts for Greg Woods's process.

Woods left the job of moderating nan four months or so after the
group came into being. His replacement, who had only agreed to
do the job while Woods was on vacation, was Eliot Lear, then the
administrator of the bionet.* hierarchy. In discussions on Lear's
fitness as moderator *and* in discussions of the inet hierarchy,
Lear repeatedly made it clear that he didn't think much of the
voting process he administered.

I don't know tale's opinions as of the time he took over nan.
But as documented above, since no later than 1993, he's been
interested in making major changes to the process. In early 1996
he explicitly said that he considered most of the changes then
under discussion far too conservative.

While I probably shouldn't speak for people now present here,
it *looks* to me like both Russ Allbery and piranha, who are,
if I understand correctly, the two current assistant/active/whatever
moderators for nan, consider the existing process seriously
disfunctional, now if not for the whole of the time they've
respectively been doing that job.

What this means, I'll leave to others.

Joe Bernstein

--
Joe Bernstein, writer <j...@sfbooks.com>
<http://these-survive.postilion.org/newsgroups/history/>

Russ Allbery

unread,
Feb 16, 2002, 3:47:46 PM2/16/02
to
Joe Bernstein <j...@sfbooks.com> writes:

> RUSS ALLBERY, author
> RUSS ALLBERY, reviser

> June 29, 1998
> Sample Message-ID: <m3n2awn...@windlord.Stanford.EDU>

> I'm quite certain that I don't have the entire revision history of this
> document, given that I have only eight versions and we are now on
> "revision 0.35", but here's an account of what I do have. This is, of
> course, the existing (though officially unofficial) process.

revision 0.35
date: 2001/11/02 00:44:12; author: eagle; state: Exp; lines: +7 -6
Include a clarification of the rules for combining or separating proposals
(point 5) avoiding the word bundling, based on language from Jim Riley.
----------------------------
revision 0.34
date: 2001/06/09 12:15:48; author: eagle; state: Exp; lines: +6 -2
Clarify the policy on the bundling of related proposals.
----------------------------
revision 0.33
date: 2000/11/27 03:54:29; author: eagle; state: Exp; lines: +21 -15
Add a point explicitly dealing with munged or invalid addresses, clarifying
that they do not count and explaining that the votetaker will send an
acknowledgement for each vote. State that it's the responsibility of the
voter to investigate the status of their vote.
----------------------------
revision 0.32
date: 2000/02/05 19:21:21; author: eagle; state: Exp; lines: +2 -2
Component length increased to twenty characters for newsgroup names.
----------------------------
revision 0.31
date: 1999/03/28 09:22:23; author: eagle; state: Exp; lines: +6 -3
Modified point 13 to change four months to 120 days and to add a note that
if a proposal goes without an RFD or PQ for 120 days, it is considered
withdrawn.
----------------------------
revision 0.30
date: 1999/03/14 23:55:45; author: eagle; state: Exp; lines: +2 -2
Fixed doubled word in point 10.
----------------------------
revision 0.29
date: 1999/03/14 14:06:28; author: eagle; state: Exp; lines: +20 -2
Added additional posting headers, switched to my header format from
tale's, and included a special note about the status of this document.
----------------------------
revision 0.28
date: 1998/11/27 06:10:11; author: eagle; state: Exp; lines: +1 -1
Fixed the revision date.
----------------------------
revision 0.27
date: 1998/11/27 06:09:11; author: eagle; state: Exp; lines: +7 -7
Added some wording changes and some clarifications from Jim Riley.
----------------------------
revision 0.26
date: 1998/07/18 08:22:33; author: eagle; state: Exp; lines: +15 -9
Reworked the introduction again.
----------------------------
revision 0.25
date: 1998/07/02 06:17:52; author: eagle; state: Exp; lines: +10 -6
Introductory paragraph reworded a bit.
----------------------------
revision 0.24
date: 1998/06/29 07:28:32; author: eagle; state: Exp; lines: +2 -2
Clarified the note about crossposting RFDs to moderated groups slightly.
----------------------------
revision 0.23
date: 1998/06/29 07:22:48; author: eagle; state: Exp; lines: +5 -4
Added a note saying that the CFV is normally posted to the same groups as
the RFD was.
----------------------------
revision 0.22
date: 1998/05/20 15:10:24; author: eagle; state: Exp; lines: +5 -5
Added more changes from Rebecca.
----------------------------
revision 0.21
date: 1998/05/15 06:53:06; author: eagle; state: Exp; lines: +1 -1
Changed punctuation to clarify the issue with psuedonyms.
----------------------------
revision 0.20
date: 1998/05/15 06:50:28; author: eagle; state: Exp; lines: +4 -4
Tweaked the wording of the first rule.
----------------------------
revision 0.19
date: 1998/05/02 06:36:39; author: eagle; state: Exp; lines: +4 -4
Changed the note about the result discussion to indicate that news.groups
is where it takes place.
----------------------------
revision 0.18
date: 1998/04/28 05:54:20; author: eagle; state: Exp; lines: +37 -40
Added in changes from Jeanne.
----------------------------
revision 0.17
date: 1998/04/19 08:31:31; author: eagle; state: Exp; lines: +3 -2
More clarifications.
----------------------------
revision 0.16
date: 1998/04/18 06:27:44; author: eagle; state: Exp; lines: +37 -33
Rewordings and clarifications.
----------------------------
revision 0.15
date: 1998/04/17 01:58:29; author: eagle; state: Exp; lines: +4 -7
Saved a few lines by wording things a bit more succinctly.
----------------------------
revision 0.14
date: 1998/04/16 04:39:35; author: eagle; state: Exp; lines: +53 -55
Added in a bunch of changes from Jim Riley, among others, and reordered
some of the points concerning when RFDs can be rejected.
----------------------------
revision 0.13
date: 1998/04/08 12:05:33; author: eagle; state: Exp; lines: +4 -4
Removal via renaming clarified to be removal via merging with an existing
group.
----------------------------
revision 0.12
date: 1998/04/08 10:40:44; author: eagle; state: Exp; lines: +13 -7
Added mention of additional subjective points, clarified the precedence
rules for overlapping proposals, changed tabled to suspended due to
English meaning, clarified the rules for vote validity, including
explicitly giving votetakers the ability to declare votes invalid due to
actions detrimental to the integrity of the vote.
----------------------------
revision 0.11
date: 1998/04/08 08:24:15; author: eagle; state: Exp; lines: +7 -8
Minor wording tweaks.
----------------------------
revision 0.10
date: 1998/04/08 08:13:54; author: eagle; state: Exp; lines: +11 -10
Tweaks to the wording concerning what groups should be crossposted to at
the RFD stage.
----------------------------
revision 0.9
date: 1998/04/08 07:27:56; author: eagle; state: Exp; lines: +1 -1
Typo fix.
----------------------------
revision 0.8
date: 1998/03/13 07:51:05; author: eagle; state: Exp; lines: +1 -1
Changed the range of what points are subjective.
----------------------------
revision 0.7
date: 1998/03/13 01:52:34; author: eagle; state: Exp; lines: +11 -10
Changed the archive name, added several other wording clarifications and
minor grammatical changes.
----------------------------
revision 0.6
date: 1998/03/12 09:40:35; author: eagle; state: Exp; lines: +1 -1
Updated the last change date.
----------------------------
revision 0.5
date: 1998/03/12 07:52:36; author: eagle; state: Exp; lines: +3 -1
Added mention of the PQ to point 14.
----------------------------
revision 0.4
date: 1998/02/26 07:32:05; author: eagle; state: Exp; lines: +2 -2
Missed a qualification that only applies to the first CFV.
----------------------------
revision 0.3
date: 1998/02/26 05:16:28; author: eagle; state: Exp; lines: +100 -85
Incorporated many, many changes from David Lawrence, Jonathan Grobe, Kate
Wrightson, and numerous others.
----------------------------
revision 0.2
date: 1998/02/25 10:55:15; author: eagle; state: Exp; lines: +3 -3
Typos.
----------------------------
revision 0.1
date: 1998/02/25 10:49:20; author: eagle; state: Exp;
*** empty log message ***

--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>

Joe Bernstein

unread,
Feb 17, 2002, 2:24:02 AM2/17/02
to
Russ Allbery <r...@stanford.edu> wrote in message
news:<yleljln...@windlord.stanford.edu>...

> Joe Bernstein <j...@sfbooks.com> writes:

> > I'm quite certain that I don't have the entire revision history of this
> > document, given that I have only eight versions and we are now on
> > "revision 0.35", but here's an account of what I do have. This is, of
> > course, the existing (though officially unofficial) process.

> revision 0.35
> date: 2001/11/02 00:44:12; author: eagle; state: Exp; lines: +7 -6
> Include a clarification of the rules for combining or separating proposals
> (point 5) avoiding the word bundling, based on language from Jim Riley.

etc.

Thanks!

As I noted, I did only quick searches. I didn't even stop to think,
to tell the truth, or I'd have remembered that the rather anemic
thread following the June 1998 draft hadn't been the first public
discussion. It had been my goal to finish that post by mid-morning,
some hours earlier than I actually did; stopping to think would not
have sped things up ;-).

So I apologise for implying anything untrue.

Regardless, thanks for the additional info. I'd like to toss it onto
the website to sit next to my own document (which I probably won't
update at this time but may later); do you object?

(Earlier drafts will probably *not* go onto the website anytime soon;
while I assume I can find them, I have other things still to do and
the hours are getting shorter. I'm still unsure how much more of the
other stuff I've collected I can upload tonight.)

Russ Allbery

unread,
Feb 17, 2002, 3:05:02 AM2/17/02
to
Joe Bernstein <j...@sfbooks.com> writes:

> So I apologise for implying anything untrue.

Oh, no, it was fine. I just figured I'd help. :)

> Regardless, thanks for the additional info. I'd like to toss it onto
> the website to sit next to my own document (which I probably won't
> update at this time but may later); do you object?

No objections at all.

> (Earlier drafts will probably *not* go onto the website anytime soon;
> while I assume I can find them, I have other things still to do and
> the hours are getting shorter. I'm still unsure how much more of the
> other stuff I've collected I can upload tonight.)

Let me know if you want the old versions; my notes on what I changed are
sometimes anemic while I was still in the original writing phase.

David C. DiNucci

unread,
Feb 17, 2002, 3:29:26 AM2/17/02
to
Russ Allbery wrote:
>
> Joe Bernstein <j...@sfbooks.com> writes:
>
> > So I apologise for implying anything untrue.
>
> Oh, no, it was fine. I just figured I'd help. :)

Thanks to both of you for this. Very concise and illuminating.

-Dave
-----------------------------------------------------------------
David C. DiNucci Elepar Tools for portable grid,
da...@elepar.com http://www.elepar.com parallel, distributed, &
503-439-9431 Beaverton, OR 97006 peer-to-peer computing

Jim Riley

unread,
Feb 28, 2002, 8:36:18 PM2/28/02
to
On 16 Feb 2002 11:59:24 -0800, j...@sfbooks.com (Joe Bernstein) wrote:

>This is a preliminary revision history of the guidelines for newsgroup
>creation in the Big Seven and Big Eight hierarchies.

<snip>

>October 31, 1987

Some precursors.

November 30, 1981 mhuxa!presley
Message ID: <anews.Amhuxa.314>

I personally prefer the specialized groups. While we're discussing
this subject, I'd like to see a method established to name a new
newsgroup (if there is one, already, ignore the rest of this
message).

If someone wants to start a new newsgroup, he should announce
his intentions over net.news or net.general, suggesting a name.
If there are no complaints after a decent interval (2-3 days?),
that's that. It's possible that someone would come up with a
better name or point out that such a group already exists with
a different name.

December 1, 1981 Mark Horton
Message-ID: <anews.Acbosgd.161>

Confirms that the method of naming is indeed that as suggested.
He also goes on to say that after actual use if it becomes clear that
the name is not appropriate, change it - with the caveat that sites
will have to update their ngfile and may miss a few days of traffic.
He also says that the idea of hierarchies is worth further
consideration, remembering that the whole name must fit be significant
in 13 characters.

December 11, 1981 utzoo!decvax!pur-ee!davy
Message-ID: <anews.Apur-ee.179>

A complaint about the presence of net.mc, net.cycle, and
net.motorcycle. The first two claim to be offical.

December 25, 1981 Matt Glickman
Message-ID: <anews.Aucbarpa.582>

In a message with the subject of 'Dictator'

Does anybody contest that we need some sort of central standardizing
(for want of a better werrd) body? Personally, I don't even have
entirely too much objection to a dictator.

There was much discussion around this time about whether to have some
sort of committee; whether additional "classes" other than 'net'
should be created, such as 'ug' for underground, or 'pers' for
personal.

January 5, 1982 Andrew Knutsen
Message-ID <anews.Asri-unix.429>

In a discussion about Usenet policies, quoting from an earlier post he
had made.

Some suggestions:
Make it easier to flush a newsgroup.
Create methods of merging/dividing existing groups.
Let old unused groups die naturally (automatically).
Have a way to let a question-asker moderate his question, by
collecting answers and reporting back.
Make it easier to find an appropriate group (like "apropos"... this
probably involves keeping a directory with descriptions).
Implement some voting scheme for answering questions (like "should
this group be flushed/created?").

December 20, 1984 Gene Spafford
Message Id: <11...@gatech.UUCP>

In response to a proposal for a Music Synthesis news group, it is
a complaint about "votes" being posted rather than mailed, the
discussion not occuring in net.news.group, and a question whether
there was enought discussion to support creation of the group.
A standard of 20 to 30 positive responses is suggested as being
conventional.


February 10, 1985 Gene Spafford
Message Id: <11...@gatech.UUCP>

A response to an announcement that net.music.gs (Gilbert&Sullivan) had
been created. Spafford explains that conventions for creation had not
been followed (rationale posted to net.news.group; 20 to 30 postive
responses and no significant negative response), and that he would not
be adding the group to the list of active newsgroups, and would issue
a rmgroup if the group appeared at his site.

October 21, 1985 Gene Spafford
Message Id: <16...@gatech.CSNET>

This was in response to the creation of net.bizarre and net.internat.

The lead paragraph states:

We have some problems about creating new groups. Specifically,
people don't seem to be inclined to follow the established
procedures for creating new groups. If this is due to the fact that
people don't agree with those procedures, then we need to discuss
changing them.

The next section outlines the current process: (1) show an interest in
a topic, either via a mailing list, or a volume of discussion within
an existing newsgroup; (2) hold discussion in net.news.group as well
as groups related to proposal. Consider need, charter, name, etc;
(3) Objections, suggestions, comments should be addressed, and
consensus reached; (4) Vote taken, with 40 to 50 more Yes votes than
No votes (and ideally more than 100) resulting in creation.

He next suggests some reason for not creating new groups. New groups
may suggest to other people that there is a need for similar new
groups, causing discussion to become too fragmented. In addition
there was no established procedure for removing unused groups.

He argues that the creation of net.bizarre and net.internat had not
followed established procedure - and that perhaps new procedures for
determining which groups are created should be devised. He concludes
with:

Until some new procedures are established, I will continue to
maintain the list of groups by the established procedure. That means
that groups created outside the procedures get "rmgrouped", without
regard to subjective "value," as the only thing "fair" to everyone.

This message along with follow-on discussion seems to emphasize that
the conventions are primarily for better organizing existing traffic
(e.g. demonstrate that there is traffic in an existing group that
could be split out, and that participants want it split), rather than
creating new groups that might be of interest.

Follow-on discussion suggests a number of alternatives: trial groups;
measuring readership from newsrc files that could be polled
network-wide; letting anyone cancel messages; removing the middles of
long articles. There is also some discussion about whether moderated
newsgroups are/should be subject to the same guidelines.

Nov 9, 1985 Thomas Cox
Message Id: <13...@sphinx.UChicago.UUCP>

This is a summary of various ideas titled "Rules for USENET". One
suggestion is to base which groups are carried based on readership (as
determined from newsrc files).

November 9, 1985 Greg Skinner
Message Id: <3...@mit-eddie.UUCP>

This message notes that the group creation/removal process is not
documented anywhere, and concludes with:

I think the next version of net.announce.newusers should contain the
rules for creating/deleting groups. What do you think, Gene?

November 21, 1985 Chris Lewis
Message Id: <26...@mnetor.UUCP>

A suggestion that inews be modified to accept newgroup messages only
from specific individuals (e.g. Spaf)

A followup <32...@lanl.ARPA> suggests that some sort of trial
mechanism be used to determine if a group should be created or
maintained.

March 2, 1986 Curtis Jackson
Message ID: <10...@burl.UUCP>

This message is entitled "proposed 'standard' for creating new groups"
and outlines a stepwise procedure that is somewhat similar to the
current process - thought it begins with the CFV. It does not specify
specific values for number of responses and percentage of Yes votes to
create a group. Instead, it would that the proponent's news admin
post a message to net.news.group with the result indicating that the
group would be created in X days unless people complain. This would
get "the opinion of concerned net citizens on whether your estimation
that there *is* enough interest to create the group is valid or not in
their eyes."

March 9, 1986 G A Moffett
Message ID: <28...@amdahl.UUCP>

This prosposed that a rule be established requiring a 2/3 majority to
remove a group. This was right after a vote on removal of
net.general. There was quite a bit of comments that the question was
confusing (e.g. Yes remove, No keep it)

Sep 25, 1986 Greg Woods
Message ID: <2...@hao.UUCP>

In a discussion about the Great Renaming, it is suggested that it will
make it simpler to create new groups, since there will be less concern
about creating new groups that use to much resources. In addition the
presence of ".misc" groups would make it easier to remove groups since
there would be a place for the traffic to go.

But hopefully the second phase of reorganization (after the renaming
of groups) will involve the setting of better-defined criteria for
whether a new group should be created, and for the first time,
setting criteria for deleting existing groups. This means that
existing groups will have to have enough traffic to justify their
continuation, which has never really been true in the past.

A followup suggested that there might now be naming battles based on
which hierarchy a group was placed in.

<snip>

Had it

--
Jim Riley

Jim Riley

unread,
Mar 3, 2002, 5:34:40 PM3/3/02
to
On 16 Feb 2002 11:59:24 -0800, j...@sfbooks.com (Joe Bernstein) wrote:

>This is a preliminary revision history of the guidelines for newsgroup
>creation in the Big Seven and Big Eight hierarchies.

<snip>

>October 31, 1987

Some precursors.

The lead paragraph states:

<snip>

>Sample Message-ID: <21...@arthur.cs.purdue.edu>

Had it

--
Jim Riley

Joe Bernstein

unread,
Mar 4, 2002, 8:59:59 PM3/4/02
to
In article <a5u8jm$3dt$2...@slb4.atl.mindspring.net>, Jim Riley
<jim...@pipeline.com> wrote:

> On 16 Feb 2002 11:59:24 -0800, j...@sfbooks.com (Joe Bernstein) wrote:
>
> >This is a preliminary revision history of the guidelines for newsgroup
> >creation in the Big Seven and Big Eight hierarchies.
>
> <snip>
>
> >October 31, 1987
>
> Some precursors.

Many thanks. I'd seen fewer of these articles than I would have
expected. Do you mind if I put this compilation into the buncha
stuff on the web site?

[long snip]

> Had it

[extremely long snip of quoted material]

Um. I'm sorry if it was too long for you. But if it's any comfort,
I paged through all the material you quoted looking for original
text - partly from hope, partly because trn has a way of insisting
that I do so if I just hit "n"... So it can be done, even on a slow
library telnet.

Anyway, thanks for the contribution. I'll see if time allows me to
comment on any of the posts you put together later this week.

0 new messages