🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: news.admin.policy
Article #92

Newsgroup creation guidelines (was Re: Folklore, synth, and guidelines)

#92
From: Rob Strom
Date: Tue, 15 Dec 1992 20:00
113 lines
5665 bytes
In article <JAAPJL.92Dec14104856@cmb00.larc.nasa.gov>, jaapjl@tab00.larc.nasa.gov (J Lee Jaap) writes:
|> In article <1992Dec14.125756.7888@jato.jpl.nasa.gov> dave@jato.jpl.nasa.gov (Dave Hayes) writes:
|> 
|>    What's wrong with trying to equalize the awareness levels of the 
|>    other "ignorant and therefore vulnerable" newsgroups? Or to fight
|>    for their sake?
|> 
|> Well, do it.  Talk is so much hot air.

Well, I made a proposal.  I tried to post it on
December 1, but I never saw it appear, so I will
assume it got lost.  I apologize if you have seen
it before.  It is based on previous ideas I had
expressed on news.groups during the rec.music.synth post-vote
"discussion".

My proposal tries to amend the guidelines to avoid
a recurrence of what happened with rec.music.synth.

It is *not* an attempt to undo the rec.music.synth
vote, or to argue over whether the result was good
or bad, or if bad, who's to blame.

Here it is:

==========
I agree that the document written by Mr. Stanley correctly
documents the newsgroup voting procedures currently in effect,
but I think these procedures are flawed.  They contradict
at least the spirit of the guidelines on Subject lines,
which I have posted before.  [on news.groups]

The published guidelines on
Subject lines imply that people reading news have a limited
amount of time, and are justified in skipping over articles
whose subject lines don't indicate relevance.  

These guidelines say:

  The subject line of an article is there to enable a person with a limited
  amount of time to decide whether or not to read your article.  Tell people
  what the article is about before they read it.  A title like "Car for
  Sale" to rec.autos does not help as much as "66 MG Midget for sale:
  Beaverton OR." Don't expect people to read your article to find out what
  it is about because many of them won't bother.  Some sites truncate the
  length of the subject line to 40 characters so keep your subjects short
  and to the point.

I agree with
these guidelines, and disagree with the exceptional treatment
of CFVs and RFDs shown in this passage from Mr. Stanley's guidelines:

	  This is important: IF you care about the process of USENET (as
  opposed to just "I want to read about X"), then READ THE RFD when it
  comes by. Do NOT decide whether to read it based on the Subject line.
  If there is a list of proposals, read the entire list. Only then should
  you decide whether or not you are interested in this RFD.

My suggestions affect: (1) limitations on bundling votes onto a single
ballot, and (2) labelling of ballots.

\begin{suggestion}
(1)
If you are proposing a reorganization of multiple groups, you presumably
believe the groups you are putting under a single node are related.
For example, you may believe that talk.origins should be renamed to
sci.biology.evolution.  But if you are reorganizing the sci.biology.*
hierarchy and describe your reorganization as such, readers of talk.origins
who don't read sci.biology and who may not think their newsgroup is
a subset of a science group may be confused.  They may even not read
your CFV or RFD, since to them it will appear to be about a group
they have no interest in.

Multiple changes should only be placed on a single ballot if no more than
a single existing group or hierarchy of groups is directly affected by the
change.  A group is directly affected by the change if a successful
"yes" vote would change the name or the charter of that group.

For example, to split rec.ham-radio into three new groups, named
rec.radio.amateur.policy, rec.radio.cb, and rec.radio.amateur.misc,
you may use a single ballot, since only the group rec.ham-radio is
directly affected.

You could also propose to rename rec.ham-radio.packet to rec.radio.amateur.packet
on the same ballot, since rec.ham-radio.packet is in the same hierarchy
as rec.ham-radio.

But if you wanted to also rename rec.truckers to rec.radio.cb.truckers,
that would have to be on a different ballot, no matter how relevant
you personally thought rec.truckers was to the rec.radio.cb hierarchy.
This is because rec.truckers is currently in a different hierarchy from
rec.ham-radio.

(2)
The RFDs and CFVs for name changes and reorganizations should
be clearly labelled in the Subject line with the acronym RFD
or CFD and the name of the newsgroup or newsgroup hierarchy
which would be directly affected by the proposed change.

For example:  Subject: RFD: rec.ham-radio.* reorganization

As a reader of news, you should be alert to RFD or CFV
messages which mention newsgroups or newsgroup hierarchies
which you read.  If the reorganization votes pass, these
groups may get new names.   There will be a transition period
when some articles will appear in the old newsgroup and others
in the new newsgroup, since some site administrators will not
merge or alias the old and new newsgroups. 
\end{suggestion}

-- 
Rob Strom, strom@watson.ibm.com, (914) 784-7641
IBM Research, 30 Saw Mill River Road, P.O. Box 704, Yorktown Heights, NY  10598
Technical Details
Message-ID: <1992Dec15.200011.18509@watson.ibm.com>
Path: arc1-ca.pugleaf.net!sparky!uunet!newsgate.watson.ibm.com!yktnews!admin!watson!Watson.Ibm.Com!strom
References: <Bz4G3p.6v7@rice.edu> <1992Dec14.125756.7888@jato.jpl.nasa.gov> <JAAPJL.92Dec14104856@cmb00.larc.nasa.gov>

Show Full Headers
Complete Article Headers
Newsgroups: news.admin.policy
Path: arc1-ca.pugleaf.net!sparky!uunet!newsgate.watson.ibm.com!yktnews!admin!watson!Watson.Ibm.Com!strom
From: strom@Watson.Ibm.Com (Rob Strom)
Subject: Newsgroup creation guidelines (was Re: Folklore, synth, and guidelines)
Sender: @watson.ibm.com
Message-ID: <1992Dec15.200011.18509@watson.ibm.com>
Date: Tue, 15 Dec 92 20:00:11 GMT
References: <Bz4G3p.6v7@rice.edu> <1992Dec14.125756.7888@jato.jpl.nasa.gov> <JAAPJL.92Dec14104856@cmb00.larc.nasa.gov>
Organization: IBM Research
Lines: 113