Option polls with indefinite duration?

[makoConstruct]

I'm thinking of using a long-running vodle choice poll to pick topics for my meetup group. Whatever the top option is would be picked, and then it would be removed, and we'd do the next top on the next event, and so on. We would not want to throw away the losing suggestions, as today's unpopular option is tomorrow's best available compromise. It's possible this wont really be good, but I'd like to try it.

Apologies if this is possible by like, taking a concluded poll and cloning it or editing it repeatedly with a new closing date, or something. I wasn't able to create a poll and test the thing because of a bug that's too obvious to bother reporting (the "[tick] ready" button is, I think, greyed out, and clicking it does not work).

[mensch72]

Hi @makoConstruct ,
first on that "ready" bug: if that happens, please try setting the poll end date freshly, this seemed to resolve it to me. I believe otherwise the validator thinks the end date is invalid. I will look at that issue

Then, thank you for suggesting this feature. It sounds like an interesting and valid use case. For now, I think the fastest solution I could offer at this point is:

1. Let users "duplicate" ended polls. This would open the poll drafting page with the old poll's data prefilled, so that you could then remove the last option and set a new end date.

Would that help for now? If so, I guess we can include this feature in the backlog for V1.0.

It would however not copy the earlier waps, so participants would have to evaluate all options freshly. So the next step would be:

2. Offer participants in the new poll to copy their waps from the previous poll at any time during the new poll. Or even more conveniently: Offer a toggle that shows the old waps alongside the new ones, and offer a "copy" button next to each slider. And then maybe even offer an "undo" button as well...

Btw, I will turn this issue item into a discussion item until we settled on what solution we want.

[makoConstruct]

Hmm, no, I think if you required users to repeatedly reapply their votes (as if this task cannot be automated) they would get genuinely mad. In some cases it might be better to not implement a flawed half-measure at all, because the way your software is right now is the clearest and loudest expression users will receive about what the software is. They might not infer that this isn't the final design.

Why couldn't you copy all of the information over? (What's a wap?)

[mensch72]

So in the use case you have in mind, you expect most user's preferences to basically stay the same from poll to poll even though some options get removed and others added?
It seems that the best would then be to:

• Let a user duplicate an existing poll, no matter whether running or ended. When doing so, ask the user whether she also wants to automatically make the new poll available to all the participants of the existing poll.
• If the decides to do that, then all participants of the existing poll are notified that there is a follow-up poll, and will be given the opportunity to copy over their existing waps (via a checkbox that is checked by default).

A wap (willingness to approve) is the main information that a poll participant gives to each option when participating in a poll. It is a number between 0 and 100 that the participant selects via a slider. 0 means "don't approve", 100 means "approve for sure", 1–99 means "approve if enough others approve". See the app's help page for more details. On the code level, waps are called "ratings", but in the user interface of the app, we later decided to avoid the term "rating" and use the invented word "wap" instead, because early tests showed that that word suggested some wrong assumptions about the tallying algorithm.

[makoConstruct]

you expect most user's preferences to basically stay the same from poll to poll even though some options get removed and others added?

Good question. Oof. Very predictable problem where users don't quickly notice when new options are added and vote count kind of corresponds to age.
I wonder if you'd be able to do something where the poll marks new options in a sense... uncompared relative to the others, until users start to update their votes after the addition of the new options, at which point they start to be ranked according to the rate at which they win within the sets of votes that include them, rather than on absolute sum wap. I think this is possible, but I don't know what the formulas nor algorithms for it would be, but I might be find some hints if you'd be interested.

There's a general principle I'd like to see explored more in voting theory, that we should not ask voters to implicitly harm the chances of candidates that they don't know anything about, but this is what happens in every voting system I know of, we end up measuring not just preferences, but noteriety and legibility, which are often not important.

[mensch72]

This points to an important issue even without the context of repeated polls: How to deal with options that are added by participants only after a poll has started, maybe even shortly before the end.

• They should certainly be marked somehow, probably for every participant as long as that participant has not expanded the new option's details or touched its wap slider.
• Maybe then all initial options that a participant has not looked at (expanded their details or touched the wap slider) should be marked as "new" as well.
• Participants should also be notified about new options (this is already on my agenda)
• They must however otherwise not be treated differently from the earlier options, otherwise the whole procedure would become non-neutral and would give incentives for agenda manipulation.
• When a poll is duplicated from an earlier poll but some options have been removed, then the welcome page for that poll (joinpoll.page.ts) should also notify about this perhaps, and the voting gui should also mention this somehow, maybe at the very bottom in an expandable "notes" section that would also contain the link to the previous poll so that participants can compare and revisit its results.

In the context of the last point, I want to emphasize that the ranking is not by total wap sum but by number of approvals. (Only if two options happen to have the exact same number of approvals, then the total wap sum serves as a tie-breaker for their ranking). Still, you are right that new options, getting initially a default wap of zero from all participants, will have initially no approval and therefore show up at the bottom of the list. One more reason to notify users of their presence.

[makoConstruct]

Maybe there should be two phases to each poll then: requesting options, and then having people vote on them. This would reduce the number of notifications produced by each poll to exactly 2, it would obligate much less attention, instead of having to pay ongoing attention to a poll, there would be two periods where users can look in on it at any time and then be done with it.

[mensch72]

Ah, but the interactivity is an essential feature of vodle that allows participants to see when they need to spend more effort to find a compromise option when there is not enough agreement yet. We will certainly not disable that! There is no "be done with it", it is a process that is meant to end in as broad an agreement as possible, aiming for consensus.