• PR refers to a Bugzilla Problem Report.
• DR refers to a Phabricator Differential Revision.

Let's just term them “issues” from here on.

Note that PRs contain a mix of suggested patches along with what is truly a Problem Report.

• find some existing issues for attendees to work on (specifically, those that already have patches), or
• discuss how to improve our handling of patches, or
• discuss bug triage and workflow in general.

• Bugzilla
  • all base system PRs with patches (570)
  • all base system PRs with patches, but assigned to no one (259)

• Phabricator
  • base system DRs (> 1000)
  • all DRs (1000s)
  • needs review (120?)
  • I do not know how to get a summary report to get the exact totals.
  • How to search for “DRs with no reviewer?” Does not seem possible.

• Bugzilla
  • PRs with patches (see above)
  • PRs assigned to particular mailing lists, e.g. net@
    • except in a few cases, not granular enough
    • tip: run general report and sort by assignee
  • one or more keywords
    • our list of keywords is sparse; the taxonomy needs to be defined better.

• Phabricator
  • can create custom queries, but somewhat cumbersome
  • I can't figure out how to query “assigned to no one”
    • Should there be a policy to say “all DRs must a non-null reviewer”? even if it is a group?

• networking? filesystems? userland? Speak up!

• Problem: firehose effect for incoming issues
• Problem: how to search existing issues
• Problem: how to present only “issues ready for committer review”
  • The Bugzilla approximation is keyword patch-ready (8)
    • requires manual work by triagers
  • The Phabricator approximation is needs review
    • automatic side-effect of workflow

• no agreed disposition of “issue held by committer too long”
  • EitanAdler used a hammer a year ago. Did people:
    • not object?
    • not notice?
    • had already given up long ago?
  • some issues should really belong to a certain committer (via MAINTAINERS)?
  • the only _existing_ policy is to deassign issues from committers whose bits are taken in for safekeeping
• more importantly, no documented policy requirement for reviewers to handle things “in a timely fashion”
  • should this policy be different for issues they authored or agreed to review, or that someone assigned to them to review?
• would regularly scheduled “bugbuster office hours” work?
• difficulty of training novice bugbusters on how to do effective triage
  • far more difficult: “doesn't work” vs. “proposed fix”
  • even with “proposed fix”, still needs:
    • does this patch even build?
      • harder to do the older the issue, leading to universal frustration
    • is this patch being seen by the right people?
    • is this patch an appropriate solution for the problem?
    • is this even a problem that should be solved?
      • “please just do this on your own system” (without being rude)?