Documentation for triaging Github issues?

LLVM Project
4

I’m not aware of such documentation, but the highlights are (not covering project-specific ones):

  1. Use confirmed for issues with bugzilla label if they are still relevant today (e.g. still reproduces).
  2. When you close an issue, pay attention to closing as completed (i.e. done, resolved, fixed) and closing as not planned (i.e. not a bug, won’t fix, works for me, duplicate, stale)
  3. When closing an issue as not planned, be sure to add the most appropriate label with reason. Options are: worksforme, wontfix, invalid, duplicate, incomplete
  4. We have labels for outcomes: crash-on-valid, crash-on-invalid, hang, miscompilation, accepts-invalid, rejects-valid. (There is also crash label, but its target audience are people doing triage for project they are not experienced with. Experts are encouraged to make a judgement between crash-on-valid and crash-on-invalid.)
  5. I believe good first issue should come with some analysis and points of entry into codebase.
  6. new issue should be removed when other labels are added.
  7. waiting-for-author is useful to track which issues can be closed (often as incomplete), because author hasn’t got back to us in a while.
  8. documentation is a single label for documentation issues. Meant to be used together with a project-specific label.
  9. metabug for (usually) long-lived issues that are used to collect references to a group of similar or related issues.
  10. enhancement for issues that are not really issues, but e.g. feature requests. Recently we tried to improve description of this one: Improving things as opposed to bug fixing, e.g. new or missing feature .
  11. question is obviously for questions.
  12. bug label exists, and widely used if you look at numbers, but I consider it redundant, because we are in bug tracker context, after all.
  13. extension:* labels were recently invented for Clang, but this group might become useful for other subprojects as well. Currently it consists of extension:gnu, extension:microsoft, extension:clang, and extension:borland.
  14. Other useful labels: regression, quality-of-implementation.

We strive to avoid proliferation of labels, e.g. clang should never go together with more specific clang:frontend label. My personal soft limit is 5 labels. After that point I think twice before adding another label.

Be sure to check labels specific to your project here: Labels · llvm/llvm-project · GitHub !

I believe PRs and issues should be treated the same way when it comes to labels (if possible, of course).

I’ll give it a try, but it’s not a step-by-step instruction with particular order. When I look at issue, I try to do the following:

  • Find or create Compiler Explorer link.
    • Ask for more context if CE link is possible, but no enough info provided
      • Add waiting-for-author
    • Mark as regression
    • Mark as confirmed
  • Add subproject/infrastructure/cmake label
  • Add crash/hang/miscompilation label
  • Add appropriate backend label
  • Mark as question or enhancement
    • I often leave enhancement to people with more experience in respective subproject

If I end up doing anything (leaving a comment or labeling), I remove new issue. To be honest, I feel embarrassed each time I look at 273 Open 50 Closed “new” issues, which date back months and years. So recently I’ve been draining this queue.

3 Likes