Repository navigation
feat: extra settings for ranking question type #3378
Description
Activity
Hi @sharko789,
thanks for the interest! Glad to hear other will also benefit from this question-type! Unfortunately work has been a little crazy, hence I cannot really commit to making these adjustments. I´d be happy to hand-off to whoever is willing to implement this!
We would also have to think through a smart default - what would be the expected behavior if the question is mandatory but no options limit given vs. non-mandatory question, but with a minimum of 3 ranked options, etc.
But definitely understand the use-case and how that would be useful!
Reacted by sharko789I had a quick look at Microsoft Forms: they also don't have an option to only rank a few options.
Calculating the Borda count would falsify the result then. If you have 10 elements (e.g. colors) and red is your favorite color, it would get 10 points if you rank all options, but only 3 if you rank only 3 of them. No problem for single submission results, but for the totals.
So I'm against implementing this.
I see you point @Chartman123. I hadn't considered that because in my scenario all the users would max out the limit and hence have the same amount of options.
So maybe we don't reuseoptionsLimitMax/optionsLimitMaxand just introduce a single setting that forces the ranking of exactly n options?We could still use the existing ones and set them to the same value in the backend. But what's the problem with ranking all options in the first place? Why do you really need the subset?
My usecase is basically about choosing what to do. E.g. there is 10 things the group wants to do, but there is only time to do 5, so everyone gets 5 votes.
Ok, but why not rank all 10 options and then choose the top 5? So your participants can also rank the options they don't like?
Reacted by paulbochtlerIt's simply not an option, it is the way our system works and it's not going to change (or up to me to change it). That's why I am hoping we can get this implemented so forms can do this natively.
So, is this where we're going to leave it?
I'm interested in voting algorithms, particularly in Schulze and CPO-STV, which, compared to Borda count, are more computationally heavy but also more resistant to spoiler effect and achieve results closer to consensus or Condorcet criterion (see Wikipedia tables about electoral systems). These methods also allow for partial ranking, like @sharko789 asks for. I think of implementing one of them in my AGPL-3.0-or-later type-checked Node.js app with a test suite and later porting the code to PHP for Nextcloud Forms, because I want it be useful to more than just my deployment. I'd like to ask beforehand, would Nextcloud developers mind if I rewrote ResultsSummary to use a multi-winner algorithm of this family of instead of the Borda count? Note that I can only implement the script close to the definition of the algorithm, not an optimized version. I also don't know when exactly I'll have time for this, but it's in my plans for the year.
@nykula you don't have to port it to PHP for Forms, we only store the order of the ranked options to the DB and the results are then rendered in the front-end.
A quick search lead me to this project (https://github.com/lzear/votes) here, that already holds several ranked voting systems. I can imagine integrating this as an
extraSettingfor ranking questions to choose one of these.- Thanks for recommendation. The library seems to focus on single-winner methods, so it won't have the same mathematical properties as the STV-family algorithms described in their papers. Nonetheless, the "iterated ranking" feature looks intuitively close to what I want for multi-winner elections. I'll first be trying the library locally for a while to see how it works in practice.
Perhaps you can also find other packages that better suits your/our needs. As I said I only invested a few minutes in searching :)
Reacted by Denys Nykula@nykula there's also already a PHP framework that might be interesting: https://github.com/julien-boudry/Condorcet
Reacted by Denys NykulaMy usecase is basically about choosing what to do. E.g. there is 10 things the group wants to do, but there is only time to do 5, so everyone gets 5 votes.
Hi. I'd like to add to the discussion that independent of the exact ranking system used, I support the use case of "pick n out if m". My use case is very similar and can maybe be compared to of assigning priorities for sprint planning.
In fact, the UI IMO currently implies that this use case is supported, as the items to rank first have to be selected by the user. Since currently all items have to be selected anyway, this can adds up to m clicks to the user interaction (if the user then resorts all items). More importantly, it implies that you can select only a subset, but then get an error message when trying tk submit.
I suggest that for rankings that require all items to be selected, the items are directly shown as ranked list for resorting, without the "click to select" step. This can be applied either for the current implementation or as special case for maxOptions == minOptions == m, in case that feature is accepted.
If you prefer to track this UI change in a separate issue, I'm happy to open a new ticket. I'd also be open to try and have a fo at the change myself (but would be happy for some getting started pointers :D)Cheers, Hinrich
Nextcloud:
Is your feature request related to a problem? Please describe.
I am regularly holding a vote through Nextcloud Forms where users have to rank a subset from a list of options. The results are then weighted using a Borda count. (n points for the first/top choice, 1 point for the last/lowest choice)
Describe the solution you'd like
The new ranking question type is great and almost exactly what I need. The only problem is, that it forces the user to rank all available options. There already exists the extra setting
optionsLimitMaxfor the multiple question type, so could that be implemented for the ranking as well? (andoptionsLimitMinshould probably be implemented alongside it)The Borda count code would have to be modified as well to be based on the amount of actually submitted options instead of all available options.
Describe alternatives you've considered
I am currently working around this limitation by using multiple dropdown inputs (one for each choice), exporting the submissions as CSV and pipe them through some python code to sort out potential duplicates and do the actual weighted counting.
Additional context
#1278
#3262
@datapumpernickel would you be willing to work on this or should someone else take a look at it?