v3 Project Planning: 3/21/2022

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