reubenyap
12 augustus 2024 om 09:53
1
We have a ranked choice poll here: [POLL] Final Tokenomics and Block Division - Polls - The Firo Forum
We allow people to change their votes until the close date.
However, when we change our votes, it is not reflected in the Results/Vote tab. I can’t find a way to export the data from the poll even though I’m an admin.
@merefield FIX: poll ranked choice result algo majority check by merefield · Pull Request #28191 · discourse/discourse · GitHub .
2 likes
merefield
12 augustus 2024 om 09:56
2
Hi Reuben, I’ll PM you to discuss more details.
1 like
merefield
12 augustus 2024 om 13:29
3
So it looks like Reuben had somehow not picked up the recent fix, and it looks as though the outcome of his poll resolved correctly after updating.
I also advised him to add the data explorer plugin or else there will not be a export option. (this is normal)
However, we found a related issue with expanding the list of voters in results (when they number over 25) for ranked choice (the issue does not exist in standard polls)
Fix is here:
main ← merefield:fix_ranked_choice_voters_expand
merged 07:28AM - 13 Aug 24 UTC
initially, the list of voters shown on the poll results has a limit of 25 per op… tion.
If the actual number of voters is longer, a button is presented to allow the user to load another page of voters if they so choose.
This calls a method to retrieve the extra voter information.
a bug existed such that the local tracked object was not correctly updated for ranked choice voters as there are two attributes per option, one which tells the interface if new data is currently loading, and the other contains the list of voters.
so instead of updating the entire option key with the voters list, we must update the voters attribute only.
a small but critical change.
The PR includes a significant new test which will add coverage over and above this issue.
merefield
13 augustus 2024 om 09:16
4
@reubenyap this has been merged now, please update your instance and the fix should be present. Please confirm.
Hi, after the update, it still does not show the people that changes their votes.
Clicking the “more/expand” button below each vote only shows it.
Which then switch back to the earlier(SS1) a couple of seconds later.
merefield
13 augustus 2024 om 13:08
7
ajaydono:
Hi, after the update
Can you please share the commit of Discourse you are on, from the dashboard?
merefield
13 augustus 2024 om 13:28
9
OK, believe it or not, the fix genuinely improved things, but this does need additional work to prevent the updates “resetting” which in Production happens quicker than in dev.
We need to consider carefully how we handle incoming updates after having expanded the voter list.
I’m tempted to freeze the voter list from remote updates once you’ve clicked the button or set a timeout to allow you to inspect the voter list for a limited time before accepting updates from the server.
Thanks for your patience.
1 like
reubenyap
13 augustus 2024 om 13:52
10
The voter list changes DRASTICALLY though which is beyond what an ordinary vote change is. I think there’s still something wrong.
BEFORE clicking
1 like
reubenyap
13 augustus 2024 om 13:53
11
After clicking all the buttons: See how it’s a vast shift and people go missing.
1 like
merefield
14 augustus 2024 om 08:35
12
The additional PR has been raised:
main ← merefield:fix_poll_voter_list_expansion
merged 05:55AM - 19 Aug 24 UTC
An additional follow-up change on top of #28315 (which is still a valid improvem… ent) is required as currently expanded voter lists are almost immediately overwritten by incoming data on the message bus and post stream and effectively cancels the expansion leading to an uncomfortable user experience. This was unfortunately not picked up during unit testing nor by manual testing because in dev the refresh cycle is so long.
So to prevent this and allow a user time to examine the expanded voter list, this change renders incoming updates for voter user lists disabled as soon as any option's voters list is expanded. This only impacts big polls with > 25 voters on an option,
I believe this is a reasonable compromise and it still allows polls with fewer than 26 votes on an option to continue to be streamed updates to voter population as this change does not affect that scale of poll as there is never any expansion action.
Background:
`preloadedVoters` is a list of all users who have voted. It is maintained locally on the client because the data can change from incoming updates from remote voting events _and_ from local events, such as voting or expansion of the collapsed list of voters.
In order to save resources, the server by default will initially only serialize the first 25 voters (per option) down to the client. If the user wishes to see more, they hit the provided expand button. This will pull down an additional page of voters. There are therefore two paths for update and the server does not keep track of the state of the local user interface.
More on the fix:
A user can restore the update process by navigating away from the Topic and returning or refreshing the browser (and that will revert the expanded list to the collapsed view - no change in that behaviour).
It obviously has no downside on Closed polls.
Test updated to reflect the change.
3 likes
reubenyap
16 augustus 2024 om 16:54
13
Just checking, is it expected that before you expand your vote, you don’t see your vote in the votes provided you changed your vote sometime before?
For example I changed my vote a couple of days ago but when I go back to the poll, my vote on the display is listing though it does appear in the raw data.
merefield
19 augustus 2024 om 08:42
14
Hi @reubenyap - didn’t really make sense to investigate further until that fix was merged.
It is now merged.
You should see a significant improvement.
If there is a remaining issue I will follow up in time. Let me know how you get on with this improvement.
reubenyap
19 augustus 2024 om 12:42
15
The voter list before expanding and after expanding is still different (though consistently so even across different users).
@ajaydono and @Anwar will provide more details.
merefield
19 augustus 2024 om 12:44
16
The voter list being different is expected.
You essentially start with a limited list of voters and once expanded you get more voters.
If votes change (e.g. from rank 1 to rank 2) that would be an issue, but in my testing I’ve not observed that.
Note that once you expand the list, the voting is frozen in the state when you expanded and will no longer be updated in real time. This is currently a necessary trade-off.
merefield
2 september 2024 om 06:55
19
Please note this PR was raised and should fully close this issue out for good, having already been tested on the bug raisers instance via a fork of the poll plugin:
main ← merefield:ranked_choice_voter_expansion_fix
merged 01:28AM - 05 Nov 24 UTC
Currently, for Ranked Choice results and voter list expansion, the code is repla… cing the voter list with the newly fetched page of voters instead of appending to the existing voter list. This is resolved in this PR and brings it in line with regular polls.
See: https://meta.discourse.org/t/ranked-choice-poll-does-not-reflect-change-of-votes-in-outcome/321227/18?u=merefield
I've made the tests more strict to cover this and confirmed test failure with existing code without this fix.
NB I'm aware code changes around this functionality have been a little numerous of late, so this time, in the interest of minimising review burden and curtailing the iteration, I made sure the changes in this PR were fully tested in Production on the very poll which identified the issue. We've successfully tested the solution in the Production instance of the bug raiser and they have signed off. (We removed the core plugin in app.yml and cloned a fork of Poll that includes these changes).
2 likes
merefield
18 september 2024 om 06:58
20
Be grateful if we could merge this fix, before the code becomes dated.
2 likes
Anwar
18 september 2024 om 11:27
21
A merge of this PR would be nice, as it helped our community immensely and would be of use in other Discourse communities as well.
1 like
