| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | Proposal |
Hello Dale. 23 Dec 03 23:55, you wrote to me: MG>> but do not get a vote in the referendum. I feel it is MG>> important to keep the referendum process as it is; because MG>> IMO it is exceedingly fair and democratic as it stands now. DS> You are contradicting yourself there. As it is now, NCs have no role DS> at all until the final vote. And that is the most /important/ stage. Policy change is not ratified if the referendum does not pass. DS> The referendum process currently is that only the RCs vote, and that is DS> not being changed -- only the quorum requirement for calling a referendum DS> is being changed. Wrong; the RC's only /initiate/ the referendum. The current policy allows one vote for every *C in the network in a policy referendum. That means NC's, RC's and ZC's all get a vote. The new proposal would take away the NC and ZC votes in the referendum. Then the new proposal also adds a third, unnecessary vote in order for the new policy to be ratified. It's sort of like saying, do we now accept the referendum vote, or not? Under current policy, if the referendum passes, then it is ratified. No ifs ands or buts. IMHO, the subsections 8.3, Eligibility to Vote, 8.4, Voting Mechanism, 8.5, Voting on a Whole Document, and 8.6, Decision of Vote, when taken together describes the most fair and democratic process we have ever seen in Fidonet, and therefore should not be changed at all, because it cannot be improved upon. DS> By adding the possibility that the NCs can play a role in initiation, we DS> are making the process more democratic (i.e. closer to the end user DS> sysop) than it is now. It adds one thing to make it easier to /initiate/ a referendum, yet takes away democracy from a large number of *C's in the network when it comes to the actual vote. No; IMO, this does not make the process more democratic. DS> As has been said in the discussion here -- the current process has no DS> initiation procedure defined. The RCs vote to have a referendum on a DS> new policy, but in the minds of some have no responsibility to DS> participate in the creation of that new policy. I can see some merit to changing the initiation requirements, be it a lower quorum, a statement of RC obligation, or addition of NC's to the process; but also I feel we should not make it too easy to start a referendum. The reason for that is because if we made it too easy to call for a referendum, we would have constant calls for referenda by narrow groups with their pet agendas, and then the membership would grow tired of dealing with repeated referenda. The end result would be that the process would become a joke, and the votes would be automatically rejected without the membership taking a serious look at the proposal. MG>> thing that needs to be changed is for a quorum be MG>> instituted as a minimum requirement for a number of RC's to MG>> /initiate/ a policy referendum. DS> Why not let a policy be initiated by a broader group? I see some merit to allowing the RC's to decide on whether to initiate a referendum. Although some say it does not always happen that way in practice, the RC's are supposed to be representives of a large geographical area containing a large number of Fidonet nodes. They /should/ be in touch with their regions' membership, and know what that membership's wishes are, and should express it when it comes to the question of should we have a policy referendum or not. NC's OTOH, may represent as little as two nodes, including themselves. If you have sufficient numbers of these sorts of NC's calling for a referendum, they may succeed in that while representing a very small number of nodes indeed. That sort of situation becomes an almost impossible occurance when the RC's are the ones deciding on initiation. --- GoldED/W32 3.0.1* Origin: MikE'S MaDHousE: WelComE To ThE AsYluM! (1:134/11) SEEN-BY: 633/267 270 @PATH: 134/11 10 123/500 106/2000 633/267 |
|
| SOURCE: echomail via fidonet.ozzmosis.com | |
Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.