--- title: Magesmiths Roadmap Meeting 08-11 tags: magesmiths --- # Magesmiths Roadmap Meeting 08-11 In this roadmap session, we discussed the roadmap 'wishlists' from various Magesmiths, identifying similarities and differences in how we look at objectives, tradeoffs and prioritisation. ## 1. Magesmiths' Wishlists (A divergent exercise) ### 1.1 Sam's diverge: ![](https://i.imgur.com/bSXk1uM.png) For DAOhaus V2, Proposal Cards should be the last major upgrade. We should use v2 as-is and all new 'features' should be done via Boosts, Skunkwerks Initiatives & community development. That said, there will be customer service & maintenance work for V2. Once Proposal Cards has been completed, we should start planning for DAOhaus V3 as well as Moloch V3. Ideally we want to launch DAOhaus V3 that supports Moloch V3 upgrades. > Bill: Full support of this direction for DAOhaus to be the most human DAO platform out there ### 1.2 Amos' diverge: ![](https://i.imgur.com/zM68am2.png) From now, we focus on improving our current product for our current user segment (via product stability, Safe features (GUI Dapp interaction & cross-chain safes), social features) & fostering more Boost building. Workstreams such as CCO & Boost community development should be done when fundraising & general developer interest is at ATH In 6 months, when Moloch V3 is ready, we build new features (powered by Baal) to attract new user segments. Also, based on our learnings from Boost community development, we can iterate on our shortfalls (e.g. docs, grants, dev tools, curation, marketplace). This is a good time to also explore sustainability & revenue for DAOhaus In 9 months, we should have a good foundation as a frictionless tool for DAO users. Here we can start more aggressive unbundling & modularity for greater experimentation among developers. > * Ven: 3,6,9 months is a good view & there are overlaps with Sam's plans > * Jord: Good to consider sustainability. DAOs typically do better in Bear ma* rket, so we don't have to be so worried > * Spencer: What is the Boost Developer Program? Amos: It's to get more community devs to build Boosts (i.e. less building + more docs, onboarding, grants, etc.) ### 1.3 Dekan's diverge: ![](https://i.imgur.com/UvKIA3u.png) Dekan's Diverge starts with a more zoomed out view. We're currently at the Modern era, focusing on compensation revamp, community voice, LPDAO/CCO and HAUS Mainnet Launch. Moving forward, as we move into the Atomic era, our focus is on 3 fronts: 1. DAOhaus V3: We unbundle V2, build a new component library & use these components to dogfood/build v3. We only build core features to achieve V2 parity (e.g. Proposals, Voting & Membership). 2. Boost Market: This is the only new feature we'll build. When building the Boost Market, we want to increase HAUS token value capture & work towards DAOhaus sustainability 3. Boost Development: Here, we foster decentralised dev teams, community Boosts developers & more Skunkwerks experiment We should aim for more decentralisation & the only centralised point is the marketplace. > * Sam & Spencer: We're pretty aligned, except degree of unbundling & what's considered core. ### 1.4 Spencer's diverge ![](https://i.imgur.com/oTwDOFL.png) We focus on the 3 strategic focuses that Magesmiths have greatest impact on: 1. Best platform for DAOs 2. Ecosystem of composable tools 3. Economy of DAO-created value The approach here is think of DAOhaus as an operating system. We work on core components (i.e UX improvements) and new primitives (for others to build on). Then, we create dev interfaces for easy access to these primitives. In the short run, we focus on core UX improvements (e.g. Summoning, Proposal Cards, Navigation & Content, Hub). Gradually, we work on discovering new primitives (e.g. Marketplace, DAO composability, Multi-chain, Custom-DAO content & Curation). > * Jord: New UI should allow for substitution of different UI or even a launcher that launches differen Boosts > * Bau: Adding docs & content boosts would be helpful ### 1.5 Ven's diverge ![](https://i.imgur.com/Y4JG8G0.png) Currently, we are working on social UI, Moloch V3 Design sprint with community personas. In December, we aspire to launch HAUS on mainnnet & prepare for V3 Looking forward to February (Eth Denver), we target a DAOhaus V3 Alpha launch with a small set of use cases. This is not a full product release, but something deployed and available for use elsewhere. The full V3 launch should come in March. After launch in March, April-June shuld be focused on new use cases & emergent integrations, before constant iterations in July and August > * Sam: In November, we might need a design (UI) sprint as well as a Dev Sprint > * Spencer: We should have a broader discussion on how it can guide other initiatives (outside of magesmiths) ### 1.6 Jord's diverge Jord's diverge was a forum post on how we can build v3 from a software engineering point of view. Read more [here](https://forum.daohaus.club/t/holistic-development-building-a-better-frankenapp/3536) Bulk of the work is not in building UI/visual aspects but processing data on the backend. If we want somethign that's safe, modular and scalable, we'll need more time & planning to do it well. As a summary of the forum post, we'll need to create the building blocks, shape of the app, routing, factories and then tie it all together. On focus, we'll most likely start with a 90% focus on building the core, and then doing a massive switch once we are ready to build utilities for communities. At this point, we want communities to build and 'feed' the DAOhaus monster to spawn new tools. For more in-depth understanding, please read the forum post. > * Sam: It's like a project plan, can help us work on it faster > * Jord: Launching some DAOs on v3 in a few months is manageable, but having a production-ready app is hard. We should really focus on testing, scaling and writing code for others. This is upfront investment that will pay off later (i.e. we don't have to worry 'is this going to break that?') ## 2. Similarities in our Diverges **Similarities in executional focus** 1. In the short run, we want to complete Proposal Cards upgrade for V2 & then focus on V3 after that 2. We want to launch an V3 Alpha product teaser by Eth Denver (Feb 2022) **Similarities in approach** 1. We want to have a certain level of modularity & hooks for community developers to work on (the nuances in this 'level' is addressed in the next section) 2. We see Boost marketplace as a core way to scale DAOhaus functionality outside of Warcamp. 3. We see Boost developers as an important community group to nurture 4. We view DAOhaus sustainability & token value capture as important ## 3. Differences in our Diverges ### 3.1 What is the role of V2 in relation to V3? **We managed to achieve consensus on this - discussion is as follows.** We are not retiring v2, but treating it as a Petri dish where community development happens (e.g. starting new weird DAOs). This is valuable for us to discover new bolt-ons, boosts and even features that go into V3 development. We'll need to babysit, maintenance and provide customer service for a while. After some discussion, the V2 UI should work with V2 Moloch, instead of using our old code to support differnt contracts, enabling us to have more reliability & security. Dekan shared that V3 should be built using component libraries. Hopefully our data has a similar shape to baal and we can implement core components (e.g. proposals, members, voting) and layer it on top of diferent frameworks/contracts (e.g. Zodiac) ### 3.2 How unbundled do we get with V3? **We have started to achieve some consensus on an approach, but will need to dive into details. This may be done during the Roadmap Meeting or the Dev Sprint in November.** First, we started with defining 'unbundling' and generally the team is on a spectrum between definition 1 & 2 | Stance | Definition | Remarks | | ---------------- | ----------------------------------------------------------------------------------------------------------------- | -------- | | 1. Most aggressive | The DAOhaus core is tiny & everything else is modular and accessible in different ways by different people | Proposed by Dekan | | 2. Moderate | The DAOhaus core is an operating system that exposes certain hooks/primitives which are built by other people | Proposed by Spencer | | 3. Least aggressive | Almost very little is modular & community developers need to talk to & integrate with DAOhaus to build new things | For illustration, no one is arguing for this | During the discussion, we leaned towards definition 1. More specifically, we are only building component libraries (for eventual community development) as well as a small UI that's core to DAOhaus (i.e. Proposals, Members, Summoning). The only other UIs we'll build are Boost / DAO Marketplace & Explore pages (where we can help fulfil the role as connectors in the ecosystem). `Explore` could be a big opportunity for us. Like how Google indexes & help people discover web pages in the 90s, Explore can help people find communities (perhaps even non-MolochDAOs). ## 4. Next Steps From an execution point of view, Ven & Sam aligned that **we'll need a Design & Dev sprint in November to dive deeper on what goes into V3 Moloch & V3 DAOhaus.** * Dev Sprint: Dev exploration of Moloch V3, DAOhaus V3, 'backward-compatibility' with V2 (if any, e.g. Discover & Hub) * Design Sprint: V3 UI & UX Exploration with community personas in mind From a Roadmap point of view, these are the areas of discussion that can lead us back to planning a Roadmap 1. **Key Question: Assess how the current approach can allow core features, boosts and all components to create a good & cohesive user experience**. This should wrap up our alignment on how we want to approach DAOhaus as a platform. 2. **Create a more defined list of 'within-scopes' and 'out-of-scopes'** for the next 3/6/ months (perhaps 6 months for the v3 launch post-Denver). With the approach aligned, we can then work on more actionable items & ship! ## Appendix Another way of moving forward was brought up by Jord - We don't actually have to start thinking about the split now. Like cells, we can start somewhere and continue building/growing the app, dividing only when we are ready to. Similarly, in theory if everything is a component, then we can pick where the line is anywhere at any time. So maybe the right place to start is with **everything as a component**?