--- 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