Belated summary: We didn't go through many bullet points above, but instead had a good open conversation about anything Phabricator and PM.

Some notes (my personal interpretation of things):

• Scope, teams planning/organizing work (project tasks) versus specific technical issues (operational tasks) and ideas to stay around or to decline
  • Two paradigms / uses: Filing tasks against a codebase, versus planning work for your team. Should be two different layers.
  • Every tag could be a workboard versus having a bucket. Maintaining multiple labels is annoying. Would like to seperate the big to-do bucket versus here's what we'd actually like to do with our limited resources.
  • Using Phab as communication with stakeholders, declining a task can be more work versus leaving a task "unscheduled" on a workboard. Closing tickets might not be socially acceptable. "Losing content" (but maybe not everybody knows how to search for closed tasks?). Do we document what the purpose of Phab is [not]? Phab could be more useful if there was a clear and shared understanding to use it for immediate things, and not for big non-actionable narratives/ideas?
  • Keeping tasks open versus closing an incomplete task which could feel like a failure. Sometimes also long-term archictecutre changes like a prototype of an Epic ticket and that never reaches a priority level. We don't want to throw away good ideas, but limited resources.
• Backlogs
  • Some backlogs are a graveyard - many tasks no longer valid or nobody understands what should happen, because they are many years old, and that backlog grows every day. Digging in for an hour is sometimes not worth this time. Potential guidance to granularity for one tool and potentially another separate tool for high-level stuff (WMF uses "Betterworks" for high-level planning), but syncing multiple systems is also confusing.
  • Some teams tried to reduce their backlog per quarter, still some tasks might be in potentially forever.
  • Team resources are limited and it can be demoralizing to have so many tasks - define task age thresholds?
  • Lack of guidance how to organize and regularly groom
    • For example, huge team boards that includes all tasks, many columns, divided by topics. Board for each project versus monolithic approach?
    • One big team board, each sprint has its own board. It's hard to provide attention to team board, sprint board and code project boards at the same time.
  • There are some project tags for components that a team is supposed to steward but not enough capacity or workflow to always look at these boards. Tagging a team can make the team triage things, but that team cannot track dozens of boards/project tags.
  • Team grooming workflows: May want to use team board for higher-level tasks only and have low-level things not be reviewed by everyone in team; might need better ownership definition per project tag/board.
  • Elephant in the room: Code stewardship.
  • Some teams move tickets to an "unscheduled" column, instead of removing their "team tag" and only leaving a codebase tag?
    • Freezer/Icebox/etc lists things that a team acknowledged to steward/own but has no capacity to work on.
  • Would criteria to mass-close older tickets help (but: social aspect above), then have a bot (?) explain? cf T248034: Decrease issues created many years ago with no recent activity (aka stale tickets), T252522: (Semi)automatically close Phabricator tickets with status "stalled" after a while
  • Lack of UI that a task has been stale or idle for a while, e.g. Trello grading of colors for cards on a workboard