kbennett: Glad to have you aboard. ;0)

"AOY be decided by a cumulative annual total of the AOM votes. Probably (but not definitely) this would result in a Poser artist being the AOY every time since the Poser AOM contest is likely to get the most voting."

Is the AOM always a Poser artist? If not, then this proves that the biases over one program do not seriously affect the outcome of the voting.

"A minimum time of membership before being allowed to vote. As stated before, this would eliminate instant clones. One problem I can forsee is that this would disbar new but valid members from voting, which might not be acceptable."

Many sites that I have seen use this technique for trying to deal with clones. If it is stated right off the bat that "upon registering, you will have access to all public site features with the exception of voting in contests/polls until you reach [insert target metric]", then no one could have a problem with it. I think it is an acceptable risk to take to resolve some of the clone activity.

However, length of membership should not be the only criteria. I could set up a clone, wait [time interval] and begin to wreak havok. I would suggest a more thorough set of criteria based upon what information is stored.

---

From the top of my noggin, what metrics do we have to work with:

• Registration Information: Most of this could be fudged, with the exception of the E-mail address; which is confirmed before continuing with Registration
• .
• E-mail Address: Although e-mail accounts are less than a dime a dozen nowadays, it could be used to "weed out" accounts that have the same e-mail address for those who do not willfully want to deceive.
• Gallaries: As we have seen, many people choose not to post to the Galleries, so this probably would not work unless you "forced" someone to post "something" in their gallery.
• Freebies: Suffers the same as the Galleries.
• MarketPlace Purchases: IMHO, it would be unethical to use any commercial transaction information on the site for anything other than the transaction.
• Forum Posts: I am not sure whether R'osity tracks the number of posts a member has made, but this could be used (ie, minimum of X posts) to deter clones and "inactive" members.
• Length of Membership: This could be easily determined (Now-RegisterDate) and used to weed out "instant clones", but not inactive clones that wait for the time interval. Still useful to consider, IMHO.
• Online Time: Although this could show how "active" a member is, some members may have little time to spend in any given session to make this worthwhile. Also, it can be "fooled" by leaving the session up and refreshing; unless a session timeout was implemented forcing more frequent refreshes.
• IP Address: This has too many complications to be worthwhile, with dynamic IPs, proxies, access to multiple systems, etc.

Suggested Voting Methods: - Cumulative Voting: It would appear that this may/may not be possible but introduce some voting biases based off the percentage of the membership that vote per given forum.

• E-bot Voting: The e-bot could send out links to the poll to only active members. However, someone could use the link or post it and allow the public in; unless the e-mail address is used for verification.
• Mods/Admins Only Voting: This would solve the clone problem, but alienate the members.
• No Contests/Voting: This would alleviate the whole mess, but also cause some backlash. I would consider this a "last effort" tactic.
• Off-Site Voting: Set up a disinterested third-party vote somewhere else. This would require anyone who wanted to vote to probably have to register somewhere else (unless the member database is shared or somehow coded to allow outside queries).
• Public Voting: Another potential possibility, but it could affect the outcome and/or voter response.

Have I missed anything?

Going off what I have, we have the following potentially viable metrics to consider:

• E-mail Address: One vote per e-mail address. (Of limited use.)
• Forum Posts: Minimum number of posts (ie, 50, 100, etc).
• Length Of Membership: Must be a member for a minimum amount of time.

Combining the three in a database query would be relatively easy. However, does this resolve enough of the potential problems to make it worthwhile?

When you get down to the "brass tacks", you can see the potential problems and that an "easy solution" may not be that easy. ;0)