---
# System prepended metadata

title: 'v3 Project Planning: 3/21/2022'
tags: [' project management', v3]

---

---
tags: v3, project management
---

# v3 Project Planning: 3/21/2022

We reviewed the process and our initial setup, and then reviewed the current cards on the [v3 Invisible Suburbs Project Board](https://github.com/orgs/HausDAO/projects/3/views/3)

## Comments and Notes

- One thing to be mindful of is increasing the size of our Kanban board
    - Given a goal is to break cards into single items where possible and we want to avoid having too many items in each lane, we may soon encounter a crowded board
    - As we identify and solidify best practices we can replicate these across other GitHub project boards. For example:
        - It may make sense to split into a Rage Board and a Sage Board as these grow -- they're already separate repos, but we're tracking issues and cards in a single project board
        - As projects emerge and evolve can share learnings and copy processes as a starting point (and then the project team can iterate)
- Items that are in the *Ready* lane should represent a level of collective knowledge and fidelity -- these cards should include enough context, detail, and resources so that folks are able to self assign and work without needing to ask additional questions
    - Dragon team responsible for ensuring that these cards are in appropriate state of fidelity (labels, context, resources such as Figma, etc.)
- Need to split out certain cards that are too big in scope (monorepo CI/CD and DevOps)
    - In progress -- this card can be archived once it's all represented
- Cards won't be directly assigned to folks -- each week in the Monday planning meeting people can grab what they want to work on and move into the Development/Design lanes from Ready
- Balance between the team assessing and identifying prioritized work and being able to self-assess:
    - Goal is to communicate and be as transparent as possible -- we're aiming for a balance and middle ground here

### Component Library and Design Ops Processes

- We need to add additional cards to represent the work being done toward this by Andy and Jord
    - Currently they're building out the Rage Summoner App and adding components to the Rage component library package as they go
    - We've identified and aligned around Radix and Stitches, so we should refine the current cards to represent this
    - Adding Storybook to this makes sense as a next step so that Andy and Jord can begin experimenting and building familarity around processes for adding stories
    - In parallel we can build the Sage component library package (DevOps around creating the package, adding Storybook, and deploying)
        - This can happen at the same time and is no longer a blocker since Andy and Jord can work in a Rage Storybook
        - **Note**: Deprioritizing the Ladle exploration since any benefits in build speed may be lost in not having tooling support
- We should create a separate Component Library GitHub Project Board and represent the workflows there
    - We can take steps for this to not become a silo'd process, and this will allow for more granularity and review between design and dev teams
    - We'll take some time this week to experiment with a v1 for this

## Action Items/Next Steps

- [ ] Break out Sage monorepo DevOps/CI tasks into separate cards
- [ ] Add additional component library cards to more accurately represent the work being done this week
- [ ] Brainstorm/test Storybook and Design Ops/Processes in the Rage component library