🚀 go-pugleaf

According to stanley@skyking.OCE.ORST.EDU (John Stanley):
>According to strom@Watson.Ibm.Com (Rob Strom):
>>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.

As a side point: this assertion is not correct.  Recall the renaming
of comp.unix.sysv386 to comp.unix.pc-clone.32bit: the group's charter
changed, expanding to cover all UNIX variants for 32-bit PC clones.

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

True but irrelevant.  Existing readership is completely covered with
one notice: "Proposed change in a.b.*".

>And they will still argue ad-infinitum about whether the reorganization
>is a logical one. Your proposal will do absolutely nothing about that.

Quite definitely true, and a point to remember.

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

Right.  The first comp.unix.* reorg proved that point beyond doubt.
-- 
Chip Salzenberg at Teltronics/TCT  <chip@tct.com>, <73717.366@compuserve.com>
  "you make me want to break the laws of time and space / you make me
   want to eat pork / you make me want to staple bagles to my face /
   and remove them with a pitchfork" -- Weird Al Yankovic, "You Make Me"

In article <1h629qINNp3r@gaia.ucs.orst.edu>, stanley@skyking.OCE.ORST.EDU (John Stanley) writes:
|> 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. 
|> 

I haven't tried to educate others yet as to what the policies are.

I was simply trying to point out that when I come to work, I
can only spend a little time reading and responding to posts.
If I spent any more, my productivity would be affected and
my managers and co-workers would complain.

So I'm going to use all kinds of shortcuts to reduce the
amount of material I read.

For example, at this very moment I don't read news.admin.policy
*except for this one thread*.  If you responded to me and
changed the Subject line even by one character, the chances are 
excellent that I just wouldn't see your response at all.

I don't read news.announce.newgroups at all.  And if
I saw a header in comp.lang.misc which said "RFD: comp.unix* reorg*"
there is still a good chance I would not scan the article in
detail to see if the "comp.unix* reorg" possibly might
rename comp.lang.misc.  I didn't say I *believe* these RFD's
are irrelevant.  Read my posting again.  I said I *treat*
them as irrelevant.  I spend too much time as it is reading
and posting news, and one of the ways I cut down is to
only read items whose subject lines are appropriately
compelling.  That only-proprieties-and-not-a-guideline
document in news.announce.newusers accurately describes
my attitude towards selectivity in reading news, and
the use of subject lines to help me become efficiently selective.

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

We still haven't communicated.  I am not suggesting to change
policies because people don't bother to find out about them.
I obviously have found out, both by experience, and by
reading your Users Guide, that the policy is that anything
with the word RFD in the subject line might be a proposal
to rename the group you're reading even though the subject line mentions
a totally different group.  *I know this*!!!!  I'm not trying
to deal with the fact that some folks don't know this.
I'm trying to deal with the fact that IMHO it's a bad policy, because
it forces people to read RFD's and CFV's that they otherwise
wouldn't have to read if the subject lines were more precise.

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

This isn't worth debating.  All I meant was that both your Users Guide
and the guidelines have statements of the form "You should do <X>;
If you don't do <X>, then <this thing you don't like> will happen".

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

If rec.scouting is split into rec.scouting and rec.scouting.policy,
then discussions of scouting policy, currently permitted in rec.scouting,
will no longer be welcome in rec.scouting.  Posters who post
policy discussions in rec.scouting will be told to move them. (To simplify the
discussion, I'm assuming that the creation of rec.scouting.policy
succeeds and the rename of rec.scouting to rec.scouting.misc fails.
By the time you read this, the vote will be over, and my example
will be obsolete.)

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

In my proposal, I am concerned only about the effect on the
a.b.c newsgroup, not the other two effects.

I am assuming that a reader of the a.b.c newsgroup will have
to physically change his/her subscription list to avoid being cut off
from accustomed news.  I consider that a major effect.

The other effects are more subtle: readers of other groups
in the a.b hierarchy, such as a.b.d, suddenly discover they've
lost a sister newsgroup; readers of other groups in the a.d
hierarchy suddenly discover they've gained a sister newsgroup.
There may be psychological consequences to this, but they're
not as immediate as the other effect.  There are also effects
on future readers who are not currently voting when they
try to find the name of a group which matches a topic they're
interested in.  I'm treating these non-physical effects
as less important than the physical one.


|> 
|> >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.
|> 
Are you telling me that if I post an RFD to news.announce.new(s)groups
and crosspost it to other groups, it doesn't appear in
the other groups until the moderator of n.a.n passes it?

This I'm going to try, using ny.test.

|> >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?
|> 
Sorry for speaking over-elliptically.  I meant
irrelevant-to-the-reader, as opposed to officially-deemed-relevant.

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

Same thing.  I meant that readers are more likely to know whether
an RFD for a name change is relevant-to-the-reader if the newsgroup name 
or hierarchy name in the subject line specifies which group(s) are 
affected-in-my-specialized-sense by the name change.

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

I had assumed that the charter of rec.scouting.misc would
exclude policy discussions if rec.scouting.policy is also
created.  That is certainly what the proposers of the split
intend to happen.

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

The context was my proposed guidelines.  If they went into effect,
if you rename rec.truckers and rec.ham-radio, then either the
changes go on separate ballots, or the ballot would have to
be called a rec.* reorg.  I viewed the second alternative as
absurd, so my first posting listed the first as the only possibility.

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

I'll change the example.  The reason I used this example is that
earlier when this was being discussed on news.groups, the original
proponent of the rec.ham-radio reorg asked how I would have handled
that change had my proposed-guidelines been the guidelines at the
time of that reorg.  I used this as a motivating example since
it actually came up.

|> >|> 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". 
|> 
They can be done all at once with two ballots.

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

It's one thing to say that there's no excuse for not reading
the new-user information.  It's another thing to say that
there's no excuse for not reading a CFV with a misleading label.
I agree that everyone should read the new-user information.
But I disagree that everyone should read every RFD or CFV,
as the guidelines currently require them to.
My whole premise here is to allow people to skip more
postings while still seeing the ones they need to see.

|> >|> >(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.
|> 
Yes, the example is obsolete.  It doesn't matter.  You can treat
these names as meaningless charstrings if you like.

No, my proposed-guidelines do not require rec.radio.* to be mentioned,
because no newsgroup in rec.radio.* has its name or charter changed
by the reorganization.

...
|> 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.
|> 
No.  Not unless there are postings formerly welcome in rec.radio.foobar
which are no longer welcome in rec.radio.foobar after the reorg.

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

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

The users guide currently tells readers that if they see an RFD posted
in a newsgroup they read, they should read that RFD regardless of
what the subject line says.  If my changed policy were to go into
effect, the users guide would explain to readers that groups named
in the RFD might get new names and that certain topics formerly
permitted to be posted to some of these groups will be removed or
moved elsewhere.


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

According to strom@Watson.Ibm.Com (Rob Strom):
>According to stanley@skyking.OCE.ORST.EDU (John Stanley):
>>Telling pople what is polite or good is not the same as telling them
>>what they must do.
>
>This isn't worth debating.  All I meant was that both your Users Guide
>and the guidelines have statements of the form "You should do <X>;
>If you don't do <X>, then <this thing you don't like> will happen".

Has it ever occured to you that the person who puts up a sign

    BEWARE OF FALLING ROCKS

may _not_ be responsible for the fact that the rocks fall?
-- 
Chip Salzenberg at Teltronics/TCT  <chip@tct.com>, <73717.366@compuserve.com>
  "you make me want to break the laws of time and space / you make me
   want to eat pork / you make me want to staple bagels to my face /
   and remove them with a pitchfork" -- Weird Al Yankovic, "You Make Me"