From MozillaWiki
Jump to: navigation, search

Making Triage saner on BMO


  • Create an "Un-Triaged Bugs" product, with per-product components
    • Only selected products will use the "Un-Triaged Bugs" product (Firefox, Thunderbird, etc), all other products will remain untouched
    • Bugs filed via the guided form (ie. by users without canconfirm) will be filed into the un-triaged bugs product
    • A custom triage field will be added, visible only on bugs in this product:
      • -- (No triager has worked with the bug)
      • Needs-additional-triage (Another triager should see if it needs any additional action)
      • Needs-user-input (The reporter/someone needs to provide more information)
      • Needs-qa-input (QA needs to provide information)
      • Needs-developer-input (A developer/module owner needs to provide information)
      • Needs-steps-to-reproduce (The reporter/someone needs to provide new/better STR)
      • Needs-reduced-testcase (The reporter/someone needs to reduce the testcase)
      • Triage-complete (No other triage action needed)
      • Triage-not-needed (No triage needed to begin with)
    • The list of versions on the untriaged product needs to mirror the versions on all the component products (ie. it needs to have at least all Firefox and Thunderbird versions)
      • This can happen automatically as versions are altered on the base product, or components are altered on the untriaged product
    • All existing UNCONFIRMED bugs will be moved to the new product
      • Use the move-bugs script, need to verify it works sanely when there are mismatching versions, milestones, etc
  • Add a RESOLVED>SUPPORT status
    • Clearly shows the issue is a support issue
    • Lessens the impact and confusion to new users from the current use of INVALID, which is now support issues are currently resolved
  • Identify and create reports to assist triage
    • Bugs with need-user-input where a comment has been made after the flag was set

Medium Term

  • Use a different/modified show_bug template for bugs in the "Un-Triaged Bugs" product
    • provided a limited view, for all users regardless of permissions
    • remove keywords?, milestone, qa, depends on, blocks
    • provide a highly limited view, for users without canconfirm
    • remove priority, product, component and importance
    • focus on making the status of the bug clear, both to the reporter and triage/support
    • can't deviate too far from the normal show_bug however, to avoid confusion
  • Send product and status specific email from the "Un-Triaged Bugs" product
    • make triage emails "friendlier" (html)
    • to minimise impact on other systems which parse the emails (bots/pulse/etc) we can make only the reporter receive the friendly version, other recipients (QA, CC, watchers) will continue to receive the full email
    • when an issue is resolved as a SUPPORT issue, automatically include links to the right support resource (eg. Firefox support issues get links to sumo)
  • Add widgets to ease triage directly to the show_bug page
    • duplicate bug detection XHR
    • add a <select> with a list of pre-defined canned responses

Long Term

  • Single-click moving of issues between BMO and sumo and other bug trackers (bug 444302)