Open ori-near opened 2 weeks ago
Thank you @FREZZZBE! Overall looks good for MVP ...
Just a couple of quick thoughts:
@ori-near Here is update
Hi @FREZZZBE – made a few copy edits within the Figma – please review.
BTW – I wonder if it's obvious that the left side of the table shows the current state and the right side shows the new state. Might want to test this with a couple of people. But I think for now this MVP is great!
Warning: Impact of changing voting duration
You are about to update the voting duration. This will affect the following requests:
12 pending requests will now follow the new voting duration policy. 2 expired requests under the old voting duration will move back to the Pending Requests tab and reopen for voting. These requests were created within thew new voting period and are no longer considered expired.
Summary of Changes [Show table]
BTW – I wonder if it's obvious that the left side of the table shows the current state and the right side shows the new state. Might want to test this with a couple of people. But I think for now this MVP is great!
English is Left to right language, and people scan iformation left to right. But yes, tests is always good idea!
@ori-near
@FREZZZBE I mean that I'm not sure if it's visually clear that the left part of the table shows current state and the right side shows affected stage after the change 😛. Maybe we just need a header that says: Current State / After Change or something like that.
Background
As part of https://github.com/NEAR-DevHub/neardevhub-treasury-dashboard/issues/116, we’re implementing a feature that allows admins to change the voting duration for proposals. However, we need to warn admins before they complete this change on what happens to existing proposals.
Problem
Currently, proposals in our system have a voting duration (e.g. 7 days). If a proposal doesn’t receive enough votes within that period, we consider it as
Expired
in the UI, and we move it from the Pending Requests to the History tab. However, this is only a visual change in the UI. On the contract side, those proposals still have the "InProgress" status because we cannot automatically update the status without an explicit transaction (e.g. user taking action on proposal such as voting to approve, reject, or explicitly voting to expire the proposal). So the status always remains "InProgress" unless a user interacts with the proposal, even though the UI shows it as expired after the voting period ends.If an admin changes the voting duration (e.g. from 7 to 21 days), any expired proposals created within the new voting duration (e.g. last 21 days) will move back to Pending Requests and become open for voting again. However, expired proposals created outside the new voting period will remain in history tab. This distinction is important because we need to inform admins about which requests will be impacted, and they need to understand that any expired proposals will be activated if they fall within the new duration.
UX Need
Design a warning message that admins see when they change the voting duration, explaining how the change will impact existing requests.
Acceptance Criteria
Sample Warning Message
Title: Warning: Changing the voting duration will affect the status of some requests"
Body: You are about to update the voting duration. This will affect the following existing requests
Pending Requests: [X] pending requests will now follow the new voting duration policy.
Expired Requests: [Y] expired requests under the old voting duration will move back to the Pending Requests tab and reopen for voting. These requests were created within thew new voting period and are no longer considered expired.
Impacted Requests:
If you do not want expired proposals to be open for voting again, you may need to delete them.
Button: