I Can Help Triage Issues for Angular on GitHub.

Developers who use Angular helpfully submit issues to Github. However, it can be hard to sort through this information. The triaging process assigns labels to issues to help the Angular core team address these problems. This page contains a list of currently non triaged issues as well as a description of the triaging process. If you would like to help with triaging, please contact a member of the angular core team to complete training as well.

Current Non Triaged Issues

Use whole words to request more results from server.

How to Triage

This process is based on the idea of minimizing user pain from this blog post.

  1. Open the list of non triaged issues
    • Sort by submit date, with the newest issues first
    • You don't have to do issues in order; feel free to pick and choose issues as you please.
    • You can triage older issues as well
    • Triage to your heart's content
  2. Assign yourself: Pick an issue that is not assigned to anyone and assign it to you
  3. Understandable? - verify if the description of the request is clear.
    • If not, close it according to the instructions below and go to the last step.
  4. Duplicate?
    • If you've seen this issue before close it, and go to the last step.
    • Check if there are comments that link to a dupe. If so verify that this is indeed a dupe, close it, and go to the last step.
  5. Bugs:
    • Label Type: Bug
    • Reproducible? - Steps to reproduce the bug are clear. If they are not,
    • Reproducible on master? - http://code.angularjs.org/snapshot/
  6. Non bugs:
    • Label Type: Feature, Type: Chore, or Type: Perf
    • Belongs in core? – Often new features should be implemented as a third-party module rather than an addition to the core. If this doesn't belong, close it, and go to the last step.
    • Label needs: breaking change - if needed
    • Label needs: public api - if the issue requires introduction of a new public API
  7. Label browser: * - if the issue only affects a certain browser
  8. Label frequency: * – How often does this issue come up? How many developers does this affect?
    • low - obscure issue affecting a handful of developers
    • moderate - impacts a common usage pattern
    • high - impacts most or all Angular apps
    • Label severity: * - How bad is the issue?
    • security issue
    • regression
    • memory leak
    • broken expected use - it's hard or impossible for a developer using Angular to accomplish something that Angular should be able to do
    • confusing - unexpected or inconsistent behavior; hard-to-debug
    • inconvenience - causes ugly/boilerplate code in apps
  9. Label component: *
      In rare cases, it's ok to have multiple components.
  10. Label PRs plz! - These issues are good targets for PRs from the open source community. Apply to issues where the problem and solution are well defined in the comments, and it's not too complex.
  11. Label origin: google for issues from Google
  12. Assign a milestone:
    • Backlog - triaged fixes and features, should be the default choice
    • Current 1.x.y milestone (e.g. 1.3.0-beta-2) - regressions and urgent bugs only
    • Unassign yourself from the issue