Implement DAO Proposal flows
Closed this issue · 4 comments
Background
Kali DAO contract supports a range of proposal types, including extensions.
Kali UI supports the full range of standard proposals plus generic extensions.
Problem
In the context of for-profit sweat equity DAOs with Series LLC structure, not all proposal types supported by the Kali DAO contract make intuitive sense. Respectively Kali DAO does not (and cannot automagically) provide intuitive UI for new proposal extension types such as Project Management and xVault. Each proposal type needs a thoughtful UX design and implementation.
For the purpose of optimized Sporos DAO app user experience, we need to cherry pick the smallest subset of proposal types that are powerful enough to allow for-profit DAO LLCs to operate effectively. Additionally we need to implement UI flows that make it intuitively clear how each proposal type maps to sweat equity - for example Add Member / Mint proposal needs to be implemented with clear guidance on the legal and tax implications of minting LLC membership tokens as sweat equity.
The Sporos DAO UI has to also properly recognize proposal types that are not submitted via the Sporos DAO UI, but possibly via other front ends or directly via contract interaction on-chain. In such cases the UI needs to notify users accordingly, provide a reference for further information and a chance to escape/delete such external proposals if the users wish to.
Next, we need to provide UI for Sporos DAO proposal extensions such as Project Management.
Desired outcome
- Develop intuitive UX optimized for Sporos DAO app users
- Implement UI representations of the underlying smart contract data types
- Implement UI flows integrated with smart contracts for Sporos DAO supported proposal types
- submitting a new proposal
- voting on proposals
- deleting/escaping a proposal
- sponsoring a proposal submitted form a non-member of a DAO
- reasonable handling of external proposals submitted outside Sporos DAO UI.
Screenshots from the latest Figma design flows below:
Quick update. There is a setback due to issues with subgraph. It does not seem to update for a while , which affects poorly UX. Just noticed Kali switched to direct RPC for proposals recently. It's a bummer because subgraph was a big middleware convenience. Not having it requires rewriting front end code to query directly RPC, which takes longer time to write code, test and doesn't scale for many users. In summary, it will take a few more days to rewrite the proposal data access code.
@ivelin Small bug,
If you connect your wallet and are on a different network than Arbitrum, you need to manually refresh