Xref: utzoo news.groups:18490 comp.sys.mac:50080 Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!sunic!dkuug!freja.diku.dk!stodol From: stodol@diku.dk (David Stodolsky) Newsgroups: news.groups,comp.sys.mac Subject: Do not reorganize comp.sys.mac.* Keywords: multiple creation renaming crossposting Message-ID: <1990Mar7.195114.1077@diku.dk> Date: 7 Mar 90 19:51:14 GMT Organization: Department Of Computer Science, University Of Copenhagen Lines: 96 chuq@Apple.COM (Chuq Von Rospach) in Message-ID: <39146@apple.Apple.COM> writes: If you feel that a name is not appropriate, rank it with 'NA'. If you have no preferences, don't rank the work. Here's how I'll count this: the name ranked 1 will get 5 points, 2nd three, third two and fourth 1. Names not mentioned (no preference) will get zero. Names marked 'NA' will get minus 2 (-2). This is not one of methods previously proposed or used for selection on Usenet. And there is no evidence that it does a good job or works fairly. In Message-ID: <77475@tut.cis.ohio-state.edu> RD Francis said: >If we were to issue this proposal one >request at a time (thank goodness we won't be, but for the sake of >argument...) I guess my question is would there be an incentive to get >these groups created. There are no guidelines for creating more than one group at a time (this was pointed out to me strongly, see enclosed below), and none for renaming. It is very hard to predict the outcome of multiple changes. The most needed new group should be created. After a few months of heavy cross-posting the actual character of the new group, and thereby, the remainder of c.s.m, will become obvious. Then further changes can be considered. Each renaming results in some newsreaders and mailing lists going out of action. No group should be renamed just to "fit" logically. If absolutely necessary a new group can be created. After people stop using the old one, it can die a peaceful death. This proposed process for restructuring puts too much power in the hands the organizer. It becomes almost impossible for the bad aspects of a big proposal to be eliminated by others. Any deviation from accepted guidelines leads to loss of distribution. The comp.groupware vote showed that even minor deviations (i. e., the use of preferential voting) can lead to substantial reductions. It would be foolish to damage the Mac groups this way. ------------------------------- enclosed------------------------------- From: Chuq Von Rospach To: newgroup@ncar.ucar.edu, stodol@diku.dk Subject: Re: comp.groupware.f(resend) Please note in all this that I didn't follow the groupware vote, so my comments are coming from completely outside the discussion. >It would be silly for comp.groupware.f to have had a vote of its own since its >function is to work with comp.groupware. True, but traditionally, and there are a number of precedents, a call for votes is on a single group, not on multiple groups. On two occasions in votes I've been involved, I tried to suggest creating multiple groups and was told that wasn't how things were done (the groups involved were comp.sys.mac.hypercard and comp.sys.mac.programmer (which was created later under a separate vote) adn comp.sys.mac.hardware and comp.sys.mac.{microsoft,applications} (the latter group not yet voted on). The reason for this is that you only create the groups you need. In the case of both these votes, it was felt a split was needed to get volume under control, but everyone felt it was better to create it a group at a time and see how the volume ended up. [....] ---------------------------enclosed---------------------------- Date: Mon, 18 Dec 89 08:52:53 PST From: Chuq Von Rospach To: allbery@uunet.UU.NET, newgroup@ncar.ucar.edu, stodol@diku.dk, uunet.uu.net.bill@twwells.com Subject: Re: comp.groupware.f(resend) [....] The precedents in USENET are simple. there are no simultaneous creation of groups, and you don't create multiple groups with a single vote. I covered that in a previous mailing, so I won't repeat myself. [....] As newgroup czar, I'd be willing to create comp.groupware. I think the vote and procedure were close enough to what's proper that this can be justified. Under no circumstances can I justify comp.groupware.f, for reasons I've discussed in previous mailings, and because I won't support multiple group creations under a single vote. [....] I, for one, am tired of watching people decide they can use or ignore the guidelines, depending on what's to their advantage. They should either be enforced, fixed or thrown out. Until the net decides to do either of the latter, I'm going to enforce them to the best of my ability. "comp.groupware" is close enough that it can be created under the guidelines. Tossing in "comp.groupware.f" however, pushes the request into unacceptability. -------------------end enclosures--------------------------- Please note that these enclosures were made public by being send to the list newgroup@ncar.ucar.edu and in any case are part of the public business of Usenet. They remain copyright of the author, but are in the public domain. -- David S. Stodolsky Internet: david@ruc.dk Department of Psychology :stodol@diku.dk Copenhagen Univ., Njalsg. 88 Voice: + 45 31 58 48 86 DK-2300 Copenhagen S, Denmark Fax: + 45 31 54 32 11