Xref: utzoo news.groups:18555 comp.sys.mac:50232
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!elroy.jpl.nasa.gov!mahendo!wlbr!hacgate!ashtate!dbase!dveditz
From: dveditz@dbase.A-T.COM (Dan Veditz)
Newsgroups: news.groups,comp.sys.mac
Subject: Re: Do not reorganize comp.sys.mac.*
Keywords: multiple creation renaming crossposting
Message-ID: <461@dbase.A-T.COM>
Date: 9 Mar 90 03:30:09 GMT
References: <1990Mar7.195114.1077@diku.dk>
Organization: Ashton Tate Development Center Glendale, Calif.
Lines: 58

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). 
 
to which stodol@diku.dk (David Stodolsky) responds:
>  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.
 
One of the problems we've been having is how to pick names.  There
aren't any guideline yet; this is an experiment.  I'd prefer simple
STV, but this seems to work well enough for a preliminary vote on 
reasonably non-controversial names.  I imagine Chuq would have held a 
more formal name survey if there had been a lot of flamage.


>  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.
 
I assume you refer to the c.s.mac ==> c.s.m.misc renaming.  This was 
not proposed to make it "fit" better, but to cut down on the cross-
and mis-posting.  If c.s.mac.misc wins and c.s.mac is not removed
then we just have the current problems plus one group worse.


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

Chuq has proposed, and held a confidence vote on, multiple concurrent
votes.  Each aspect of the proposal stands on its own.  If there are
"bad aspects" let's hear about it.  Something along the lines of
"I urge a NO vote on point X because..." would get the ball rolling,
or "I think point X should be split into...", "X and Y should be
combined into..."     

If you have some complaints I want to hear about it before the 
vote -- that's what a discussion period is for.


>  [David quotes two letters from Chuq saying that he is 
>   against creation of multiple groups from a single vote.]
    
I'm not sure how the .groupware vote went, but Chuq mentioned creating 
multiple groups with a *single* vote.  In his current proposal there 
will be multiple votes, albeit simultaneously.


Look, you're obviously unhappy with Chuq's proposal, but the only
concrete complaints I saw were about the voting *procedure*.  If you
see something in the proposal that will damage the mac groups themselves, 
please bring it up.

-Dan Veditz      dveditz@dbase.A-T.com       
                 { uunet | ncar!cepu }!ashtate!dveditz