---
# System prepended metadata

title: Magesmiths Meeting 29-11

---

---
title: Magesmiths Meeting 29-11
tags: 
--- 

# Magesmiths Meeting 29-11

This week's discussion is centred on last week's decision to have the Magesmiths to focus on a **Build Stream**, while the Rangers create non-techincal and technical content for ETH Denver (i.e. **Shill Stream**). 

## **1. Shill Stream** 
*Create technical & non-technical content for ETH Denver*

### 1A. Non-Tech 
**Objectives**
Educate non-technical audiences on how Baal works and how it might affect them as a DAO summoner / member

**Content**
**Why is Baal awesome & why they should use it? Start with jargon & sand it down into 1 sentence** 
- **1. Flexibility**: Baal's flexibility & composability is a strength & weakness. For instance, more flexible = more complex / not the precise tool for a particular use case)
    - Flexibility is helps you to customise & build your DAO as you grow. A more 'precise tool' might not be the one you need in X months. 
    - Meme: Starter DAO -> Forever DAO (or not) 
- **2. Different personas/problem statements)**: We can frame it in different personas/stages/use case
    - We're a sweet spot for Purpose-driven DAOs. Today, most DAOhaus DAOs are small & permissioned, but as we add functionality to support other DAOs, size & permissionedness might change (and we can support it)  
- **3. Community-owned, open-source, expansive** ecosystem (vs VC product)
- **4. We've the experience on what works & what doesn't**. Flexibility that is born out of experimentation 
    - Flexibility within certain guardrails (DAOhaus UX, UI + Moloch), while expanding options of what Moloch could do before
    - Moloch Mystics built a new contract & we're building on top of it

**Next Steps** 
*More executional TODOs*
- [ ] Plan out milestones 
- [ ] Synchronise with Design on UX exploration & deep dive into features to highlight

---

### 1B. Tech 

**Objectives**
Explain why should a community developer build on top of DAOhaus?

**Building your Boost on DAOhaus helps:**
- Align yourself with the DAO culture & meme, hence looking cool
- Align with the **DAO tooling narrative** to build legos freely interoperable
- Enables you to be entrepreneurial and **help purpose-driven communities do cool stuff** 
- Make your product/tech discoverable instantly by 2000 DAOs
- Increase **visiblity & branding via Boost Marketplace, etc**, regardless whether you're an existing project expanding touchpoints or community developers who just want to build things
- Gain access to future revenue
- Learn about DAOs & Web3 development by doing / building instead of reading about it
- You get started through our Dev Grants

**Call To Action**: Build a Boost today! (Or Bolt-on potentially)
> - We need some building blocks (e.g. component library, create-dao-app, making data layer more usable. See Next Steps 
> - Boosts could be a prototyping tool to run experiments & test. Only when there's traction, developers can put in more effort to build Bolt-ons.
> - Bolt-ons as the headless DAOhaus

**Next Steps**
*More executional TODOs*
- [ ] Define process on how to build Boost legos 
- [ ] Create Developer docs / tutorial series 
- [ ] Work on Component library, **data layer** (getting data off the Subgraph & make it usable)
- [ ] Finalise Grants

## **2. Build Stream** 
*Build & ship V3!*


**How do we experiment unimpeded & still build product reliability?** 
- Site reliability & UX comes in direct conflict with experimentation. As we learn new things on the fly & chagne constantly, it's hard to build a constant, nice UX experience. 
- Proposal: A complementary structure between: 
    - 1. R&D + Experiments: Design experiments, build fast, document & scope learnings using the Scientific Method (falsifiability, etc.)
    - 2. UX & Reliability: Build things more permanently 
- R&D track should be using base Chakra components build a new app/interface on V2 rails. When the new data model is ready, we can adapt it to the new UI
- Having a component library helps to build faster/better and also run experiments

**Next Steps**
- What's the ratio of experimentation vs more structured development?
- What's needed for quick experimentation?
    -  Data layer (Making graph data usable), Basic component library (proposal UI), create-dao-app, data caching/availability
- Align on Sam's workflow / process design efforts


## Next week's Roadmap Focus

- Where does building Yeeter fit in?
    - There could be some value in the Yeeter app using Moloch 2.5 (with Shaman) showcasing the power of Baal
- How do we move forward with the Build stream?

