Skip to content

Latest commit

 

History

History
30 lines (22 loc) · 1.23 KB

2022-02-02.md

File metadata and controls

30 lines (22 loc) · 1.23 KB

2 February 2022

or, Thoughts on triage

I'm not sure the currently forming process for bug triage is heading in the right direction. It seems we're doing:

  1. Walk through repos, looking at new issues in some ~arbitrary time frame but ostensibly "since last time we did this".

  2. Talk about each, add some to board and label them with "user pain", leave others as is.

  3. Roughly work on issues from the board's backlog.

But this single threads ~7 people's time and doesn't seem to acknowledge the reality that we do a lot of work not represented by our labels or even our issues.

I think instead that our planning board should be focused on strategic goals or changes that are bigger picture than issues, with issues present there but taking a backseat instead of the primary thing.

Instead of triaging issues as a separate process and then working down that list, triage as they come in (whoever does it first). Then work on issues as they relate to features (strategic, goal-oriented, future-driven) or other strategic goals.

Update 15 Feb: Triage is changing so that we'll default to adding things to board and triaging from there. This helps a bit, but is still not focused on strategic, longer-term, bigger-picture planning.