Roadmap Proposal: Team Rage & Team Sage

Warcamp (DAOhaus Core Contributors)
#1

Roadmap Proposal: Team Rage & Team Sage

Key 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 each other’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 experiments.
    • Should be scientific enough to provide useful insights and approximations, but without the academic bloat.
  • ED (Experiment 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 responsible 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 experiments?
- 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.

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

On 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 experiments.
  • 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?

2 Likes
#2

This is looking great. I fully agree on the process and approach!

Couple of details jumping out to me:

  1. Let’s also spend some time outlining how current v2 is supported
  • will need to do general maintenance - even if minimal - but also something no one wants to do
  1. Along those lines I think we can initially spend some sage time on v2 tooling to enable more community contribution - BOOSTS and BOLT-ONS
  • really good v2 docs
  • enhanced build set up on current app
  • maybe even a new bolt on starter repo with some key v2 primitives
  1. Team # caps and experiment prescription:

This is feeling a little too prescriptive to me and we don’t want to stifle emergent experimentation. What if we split rage into a couple of groups - one under team sage’s wing that is fully focussed on Baal and one that might be using v2 bolt-ons and chasing emergent ideas? - maybe this is the Open Rage idea?

#3

this is super powerful.

#4

Notes from Friday Meeting and Answers to Sam’s Questions.

Response to Sam’s Questions.

1. Let’s also spend some time outlining how current v2 is supported

Completely agree. If we have someone who would enjoy sticking around to do maintenance + assistance from folks on Team Sage, that would be great. If not, we’d probably need to make a schedule where we each take turns working ‘bug shift’

2. Along those lines I think we can initially spend some sage time on v2 tooling to enable more community contribution

For sure. We all agree that this part of the feedback loop needs to wired in better. In the meeting I mentioned that we shouldn’t build anything for v2 (old), and should stick to things like docs and tutorials. Also the fixing the dev environment is probably one of the easiest wins.

There was a slight difference of opinion about doing a starter repo. Definitely worth hashing out more. I was also thinking if we were going to invest a bit of Rage time into something for the existing V2, maybe we could prototype some of the backend services mentioned. Perhaps a /dev bolt-on that makes it easier to publish boosts. Something to think about.

3. This is feeling a little too prescriptive to me and we don’t want to stifle emergent experimentation.

In the convo, I stressed the need for a bout of extreme focus for a period of time in order to meet our own expectations. I think we need some temporary hard-focus in order to accomplish that. Distributing authority, where Sage is able to direct the focus of Rage and vice versa, might be a great way to get there. Definitely worth hashing out more–especially when there’s more potential Rage-folk there.

We also talked about setting aside some time for creative work. We all agreed on this, but the details of how much and when will still need to be ironed out.

Other Highlights I can Remember

Separating Concerns

Ven had summarized this as an effort to separate concerns. It allows us to take all of the UX concerns that we’d learned them over the past year and apply them to the app, without having to worry about also incorporating Baal at the same time. That way, once Baal is ready, it becomes much easier to roll that in.

Emergent Tools

The proposal above suggests that we’d make our libraries before building the app. As we discussed in the meeting, this is an awkward way to build things. It’s likely that the libraries will emerge from the app. However, we can still build in a way that optimizes for separation.

Rage/Sage Roles

The proposal does make it seem like Team Rage is just going to be testing Baal. As Keating pointed out, the lines of what type of tech gets created where will probably blur. One feature from Rage gets hacked together, bounced back to Sage for refinement, then used in the next experiment. There might not be a certain type of tech that’s sacred to each side–which is good.

The main distinction between the two teams will probably be a persona or mindset when it comes to the purpose of why something is being built.

Including the Rangers

I’d written more about including the Rangers in the original drafts, but I decided to take it out to focus the proposal. But we all agreed in the convo that we need to work with the Rangers in unsion. I made a flow chart for how the Rage/Sage relationship works, I’ll share in the next comment.

Roadmap Timelines

We didn’t cover too much timeline stuff during the meeting, but I think it’s fair to say that the timeline mentioned above is not up to date. Since we decided that the DAOtools will come after a revamped V2, releasing a the V2 would be more like 4-5 months instead of 5-7.

Still Very Much a Rough Draft.

There’s a lot to discuss and debate here. Nothing’s set in stone. I’m looking forward to hearing everyone’s thoughts about this during the roadmap meetings.