---
tags: v3, working session, notes, dragons
---

# Cards for v3

- Taking the meeting notes from [Blacksmiths v3 Working Session #1](/lJS5s5cpRBaQASaut3DDIQ) and creating potential notes before syncing

## Ops

- **Build GitHub Actions and Deploy Targets**
- Owner: Keating
- What:
- Main app: domain set up for Skynet deploys: `alpha.summon.daohaus.club`
- GH Actions/Deployment Pipelines:
- Component library
- Subgraph deployment
- Serverless deployment

- **Component Library DevOps**
- Owner: Keating

- **Subgraph DevOps: Package setup, GitHub Actions, Deploy Target**
- Owner: Keating
- What:
- Packages:
- Subgraph
- Research local Graph deployment
- Local Graph node for development
- UI/Component library
- Baal Contract (down the line)

- **Serverless DevOps: Package Setup, GitHub Actions, Deploy Target**
- Owner: Keating
- What:
- Set up our serverless package in the monorepo
- Set up GitHub actions and deploy targets for our serverless package

- **Common Configurations**
- Owner: Unasssigned
- What:
- `eslint`, `prettier`
- Scaffold from `nx` recommended `eslint` and `prettier` configurations
- Share `.vscode` setup with format on save for linting
- Get a first version before the setup walkthrough

- **Local Development Environment Setup Docs**
- Owner: Keating, jp
- Depends On: Common Configurations
- What:
- Do a session to ensure that everyone is able to run things locally
- Lead (and record) a walkthrough to get folks up and running locally
- Create a README for each package in monorepo
- Create a high-level README at the root with overview of how to set up and work with the monorepo
- Make sure everyone has `eslint` and `prettier` working locally

- **POC CLI**
- Owner: dekan
- What;
- Currenly in the Baal repo
- Will help with dev work to spin up new proposals
- dekan is currently working on this

## Component Library

- Created as a package with a namespace such as `@haus/components` in the monorepo
- Storybook installed on this package so that each component can have a story
- Storybook can then be deployed separately from apps which allows for standalone component documentation and for designers (or community folks) to check out our most recently deployed component library
- As we document in Storybook we can push updates and feature releases for our component library which will then be represented in the deployed version
- Building out the component library (`@haus/components`), `@haus/commons`, and `@haus/sdk` will increase efficiency as these can be used in each new Rage App and experiment. We then continue to add to these packages as we go and build new apps
- Goals:
- Component library (`@haus/components`) and Figma Pattern Library kept in sync and are aligned from the design token level to the macro level
- `@haus/components` components include all states and props, and this is represented and documented in the Storybook
- Designers can review the live component library via Storybook and work with devs to make sure that we're all using the same design language and that the libraries (Figma and `@haus/components`) remain synced
- Design Ops Workflow:
- Designers work within the Figma Pattern Library and have workflows for creating UI for features and apps
- These would ideally be moved into the Figma Pattern Library at an atomic/macro level
- Components are then added into the component library

- **Share Learnings from Component Library Experiments**
- Owner: Andy
- What:
- Provide pros/cons from each UI library
- Provide quick Radix demo / small project demonstrating how we'd use it in v3
- Schedule a Show and Tell Friday for the demo
- Potentially document any learnings and feedback

- **Scaffold Component Library Package in Monorepo**
- Owner: Andy, Jord
- Tags: Ops, Component Library
- Depends On: Share Learnings From Component Library Experiments..., Component Library DevOps
- What:
- Component library has [Radix](https://www.radix-ui.com/) (and possibly [Stitches](https://stitches.dev/)) as dependencies
- Export all core components from Radix while building DAOhaus specific ones
- Document getting started/basic usage in the README

- **Show and Tell: Radix**
- Owner: Andy
- What:
- Demo Radix (and possibly Stitches, if ready) inside the Summoner App
- Document the learnings from this session (if we can record)

- **Get Storybook Set Up**
- Added to the component library package
- Depends On: Component Library Setup
- What:

- **Create basic DAOhaus Theme**
- Down the road

## Data SDK

- Mirror the card order to match the structure for the component library
- Add these to the board with more detail and assign to Sam
- tag: haus-sdk
- Relates to fetching data
- Should common functions go in here?
- `commons` shared across several packages
- Present this structure for feedback on Friday

## Deliverable Questions

- How do we work with these things? How do we break them up?
- Currently, doing rages on each piece
- Can play with everything and iterate on top of it all -- when do we know when to move from Rage to Sage?
- Case by case basis for when to move from Rage to Sage per product
- Create a Rage Report
- https://github.com/HausDAO/daohaus-rage/issues/9
- Review on Friday after Rage
- This may create new tasks

## The Rage Machine (Rage App Lifecycle)

- Create a `rage` tag for us across all repos
- Rage Identified! -> Rage scoped and added to Project Board -> Identify if the Rage has subtasks
- Occurs at the technical speccing for the Rage

### Leading up to a Rage

- "Define" the Rage
- Add a `rage` label as well as the app you're working on:
- Example Labels: `rage` `hub-app`
- Create a template with whatever we'd want to include in the speccing for a Rage App
- Basic Details/Overview
- Resources Needed
- Identify what's needed for this Rage: Subgraph? Figma mock? Contracts?
- What is the Purpose? / Hyptothesis Being Tested
- Rage Report can reflect on this hypothesis and learnings along the way
- Team
- Certain Rages will likely be a single person, but some may have a team (such as Andy and Jord on the Summoner Rage App)

### Rage is happening
-

### Rage is done

1) Rage finishes
2) Rage report shared on the Friday after
3) Added to Wiki
4) If cards come out of the demo, add these to Board/next work cycle
- ie: From Summon, want to do a Rage on how to pull out transactions to add to the SDK? -> May have additional cards for the next work cycle
5) If everything is ready, move to Sage version
- This then enters the project lifecycle:
- Backlog -> Design -> Speccing -> etc
- Would contain more classic user stories with features

### Rages Needed:
- Summon App (done -- report in progress)
- Hub App
- Sam for Subgraph work, Jord for frontend
- Proposal Form (Core UI)

## Sage App Lifecycle

- This will be established as we get here -- we also need a cool name like "The Rage Machine" for the Sage App Lifecycle
- More traditional user stories

## Design Ops Processes

- This is a bit less defined at the moment, but wanted to capture some items here that will be useful for establishing *Design Ops* processes
- Once this are ironed out more we can turn into issues/cards
- Goals:
- Streamline handoff and sync process between designers and devs
- Ensure that the component library `@haus/components` is in sync with the Figma design system -- these ideally should match
- Establish common design language for DAOhaus (especially as related to v3)
- Storybook process and management
- Documentation of components
- Designers to test in isolation and see all states
- Design token management
- Identifying color systems
- Sizing, spacing, etc.
- Pattern library
- Identifying items in the Figma pattern library and the workflow for integrating these into the component library

## Next Steps

- [ ] Add cards to *Invisible Suburbs* Project Board - jp
- [ ] Expand the Data SDK cards
- [ ] Expand the Component Library cards
- [ ] Create cards for the `@haus/commons` package - jp
- [x] Write up notes on component library structure - jp
- [x] Rage App Lifecycle into the Wiki as a starting point - jp
- https://github.com/HausDAO/daohaus-monorepo/wiki/Rage-Machine:-Rage-App-Lifecycle
- [x] First version for Rage ticket template - Sam
- [x] Make sure we have all the tags and labels we need -- set these in the individual repos
- [x] Create `rage` and `sage` tags
- [x] Look at Jord's Rage Report for Summoner - jp
- [Rage Report: Summoner](/SLJNR5VoSzGlrJPN1_DnqA)
- [ ] Rage Report Template v1 - jp
- [ ] Schedule work session for local environment setup - jp
- Show and Tell Friday session?

## Next Steps 3/21

- parsing details
- parsing statuses
- break up other issues into cards
- component library cards
- think through v2 issues