Reasoning
- tracking "in-progress" in multiple places is hard and the fewer places we do it the better. I've seen in-progress tracked well in team-specific "sprint" or "kanban" boards instead.
- Categorizing tasks by type...
- makes it easy to see where a lot of tech debt lives (or where processes/tooling should be improved, at least)
- helps new comers to get involved
- encourages more active triaging into those categories (easier to do and more reward than just making the huge backlog column even huger)
- and, it more manageable than a single big "backlog" (and to-triage) column
Proposal
(based on trying to categorize all of the current tasks in my head)
- To Triage (default)
- EPICs / Tracking
- Backlog (general) - general column, could be broken up more later if we need to (or other columns merged into it if they don't seem useful in practice)
- On wiki change - no code changes/deploys needed
- Extension and Services deploys - deploying/enabling new extensions and/or services on Beta Cluster
- combined extensions and services because A) there aren't that many tasks to be unwieldy and B) they should both have the same level of awareness
- CI or CD related - changes to how Beta works to better support Continuous Integration or Continuous Deployment practices
- This may come later
- Tag
- For things like T142119: Dashboard or pane for ORES failed jobs on beta