---
tags: magesmiths, v3, project management
---
# Magesmiths Sync and Planning Meeting (3/28/2022)
## Magesmiths Product Roadmap
- Ensure that v2 is maintained (customer service, bug fixes, critical updates, etc.) while working on v3
- DevRel workstream
- In progress (loosely) while building v3 via documentation
- Explore learnings in decentralized app management
- Documenting what we learn from this process in v3
- Summoner and Hub will be getting into Sage sooner
- v1 Sage on these beginning in April
- Bottleneck of dev resources at this point
- Someone saging on components, we need room to sage on Summoner if doing both at once
- What level of visibility would we want ito our processes?
- Accountability to CCO contributors and the larger DAOhaus community
- Public communications relate to Q2 priorities and goals, not specific features, timelines, and dates
- Developer facing/Dev Rel:
- We're working openly in our GitHub board as well as our Dragon processes, so this dovetails well with what we're already doing as we're working openly
- Missing from the current Roadmap is the Boost development and marketplace, but we can offer the starting point via the component library and sdk
- Infrastructure for folks to build on
- Bringing new devs on:
- Working on core infrastructure or working alongside us by building *on* our infrastructure
- Want to avoid having a Dev Rel team being swamped by outside devs, we want folks that are focused on those who are closer to us
- Bigger priority after this timeline is accomplished
- Helpful to have a docs page that would represent general v3 roadmap (Contributors Handbook)
## Workstreams and Teams
- Skills would be role, but folks working on projects would be made up of these people
- Working to identify a lead and owner for each of these projects
## v3 Planning Meeting
### Feedback and Thoughts
- Process is good so far, easy to use, and more accessible than ClickUp
- Structure and stages working well
- v3 Retro will be on a bi-weekly basis alternating with Campfire
- Need to create a component library board and meet with Jord and Sam as we move into Sage for this
### Notes
- Rages emphasize shipping speed, but Sage will be more systematic and refined
- Refine our PR and review processes to help facilitate moving things forward to Done
- Poster is in Code Review
### Baal Audit
- Schedule with Bill to review the Baal related tickets on board
- What else do we need/want to explore before getting an audit locked in?
- Peer review
- More eyes on the code -- do we have some $HAUS for the bounties?
- CLI hitting a lot of the proposal items -- challenge is the DAO config
- **CLI needs some developer docs**
- Fuzzing would be good to look into
- Plugins to autogen docs that we can build on top of -- good starting point for the audit
- [Ethdoc](https://ethdoc.io/)
- Also may be a Hardhat plugin for docs autogen
### Summoner Design and Component Library
- Components:
- **Connect Wallet, Network Switch, Wrong Network**
- Wrong Network is app specific -- would receive this message as a prop, as well as the current network
- **Transaction modal**
- Global info/error messages about Subgraph and other states
- **Toast**
- Customized Radix Toast -- clicking shows more detail, closeable
- Provides contextual information about what is happening
- What is our philosophy around this? When is the transaction finalizeed? Is it through indexing?
- How does this relate to the polling Rage (and what is available to us)?
- Need to consider more before Sage
- [Notify library from BlockNative](https://docs.blocknative.com/notify)
- UX and design considerations of continuous polling -- how may this work?
- **General Status Indicator**
- Context sensitive status indicator
- Link to docs page for Frequent Questions such as "Why is my DAO not showing?"
### Other Ideas
- DAO Console separate from Core UI
- Would we want to link to Snapshot?
- Standalone Hub would provide a lot of utility (managing all of a user's DAOs)
- Does this live in or outside of DAOhaus? This has design implications
- We have a lot of lists -- how do we systemize this?
- Grid view, list view, etc.
- How do we turn this into a system (if possible) so that we can reuse this?
- Some views need both Grid and List views (or is this an option prop)
- [ ] Jot down notes on these types of questions for component library
- What data do we want to use to inform the UX/UI design?
- How much data do we want to work with in the first Hub Rage?
- Designers doing a sub-sprint on inter-app navigation and exploration
- Divergently exploring, but could surface to a shared nav
## Review Stage
- How do we move these forward?
- What are the processes we want to do here?
- Review process for Rage and Sage
- Next steps, additional Rages
- We're still in this stage where we're not integrating specific features so our Review -> Done process is a bit more amorphous
- Are we getting to the point where we need separate dev docs instead of having it all in the Wiki?
## Next Steps and TODOs
- [ ] Jot down notes on these types of questions for component library
- [ ] Component library sync and setup Project Board
- [ ] Summoner Sage sync and scoping/card creation
- [ ] Add more notes to components identified in today's design review
- [ ] Identify v1 of Rage Report pipeline (how do we count things as done?)
- [ ] Document Proposal Details Schema (add to Wiki)
- [ ] Reach out to Rowdy for component library work
- [ ] Baal audit docs need to be ready in next 2 weeks for Auryn
- [ ] Start with a Button for the Rage component library
- [ ] "Start with why" about design processes and structures
- [ ] Lots of priority going to the Hub and Summoner, but we need equal attention to the component library for Sage
## Component Library Discussion
- This needs to start becoming its own team
- Developers and designers need to be more in sync as we build this out
- Become a sub-team with a Project Board for the component library
- Making progress in the Figma, but we need to understand all the micro components from an architecture standpoint
- Maybe this week we need to take some time to work through the tooling
- Raging and thinking through Radix, Stitches, and Storybook
- Where are we on the Figma?
- How do we help the design team with identifying what's needed for handoff?
- Identify a table of what's needed:
- All variants of what is needed (all variants/states)
- Will be different for each component
- How do we provide the design team with the blanks that need to be filled in?
- Does the Figma design system have a specific owner?
- To avoid tech debt we'd want to try to start having equal priority on this before doing other pieces
- Working in isolation in Storybook
## TODOs
- [ ] Start with a Button for the Rage component library
- [ ] "Start with why" about design processes and structures
- [ ] Lots of priority going to the Hub and Summoner, but we need equal attention to the component library for Sage