-
Notifications
You must be signed in to change notification settings - Fork 275
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add the ability to create votes before they start (Vote Scheduling) #591
Comments
Work on this should keep in mind time zones (and make it explicit for users) if we want to show/render local start time |
The difficultly with building this directly into the Voting app with a direct timestamp was the selection of a snapshot block. Something we could do is always use block numbers, but estimate the block number in the UI if the user wants to use a timestamp. |
@lkngtn how do you feel about expanding the scope of the issue and changing the title to "Add the ability to create a vote start time and end time for every new proposal"? I started to create an issue requesting "add the ability to schedule an end time for each proposal" feature and thought maybe we can combine these issues. |
Closing for now; we can evaluate this feature when we do the next round of contract upgrades. |
Note: this has been closed to be tracked in the "wishlist for future upgrades".
Is your feature request related to a problem? Please describe.
Currently vote duration starts as soon as a vote is created, but practically speaking it would make more sense to allow votes to be created early and a start time specified.
Describe the solution you'd like
Add the option of setting a startBlock/Time parameter when creating a new vote, this could be verified agains a global setting to prevent votes from being created too far in advance.
Describe alternatives you've considered
A generic app for managing scheduling could be created, which would allow an action to be verified against the ACL but delayed until some specified time, when the time is reached the action could be executed by anyone (via a public function). Calling the public function could be incentivized by releasing a bounty/payment to the caller of the function. This feels like a powerful solution to a broad class of scheduling challenges, but also feels much more complex than simply adding a scheduling option to the voting app itself.
Additional context
This issue was brought up in #590
The text was updated successfully, but these errors were encountered: