Open swfsql opened 2 years ago
I think this change implies new kind of proposals, such as adding/changing/removing roles specifically, and also the roles would probably need to reside directly on the dao (instead of being inside the policy
), and they would probably require tracking of on-going proposals that they are observing votes on.
That is to say, this should require breaking changes on some functions.
I had started (currently WIP) working on this, but I'm not sure if this kind of change is be desired, or if the design should be different from what I'm thinking.
@swfsql this is a very interesting feature for sure, however i see a few issues in addition to the ones you mentioned, mostly how to accomplish guarding re-entrancy or finalization behaviours. I think it would be possible, but the vote tally state would have to be changed, and potentially pull away from allowing async voting with enum/blocking state. This then becomes a more costly operation for voting. From a user-point of view, having the ability to change my vote is nice to have, but it should only be in more rare cases. Happy to hear more thoughts however.
Users can vote on on-going proposals in three different ways: as in approving, as in rejecting or as in removing (for punishing spams) a proposal.
But users cannot undo their votes once they are made, and for on-going proposals, I believe this could be useful since users could individually change their minds after they voted.
If some users would like to "change" their votes, this may be possible by re-creating the proposal and then voting differently, but that requires some coordination.
So I expect this to be a "desired" feature for users, as they would be allowed to "change" or "undo" their votes.
But this also has implications for internals, since this opens the possibility to track users and roles changes more closely. Although consuming more gas and increasing the overall code complexity, this should make the voting system behave in a safer manner.