Project Formation Algorithm supports new config & constraints

[bundacia]

The Project formation algorithm needs several related changes. It must:

• [ ] Support using a configured list of advanced players.
• [ ] Enforce new constraints
• [ ] Consider list of prioritized optimizations

Some of this is needed for the algorithm to be able to run inside "voting pools". The work for creating voting pools is tracked in a separate issue (#427).

[bundacia]

@shereefb / @tannerwelsh: I have a clarifying question about about "making players votes count":

Players get two votes. Should we weight those votes equally, or give their first vote more weight and prefer outcomes where people get their first vote over those in which they get their second?

[bundacia]

Follow up: Assuming that we do want to prioritize 1st votes over 2nd ones, how much more is the first vote "worth". Let's say I'm evaluating these two outcomes in a pool of 10 people.

1. 5/10 people got their first choice and 5/10 people got things they didn't vote on.
2. 10/10 people got their second choice

If I give scenario 1 a grade of 50%, what grade should scenario 2 get? If we say that the second vote is worth half of the first, than the second scenario would also get a score of 50%.

That seems low to me since everyone getting something they voted on seems better than half of the players votes being ignored. If we weight 2nd votes at 0.8 of a 1st vote than the second scenario gets a score of %80, meaning it would be chosen over an outcome where 7/10 people got their first vote.

This will be an easy thing to adjust (and could eventually be configured by the moderator). My gut is to start off weighting 2nd votes at 70-80% of 1st votes. WDYT?

cc @tannerwelsh, @shereefb

[heyheyjp]

@bundacia: as vote preferences are point of optimization (rather than a strict requirement), it doesn't seem that accommodating player votes need be as complicated as this. The way I thought about optimizations & prioritization when implementing v0 of the algo was that they are essentially tie breakers. That is, given that all constraints are met and higher priority optimizations have been made, if the outcome is still non-deterministic, remove the option that least satisfies the next highest priority optimization. Repeat as necessary until you reach the terminal (singular) option. Does this help?

[heyheyjp]

also, i think we should try to avoid ever making assumptions in project formation logic that there will only ever be exactly 2 votes submitted by each player. this is primarily a UX constraint currently (afaik), and v0 of the formation algo doesn't make any such assumption.

[shereefb]

70% sounds about right.

On Fri, Aug 19, 2016 at 9:29 AM, Trevor Little notifications@github.com wrote:

Follow up: Assuming that we do want to prioritize 1st votes over 2nd ones, how much more is the first vote "worth". Let's say I'm evaluating these two outcomes in a pool of 10 people.

1. 5/10 people got their first choice and 5/10 people got things they didn't vote on.
2. 10/10 people got their second choice

If I give scenario 1 a grade of 50%, what grade should scenario 2 get? If we say that the second vote is worth half of the first, than the second scenario would also get a score of 50%.

That seems low to me since everyone getting something they voted on seems better than half of the players votes being ignored. If we weight 2nd votes at 0.8 of a 1st vote than the second scenario gets a score of %80, meaning it would be chosen over an outcome where 7/10 people got their first vote.

This will be an easy thing to adjust (and could eventually be configured by the moderator). My gut is to start off weighting 2nd votes at 70-80% of 1st votes. WDYT?

cc @tannerwelsh https://github.com/tannerwelsh, @shereefb https://github.com/shereefb

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LearnersGuild/game/issues/426#issuecomment-241066402, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGoAZvioE3kYYk9IePEfiImRiegbsv-ks5qhdn_gaJpZM4Jn41B .

Schedule time with me: https://calendly.com/shereef https://via.intercom.io/e?ob=k4XZlLJri6SLkFHzB6WH8bHNlvRYyYIqi54GeaH7Fzw%3D&h=0d8a6ba26a76a151ed05ecd54932578940f8c56d-1436053208

“Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral.” - Paulo Freire

“When they tell you to grow up, they mean stop growing.” ~ Tom Robbins

[heyheyjp]

@bundacia, @shereefb: sounds like this is something that should be expressed as another prioritized optimization?

[bundacia]

Looking back at the requirements with @prattsj we realized that this would be a slight change. Right now we have two separate "prioritized optimizations" about voting:

2. Maximize number of players assigned to the primary goal that they voted for
3. Maximize number of players assigned to the secondary goal that they voted for

I'm proposing that we combine those two into one and express the relative of 1st/2nd votes with a percentage. As written the requirements would choose scenario 1 in my comment above (where half of the people are working on things they didn't vote for) over scenario 2 (where everyone is working on something they voted on). That seems wrong and I think this simple change would address that.

[bundacia]

I'll go with 70% for now. It's easy to change later if needed.

[tannerwelsh]

Sounds good to me @bundacia.

As a reminder, the 2-vote limitation was applied so that we could use the Single transferable vote method. That's one way to resolve this problem without using weighting.

Granted, I'd only suggest going down that path if you can use it in such a way that doesn't cause too many headaches if/when we switch to 1..n votes in the future as per @prattsj's comment.

[bundacia]

My gut is to move away from SVT now that the requirements are more complex. We need to not only pick the "most popular N goals" but we actually need to maximize the number of people on goals they voted for. This could mean choosing an "unpopular" goal if there are enough people who voted for it to form a team. Also, we're looking at votes as a single factor weighed against several others when forming projects which further complicates things.