Identity
Filter
Visitors
(1) (0) (0) (1) (0) (0) (0) (0) (0) (0) (0) (0) (0) (0) (0) (16) (0) (0) (61) (0) (0) (0)Subscribers
(0) (0)
Links
Blogs
Democracy
Search
[top-politics] Dance-Monkey algorithm
-
At 03:41 PM 9/5/2006, Mark wrote: >-M: ‘of course’ – again, why the override? Why not let the voter decide >if there is going to be an override or not? Maybe the voter wants both >a direct vote and more than one delegate. SD2-S allows for this. How is >your way better?
Indeed, why not? The question is whether or not a coded solution is necessary to implement such choice.
If we have a very simple proxy list (one proxy per member), and we have voting records, that is, we know who voted and how, then any analyst can determine
(1) the direct vote. This is generally automatic with, say, yahoogroups voting. Note that this direct vote is what is already generally available. (2) the expanded proxy vote. This can be done by comparing the vote record with the proxy list. The algorithms which can do so are simple, the core of the process, in its simplest form, would be that where a member has not voted, the member’s vote is added with the vote of his or her proxy; if his or her proxy has not voted, the chain of proxies up the tree is examined until an actual voter is found, and the member’s virtual vote is determined in this way. If no voting proxy has been found, the member is in a loop or an inactive branch, and the member may be notified. This notification can be done by any privileged member, that is, any member entrusted with the actual membership list.
So, if the member wants an override, in this simple system, the member merely votes. And if the member does not want an override, the member does not vote. Either the member wants analysts to consider the member’s vote in a result, or not. If not, the member’s vote is dicta, meaningless.
I presume that voting results would appear in stages. However, the essence of the FA/DP systems we envision are that they do not generate excess traffic for members. Many members may not want to be notified of every vote. If we are thinking of a single organization, as many of us do, we often imagine active members and members who would want to know everything going on. But this becomes impossible when there are hundreds of organizations that a member might belong to.
Some would set up a single, massive organization, and then members would participate in issue forums. This is really equivalent to a set of distinct organizations sharing certain central resources. However, independent organizations can already share central resources.
If the relatively complex systems being proposed actually exist and are operational, I’d be happy to see them, indeed I am eager to do so. But I’d personally invest my coding resources—and conceptual resources—in the very simplest systems first. From our experience with these, I would then move to more complex systems, the bells and whistles, so to speak, or even to crucial features that were not possible with the initial simplicity.
Simple DP, through a proxy list, available for analysis, will serve quite well, I expect, in organizations with the purpose of communication and voluntary coordination and cooperation, and specifically in the FA context, where votes do not directly move power. Once power is moved, the control mechanisms become crucial. And we really don’t know the hazards.
As the members of FA/DP organizations increasingly become involved in power and control structures, they will bring with them an experience with DP, as well as of how possible it is to find consensus when the structures encourage and allow it. And at that time, we will have much more knowledge about what works and what does not and what is necessary and what is not.
Complexity in communication systems is a double-edged sword. It can increase utility, but it also increases the number of possible failure modes. It is generally good engineering practice to seek the simplest possible functional systems and to be cautious about complicating them. Every added component, unless the design is very careful, adds increased risk of failure.
Now, I just wrote a relatively long post, in answer to a simple question. The question was not directed at me, but at someone else who is, from what I’ve seen, thinking very much along the same lines as I have. A briefer answer is that what was called “your way” is better because it is simpler. In the absence of demonstrated necessity for the complications suggested, simplicity is a commonly-recognized engineering goal. And engineers who don’t understand that find failure in the market, I’ve seen it again and again. Even if, from their perhaps obsessive point of view, their way was “better.”
I know one RF engineer who is as picky as one can imagine. Now, RF engineering is complex, and, as a support engineer, I expect to see, shall we say, unusual requests. But the pickiness goes far beyond the ultimate customer’s design goal. The documentation must be just so. The parts used must be cost-optimized to the last penny. None of these things are wrong, in themselves, indeed, they can be quite important. But if the job is not ready in time because less consequential aspects of the design require further work to satisfy the engineer’s artificially exacting requirements…. the whole project was wasted. Striking the proper balance is a crucial skill for an engineer. Without it, engineers tend to be isolated dreamers, wondering why the world is not building their castles. Their very perfect castles. Better than anyone else’s.
+2
-
+1
+1
-
