🚀 go-pugleaf

In article <1glu0dINNmc5@gaia.ucs.orst.edu>, stanley@ruby.OCE.ORST.EDU (John Stanley) writes:
|> In article <1992Dec15.200011.18509@watson.ibm.com> strom@Watson.Ibm.Com (Rob Strom) writes:
|> >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]
|> 
|> And, as I have posted before, the guidelines do not specify anything
|> about the Subject line.
|> 

OK.  We've had an exchange of postings in which I concede
I was using the word "guidelines" loosely.  I meant the
new users' documentation on postings in general.

|> >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.  
|> 
|> The fact that an RFD/CFV was posted to a group implies relevance, no
|> matter what the rest of the Subject line contains. The three characters
|> RFD or CFV indicate the relevance.
|> 

I agree that this is what is the policy today.  That's whu I
want to change it.  I think many people (including myself)
treat RFD for what looks like a group they don't read
as irrelevant despite what you say above.  So either
we can change people's habits to reflect current policies
or change current policies to reflect the habits, and
I'm proposing to do the latter.


|> 
|> >I agree with
|> >these guidelines, and disagree with the exceptional treatment
|> >of CFVs and RFDs shown in this passage from Mr. Stanley's guidelines:
|> 
|> I have written no guidelines. I wrote a descriptive document, not a
|> proscriptive one.
|> 

I'm not convinced there's such a clear line.  If you say
"Ignore RFDs at your peril no matter what the rest of the
Subject line says", that has a prescriptive
flavor to it.

|> >	  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.
|> 
|> The "exceptional treatment" I give RFD's is hardly that. It is a
|> statement of reality. 
|> 
|> The relevance of the article is indicated by the RFD or CFV in the
|> Subject. A fact of life is that not every piece of information about a
|> proposal can be stuffed into the Subject line. If it could, then there
|> would be no need for the body of the article. 
|> 

I didn't try to stuff every piece of information into the Subject line.
I simply proposed that one particular piece of information be
inserted into the Subject line:  the name of the group or hierarchy
whose names and/or charters may be changed by the vote.

|> People certainly are justified in skipping the article, but they will
|> be skipping an article despite it being relevant. The relevance is
|> proven by it showing up in the group. Unlike almost all other postings,
|> RFD and CFV are posted by someone who knows what is going on and takes
|> an active interest in making sure the right groups are included.
|> 

As far as I know, anyone may post an RFD, and there are
no constraints on how widely they may be crossposted.

The more frequently readers find irrelevant RFDs, the
more likely they are to ignore future ones.  My syntactic
criterion is a way to increase the likelihood that
Subject lines match content.

|> >\begin{suggestion}
|> >(1)
|> >change.  A group is directly affected by the change if a successful
|> >"yes" vote would change the name or the charter of that group.
|> 
|> Charters for groups are not changed, names are.
|> 

Sometimes charters are changed.  For example, if rec.scouting
is split and rec.scouting.policy is created, and rec.scouting.misc
is not created, it will no longer be allowed to post policy
discussions in rec.scouting; hence the charter of rec.scouting will have changed
to narrow the permissible set of topics for the newsgroup.

|> >For example, to split rec.ham-radio into three new groups, named
|> 
|> rec.ham-radio is a obsolete group.
|> 
|> >This is because rec.truckers is currently in a different hierarchy from
|> >rec.ham-radio.
|> 
|> No, both are in rec. Rec.truckers, as a group, is in the same hierarchy
|> as the group rec.ham-radio.

You're right.  But then it couldn't be called any longer
"rec.ham-radio* reorg".  It would have to be called "rec.* reorg".
This is impractical (you'd have to notify all of rec.*, which
is much too broad).  It's better to have two separate
renamings, one for rec.truckers, and one for rec.ham-radio*.

|> 
|> Note that none of my comments so far have been on the desirability of
|> the change, only technical details of the wording. Fix those and maybe
|> it will have some merit. Perhaps using generic "a.b.c" group names
|> instead of obsolete ones will help.
|> 
|> The only problem with this is that it will not permit logical
|> reorganizations to occur all at once, for anything that attempts to pull
|> groups from more than one hierarchy on the net and put them into a new
|> one that covers them all can't be done.
|> 

They can be done, but they can't be done in one ballot.  I
think this is a good thing, because people will argue
ad infinitum on whether a particular reorganization is
"logical".  But in my proposal, whether a vote is well-labelled
or not is a purely syntactic question which both 'yes' voters
and 'no' voters can agree on.  

|> >(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
|> 
|> Problem: there are two hierarchies affected by this change.
|> rec.ham-radio and rec.radio.*. Are both to be included? If not, how
|> are the readers of the destination hierarchy to know that the RFD
|> applies to them? (Barring, of course, that it would be posted in their
|> groups.)
|> 
|> And, technically, splitting rec.ham-radio is not a reorganization of
|> rec.ham-radio.*.

Yes; the dot before the star should be deleted.  

As to your earlier question, I have defined "affected" so that
only the groups whose names/charters are changed are affected.
Rec.radio.* is not affected since the effect is less; a reader
of rec.radio.foobar may have different sister groups in the
rec.radio.* hierarchy, but the name or charter hasn't changed.

|> 
|> >As a reader of news, 
|> 
|> The guidelines are not designed to be read by Joe News User, they are
|> designed for Joe New Newsgroup Proposer. Comments to the generic reader
|> population should be in a different document, just to prevent the 
|> possibility of valid charges that news users must read the guidelines to
|> understand USENET. They don't now, and they shouldn't have to in the
|> future.

I agree.  We need two documents.

|> 
|> >you should be alert to RFD or CFV
|> >messages which mention newsgroups or newsgroup hierarchies
|> >which you read.  
|> 
|> As a reader of news, you should be alert to ANY RFD or CFV posted to
|> groups you read, for the fact that they are there means that someone
|> thinks you ought to know, and one of those someones is the moderator of
|> news.announce.newgroups.
|> 
|> This, of course, was in the User's Guide.

Yes, the User's Guide reflects current policy.  If I succeed
in changing current policy, the User's Guide should be updated
to be consistent with the new policy.


-- 
Rob Strom, strom@watson.ibm.com, (914) 784-7641
IBM Research, 30 Saw Mill River Road, P.O. Box 704, Yorktown Heights, NY  10598