home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: news.admin.policy
- Path: sparky!uunet!scifi!watson!Watson.Ibm.Com!strom
- From: strom@Watson.Ibm.Com (Rob Strom)
- Subject: Re: Newsgroup creation guidelines
- Sender: @watson.ibm.com
- Message-ID: <1992Dec22.174745.56455@watson.ibm.com>
- Date: Tue, 22 Dec 92 17:47:45 GMT
- References: <1h629qINNp3r@gaia.ucs.orst.edu>
- Organization: IBM Research
- Lines: 328
-
- 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
-