---
# System prepended metadata

title: Cards for v3
tags: [' working session', ' dragons', ' notes', v3]

---

---
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