Allow a higher number of votes than options at creation time

[Manuzor]

Currently, there's no way (that I'm aware of) that would allow users to add options and to have everyone able to vote for all options. The number of votes per user is currently set at creation time of the poll and is capped at the number of options at that time. However, when a new option is added later by someone else, the maximum number of votes per user stays the same.

With the experimental GUI this means that right now the maximum number of votes allowed is 3 since there's no way to add more than 3 options at creation time.

I suggest removing the upper limit on votes altogether. This would allow the creator of the poll to just specify --votes=99 and be done with it.

I suppose this the function that would have to change: https://github.com/matterpoll/matterpoll/blob/1f381a508314e737f7e6d1de59aed968ab3d937f/server/poll/poll.go#L164-L179

[OnlineCop]

There might be a few ways to handle this. Assuming the following for illustration:

• the poll was created with 4 default options: /poll "Should users add options?" "Yes" "I guess" "Better not" "No" --public-add-option
• two options were submitted by users: "On the fence", "HR would disapprove"

1. --votes=n could allow n <= 0:

   • n>0 indicates the hard limit of all options, whether default or user-submitted.
   • n=0 indicates "max" votes: users may vote for any/all default or user-submitted options.
   • n<0 indicates the hard limit of votes for default options (its absolute value would be used, examples below), but users receive one additional vote for each user-submitted option.
     • Given --votes=0, users have 6 votes: 4 for the default ["Yes" "I guess" "Better not" "No"] options, plus 2 for the user-submitted ["On the fence", "HR would disapprove"] options.
     • Given --votes=-1, users may only select 1 from the default options, but may additionally select one or both from the user-submitted options.
     • Given --votes=-2, users may select 2 from the first default options, and one or both from the user-submitted options.
   • This has the disadvantage that the poll creator couldn't limit votes for user-submitted options: if there were 10 user-submitted options, a user would have abs(p.Settings.MaxVotes) votes for default options plus 10 more votes for each of the user-submitted ones.

2. --votes=n could allow n = 0, and add --public-add-option-vote=m where m >= 0:

   • Users would only be allowed to use these votes toward user-submitted options, not toward default options.
   • n=0 indicates "max" votes for default options, but does not affect votes toward user-submitted options.
   • m=0 indicates "max" votes for user-submitted options; for each user-submitted option, 1 extra vote is given to each user.
   • m>0 indicates the hard limit of votes for user-submitted options.
     • Given --votes=1 --public-add-option-vote=0, users have 3 votes: 1 for the default ["Yes" "I guess" "Better not" "No"] options, plus 2 for the user-submitted ["On the fence", "HR would disapprove"] options.
     • Given --votes=1 --public-add-option-vote=1, users have 2 votes: 1 for the default options, plus 1 for the user-submitted options.
     • Given --votes=1 --public-add-option-vote=10, users have 3 votes: 1 for the default options, plus 2 for the two (existing) user-submitted options. As more user-submitted options were added, users would gain additional votes, up to a max of 10 votes (for user-submitted options). Therefore, if 15 user-submitted options were provided, '10' would still be the upper limit.
     • Given --votes=0 --public-add-option-vote=1, users have 5 votes: 4 for the default options, plus 1 for the user-submitted options.

These ideas aren't exhaustive; feel free to reply with suggestions/additions.

[naresh97]

I'm working around this issue by simply removing the upper limit, although I consider that a hacky fix.