Conventions

Kitchener bugbusting topics.

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”