-
Notifications
You must be signed in to change notification settings - Fork 2
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
clearer messages #80
Comments
What we have now in UI: Proposal: // current state // estimated proposal state // wait for state Payloads: in proposal details (create/overview) screens:
in payloads overview screen:
After discussions in slack, and all the suggestions, here is my version of the statuses Proposal: // current state (I think we can leave it as it was) Payloads: // estimated payloads state (I think we can leave it as it was) // payloads state we can combine to one What do you think @sakulstra @kyzia551 @eboadom ? |
Waiting for proposal execution
when a proposal has succeeded and the result has been bridged back to mainnet, currently the ui shows
Pending execution.
. While technically that's correct (as it's pending execution of the proposal), it's also misleading as by execution ppl naturally understand execution of the payload, but in this case it's just he execution of the proposal = queuing of the payload.Perhaps better "Pending payload queuing via proposal execution", idk
"Will expire in x", as long as bridging is not finished.
Currently the ui shows "will expire in x" as long as not all payloads have been queued.
As we know: the proposal was executed & the paylaods have not yet been queud, perhaps better to show sth lik "Pending payload queuing via bridge"
Payloads not yet queued will show "time-locked"
Not sure what "time-locked" means exactly... To me that state is quite confusing tbh.
If the proposal is executed & message is not yet bridged, should probably say exactly that "Awaiting queuing via bridge"
Quite sure especially @eboadom will not like the suggested messages, so plz suggest alternatives 😅
From a puristic view one could say should just be "pending queuing" in all cases... at for most users that's all the info they need.
I think i would still be confused with this though & it would hide problems (like failing automation) as from the ui alone will be hard to tell why its "pending queueing".
The text was updated successfully, but these errors were encountered: