Process
We rage to build the machine!
Then Sage to dial it in...
Our initial approach is oriented around the Invisible Suburbs GitHub Project Kanban view and the associated issues that can be created/connected to repos in our DAOhaus GitHub organization.
We intend to start with this approach and refine and iterate and see if we experience any pain points that a more involved tool such as Linear can solve. We want to meet folks where they're used to working and limit the amount of friction as we're setting up new processes.
- Backlog
- Discovery
- Design
- Specification
- Development
- Review
- Testing
- Done
For developer focused information about our git processes, check out the Git Workflow docs page.
- Issues start here and detail is gradually added as it's available
- These can be bugs, feature requests, general ideas, etc.
-
Moves when it's decided that the team should work on these
- If design is already available (or it doesn't need design) -> Spec
- If it needs design and there aren't already design files -> Design
- Not all issues may require design, so some may move into Spec right away
-
Description: Short description of the feature
-
Criteria: How will we know it is done?
-
Requirements: (Components, Data)
- User Story
- Considerations
- Flows
- Mockups
- Specifications
Design has their own processes and workflows, so this is mainly indicators about how to sync up on hand off to Development
- Issues here require design work such as Figma wireframes
- Examples: UX/UI designs for specific features, UI mockups for specific components
- Design team will largely work within these issues and own the processes around managing this work and handoff
- Design team may have an internal process for estimating and scoping, and would add these estimates to the effort level/issue details
- Once there is a Figma design associated with the issue, this moves into Spec
- Design team can decide if they want their work to also move to In Progress
- Scenarios
We can leverage several types of testing. For now, this section will focus on Manual testing while we establish other methods.
- Automated
- Manual
- User
- All PRs from the code changes (on feature branches) merged into our
develop(or QA) branch - QA Team (ideally comprised of various stakeholders across DAOhaus) conduct thorough and holistic tests across all impacted apps
- This step may look different for the SDK, Subgraphs, etc. but we'd still want to test all of the changes instead of individual feature changes
- Another area we'll want to think about is when we want to move issues to done. We can do it once the initial review happens (such as the feature branch is merged into
develop) or we can wait until all feature changes are merged into prod. This will change over time since right now we're not quite at the feature release stage in prod.
- Create descriptions for each column
- Create definition of done for each column
When is a draft converted to issue?
- Titles
- User Stories
- Links to specs
- Links to assets
- BDD Scenarios (Amos)
-
Milestones
summoner-alpha
- Tags
- Kanban
- v3 Project Statuses - WIP for addressing each of the items in the TODO section