AGP-14: improving voting logistics & AGP-16: Extend AGP Vote Duration both propose changes to the AGP process and it felt reasonable to discuss them in the same place though they can be approved or rejected independently.
AGP-14 Improving Voting Logistics
- Remove redundant Stage IV (Draft), merging Stage III and Stage IV
- Changes the day that votes start to later in the month
- Removes requirement for AA to submit a Meta proposal polling vote frequency preferences
- Add explicit authority for the AA to reschedule a vote + restrictions for rescheduling
AGP-16 Extend AGP Vote Duration
- Extends the vote duration for future AGPs from 48 Hours (2 Days) to 168 Hours (7 Days)
I’m in favor of AGP-14. It streamlines and simplifies the voting process and rescheduling the votes to later in the month helps prevent some conflicts that would likely come up again next year as much of the discussion and preparation for the Q1 ballot happened over Christmas and New Years which is not ideal. The reschedule of the vote feels like a reasonable modification to allow for unexpected circumstances (e.g. scheduling of the Ethereum hardfork).
I’m against AGP-16: I don’t think its particularly helpful to extend the duration of votes beyond 2 days, Ideally review/discussion about AGPs should be happening well in advance of the vote starting, and 2 days feels like sufficient time to send transaction to vote if you are interested in voting.
Another point related to AGP-16 that was brought up on the github PR – https://github.com/aragon/AGPs/pull/15#issuecomment-452996842
Currently there is no way to change the duration of the voting app instance, which would mean changing this parameter may have the unintended consequence of requiring a second voting app instance installed, or making the history of past votes not visible.
I am in favor of both AGP-14 and 16
14 is obvious, simplifying the process and allowing for flexibility (that was already needed in this first vote) is important to get into our system.
16 is less obvious, but i am very much in favor of the proposal. Extending the duration to 7 days is important because not everyone always has access to their keys every day. Because they need to access their keys to vote, but those keys are sensitive, extending the voting period to 7 days mitigates the issues of accessibility to a hardware wallet or other secure method of cold storage.
To put this more concretely, I’m with a prominent community member right now that can’t vote because their hardware wallet is at home, they are traveling and they don’t feel comfortable traveling to all countries with access to the bulk of their funds. This is true of many whales as if they have direct access to funds they might be kidnapped and coerced into sending their funds to someone… its not likely of course, but it is a real fear
Extending it to 7 days helps get more votes.
I agree with Griff on the problem to solve, just I am not sure extending the number of days is the solution.
When vote delegation is a thing, it then becomes possible to delegate to a less secure wallet such as Metamask or a mobile wallet. Which begs the question, when it is expected to become a thing?
I think the point about a longer duration making voting more accessible to people who are travelling and may not have access to a secure private key is a good one. Though I agree with @GustavMarwin that simple delegation is a much more practical solution.
As far as timing, its my understanding that adding simple delegation as described here, is fairly simple and is being prioritized. However from a timing perspective, if we want to follow the AGP process we should have a meta-track proposal in Q2 which would approve the switch to delegative voting which would mean that we would not be able to do delegation in the Q2 voting ballot. If the delegative voting app is ready before the Q2 vote cycle, and there appears to be wide support and felt that it should be urgently addressed, perhaps the an “emergency” vote could be held prior to the Q2 ballot to switch over to delegative voting.
Sounds like a great actual solution, thanks for clarifying this aspect. I don’t think emergency voting should be used outside of actual emergencies, and we have enough of those lately in the ethereum community tbh.
I wonder if these type of details should be mentioned directly in the AGP, it’s reasonably important as it can affect the UX in negative ways. Alternatively or cumulatively, AGPs on Github should maybe point to their respective official threads on the forums. I could have easily missed this aspect.
edit: ok I see there’s a link to the related Github pull request, including this aspect. I think we shouldn’t need to click any link to get important details. AGPs should maybe fit all important details in a single place.
I also would like for future AGP votes to include the title of the proposal in addition to the AGP-X in the title.
Would be good to create an AGP/Meta AGP for these changes, these can be made at any point and can be discussed and refined before the next vote.