• 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.
    • examples: D19690, D19690, D17105

• 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

• overall management concern: showing respect for contributors/triagers/developers no matter what their participation
  • this is why MarkLinimon is opposed to “big sweeps to close”
    • exception: FreeBSD version no longer supported
  • must assume that everyone is overcommitted
• no agreed disposition of “issue held by committer too long”
  • EitanAdler used a hammer ~ one year ago. Did people:
    • not object?, or
    • not notice?, or
    • had already given up long ago?
  • some issues should really belong to a certain committer (via MAINTAINERS)?
  • the only _existing_ policies:
    • deassign issues from committers whose bits are taken in for safekeeping
    • close issues that have already been committed
• 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?
• 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)?
  • we are not doing a good job on cross-training
    • individuals “do not scale”
• would regularly scheduled “bugbuster office hours” work?
  • possibly with a specific topic for session N:
    • “today we look for issues that have already been committed”
    • “today we look for issues assigned to committers which have not been touched in a year”

• src PRs with patches, assigned to no one, in state "new" (62 → 50)
  • dealt with:
    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237576
    • https://reviews.freebsd.org/D20072 (xref to above)
    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236836 (feedback given to submitter)
    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235380 (assigned)
    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233960 (Intel notified)
    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231873 (closed/committed)
    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231851 (closed/OBE)
    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231768 (needs to be discussed on mailing list)
    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231445 (notify kib)
    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231354 (assigned)
    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229818 (assigned)
    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229763 (person who is doing the actual work notified)
    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228800 (assigned)
    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228668 (false positive, needs bugmeister work)
    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228409 (“needs work in order to be committable)
    • https://reviews.freebsd.org/D20324 (assigned)
    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228076 (assigned)
    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227436 (assigned, to see if fixed/OBE)
    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227285 (notified more people)
    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226609 (really, a “feature request”)
    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225096 (???)
    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224615 (deferred)
    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223831 (Cc:s added)
    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223640 (committed/OBE)
    • …
    • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221906 (assigned)
    • …