🚀 go-pugleaf

In article <1992Dec21.225351.18200@watson.ibm.com> strom@Watson.Ibm.Com (Rob Strom) writes:
>In article <1glu0dINNmc5@gaia.ucs.orst.edu>, stanley@ruby.OCE.ORST.EDU (John Stanley) writes:
 
>|> 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.  

That you still treat them as irrelevant only proves that you can't
provide enough information to some people to educate them as to what the
policies are. Your claims are contradictory -- you say that you accept
that the User's Guide reflects cuurent policy (which implies that you
have read and understood it), but you also claim to continue to believe
that RFD posted to groups you read are irrelevant. 

>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.

Changing policies because people don't bother to find out about them
will lead to a never ending cycle of changes, for there will always be
people who don't bother to find out how things work  no matter how
things work.

>|> 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.

Then you do not understand the difference. As Chip has pointed out,
telling pople what is polite or good is not the same as telling them
what they must do.

>I didn't try to stuff every piece of information into the Subject line.

If the current process is bad because this one particular piece of
information is missing, then it is bad because other pieces are missing.
On the other hand, you can accept that Subjects are not meant to convey
every piece of information. 

>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.

First, I will tell you again, charters are not changed.

Second, there is more than one piece of information you want included.
Renaming a.b.c to a.d.e affects both the a.b hierarchy and the a.d
hierarchy, as well as the a.b.c newsgroup. I count three things that
need to be in the Subject.

>As far as I know, anyone may post an RFD, and there are

Of course, anyone may POST one. There is only ONE moderator of
news.announce.newsgroups, however, and thus each and every RFD is
required to pass through him. He has yet to pass on frivolous RFD (with
one exception), so claiming since anyone can post one that newsgorups
are flooded with irrelevant RFD is foolish. There is a gate to prevent
such occurances.

>no constraints on how widely they may be crossposted.

The moderator of news.announce.newgroups is a constraint.

>The more frequently readers find irrelevant RFDs, the

I thought you accepted that the presence of an RFD in a newsgroup meant
it was relevant. This is the cuurent policy that you want to change,
remember?

>more likely they are to ignore future ones.  My syntactic
>criterion is a way to increase the likelihood that
>Subject lines match content.

As long as an RFD contains an RFD and a CFV contains a CFV, then subject
matches content, problem solved.

>Sometimes charters are changed.  For example, if rec.scouting

Present an example of a charter ever being changed by a vote. Provide
both the pre-vote and post-vote charter. Save your time, there hasn't
been one.

>|> 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".

Which ficticious quidelines are you now using to claim that reorganizing
rec.ham-radio should have been called rec.* reorg? There ain't no such
rule. It could have quite properly been called rec.ham-radio reorg. As
it was, I believe it was called "rec.radio.* reorg...", and that nobody
whined about the fact that the Subject  didn't have rec.ham-radio in
it.

I didn't notice whether you caught the comment: rec.ham-radio is an
obsolete group. Don't use that as an example group in your proposal for
the guidelines.

>|> 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. 

Like I said, "all at once". 

> 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.  

And they will still argue ad-infinitum about whether the reorganization
is a logical one. Your proposal will do absolutely nothing about that.
The only thing your proposal would reduce is the number of people who
whine about missing a vote because they  chose not to read the CFV, and
even then it won't fix that problem because people will STILL choose not
to read things.

>|> >(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.  

Good try, but I'm not going to go for it. You nicely avoided answering
the problem that your example is 1) obsolete, and 2) incorrect. To meet
the requirement you are proposing, the Subject, using the same obsolete
groups you continue to use, would have to be:

Subject: RFD rec.ham-radio reorganization and rec.radio.* reorganization.

That is more than the 40 characters that the "guidelines" specify.

>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.

If, as you claimed earlier, splitting a group changes the charter of the
remaining one, then moving another group into a hierarchy changes the
charter of every other group in the hierarchy.

Thus, every group in rec.radio.* would be affected in exactly the sense
you define affected to be.

Uhhh, what was that comment about "syntactic specification that both yes
and no voter could agree on"? Your own example doesn't agree with your
rule.

>|> 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.

If policy changes, I will update the User's Guide, in spite of your
instructions to do so. I don't see that your proposed changes would
require any changes, however.