TIP: Click on subject to list as thread! ANSI
echo: ic
to: Dale Shipp
from: Michael Grant
date: 2003-12-24 11:12:00
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™.