Conventions

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.

Different possibilities for this conference

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.

Existing Issues

Resources

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

How To Find Things To Work On

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?

Specific Attendee Interests

networking? filesystems? userland? Speak up!

How To Improve Our Handling Of Patches

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

Bug Triage And Workflow In General

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"

Prototype of "bugbuster office hours"

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)
  - ...