I gave you my proxy (is that the proper way to say it? English is not my native language, and I am not always sure of the proper phrasing: you can also advise on that.)
Your test highlighted a small problem. I am going to fix it this week:
1) you created the new poll.
2) you added the option "FA/DP is groovy"
3) you voted (for me, too)
4) you added the option "Chocolate" (Yummy!)
5) you updated your vote and I know why it didn't update mine.
That's why we now have 2 votes for "FA/DP is groovy" and 1 for "chocolate".
I am going to change so that if a proxy updates a vote, the update is valid for all the proxy ballot by the same proxy.
I think this is the first time in my life that someone answered my bug report before I wrote it!!
Yes, I was playing around, trying strange stuff to see if it counted the votes the way I think it should.
After you have fixed it, let me know. I'll try creating some "sock puppets" and seeing what happens if proxy assignments are added or changed. I think there should be a couple principles that apply:
* A direct vote always overrides a vote by ones proxy. It doesn't matter who votes first.
* "I don't know" is equivalent to not voting. So if I vote "I like" and then change it to "I don't know", my proxy's vote would then count for me (and any of my clients who haven't voted, or who voted "I don't know").
* If I fire my proxy, then the poll results should stop showing any votes that my ex-proxy made for me.
Please check that proxy loops don't cause your programs to get into an infinite loop. I don't want your web host to get mad or charge you lots of money for CPU time. Check what happens if a person tries to assign himself as his proxy.
I think you mentioned that a person can have more than one proxy. How does that work? Which proxy would vote for you? Here is how it should work, I think (I'll ask Abd to comment). When an FA (such as minguo or metaparty) deals with multiple subject areas (such as war, voting methods, health care...), a member can have one "general" proxy, and one "special" proxy for each subject area. The same proxy may serve the client in more than one subject area, but a client can not have more than one proxy for any subject area. If a client assigns a general proxy, then that proxy votes for the client in any subject area where the client hasn't assigned a special proxy. Thus, I might assign a libertarian as my general proxy, but assign Abd as my special proxy for voting methods and FA/DP subject areas. Augustin, if you don't want to implement that proxy assignment scheme right now, then I suggest that you allow only one proxy per member, and that proxy would be a general proxy.
Abd has the idea that a client-proxy relationship should be "pending" until accepted by the proxy. My opinion is that if a person has indicated that he is willing to serve as a proxy, then clients can make the assignment and the assignment goes into effect immediately. However, the proxy should get an email notification of the assignment, and the proxy should be able to revoke the assignment any time.
What is a "subject area"? In Metaparty, it's a forum. Each forum has a name (like "US-Iraq Conflict") and a description of what would be discussed in that forum. Any polls in Metaparty would be connected to a forum. Inside forums are threads. I suggest minguo have a similar organization. In minguo, you currently have discussion topics and poll topics. I think poll topics should use the same set of names as the discussion topics, which are equivalent to subject areas or forums in Metaparty. If you want, you could have multiple "pages" under a discussion topic. A "page" would be like a thread in Metaparty.
There are several levels of openness or secrecy that could be applied to polls:
0: The log of votes received is viewable by anyone.
1: Proxies can see the vote log of their constituents, and clients can see the vote log of their immediate and higher level proxies.
2: Proxies can see the vote log of their clients (but not clients' clients, etc.), and clients can see the vote log of their immediate and higher level proxies.
3. Clients can see the vote log of their immediate and higher level proxies.
4. Members can see only their own vote logs.
At this time, I think level 0 is most needed, level 2 is second-most needed, and level 4 is third-most needed.
One should be able to view vote logs (by clicking "view vote log", for example), or just the most recent votes ("view votes"), or (what we have now, by default) the summary.
I think the "comments" you can write about the poll choices (such as "This is a comment about chocolate") should just go to the vote logs next to the votes. They are intended as brief comments for the benefit of people analyzing the vote logs to figure out why people are voting as they are.
Amazing customer service! :-)
I think this is the first time in my life that someone answered my bug report before I wrote it!!
:) I just happened to be online when you started testing. I saw the poll results which were not the ones anyone would have expected. I just anticipated your question. The fix is easy.
I have to go home, now. I'll reply in more details later. You make many good points. Some things are easy, some require a lot of changes. Some points were already planned, other need to be discussed.
Maybe I should set up a test web site, so that we can test as much as required, without messing with the data here.
Re. CPU usage: before I even started coding the DP functionality, I spent many many hours thinking about a proper algorithm that would scale well. The current code should be able to cope well under heavy load, when many people with many proxies vote on the same or different polls, all of this while avoiding race conditions in updating the poll results. It handles loops perfectly (i.e. with client/proxy relationships like: A > B > C > A).
Some of your proposed changes are ok in theory, but it would require drastic changes in the algorithm: I would then be worried about CPU usage.
I'll answer in detail to each of the points you raise in the next few days.
I'll fix the bug I mentioned in my first comment first: I think this is the only truly critical change to be made now. All the rest can be improved incrementally, a bit every week.
Check the /tracker ('Recent Posts' link at the top) for updates.
First of all, for uncomplicated single proxy systems, every member either has no proxy or has named one, which they can change at any time. If everyone names a proxy, rather obviously, proxy loops will occur. Proxy loops are harmless, except that a mature system might periodically notify members, under some conditions, when there is some significant activity where they are not represented because their entire proxy hierarchy was absent.
Proxy assignments that create a loop should probably be flagged. This may come up later, and it may be appropriate to notify members of such loops under some circumstances.
When votes are reported, it is suggested that
(1) The identity (user name) of all *direct* votes be available. If it is really large, the list of votes, then a user should be able to enter a specific user name and see if that user, or a proxy up from that user, has voted, and how. Since "proxy up" is always just one user, it would ordinarily not be more than a few users in the list. In common polling software usage (such as Yahoogroups polls), if the poll is so configured, users can see who voted, and how....
(2) The vote reporting should include, separately, direct votes, and then proxy votes. It might be reported as Direct Votes, Indirect Votes, Total.
If a user looks at the list of those who voted, the list should show the username of all those who voted in a particular way, plus the number of additional votes. Ideally, there would be a link to a proxy hierarchy, showing the actual votes added.
(Our tentative manual implementations simply look at the list of user names from the poll, the list of proxy assignments, and then all the rest of what is given above is easily derived offline, by anyone who cares.)
A list should also be possible to get of all those members who have not voted directly or indirectly.
Secret ballot polls are another matter. They are of questionable value, for they are impossible for the general membership to verify, only admin could do it.
I generally agree, except I'm not clear about what you are asking for, here:
If a user looks at the list of those who voted, the list should show the username of all those who voted in a particular way, plus the number of additional votes. Ideally, there would be a link to a proxy hierarchy, showing the actual votes added.
Are you thinking about a poll with just one choice, used to get a yes/neutral/no vote on some question?
If there are several choices (candidates), then there are lots of ways people could vote...
I fixed the bug mentioned at the top of this thread.
I also added to each opinion post a direct link back to the poll to which the opinion post is related.
Please, do NOT create sock-puppet accounts on this site, even for good reasons (e.g. testing). If everyone does that, it'll be a mess very soon.
I have just set up a new test site: http://minguo.info/test/
you can use it... for testing! It is completely separate from this site, i.e. it requires a different login. Access is reserved to any member who is interested in testing the functionality. I have created an account for Jan and Abd (you should have received an email). If you want to create more test accounts on the test site, please go ahead (you'll need to wait that I enable them, though). Or else, I can create some more test accounts for each of you (i.e. jankok1, jankok2, etc.). Just ask me.
The test site is running on the same code as this one.
You mention many things in your comment. I'll do my best to reply to everything, in separate comments.
I have no reason to disallow proxy loops. It's easier to allow them and they're useful. They are properly handled at the code level and they won't cause problems.
Having several proxies is useful, too. If I trust my two closest friends to vote in my name, I can give them both a proxy. Thus, should one be busy and unable to visit the site for a while, the other might still be available to vote.
Again, multiple proxies are properly handled, and only one vote will be registered in any case, so I see no reason to disallow them.
Before I can answer specific questions, I need to say more about how the system was conceived.
What I should document somewhere is the following:
Given the fact that proxies can be delegated, etc, several person have potentially the right to vote in the name of a given user. But only one vote can be counted. So: whose ballot will take precedence over the ballot of another proxy will depend on a set of simple rules.
A poll is created. User A has not voted. User A may have several proxies, one/some of which is direct, the others delegated. All those proxies can vote in the name of A.
1) If no vote has been registered for A, the first proxy to vote will do so for A, too.
2) If we have the chain of delegated proxies like this: A > B > C > D > E, B,C,D and E can all vote for A. B is one level away from A, C 2 levels away, D: 3, E:4. And A is 0 level away from himself. A proxy closer to A takes precedence over a more distant proxy.
If E votes, his ballot will count for D, C, B and A.
If C votes after E, his ballot will replace E's ballot for himself (C), B and A, since C is closer to the latter two than E is.
If D votes after C, his ballot will replace E's ballot for himself (D) only. C is closer to A and B and has already voted in their name.
If A votes last, his ballot replaces C's ballot.
This is a generalization of what Jan asked above:
A direct vote always overrides a vote by ones proxy. It doesn't matter who votes first.
Yes, a vote by A overrides any proxy ballot by B,C,D and E.
So, the 2nd rule is that a closer proxy (ultimately the client himself) overrides a ballot by a further proxy.
3) This rule is not implemented yet. Between two equally close proxies, a more specialized proxy takes precedence. I.e. if we have A > B and A > C, but B is a "general proxy" (as you say), and C is a specialist of economic affairs and is given a proxy only on economic affairs, we have the following:
- B can vote in the name of A on all issues, including economic affairs.
- C can only vote in the name of A on polls tagged 'economic affairs'.
- If B has voted first, and C votes second, C's ballot will override B's ballot on economic affairs.
But as I said, this rule is not implemented yet. All proxies are "general proxies" for the time being.
4) A proxy updating his own ballot does so for his clients, too (which was the bug above, now fixed).
5) everything being equal, an earlier ballot takes precedence and cannot be overridden.
There is one major problem with this algorithm: it assumes the poll is fixed and no answers are added. If a client votes himself, and 3 answers are added after that, nobody can override the client's ballot. This will be solved later in two different ways: 1) improving the workflow for a ballot, 2) improving the handling of ballots at the level of 'answers' (Now, as I said in my announcement, it is an all or nothing affair: we deal with a whole ballot, but not with its parts. Improving this will have to wait until I have abstracted the EM layer (which I shall do next), because the handling of the parts of a ballot will depend on the EM. What is possible with Emocracy is not necessarily possible with Condorcet or Plurality.
"I don't know" is equivalent to not voting. So if I vote "I like" and then change it to "I don't know", my proxy's vote would then count for me (and any of my clients who haven't voted, or who voted "I don't know").
I never thought about handling the "I don't know" option this way, but I LOVE your idea. It make senses and it is in accordance with the meaning of this option within an Emocracy poll. I wrote in the guided tour: http://minguo.info/guided_tour/better_voting_systems_emocracy "I don't know: I do not know this choice or candidate. I would need more information before I can express myself otherwise."
So it makes sense that if a proxy has more information, that the proxy's vote comes to complete the client's vote.
So, in principle, I like this idea.
In practice, I'll need to wait until I have made a basic EM abstraction layer. The idea is valid for Emocracy, but not for other EM. I need to see how everything will work out with this abstraction layer.
I am a bit concerned about CPU usage. There are many candidates (options) on a ballot. Currently I am handling a whole ballot at a time. This kind of feature would require me to handle each candidate separately. But I need to do this for other features, too (like I said above: "If a client votes himself, and 3 answers are added after that, nobody can override the client's ballot.". If we have a per-candidate handling, I could solve this kind of problem better).
I need time to study the best way to implement this. The EM abstraction layer will have to come first.
If I fire my proxy, then the poll results should stop showing any votes that my ex-proxy made for me.
I don't agree. We should follow the principle of least surprise. People may not understand why their ballot disappear. Imagine you have A > B > C > D > E. E votes in a poll for D, C, B, A. Then D fires E. It means that all the ballots for C, B and A should disappear, too.
Also if the proxy D > E had been ongoing for a long time (years?), there are potentially hundreds or thousands of ballots to be revoked for D and any of D's clients and sub-clients. It'd be a hassle to recompute everything on dozens or hundreds of polls (CPU intensive).
And again: people might not expect this to happen, and sub-clients might not understand what happened.
Besides, D might be happy with E's ballots in the earlier years, but not the most recent ones, which may have caused the falling out between D and E.
I can make the following compromise. I explained that a lower level proxy (closer to the user for whom the ballot is counted) takes precedence. I can flag all the ballots that were cast under the authority of a D > E proxy with a very high number: thus if any other proxy comes around and vote, the ballot will be automatically updated at that time. Thus, the ballots that relied on the D > E proxy relationship would be updated little by little.
Ok?
Currently, the ballots are left intact. But what I propose here could be implemented fairly easily.
Abd has the idea that a client-proxy relationship should be "pending" until accepted by the proxy. My opinion is that if a person has indicated that he is willing to serve as a proxy, then clients can make the assignment and the assignment goes into effect immediately. However, the proxy should get an email notification of the assignment, and the proxy should be able to revoke the assignment any time.
Something like this was already planned for later. http://minguo.info/latest_news/basic_proxy_feature_now_online_try_it
I agree that a proxy should have the possibility to screen clients, accept and refuse them.
A client should also have the possibility to prevent his proxy to delegate further the proxy (as in "I trust my friends, but I don't trust my friends' friends").
etc.
Currently only the client can revoke the proxy, but the proxy cannot revoke the client. It should be possible.
Email notifications and such are useful, too.
Features like these can be added over time. I agree with you on those features. I cannot do everything at once: up to you to tell me which feature is more important.
What is a "subject area"? In Metaparty, it's a forum. Each forum has a name (like "US-Iraq Conflict") and a description of what would be discussed in that forum. Any polls in Metaparty would be connected to a forum. Inside forums are threads. I suggest minguo have a similar organization. In minguo, you currently have discussion topics and poll topics. I think poll topics should use the same set of names as the discussion topics, which are equivalent to subject areas or forums in Metaparty. If you want, you could have multiple "pages" under a discussion topic. A "page" would be like a thread in Metaparty.
The "Poll topic" (http://minguo.info/usa/tagadelic/chunk/4) are what are slated to become, at one stage, (one of) the topics used to assign "special" proxies (as you say) (or "specialist proxies"?). Each poll is assigned exactly one term from this taxonomy. See my comments in the main blog (link above).
The "Discussion topic" (http://minguo.info/usa/tagadelic/chunk/5) are only here to help tag different nodes (polls, opinion posts, etc.) to help visitors find content on a specific topic. That's all. When you create a node, you have the choice to tag it with several key words.
You can suggest better names for each.
And with each of those two taxonomies ("Poll topic" and "Discussion Topic"), you can find all the nodes (content) listed under the same term.
Minguo.info is using a different tool (Drupal), but in essence, the organization is the same as in metaparty. The "poll topic" allows you to find all polls with that topic (see chunk/4), and for each poll, all the opinion posts created to discuss the poll. If you want a list of all the discussion posts related to the same poll topic, it can be fairly easily done.
There are several levels of openness or secrecy that could be applied to polls:
0: The log of votes received is viewable by anyone.
1: Proxies can see the vote log of their constituents, and clients can see the vote log of their immediate and higher level proxies.
2: Proxies can see the vote log of their clients (but not clients' clients, etc.), and clients can see the vote log of their immediate and higher level proxies.
3. Clients can see the vote log of their immediate and higher level proxies.
4. Members can see only their own vote logs.
At this time, I think level 0 is most needed, level 2 is second-most needed, and level 4 is third-most needed.
I don't really understand what you are saying here.
I follow the following principle: everything should be secret and private ... until we find a good reason to make it open.
This goes against what Abd says: he seems to say that absolutely everything should be open (like who voted what, etc.) I say: until we have a need for the contrary, keep things private and leave the users the choice to shout the way they voted on the rooftops or to keep it quiet.
Example 1:
Everyone's ballot is secret. But a client needs to know how their proxy voted. So the ballot is hidden, and shown only to the client who has a legitimate right to know.
Example 2:
Who is whose client and whose proxy is none of our business. I only need to know who is my direct proxy, and who is my direct client. However, such a level of secrecy can easily be abused by sock-puppeters. For this reason, I plan to print a list of all the proxy ballots for each poll. Not the ballots themselves, but the name of the proxy, and the name of the client and all the links in between. This way we'll see very clearly which member carries a lot of weight. It will be harder (but not impossible) for sock-puppeters to do play their dirty tricks.
This is not done yet, but I plan to do it.
To reply your comment: I am not sure what information you want to include in the 'logs', what you mean by them.
One thing I agree with, is that a proxy should have a field to enter a justification for a vote. The clients (and only them) will be able to see this note and understand the motivation of their proxy.
Speaking of privacy: here is an important note.
The core of Drupal gives me by default more rights throughout the web site than any of you. You can understand this. I hope to be able to demonstrate that I won't abuse those rights.
HOWEVER, as I am coding the minguo.info custom module, implementing EM and proxy voting and what not, I am NOT coding a way for myself to do more things than you can.
I.e. short of going straight to the database and making complex queries, I have no more ways than you to know how an individual has voted or who is whose proxy. I don't care to know.
I will code only what's necessary for basic administration, to ensure the site runs smoothly. I will also code some safeguards against abuse, with tripwire bells, etc. But I am NOT making it easy for myself to spy on other people's votes, etc. E.g. I don't know if you gave a proxy to AllAboutVoting or him to you. If either of you did, I wouldn't be able to know it... unless a ballot is cast in my name under the faith of this proxy relationship (i.e. if we have Augustin > Jan > AAV and AAV casts a ballot on a brand new poll, I will see that a ballot was cast for me by AAV because he is my proxy's proxy). It works like it would for you or any other member.
I think the "comments" you can write about the poll choices (such as "This is a comment about chocolate") should just go to the vote logs next to the votes. They are intended as brief comments for the benefit of people analyzing the vote logs to figure out why people are voting as they are.
The 'comments' (or 'opinion' posts) are here to start a dialogue, to inform, to help find the best solution/answer/candidate to a given poll, etc. Not to justify a vote.
A proxy should be able to justify privately his vote to his clients. I mentioned that above.
The ballots are secret unless they NEED to be open (to some people).
I am in favor for having some form of vote log, but only after the need to be fulfilled has been well defined (like: making it less easy for sock-puppeters to go undetected).
I don't know if you gave a proxy to AllAboutVoting or him to you. If either of you did, I wouldn't be able to know it... unless a ballot is cast in my name under the faith of this proxy relationship (i.e. if we have Augustin > Jan > AAV and AAV casts a ballot on a brand new poll, I will see that a ballot was cast for me by AAV because he is my proxy's proxy). It works like it would for you or any other member
I made a mistake. I'll explain and it will help you understand better how things work.
The fact is that I gave a proxy to each of you. I am the client of both of you. My motivation is to "prime the pump" or "get the ball rolling". When the site is busier, I'll have more choices in terms of proxies and I might revoke the ones I gave you :)
Anyway, you are both my proxies and for that reason, I shall never know if either of you gave a proxy to the other one or not.
Suppose you gave a proxy to AAV.
Basically, we'd have:
Augustin > Jan
Augustin > AAV
Jan > AAV
and
Augustin > Jan > AAV.
However, according to the principle explained above, Augustin > AAV takes precedence over Augustin > Jan > AAV (which is one level higher, and the lowest takes precedence).
Thus, if AAV casts a ballot in a new poll, I shall only see Augustin > AAV. I'll never see Augustin > Jan > AAV unless I revoke my direct proxy to AAV.
The identity (user name) of all *direct* votes be available. If it is really large, the list of votes, then a user should be able to enter a specific user name and see if that user, or a proxy up from that user, has voted, and how. Since "proxy up" is always just one user, it would ordinarily not be more than a few users in the list. In common polling software usage (such as Yahoogroups polls), if the poll is so configured, users can see who voted, and how....
I know you are in favor of more openness. I'd rather leave the possibility to retain as much privacy as possible (retain the principle of a secret ballot).
See my more complete reply above.
The vote reporting should include, separately, direct votes, and then proxy votes. It might be reported as Direct Votes, Indirect Votes, Total.
Something like that will be done to the extent that it helps fight socket-puppetting. See above.
If a user looks at the list of those who voted, the list should show the username of all those who voted in a particular way, plus the number of additional votes. Ideally, there would be a link to a proxy hierarchy, showing the actual votes added.
According to what I proposed above, ballots will be secret, but proxy hierarchy will be visible on a given poll.
Making everything open might scare too many people away. And again, I want to maintain the principle of a secret ballot as much as possible.
Comments
testing
I am aware of many small bugs, especially useability bugs. As you are testing things, I am sure you will notice them.
I cannot fix everything at once. Just let me know which ones, in your opinions, are the most critical problems and I'll get those sorted soon.
This is a comment on http://minguo.info/usa/node/59 (a direct link back to the poll would be nice!)
I gave you my proxy (is that the proper way to say it? English is not my native language, and I am not always sure of the proper phrasing: you can also advise on that.)
Your test highlighted a small problem. I am going to fix it this week:
1) you created the new poll.
2) you added the option "FA/DP is groovy"
3) you voted (for me, too)
4) you added the option "Chocolate" (Yummy!)
5) you updated your vote and I know why it didn't update mine.
That's why we now have 2 votes for "FA/DP is groovy" and 1 for "chocolate".
I am going to change so that if a proxy updates a vote, the update is valid for all the proxy ballot by the same proxy.
Amazing customer service! :-)
I think this is the first time in my life that someone answered my bug report before I wrote it!!
Yes, I was playing around, trying strange stuff to see if it counted the votes the way I think it should.
After you have fixed it, let me know. I'll try creating some "sock puppets" and seeing what happens if proxy assignments are added or changed. I think there should be a couple principles that apply:
* A direct vote always overrides a vote by ones proxy. It doesn't matter who votes first.
* "I don't know" is equivalent to not voting. So if I vote "I like" and then change it to "I don't know", my proxy's vote would then count for me (and any of my clients who haven't voted, or who voted "I don't know").
* If I fire my proxy, then the poll results should stop showing any votes that my ex-proxy made for me.
Please check that proxy loops don't cause your programs to get into an infinite loop. I don't want your web host to get mad or charge you lots of money for CPU time. Check what happens if a person tries to assign himself as his proxy.
I think you mentioned that a person can have more than one proxy. How does that work? Which proxy would vote for you? Here is how it should work, I think (I'll ask Abd to comment). When an FA (such as minguo or metaparty) deals with multiple subject areas (such as war, voting methods, health care...), a member can have one "general" proxy, and one "special" proxy for each subject area. The same proxy may serve the client in more than one subject area, but a client can not have more than one proxy for any subject area. If a client assigns a general proxy, then that proxy votes for the client in any subject area where the client hasn't assigned a special proxy. Thus, I might assign a libertarian as my general proxy, but assign Abd as my special proxy for voting methods and FA/DP subject areas. Augustin, if you don't want to implement that proxy assignment scheme right now, then I suggest that you allow only one proxy per member, and that proxy would be a general proxy.
Abd has the idea that a client-proxy relationship should be "pending" until accepted by the proxy. My opinion is that if a person has indicated that he is willing to serve as a proxy, then clients can make the assignment and the assignment goes into effect immediately. However, the proxy should get an email notification of the assignment, and the proxy should be able to revoke the assignment any time.
What is a "subject area"? In Metaparty, it's a forum. Each forum has a name (like "US-Iraq Conflict") and a description of what would be discussed in that forum. Any polls in Metaparty would be connected to a forum. Inside forums are threads. I suggest minguo have a similar organization. In minguo, you currently have discussion topics and poll topics. I think poll topics should use the same set of names as the discussion topics, which are equivalent to subject areas or forums in Metaparty. If you want, you could have multiple "pages" under a discussion topic. A "page" would be like a thread in Metaparty.
There are several levels of openness or secrecy that could be applied to polls:
0: The log of votes received is viewable by anyone.
1: Proxies can see the vote log of their constituents, and clients can see the vote log of their immediate and higher level proxies.
2: Proxies can see the vote log of their clients (but not clients' clients, etc.), and clients can see the vote log of their immediate and higher level proxies.
3. Clients can see the vote log of their immediate and higher level proxies.
4. Members can see only their own vote logs.
At this time, I think level 0 is most needed, level 2 is second-most needed, and level 4 is third-most needed.
One should be able to view vote logs (by clicking "view vote log", for example), or just the most recent votes ("view votes"), or (what we have now, by default) the summary.
I think the "comments" you can write about the poll choices (such as "This is a comment about chocolate") should just go to the vote logs next to the votes. They are intended as brief comments for the benefit of people analyzing the vote logs to figure out why people are voting as they are.
quick reply
:) I just happened to be online when you started testing. I saw the poll results which were not the ones anyone would have expected. I just anticipated your question. The fix is easy.
I have to go home, now. I'll reply in more details later. You make many good points. Some things are easy, some require a lot of changes. Some points were already planned, other need to be discussed.
Maybe I should set up a test web site, so that we can test as much as required, without messing with the data here.
Re. CPU usage: before I even started coding the DP functionality, I spent many many hours thinking about a proper algorithm that would scale well. The current code should be able to cope well under heavy load, when many people with many proxies vote on the same or different polls, all of this while avoiding race conditions in updating the poll results. It handles loops perfectly (i.e. with client/proxy relationships like: A > B > C > A).
Some of your proposed changes are ok in theory, but it would require drastic changes in the algorithm: I would then be worried about CPU usage.
I'll answer in detail to each of the points you raise in the next few days.
I'll fix the bug I mentioned in my first comment first: I think this is the only truly critical change to be made now. All the rest can be improved incrementally, a bit every week.
Check the /tracker ('Recent Posts' link at the top) for updates.
Desirable Proxy procedures
First of all, for uncomplicated single proxy systems, every member either has no proxy or has named one, which they can change at any time. If everyone names a proxy, rather obviously, proxy loops will occur. Proxy loops are harmless, except that a mature system might periodically notify members, under some conditions, when there is some significant activity where they are not represented because their entire proxy hierarchy was absent.
Proxy assignments that create a loop should probably be flagged. This may come up later, and it may be appropriate to notify members of such loops under some circumstances.
When votes are reported, it is suggested that
(1) The identity (user name) of all *direct* votes be available. If it is really large, the list of votes, then a user should be able to enter a specific user name and see if that user, or a proxy up from that user, has voted, and how. Since "proxy up" is always just one user, it would ordinarily not be more than a few users in the list. In common polling software usage (such as Yahoogroups polls), if the poll is so configured, users can see who voted, and how....
(2) The vote reporting should include, separately, direct votes, and then proxy votes. It might be reported as Direct Votes, Indirect Votes, Total.
If a user looks at the list of those who voted, the list should show the username of all those who voted in a particular way, plus the number of additional votes. Ideally, there would be a link to a proxy hierarchy, showing the actual votes added.
(Our tentative manual implementations simply look at the list of user names from the poll, the list of proxy assignments, and then all the rest of what is given above is easily derived offline, by anyone who cares.)
A list should also be possible to get of all those members who have not voted directly or indirectly.
Secret ballot polls are another matter. They are of questionable value, for they are impossible for the general membership to verify, only admin could do it.
Re: Desirable Proxy procedures
I generally agree, except I'm not clear about what you are asking for, here:
Are you thinking about a poll with just one choice, used to get a yes/neutral/no vote on some question?
If there are several choices (candidates), then there are lots of ways people could vote...
bug fixed and test web site
Hello,
I fixed the bug mentioned at the top of this thread.
I also added to each opinion post a direct link back to the poll to which the opinion post is related.
Please, do NOT create sock-puppet accounts on this site, even for good reasons (e.g. testing). If everyone does that, it'll be a mess very soon.
I have just set up a new test site:
http://minguo.info/test/
you can use it... for testing! It is completely separate from this site, i.e. it requires a different login. Access is reserved to any member who is interested in testing the functionality. I have created an account for Jan and Abd (you should have received an email). If you want to create more test accounts on the test site, please go ahead (you'll need to wait that I enable them, though). Or else, I can create some more test accounts for each of you (i.e. jankok1, jankok2, etc.). Just ask me.
The test site is running on the same code as this one.
You mention many things in your comment. I'll do my best to reply to everything, in separate comments.
proxy precedence rules
I have no reason to disallow proxy loops. It's easier to allow them and they're useful. They are properly handled at the code level and they won't cause problems.
I see a loop here, too :)
http://metaparty.beyondpolitics.org/tiki-index.php?page=Metaparty%20prox...
jankok5,Abd,Yes
Abd,jankok5,Yes
Having several proxies is useful, too. If I trust my two closest friends to vote in my name, I can give them both a proxy. Thus, should one be busy and unable to visit the site for a while, the other might still be available to vote.
Again, multiple proxies are properly handled, and only one vote will be registered in any case, so I see no reason to disallow them.
Before I can answer specific questions, I need to say more about how the system was conceived.
What I should document somewhere is the following:
Given the fact that proxies can be delegated, etc, several person have potentially the right to vote in the name of a given user. But only one vote can be counted. So: whose ballot will take precedence over the ballot of another proxy will depend on a set of simple rules.
A poll is created. User A has not voted. User A may have several proxies, one/some of which is direct, the others delegated. All those proxies can vote in the name of A.
1) If no vote has been registered for A, the first proxy to vote will do so for A, too.
2) If we have the chain of delegated proxies like this: A > B > C > D > E, B,C,D and E can all vote for A. B is one level away from A, C 2 levels away, D: 3, E:4. And A is 0 level away from himself. A proxy closer to A takes precedence over a more distant proxy.
If E votes, his ballot will count for D, C, B and A.
If C votes after E, his ballot will replace E's ballot for himself (C), B and A, since C is closer to the latter two than E is.
If D votes after C, his ballot will replace E's ballot for himself (D) only. C is closer to A and B and has already voted in their name.
If A votes last, his ballot replaces C's ballot.
This is a generalization of what Jan asked above:
Yes, a vote by A overrides any proxy ballot by B,C,D and E.
So, the 2nd rule is that a closer proxy (ultimately the client himself) overrides a ballot by a further proxy.
3) This rule is not implemented yet. Between two equally close proxies, a more specialized proxy takes precedence. I.e. if we have A > B and A > C, but B is a "general proxy" (as you say), and C is a specialist of economic affairs and is given a proxy only on economic affairs, we have the following:
- B can vote in the name of A on all issues, including economic affairs.
- C can only vote in the name of A on polls tagged 'economic affairs'.
- If B has voted first, and C votes second, C's ballot will override B's ballot on economic affairs.
But as I said, this rule is not implemented yet. All proxies are "general proxies" for the time being.
4) A proxy updating his own ballot does so for his clients, too (which was the bug above, now fixed).
5) everything being equal, an earlier ballot takes precedence and cannot be overridden.
There is one major problem with this algorithm: it assumes the poll is fixed and no answers are added. If a client votes himself, and 3 answers are added after that, nobody can override the client's ballot. This will be solved later in two different ways: 1) improving the workflow for a ballot, 2) improving the handling of ballots at the level of 'answers' (Now, as I said in my announcement, it is an all or nothing affair: we deal with a whole ballot, but not with its parts. Improving this will have to wait until I have abstracted the EM layer (which I shall do next), because the handling of the parts of a ballot will depend on the EM. What is possible with Emocracy is not necessarily possible with Condorcet or Plurality.
replies.
I never thought about handling the "I don't know" option this way, but I LOVE your idea. It make senses and it is in accordance with the meaning of this option within an Emocracy poll. I wrote in the guided tour:
http://minguo.info/guided_tour/better_voting_systems_emocracy "I don't know: I do not know this choice or candidate. I would need more information before I can express myself otherwise."
So it makes sense that if a proxy has more information, that the proxy's vote comes to complete the client's vote.
So, in principle, I like this idea.
In practice, I'll need to wait until I have made a basic EM abstraction layer. The idea is valid for Emocracy, but not for other EM. I need to see how everything will work out with this abstraction layer.
I am a bit concerned about CPU usage. There are many candidates (options) on a ballot. Currently I am handling a whole ballot at a time. This kind of feature would require me to handle each candidate separately. But I need to do this for other features, too (like I said above: "If a client votes himself, and 3 answers are added after that, nobody can override the client's ballot.". If we have a per-candidate handling, I could solve this kind of problem better).
I need time to study the best way to implement this. The EM abstraction layer will have to come first.
I don't agree. We should follow the principle of least surprise. People may not understand why their ballot disappear. Imagine you have A > B > C > D > E. E votes in a poll for D, C, B, A. Then D fires E. It means that all the ballots for C, B and A should disappear, too.
Also if the proxy D > E had been ongoing for a long time (years?), there are potentially hundreds or thousands of ballots to be revoked for D and any of D's clients and sub-clients. It'd be a hassle to recompute everything on dozens or hundreds of polls (CPU intensive).
And again: people might not expect this to happen, and sub-clients might not understand what happened.
Besides, D might be happy with E's ballots in the earlier years, but not the most recent ones, which may have caused the falling out between D and E.
I can make the following compromise. I explained that a lower level proxy (closer to the user for whom the ballot is counted) takes precedence. I can flag all the ballots that were cast under the authority of a D > E proxy with a very high number: thus if any other proxy comes around and vote, the ballot will be automatically updated at that time. Thus, the ballots that relied on the D > E proxy relationship would be updated little by little.
Ok?
Currently, the ballots are left intact. But what I propose here could be implemented fairly easily.
Something like this was already planned for later.
http://minguo.info/latest_news/basic_proxy_feature_now_online_try_it
I agree that a proxy should have the possibility to screen clients, accept and refuse them.
A client should also have the possibility to prevent his proxy to delegate further the proxy (as in "I trust my friends, but I don't trust my friends' friends").
etc.
Currently only the client can revoke the proxy, but the proxy cannot revoke the client. It should be possible.
Email notifications and such are useful, too.
Features like these can be added over time. I agree with you on those features. I cannot do everything at once: up to you to tell me which feature is more important.
I should explain this a bit better, somewhere.
First of all, see AllAboutVoting's concerns, and my replies on this topic:
http://minguo.info/latest_news/basic_proxy_feature_now_online_try_it#com...
The "Poll topic" (http://minguo.info/usa/tagadelic/chunk/4) are what are slated to become, at one stage, (one of) the topics used to assign "special" proxies (as you say) (or "specialist proxies"?). Each poll is assigned exactly one term from this taxonomy. See my comments in the main blog (link above).
The "Discussion topic" (http://minguo.info/usa/tagadelic/chunk/5) are only here to help tag different nodes (polls, opinion posts, etc.) to help visitors find content on a specific topic. That's all. When you create a node, you have the choice to tag it with several key words.
You can suggest better names for each.
And with each of those two taxonomies ("Poll topic" and "Discussion Topic"), you can find all the nodes (content) listed under the same term.
Minguo.info is using a different tool (Drupal), but in essence, the organization is the same as in metaparty. The "poll topic" allows you to find all polls with that topic (see chunk/4), and for each poll, all the opinion posts created to discuss the poll. If you want a list of all the discussion posts related to the same poll topic, it can be fairly easily done.
I don't really understand what you are saying here.
I follow the following principle: everything should be secret and private ... until we find a good reason to make it open.
This goes against what Abd says: he seems to say that absolutely everything should be open (like who voted what, etc.) I say: until we have a need for the contrary, keep things private and leave the users the choice to shout the way they voted on the rooftops or to keep it quiet.
Example 1:
Everyone's ballot is secret. But a client needs to know how their proxy voted. So the ballot is hidden, and shown only to the client who has a legitimate right to know.
Example 2:
Who is whose client and whose proxy is none of our business. I only need to know who is my direct proxy, and who is my direct client. However, such a level of secrecy can easily be abused by sock-puppeters. For this reason, I plan to print a list of all the proxy ballots for each poll. Not the ballots themselves, but the name of the proxy, and the name of the client and all the links in between. This way we'll see very clearly which member carries a lot of weight. It will be harder (but not impossible) for sock-puppeters to do play their dirty tricks.
This is not done yet, but I plan to do it.
To reply your comment: I am not sure what information you want to include in the 'logs', what you mean by them.
One thing I agree with, is that a proxy should have a field to enter a justification for a vote. The clients (and only them) will be able to see this note and understand the motivation of their proxy.
Speaking of privacy: here is an important note.
The core of Drupal gives me by default more rights throughout the web site than any of you. You can understand this. I hope to be able to demonstrate that I won't abuse those rights.
HOWEVER, as I am coding the minguo.info custom module, implementing EM and proxy voting and what not, I am NOT coding a way for myself to do more things than you can.
I.e. short of going straight to the database and making complex queries, I have no more ways than you to know how an individual has voted or who is whose proxy. I don't care to know.
I will code only what's necessary for basic administration, to ensure the site runs smoothly. I will also code some safeguards against abuse, with tripwire bells, etc. But I am NOT making it easy for myself to spy on other people's votes, etc. E.g. I don't know if you gave a proxy to AllAboutVoting or him to you. If either of you did, I wouldn't be able to know it... unless a ballot is cast in my name under the faith of this proxy relationship (i.e. if we have Augustin > Jan > AAV and AAV casts a ballot on a brand new poll, I will see that a ballot was cast for me by AAV because he is my proxy's proxy). It works like it would for you or any other member.
The 'comments' (or 'opinion' posts) are here to start a dialogue, to inform, to help find the best solution/answer/candidate to a given poll, etc. Not to justify a vote.
A proxy should be able to justify privately his vote to his clients. I mentioned that above.
The ballots are secret unless they NEED to be open (to some people).
I am in favor for having some form of vote log, but only after the need to be fulfilled has been well defined (like: making it less easy for sock-puppeters to go undetected).
to help you understand
I wrote:
I made a mistake. I'll explain and it will help you understand better how things work.
The fact is that I gave a proxy to each of you. I am the client of both of you. My motivation is to "prime the pump" or "get the ball rolling". When the site is busier, I'll have more choices in terms of proxies and I might revoke the ones I gave you :)
Anyway, you are both my proxies and for that reason, I shall never know if either of you gave a proxy to the other one or not.
Suppose you gave a proxy to AAV.
Basically, we'd have:
Augustin > Jan
Augustin > AAV
Jan > AAV
and
Augustin > Jan > AAV.
However, according to the principle explained above, Augustin > AAV takes precedence over Augustin > Jan > AAV (which is one level higher, and the lowest takes precedence).
Thus, if AAV casts a ballot in a new poll, I shall only see Augustin > AAV. I'll never see Augustin > Jan > AAV unless I revoke my direct proxy to AAV.
Replies to Abd.
I know you are in favor of more openness. I'd rather leave the possibility to retain as much privacy as possible (retain the principle of a secret ballot).
See my more complete reply above.
Something like that will be done to the extent that it helps fight socket-puppetting. See above.
According to what I proposed above, ballots will be secret, but proxy hierarchy will be visible on a given poll.
Making everything open might scare too many people away. And again, I want to maintain the principle of a secret ballot as much as possible.