Sage - HausDAO/daohaus-monorepo-deprecated GitHub Wiki

This doc begins to explore when we start non-experiemental application development and what the criteria is for making the decision to jump from Rage to Sage.

Wen Sage

For dev projects, once all of the major technical implementation questions have been answered, usually that means it's time to start Saging.

This prevents us from having to solve large config or architectural patterns on the fly. While flowcharts and other document-based planning tools are still useful, Rages also allow us to see if our preconceptions of how something will work is actually grounded in reality.

So when a Sage starts working, they can focus on details and quality. Taking that extra time to optimize for quality will return dividends in the future as the code that the sage writes becomes a load-bearing bastion that can easily support other projects atop it.

tldr;

  • The major problems are solved.
  • The developer knows what needs to be done
  • The major patterns have been tested and there's a rough consensus among the team.
  • There's a detailed spec and Rage Reports to reference.

What is Saging (in terms of development)

Essentially, Sage is crafting with quality in mind. Where Raging is about getting something to work, Sageing is about getting something right.

Here are some of coding guidelines for sages, though the principles could be applied to other professions as well.

  • The Sage codes for the long-term. In this time-frame, shortcuts are costly.
  • The Sage writes for others, meaning that the code is maximally reusable, readable, and refactored once pushed to the repo.
  • The Sage developer writes for longevity. The more we re-solve the same problems, the less time we spend adding value.
  • The Sage focuses on depth.
  • The Sage invites criticism. They know they have many blindspots, and only the perspectives of others will be allow them to see.
  • The Sage focuses on the task at hand.

SageMode (Optional)

Doing Sage work is harder and it's generally more work. In order to meet these demands, a Sage needs to free up brain-space that's currently being wasted on unnecessary noise.

SageMode is a temporary vacation from Discord, social media, meetings, and the news. Upon taking on a large task, the Sage chooses a handler, someone who can pass them emergency information from the DAO. Then they leave Discord for a certain amount of time.

A developer's mind is usually mostly occupied with messages they need to respond to, or positions they need to take on certain issues, something they read on the news, or the choices they'll need to make on a future project.

In Sage Mode all that wasted mental energy turns to the task at hand.

It's worth noting that SageMode is not necessary to do team Sage related tasks. It's just a useful way to enhance productivity and improve quality of life.

Here are the rules for SageMode:

  • Treat SageMode like travel. Pack everything you need first.
  • Before embarking, ensure that the task is broken down, and that you fully understand what needs to be done.
  • Assign a contact to act as a liason to the outside world.
  • Create a new set of online accounts (email and Discord) that only have the liason added. Then quit everything. Uninstall apps if need be.
  • Consider browser blockers and other productivity tools to prevent compulsive distractions.
  • Work regular hours while on SageMode.
  • If you need to speak to the Liason, do so after the day's work is done.
  • Take note of how you feel when in SageMode. This is not just about getting things done, but also how good it can feel to get things done.

Sage Roadmap

Right now, we know how we want to fire TXs, how we'll build forms, our component library, and some of our TS patterns. We're learning more about the mono-repo, but there's lots of kinks to work out. We still have yet to deep dive into state mgmt and testing.

Here's what's close to Sage-worthy (1, maybe 2 weeks away)

  • Component Library (Forms and Micros)
  • Summon
  • Hub
  • SDK (Fetch)

Summon does not need statemanagement, nor does it need a complete design system.

Component library has only some tooling challenges to work through. While it is awaiting a full design system, we can start the first iteration.

Hub is a little further away than the others because we'd like to implement it with a prod ready SDK. However, like the component library, we can implement part of it.

All of these tasks require us to fix the current mono-repo bugs. We shouldn't move over to Sage without all of those issues being addressed. We should also review the structure of our repo and consider any changes that are needed before building out the production repo.

Here's what's further away:

  • Core app
  • Rest of SDK
  • Component Library Macros (beside form builder)