Thank you @Pepperoni_Jo3 for responding and providing some thoughts.
One material change could be to break down the proposed adjustments into individual snapshot votes rather than grouping them together as one holistic set of governance changes. This would allow the DAO to assess, deliberate and ultimately decide on each option independently.
In my initial drafting of this, my goal was to discuss the voting process on the whole and getting to a standardized guideline. As I added issues to illustrate why I think the overhaul was needed, it has sort of morphed into these three key issues. I do believe all three are worth addressing at once for simplicity and effectiveness, but I also don’t want one controversial piece stop another popular item from passing. I’m no way opposed to splitting this up (and upon further reflection this may be the way to go anyway). Maybe the process looks like 3 Snapshot temp checks, where then the passing items go to Tally all as 1 item however.
I’ll add, there may be other best practices that can benefit the election process that I may not have addressed. So if other issues are present I have no issues expanding this out into a 4+ item discussion either.
For this reason, and to avoid the issues of “how do we decide how to decide” (a common pitfall when approving multi-option governance and voting changes) I would propose the following action.
Action:
- Run a snapshot proposal where the DAO can provide it’s feedback on whether it would like a standardised approach for election (1) OR leave the election process up to the discretion of the individual proposal writer (2)
- If the DAO is in favour of a standardised process (option 2), we can then run a follow up Snapshot detailing the different voting mechanisms the DAO could choose to select.
Regardless, learning from the LTIPP “self voting” issues, going forward I think it is important for proposals to clearly articulate their election mechanism prior to starting the election process.
I think this is fair and I like the idea, and to your point earlier there are a lot of variables between the issues that may need multiple temp-check elections. The more I think about it the more I think this may be the cleaner option.
A question back to you - I was struggling with this in terms of how to set a guideline without affecting flexibility proposal to proposal. However, I couldn’t really see a scenario where say 95% of elections would be perfect for Weighted Voting, but there then is a specific use-case that is for Single Choice. Or the same with say Weighed vs Approval in a 2+ winning candidate election. Do you have thoughts on what I may be missing? I am all for allowing flexibility for situations we can’t foresee, but I also don’t want to create openness just for the sake of it… as the balancing act with this is always going to be that if we loosen the rails too much it opens us back up to the gamification issue.
Maybe the play here is we define a specific voting type, but proposers can use a different voting type if and only if they clearly state that in the initial proposal discussion. Snaphot vote 1 is for the proposal, then in tandem a Snapshot vote 2 is up for approval for the ability to use a different voting method. That way delegates have a chance to block that voting style before the election occurs. I know it creates extra steps and I admittedly don’t like how ‘ugly’ that is, but I’d also rather have that option there in that edge use case where it really does make a difference… and in theory it would be only happening once in a blue moon anyway. Food for thought - @JoJo tagging you as I saw you had a similar thought about allowing proposal writers to ask for another mechanism. I would agree it really should be a ‘99 out of 100’ type thing.
I am strongly in support of the introduction of the “Shutter” feature for the reasons articulated above. It would also have the added benefit of reducing the frequency of last minute tactical voting.
From discussions had in the Security Council Election Thread as well, it seems this will be the least controversial item. To your point above I’d hate to see this specific item lost because one of the other issues can’t be agreed upon. FWIW, I think this is the both the easiest thing to fix and conveniently probably causing the biggest issues regarding gamification of votes.
I’ll need to reflect further on the specific mechanism. If the problem statement is “seven days may not give high quality applications enough time to apply for council positions” , reaching the minimum application threshold within seven days may still leave high quality applications without insufficient time to apply. For that reason we could propose an increased application window of 10 days. This could be combined with a minimum application count (N+2) with the voting rolling over by an additional week if the minimum application count is not reached within the initial 10 day period.
Thank you for adding your thoughts on this one, as this one I spend the most thinking time on. I don’t know if there really is a perfect answer here, so I too welcome anyone who is willing to input their thoughts into this. It’s all about flexibility while still setting a ‘floor’ of minimum viable action. I personally have no issues with 10 days instead of 7. Again this is probably where your point of breaking up the votes shines as we can propose a few popular methodologies.