proposal order

A question for Patrick May. Is the order in which voters view the proposals
fixed? In other words, does everyone view proposal X0 first, then proposal
X1 etc? I've heard a couple of people so far say they only got through 30 or
so of the proposals.

Perhaps 'ideally', the order in which the proposals are viewed would be
random for each viewer/reader. I guess that'd be a 'next year' thing though.
You probably wouldn't want to muck with it at this point.

ja
http://vispo.com

Comments

, ryan griffis

That's a good point Jim… i kind of assumed it was random, but if it's
not, that could be very prejudicial.
ryan

On Apr 27, 2006, at 4:09 PM, Jim Andrews wrote:

> A question for Patrick May. Is the order in which voters view the
> proposals
> fixed? In other words, does everyone view proposal X0 first, then
> proposal
> X1 etc? I've heard a couple of people so far say they only got through
> 30 or
> so of the proposals.
>
> Perhaps 'ideally', the order in which the proposals are viewed would be
> random for each viewer/reader. I guess that'd be a 'next year' thing
> though.
> You probably wouldn't want to muck with it at this point.
>
> ja
> http://vispo.com

, Jim Andrews

> That's a good point Jim… i kind of assumed it was random, but if it's
> not, that could be very prejudicial.
> ryan

I just assumed it would be fixed, because that's the easiest way to program
it. Which is not a knock on Patrick or Francis, just the way it goes,
usually, in the first few iterations of such programs.

It wouldn't be a problem if there were 30 proposals, but with 195, yes, it
probably is.

Which is another reason why it's probably good to have a regular jury
looking at things after the voting.

I think eventually the voting software will be pretty cool, but I doubt it
deals with things like this, at the mo. Could be wrong though.

ja

, Eric Dymond

Randomizing the presentation would certainly be a step in the right direction. I must admit though, given the volume of submissions, which reflects well on Rhizome, is still an issue.
A random generator would still fail on a technical point.
Given that we present 10-20 projects per page, the randomizer wouldn't necessarily exclude prior listings, once again given that numerous users are acticely voting. If I decide to view 20 projects on one computer, and then come back and view the next 20 on another, time and location of the user become a problem.
The programming would have to flag every voter, randomize and then exclude based upon prior views. The error here would be to exclude works that you might want to see a second time.

It's actually a very tough programming/design problem.

I supppose there is a way to do it , but I am pretty experienced at these types of programming problems, and this one is very difficult, given the very different definitions of users on the commisions base.
The submission process is pretty straightforward, but the voting process works best when there a far fewer candidates.

As it stands, my answer is simple. If you care about the process, go through all the submissions. If the user has been flagged with all sites seen.. (and I do mean every one), then they can vote.
I'm certainly open to suggestions, but 175 possibilities is tough to set up, and nearly impossible to present without a complete conviction on the part of the voter.

Eric

, Pall Thayer

If I recall correctly, an explanation on how the proposals are
presented by the system was provided and states that projects that
haven't received many votes will automatically move to the front so
that later voters will see them first. I think randomizing it would
have been fairer but at least there is something there to ensure that
all projects are presented to people.

Pall

On 27.4.2006, at 22:52, Eric Dymond wrote:

> Randomizing the presentation would certainly be a step in the right
> direction. I must admit though, given the volume of submissions,
> which reflects well on Rhizome, is still an issue.
> A random generator would still fail on a technical point.
> Given that we present 10-20 projects per page, the randomizer
> wouldn't necessarily exclude prior listings, once again given that
> numerous users are acticely voting. If I decide to view 20 projects
> on one computer, and then come back and view the next 20 on
> another, time and location of the user become a problem.
> The programming would have to flag every voter, randomize and then
> exclude based upon prior views. The error here would be to exclude
> works that you might want to see a second time.
>
> It's actually a very tough programming/design problem.
>
> I supppose there is a way to do it , but I am pretty experienced at
> these types of programming problems, and this one is very
> difficult, given the very different definitions of users on the
> commisions base.
> The submission process is pretty straightforward, but the voting
> process works best when there a far fewer candidates.
>
> As it stands, my answer is simple. If you care about the process,
> go through all the submissions. If the user has been flagged with
> all sites seen.. (and I do mean every one), then they can vote.
> I'm certainly open to suggestions, but 175 possibilities is tough
> to set up, and nearly impossible to present without a complete
> conviction on the part of the voter.
>
> Eric
>
>
> +
> -> post: [email protected]
> -> questions: [email protected]
> -> subscribe/unsubscribe: http://rhizome.org/preferences/
> subscribe.rhiz
> -> give: http://rhizome.org/support
> +
> Subscribers to Rhizome are subject to the terms set out in the
> Membership Agreement available online at http://rhizome.org/info/
> 29.php
>




Pall Thayer
[email protected]
http://www.this.is/pallit

, Eric Dymond

Pall Thayer wrote:

> If I recall correctly, an explanation on how the proposals are
> presented by the system was provided and states that projects that
> haven't received many votes will automatically move to the front so
> that later voters will see them first. I think randomizing it would
> have been fairer but at least there is something there to ensure that
>
> all projects are presented to people.
>
> Pall
The process still has errors though.
What if I vote after 50 viewings, or 100.
The others, although rising to the top will still escape my view.
As well , rising to the top is time based, and if the viewers come in at an ad hoc way then the presentation becomes weighted as well.
I still think that only the voters that have viewed all the proposals should be allowed to vote.
It would be easy to set up a network of friendly users to upset the vote, but thats the way the world works.
I hope that Lauren and the other judges take the voting with a small grain of salt and blend it with thier own belief systems.
Eric

, Jim Andrews

> If I recall correctly, an explanation on how the proposals are
> presented by the system was provided and states that projects that
> haven't received many votes will automatically move to the front so
> that later voters will see them first. I think randomizing it would
> have been fairer but at least there is something there to ensure that
> all projects are presented to people.
>
> Pall

Sorry, I missed that.

I agree that randomizing it would be better. Randomizing it in the sense
that the order in which the proposals are viewed by any particular voter is
fixed but random. In other words, when a voter logs in, a random permutation
of the numbers 1 to 195 (or however many proposals there are) is associated
with that voter, and that's the order that voter will see the proposals in
for that session.

That way, there should be no statistically significant relation between the
number of votes a proposal receives and the order in which the proposals are
viewed–overall (over all voters).

on generateRandomPerm n
–n is the number of proposals.
–This handler returns a random permutation
–of the integers from 1 to n.
a=[]
repeat with i=1 to n
a.append(i)
end repeat
–a is a list from 1 to n
b=[]
–List b will be our random permutation
–of the integers from 1 to n.
repeat with i=n down to 1
x=random(i)
–x is a random integer
–from 1 to i
b.append(a[x])
a.deleteAt(x)
end repeat
return b
end

ja
http://vispo.com

, Eric Dymond

The sample is too small to yield a fair distribution using a random generator.
Check out the laws of probability and statistics. Some applicants will get lucky, while some will lose out.
Now if there were 100,000 voters, and 195 applicants, then the distribution curve would be fairer using your model (but still not completely fair).
Eric

, Patrick May

Jim,

The order is not fixed. The proposals are first sorted by number of
votes. The purpose is to ensure all the proposals receive equal
attention, so Yes and No votes are both counted. Then, within a
given range of votes, the proposals are randomly sorted. So for
example, if we have these proposals:

Foo: 4 yes, 8 no = 12 votes
Bar: 3 yes, 2 no = 5 votes
Widget: 1 yes, 2 no = 3 votes
Thingy: 1 yes, 4 no = 5 votes

Then the first proposal on the ballot would be:

Widget: 1 yes, 2 no = 3 votes

These two would be next, in a random order:

Bar: 3 yes, 2 no = 5 votes
Thingy: 1 yes, 4 no = 5 votes

Finally, since this project has received the most attention, it would
be last:

Foo: 4 yes, 8 no = 12 votes

The ballot design ensures that proposals receive the same amount of
attention, even if individual voters don't view all the proposals.
This is much the same design as last year. The random sort was an
addition made this year because last year it was observed that naming
a proposal 'Aa…' would give an advantage.

Reading all the commissions, while rewarding, is a major commitment.
I greatly appreciate the Rhizome members who took the time to review
every proposal.

Cheers,

Patrick




Patrick May
Director of Technology
Rhizome.org
phone: (212) 219-1288 x202
AIM: cyclochew
+ + +


On Apr 27, 2006, at 5:09 PM, Jim Andrews wrote:

> A question for Patrick May. Is the order in which voters view the
> proposals
> fixed? In other words, does everyone view proposal X0 first, then
> proposal
> X1 etc? I've heard a couple of people so far say they only got
> through 30 or
> so of the proposals.
>
> Perhaps 'ideally', the order in which the proposals are viewed
> would be
> random for each viewer/reader. I guess that'd be a 'next year'
> thing though.
> You probably wouldn't want to muck with it at this point.
>
> ja
> http://vispo.com
>
>
> +
> -> post: [email protected]
> -> questions: [email protected]
> -> subscribe/unsubscribe: http://rhizome.org/preferences/
> subscribe.rhiz
> -> give: http://rhizome.org/support
> +
> Subscribers to Rhizome are subject to the terms set out in the
> Membership Agreement available online at http://rhizome.org/info/
> 29.php

, Jim Andrews

You guys are on the job, Patrick. Thanks. Your procedure distributes the jar
of eyeballs evenly among the proposals. That sounds fair to me.

ja
http://vispo.com

, Lee Wells

As I see it and with the system as it is all yes or no votes go into your
approval stage review page. From there dig in and really look into the
proposals. I've since gone back in and reevaluated my original selections a
couple times now. Fairness is relative. Once you make your initial votes
they are all in one list. First and last make no difference at that point.



On 4/28/06 10:53 AM, "Eric Dymond" <[email protected]> wrote:

> The sample is too small to yield a fair distribution using a random generator.
> Check out the laws of probability and statistics. Some applicants will get
> lucky, while some will lose out.
> Now if there were 100,000 voters, and 195 applicants, then the distribution
> curve would be fairer using your model (but still not completely fair).
> Eric
> +
> -> post: [email protected]
> -> questions: [email protected]
> -> subscribe/unsubscribe: http://rhizome.org/preferences/subscribe.rhiz
> -> give: http://rhizome.org/support
> +
> Subscribers to Rhizome are subject to the terms set out in the
> Membership Agreement available online at http://rhizome.org/info/29.php


Lee Wells
Brooklyn, NY 11222

http://www.leewells.org
http://www.perpetualartmachine.com
917 723 2524