Closed JakeHartnell closed 7 months ago
Attention: 18 lines
in your changes are missing coverage. Please review.
Comparison is base (
db42d45
) 96.25% compared to head (54c5484
) 95.71%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
All modified and coverable lines are covered by tests :white_check_mark:
:exclamation: No coverage uploaded for pull request base (
development@db42d45
). Click here to learn what that means.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
@NoahSaso @JakeHartnell I think it's mostly ready. I'll give it another pass in a few days for the final cleanup.
One question though: do we want to accept votes when prop is Timelocked
or Vetoed
? atm voting is allowed until the prop expiration
(not the timelock expiration but the prop itself) is active. Somewhat similar logic to how we allow voting when prop is passed early before expiration so that any members late for voting can still cast their votes to express their opinion.
One question though: do we want to accept votes when prop is Timelocked or Vetoed? atm voting is allowed until the prop expiration (not the timelock expiration but the prop itself) is active. Somewhat similar logic to how we allow voting when prop is passed early before expiration so that any members late for voting can still cast their votes to express their opinion.
Hmmmm, on the fence about this... guess we should make it consistent?
One question though: do we want to accept votes when prop is Timelocked or Vetoed? atm voting is allowed until the prop expiration (not the timelock expiration but the prop itself) is active. Somewhat similar logic to how we allow voting when prop is passed early before expiration so that any members late for voting can still cast their votes to express their opinion.
Hmmmm, on the fence about this... guess we should make it consistent?
yeah i'm on the fence too.
on one hand, it feels weird that some may get to vote (and have their vote recorded/displayed) while others who did not vote before it was vetoed (pre-expiration) do not get to express an opinion.. but on the other hand, it feels meaningless to vote after a veto, so i foresee some people not voting while others vote anyway, leading to an outcome that is not representative of the members' opinions.
maybe it shouldn't be veto-able until after the prop is decided (i.e. it is early-passed because revoting is disabled, or it expires). or alternatively, votes could be deleted if it's vetoed early (that feels pretty weird too though). wdyt about that?
Attention: 11 lines
in your changes are missing coverage. Please review.
Comparison is base (
6ca751c
) 96.31% compared to head (37ebd9d
) 96.43%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
this is sooooo cool, super excited for this!!!!! and great job.
i have a handful of questions and a few bugs i believe need correcting. also, two discussion points (that are both covered by conversations i opened in this review, just surfacing them here for visibility):
Thanks for the awesome and helpful bug discovery and comments!
- i think we should rename timelock entirely to veto. timelock is ambiguous and somewhat distracting. i think it makes sense for the status to be
VetoTimelock
as that describes the state of a proposal, but the config option being calledveto
makes way more sense to me thantimelock
. thoughts?
Yes. 100%.
- should the status of proposals once the veto timelock expires revert back to passed? or should it stay timelocked with an expired expiration field? i'm not really sure. i mentioned some pros and cons in the conversation where i thought of it.
Hmmmmmm, this is a really good question... going to think about this one while addressing low hanging fruit.
Closes #736