Severity/Priority of related issues
Problem
tldr: How to label related issues necessary to complete a typebug issue?
Given there’s a typebug issue that needs some combination of frontend, backend, and database work, we might create new issues to
- represent the work needed in cohesive chunks
- make it easier to track and understand who is DRI for what
- understand timing of each part of the work
For example:
-
issue A, the bug report
-
issue B, the backend work needed to fix bug
-
issue C, the frontend work needed to fix bug
-
issue D, the database work needed to fix bug
In this scenario, issue A won't be considered complete until all the other work is done.
Issue A has a priority, severity, and due date set.
Questions arising from problem
- Should issues B, C, and D take the same labels (typebug , Deliverable, severity x, priority y) and Due Date as Issue A (the original bug report)?
- If not, what should their labels be?
Recommendation for labeling the related issues
- label all the related issues as typebug
- do set a Due Date that is before the due date of issue A.
- do not set a priority or severity for issues B, C, D.
- set as blocking the original bug issue
- say why it's blocking the original bug issue
- on the original bug issue, clearly state in the description the order (if applicable) that the blockers need to be resolved in
- if DRI of Issue A (the main bug issue) cannot complete all ancillary work on their own (for example DRI is backend and needs frontend support) and the bug is Deliverable, it must be brought up in the Planning Issue to determine if there's bandwidth from the relevant disciplines.
Alternative
We could use just 1 issue and use well structured threads on the issue (like a backend thread, frontend thread, etc). We'd have to then have a a label like frontend-weight1 backend-weight2 and a new one like that for database.
The benefits are
- single source of truth
- less time applying labels, linking issues
The negative is
- I think it's harder to properly credit work to people this way and probably harder to keep an accurate view of the team velocity.
- this can get very hard to parse a long issue with many threads rather than keeping discussions about particular parts on their own issues.