kylefang/angular.js
1
0
Fork 0
mirror of https://github.com/zhigang1992/angular.js.git synced 2026-01-12 22:45:52 +08:00
Code Issues Packages Projects Releases Wiki Activity
Files
f4d850e16803dfd2ea4ffc7399b41cede688bba6
angular.js/TRIAGING.md
Tobias Bosch f4d850e168 docs(TRIAGING): Labels cla yes/no are automatically set 
The labels are set by a script and
should not be set manually any more.
2013-12-09 17:30:43 -08:00

2.9 KiB
Raw Blame History

Triage new issues/PRs on github

This document shows the steps the Angular team is using to triage issues. The labels are used later on for planning releases.

Tips

  • install github pr helper extension and become 356% more productive
  • Label "resolution:*"
    • these tags can be used for labeling a closed issue/PR with a reason why it was closed. (we can add reasons as we need them, right there are only a few rejection reasons. it doesn't make sense to label issues that were fixed or prs that were merged)

Automatic processing

We have automatic tools (e.g. Mary Poppins) that automatically add comments / labels to issues and PRs. The following is done automatically and should not be done manually:

  • Label "cla: yes" or "cla: no" for pull requests

Process

  1. Open list of non triaged issues

  2. Assign yourself: Pick an issue that is not assigned to anyone and assign it to you

  3. Assign milestone:

    • "Docs only" milestone - for documentation PR -> Done.
    • Current/next milestone - regressions
    • 1.2.x - everything else

  4. Label "GH: *" (to be automated via Mary Poppins)

    • PR - issue is a PR
    • issue - otherwise

  5. Bugs:

    • Label "Type: Bug"
    • Label "Type: Regression" - if the bug is a regression
    • Duplicate? - Check if there are comments pointing out that this is a dupe, if they do exist verify that this is indeed a dupe and close it and go to the last step
    • Reproducible? - Steps to reproduce the bug are clear, if not ask for clarification (ideally plunker or fiddle)
    • Reproducible on master? - http://code.angularjs.org/snapshot/

  6. Non bugs:

    • Label "Type: Feature" or "Type: Chore"
    • Label "needs: breaking change" - if needed
    • Understandable? - verify if the description of the request is clear. if not ask for clarification
    • Goals of angular core? - Often new features should be implemented as a third-party module rather than an addition to the core.

  7. Label "component: *"

    • In rare cases, it's ok to have multiple components.

  8. Label "impact: *"

    • small - obscure issue affecting one or handful of developers
    • medium - impacts some usage patterns
    • large - impacts most or all of angular apps

  9. Label "complexity: *"

    • small - trivial change
    • medium - non-trivial but straightforward change
    • large - changes to many components in angular or any changes to $compile, ngRepeat or other "fun" components

  10. Label "PRs welcome" for "GH: issue"

    • if complexity is small or medium and the problem as well as solution are well captured in the issue

  11. Label "origin: google" for issues from Google

  12. Label "high priority" for security issues, major performance regressions or memory leaks

  13. Unassign yourself from the issue