---
# System prepended metadata

title: 'Roadmap Proposal: Team Rage & Team Sage'

---

# Roadmap Proposal: Team Rage & Team Sage

## Challenges:

- Process Problems
    - Learning hard lessons on a production app is costly and often limits what we can do 
    - Creating features based on whims, not having a plan, and not sticking to a plan (if we had one) keeps us glued to Discord and diminishes the quality of our work.
- Baal challenges
    - Baal is riskier than Moloch
    - Baal is newer than Moloch
    - Baal is harder to understand
    - Baal, due to its complexity, will be harder to meme. 
- App problems
    - Playing bug whack-a-mole is a black hole that sucks our money, efforts, and souls into the dark, empty void 
    - Creating a reliable, composable set of DAO tools and an app with great UX/DX is already a massive undertaking for a team our size.  
    - Doing that while incorporating a new contract with differing mechanics would make that task impossible. 

- PR problems
    - Much of Warcamp is unaware of what goes on in Magesmiths, at least in detail. 
    - The public definitely has no clue what's going on in MageSmiths
    - We're often left out of the larger DAO conversation largely because we have no VC backing, and we give people excuses to write us off (UX, DX, Site Reliability). 
    
## Proposed Solutions
- **Separate into 2 teams.** 
    - **Team Rage** A research team that hacks experimental projects. Uses short-term development and a disciplined approach to experiment design.
    - **Team Sage** designs and builds the app (and DAO tools) using Team Rage's data. This team prizes long-term thinking, focus, and quality control above all else.  
   
- **Chunking into smaller problems.**
    - Build DAO tools(UI lib, backend services, d-CMS's, lego lib) 
    - Rebuild V2 with DAOtools
    - Once DAOtools are built, migrate them easily to new V3 app, or better yet migrate v3 contract to reskinned v2 app. 
    - Chunking DAOtools into smaller pieces allows us to isolate and test code, greatly reducing bugs. 
    - Chunking experiments to focus on one thing at a time improves the quality and clarity of data 

- **Speed up progress with positive feedback loops**
    - The two teams utilize eachother's strengths to increase the speed and quality of output. Read more about this in the **Feedback Loops** section.      
- **Accountability**
    - Deadlines 
    - Leaders who are responsible 
    - Very little diffusion of responsibility (people owning tasks, not sharing them)
- **So Good they Can't Ignore Us (Showmanship)**

    - Traditionally, showmanship is our weakness. 
    - It's a focus on quality over quantity.Do more with less and make sure everyone sees what we've done. 
    - Showmanship is not just content creation and PR. It's the entire rollout. Devs, designers, rangers, we should all do what we can to present our features in the best possible light. 
    - As an example, when Discord rolls out a feature, they make sure we know about it. We don't have to go to their Twitter page or skim through docs to find out. 
    - Showmanship is a way to share more of the app with our users. It increases accessibility and forces us to address the user more directly. 
    - I wrote more about showmanship in additional reading. 


## What is Team Rage? 

### Team Goals: 
 
- Discover the future of DAOs and governance.
- Chronicle experiments to build a body of knowledge 
- Collect Baal-specific information for MageSmith and community education. 
- Pass on interesting findings to Rangers for community engagement and lore
- Test and compare new Web3 products, DAO designs, and community designs (ex. decentralized storage)
- Learn Baal's vulnerabilities and blind spots.
- Dogfood Team Sage's build tools for later experiments. Pass on feedback. 
- Ensures that Team Sage is well-informed before UX stage. 

  
### Characteristics of Team Rage
- Strives to find the truth as fast possible
- Hacking over engineering.  
- limited science based-approach to designing experiements. 
    - Should be scientific enough to provide useful insights and approximations, but without the academic bloat. 
- ED (Experiement Designer) strives to create the leanest experiments possible 
    - testing falsifiable positions 
    - Uses reliable benchmarks
    - simplifies experiments as much as possible
    - results are recorded for all to read (abstract, design, observations, conclusions)
    - Does not do peer review, reproductions etc (unless another Team Rage pops up)
- Team Rage is canary in the coal mine for
    - new tech
    - new DAO designs
    - new coordination mechanism
    - Baal stuff
- Writes abstracts for Rangers
- Gives presentations to WarCamp


### Makeup

Involvement in Team Rage should be capped. Based on previous patterns, most are going to want to work in the dept. To ensure balance, we should set a ratio of Rage to Sage. 

Must Haves:

- 1 fullstack dev who also does DAO admin. Full time 
- 1 Experiment Designer (Project Management, writing observations, Coordination w/ Team Sage). Full time. 

Nice to Haves: 
- 1 back end dev (deployement, subgraphs, centralized caching) part time.


## What is Team Sage? 

### Team Goals: 
 
- Build a high-impact quality product 
- Build tools to speed up develop development 
- Drive usership through UX
- Drive an ecosystem of boost with a robust boost architecture
- Encourage DAO apps (bolt-ons) with a suite of Dev Tools
- Dogfood DAOtools in our own apps and experiments.
- Create a polished UX throughout the app
- Minimize the bug whack-a-mole. Write lasting code that rarely needs to be fixed or refactored.  
  
### Characteristics of Team Sage
- Strives to create the best experience possible
- Engineering approach over hacking. 
- Decisions are informed by real world experiments 
- Project Manager handles coordination, timelines, deadlines, meetings so that Devs and Designers can focus on their work. 
- Utilizes Deep Work to come up with creative, minimalistic solutions to novel problems. 
- Tests, QA, code review, types. We want as little bugs in prod as possible. 
- Still not searching for perfection. But as close as possible, given our constraints. 
- Is resposnible for patches, bug-fixes
- Writes docs after feature releases
- Writes dev docs after architecture releases
- Gives presentations to WarCamp
- Works with Rangers on tutorials. 


### Makeup

Must/Already Haves:

- 1 Fullstack team lead. Coordinates dev resources Full Time. 
- 1 Project/Product manager. Keeps team focused, enforces deadlines and QC. Full time.  
- 1 Principle Frontend or Fullstack Dev to design app architecture and patterns. Full time.
- (Need Design notes here)


Nice to Haves: 
- 1 Decentralized Storage and Dev Ops. PT/FT.
- Additional Devs to manage and maintain DevTools. FT/PT.   
- Technical Writer. Docs, dev docs, tutorials, 'the making of' pieces.  
- User Testing specialist
- (hear more from design)
- 1 (capped) boost dev to test boost DX. PT. 

## The Handoff
The handoff is the phase where data is passed from Rage to Sage. Both parties make sense of what's going on and how this makes sense for the product. 

Team Sage may ask for more data before implementation. 

**Cost Benefit**
Team Sage uses the data to determine cost/benefits for new features. Team Rage does so for studies. 

**Who gets to choose the experiements?**
    - To speed up development, Team Sage gets first pick
    - Then Team Rage
    - Then wider WarCamp
    - Then the community 
    - Later on, once we've accomplished our goals, we should devote a guaranteed timeframe for free, open experimentation.
    
 **What should be passed to Rangers**
 
 **What should be presented at WarCamp meeting**
    
    

## Proposed Roadmap for 2022 

Note: Much of this centers around what I'll be doing. I need input from designers and people who'd like to work on Team Sage. 

**Short term (2-4 months)**
- Rage begins Baal tests
- Rage produces a provocative, interactive Baal experiment for Eth Denver
- Rage tests decentralized storage
- Sage finalizes V2 designs 
- Sage devs learn new Frontend tooling
- Sage finalizes DAOhaus design system 
- Sage builds backend architecture (legos, caching, DAO state, CRUD ops)
- Sage builds frontend state management layer
- Sage incorporates ID and CMS for V2 DAOs


**Med Term Goals (4-7 months)**  

- Rage after having completed many studies on Baal consolidates data (I'll need more data on what Rage will be doing)  
- Sage builds out component library
- Sage designs v3 app. 
- Sage hosts a site with code for all of our hooks (as opposed to repo; similar to usehooks.com)
- Sage builds a new, re-skinned V2 built with DAOtools (timed release with raise)
- Sage builds API for publishing boosts & legos

**Long Term Goals (9-10 months)**
- If still no interest in boosts, Team Rage goes all out on boosts to ignite interest
- Sage builds V3 app and links into existing app. 
    
Still needed: 
- Marketplace
- Explore 

## Additional Reading

### Feedback Loops

 - **Tooling:** Team Sage creates DAOtools.=> Team Rage uses those tools to build experiments faster => They test and pass feedback back to Team Sage.  
-  **Community Growth:** Team Rage enrolls participants to enhance DAO coordination studies => passes findings to Rangers => Rangers engages community with lore => More participants sign up to join in on experiements. 
-  **Open Rage**: Team Sage builds **super-sweet** DAO tools => community members get research grants from UberHAUS and uses tools to make their own Team Rage-style R&D units => Team Sage benefits from knowledge
-  **Distributed Authority**: Team Sage takes direction from the results of Team Rage's experiments. Team Rage's experiments are decided mostly by what Team Sage needs to know. 

### On Showmanship

Showmanship, in the context of Team Sage and Rangers, should be a focus on quality over quantity, removing any possible flaws (within budget), and making sure others are aware of this quality. 

It's also a focus on how a feature is presented to the public. Everything should work in unison with the various circles of DAOhaus. 

For a gourmet chef, it's not enough to simply use good ingredients. The dish's presentation, the professionalism of the staff, the  atmosphere of the restaurant all tie into the experience. We need to take that approach with our feature releases. 

If we a feature gets released on an empty Discord channel, does anyone hear it? 

