dcrdata
dcrdata copied to clipboard
multi: Expose more treasury mechanics on TSpend tx page
- show max possible votes for the voting interval.
- show min required votes(quorum).
- show approx. calendar dates of start and end blocks.
- show quorum pass progress.
- show required yes votes pass progress.
- show which Pi key signed the TSpend. closes #1835
Before the second commit, the TSpend vote meter looks like the one we have on the proposal page:

The second commit modified the vote meter to display the actual percentage of yes votes of possible votes (total votes + Maxremaining Votes), leaving the table to show the percentage of yes votes of total votes.

Meant to deploy while a tspend was in mempool but missed the window, sorry.
Thanks for the review. I'm looking to re-test this with a live tspend which might come by in the next few days.
The second commit modified the vote meter to display the actual percentage of yes votes of possible votes (total votes + Maxremaining Votes), leaving the table to show the percentage of yes votes of total votes.
This makes it look like it's on track to fail. If it has no "no" votes, it's approval should be 100%, not some small number. Quorum is a separate concept and trying to consider either quorum (3456) or max possible votes (13,534?) makes it more confusing. "X% approval of N possible" has little meaning because the max possible is rarely achieved, so it will look to be failing until the moment the voting interval is over and it actually passes (assuming quorum met).
PR running at https://tip.dcrdata.org
"X% approval of N possible" has little meaning because the max possible is rarely achieved, so it will look to be failing until the moment the voting interval is over and it actually passes
So you mean, we can ignore "possible votes" while calculating the percentage for the text display and vote meter just as it was before my second commit? i.e (x% of total votes).
The text display and vote meter tries to provide the overall percentage (including possible votes) but maybe a correct behaviour is to display yes% of total votes? Btw, this info is already on the table.
EDIT: I've resolved this possible confusion in https://github.com/decred/dcrdata/pull/1918/commits/09fd9791a06b1fbce62297ae6151eed4a818a34f.
PR running at https://tip.dcrdata.org
Cool.
"Min Required Yes Votes" was discussed at lenght in chat. I found a simple way to explain why I found it confusing, and more generally what a "normal" user may expect from tspend info section.
As a user I'd like to see if things are "looking good" for the current tspend. TSpend has two milestones to achieve - quorum and threshold.
- First I want to see the quorum thing, so I need the votes cast and votes for quorum (e.g. 1,883 cast, and 3,456 quorum). Personally I love seeing the 3,456 number because I keep forgetting it and deriving it from DCP-6 every time, which is not productive.
- Second is I need the Yes-vs-No breakdown as of now - e.g. 1,883 Yes, 0 No, 100% approval.
- Now that I have the facts, next I need some projection of what to expect. There can be many algos to simulate different scenarios (iirc matheusd had some script for that), but maybe a simple one would do for now. For example: "If vote continues at current approval (100%) and turnout (41%) rates, the spend will be (approved|rejected) in N days".
I guess some of this is already taken care of in the last commits but just in case. Thanks.
Now that I have the facts, next I need some projection of what to expect. There can be many algos to simulate different scenarios (iirc matheusd had some script for that), but maybe a simple one would do for now. For example: "If vote continues at current approval (100%) and turnout (41%) rates, the spend will be (approved|rejected) in N days".
Yeah, thanks for the suggestions. Concerning projection of what to expect, there is a Yes Votes Still Needed value displayed on the table and also I think we'd like not to give a projection that we know won't be even 90% correct in practice.
This is because the supposed projection will be affected by the number of votes and will always be incorrect.