Some good kabbalistic significance to our issue tracker, but I’m not sure how.
First, a note: I have heard recommendations to try to lower the number of issues. I’ve never understood it except as a way to pretend like you don’t have bugs. For sure some of those issues are stale and out of date, but quite a few are probably live but ultimately very edge-case and unimportant bugs, or feature requests we probably won’t get to but could be good. I don’t think it’s a good use of time to prune it, and most of the approaches I’ve seen companies take is to auto-close old bugs, which strikes me as disingenuous.
In any case, we have a fairly normal process of setting OKRs for our larger projects, and tiny features / bugfixes get triaged into a backlog that we look at when planning our weekly sprints. The triage process done in our asana and is intentionally not visible publicly so we can feel comfortable marking something as low priority without worrying about needing to argue about it.
Some good kabbalistic significance to our issue tracker, but I’m not sure how.
First, a note: I have heard recommendations to try to lower the number of issues. I’ve never understood it except as a way to pretend like you don’t have bugs. For sure some of those issues are stale and out of date, but quite a few are probably live but ultimately very edge-case and unimportant bugs, or feature requests we probably won’t get to but could be good. I don’t think it’s a good use of time to prune it, and most of the approaches I’ve seen companies take is to auto-close old bugs, which strikes me as disingenuous.
In any case, we have a fairly normal process of setting OKRs for our larger projects, and tiny features / bugfixes get triaged into a backlog that we look at when planning our weekly sprints. The triage process done in our asana and is intentionally not visible publicly so we can feel comfortable marking something as low priority without worrying about needing to argue about it.