Dev: Governance Setting – Vote Duration

[ori-near]

See #86 for Governance Settings background.

Background

Our Treasury App currently lacks a dedicated section for admins to configure governance settings (see #86 for background). Specifically, there is no way for admins to adjust the "voting duration," or the number of days a vote is active before it expires. This limits the flexibility of governance processes, especially when there’s a need to adapt voting periods to different requirements

This ticket focuses on implementing a "Voting Duration" component within the Settings page, which would allow admins to configure the number of days a vote is open for proposals before it expires.

User Story

As an admin (user with permissions to manage members & setting), I want the ability to configure the voting duration so that I can choose the number of days a vote remain active before it expires, allowing me to manage voting timelines that work for my team.

Acceptance Criteria

1. Voting Duration Configuration Section

• A new "Voting Duration" section is added to the Treasury settings
  • Title: "Voting Duration"
  • Instructions text: "Set the number of days a vote is active. A decision expires if voting is not completed within this period."
  • Input feed: Admin can input the number of days for the voting duration
    • Admin can only enter a number
    • Default value is 7 days
  • Button
    • Cancel: Cancels any changes and leaves the voting duration unchanged
    • Submit Requests: Confirm the changes and submits the request

2. Warning Message for Impact on Existing Requests

• Admin sees a warning message if the voting duration changes will impact any existing requests. See mock up below.

3. Submit Request to Update Voting Duration

• When admin clicks Submit Request, a new policy change request is added to the "Pending Requests" section of the Settings page.
• The requests will need to be voted on before the change is implemented. The voting thresholds for this policy change will be follow the "Manage Members & Settings" permission group. So if 1 vote is required, after 1 vote that policy change will take effect.
• Once the votes are cast, the new voting duration policy will take effect.

4. Handling of Existing Requests

• Once policy change takes effect, all existing requests that had the old vote duration policy will inherit the new voting duration policy:
  • Pending Requests: All pending requests that were created under the previous duration will inherit the new voting period
  • Expired Requests: Any requests that were expired under the old voting duration but fall under the new voting duration will automatically move to the Pending Requests tab and be available for voting again

Voting Duration Mockup

Voting Duration Warning Mockup

@FREZZZBE will add once #119 is complete.

[ori-near]

Moving this into sprint 3

[petersalomonsen]

@ori-near Regarding this point:

"Expired Requests: Any requests that were expired under the old voting duration but fall under the new voting duration will automatically move to the Pending Requests tab and be available for voting again"

The sputnik-dao contract works this way that the "Expired" state will only be applied if you act on a proposal ( if you vote ). So proposals that are not voted for, and if they are expired by the current duration setting, will be available for voting if the duration is extended.

If the proposal was voted for after expiry, and the "Expired" state was set on the proposal, then this change is irreversible, and changing the duration setting will not fix it.

[ori-near]

@petersalomonsen – understood this is the behavior on the contract side. That point was written from point of view of the user.