This document describes how the Angular team uses labels and milestones to triage issues on github. The basic idea of the process is that caretaker only assigns a component and type (bug, feature) label. The owner of the component than is in full control of how the issues should be triaged further.
Once this process is implemented and in use, we will revisit it to see if further labeling is needed.
A caretaker should be able to determine which component the issue belongs to. The components have a clear piece of source code associated with it.
comp: animations
:@matsko
comp: benchpress
:@tbosch
comp: build & ci
:@IgorMinar
-- All build and CI scriptscomp: common
:@mhevery
-- This includes core components / pipes.comp: core & compiler
:@tbosch
-- Because core and compiler are very intertwined, we will be treating them as one.comp: forms
:@kara
comp: http
:@jeffbcross
comp: i18n
:@vicb
comp: language service
:@chuckjaz
comp: metadata-extractor
:@chuckjaz
comp: router
:@vicb
comp: testing
:@juliemr
comp: upgrade
:@mhevery
comp: web-worker
:@vicb
comp: zones
:@mhevery
There are few components which are cross-cutting. They don't have a clear location in the source tree. We will treat them as a component even thought no specific source tree is associated with them.
comp: docs
:@naomiblack
comp: packaging
:@IgorMinar
comp: performance
:@tbosch
comp: security
:@IgorMinar
What kind of problem is this?
type: RFC / discussion / question
type: bug
type: chore
type: feature
type: performance
type: refactor
It is the caretaker's responsibility to assign comp: *
to each new
issue as they come in. The reason why we limit the responsibility of the
caretaker to this one label is that it is likely that without domain
knowledge the caretaker could mislabel issues or lack knowledge of
duplicate issues.
At this point we are leaving each component owner to determine their own process for their component.
It will be up to the component owner to determine the order in which the issues within the component will be resolved.
Several owners have adopted the issue categorization based on user pain used by AngularJS. In this system every issue is assigned frequency and severity based on which the total user pain score is calculated.
Following is the definition of various frequency and severity levels:
freq(score): *
– How often does this issue come up? How many developers does this affect?- low (1) - obscure issue affecting a handful of developers
- moderate (2) - impacts auxiliary usage patterns, only small number of applications are affected
- high (3) - impacts primary usage patterns, affecting most Angular apps
- critical (4) - impacts all Angular apps
severity(score): *
- How bad is the issue?- inconvenience (1) - causes ugly/boilerplate code in apps
- confusing (2) - unexpected or inconsistent behavior; hard-to-debug
- broken expected use (3) - it's hard or impossible for a developer using Angular to accomplish something that Angular should be able to do
- memory leak (4)
- regression (5) - functionality that used to work no longer works in a new release due to an unintentional change
- security issue (6)
These criteria are then used to calculate a "user pain" score as follows:
pain = severity × frequency
Any issue that is being worked on must have:
- An
Assignee
: The person doing the work. - A
Milestone
: When we expect to complete this work.
We aim to only have at most three milestones open at a time:
- Closing Milestone: A milestone with a very small number of issues, about to release.
- Current Milestone: Work that we plan to complete within one week.
- Next Milestone: Work that is > 1 week but current for the team.
The backlog consists of all issues that have been triaged but do not have an assignee or milestone.
PRs should also be label with a comp: *
so that it is clear which
primary area the PR effects.
Because of the cumulative pain associated with rebasing PRs, we triage PRs daily, and closing or reviewing PRs is a top priority ahead of other ongoing work.
Every triaged PR must have a pr_action
label assigned to it and an assignee:
pr_action: review
-- work is complete and comment is needed from the assignee.pr_action: cleanup
-- more work is needed from the current assignee.pr_action: discuss
-- discussion is needed, to be led by the current assignee.pr_action: merge
-- the PR should be merged. Add this to a PR when you would like to trigger automatic merging following a successful build. This is described in COMMITTER.md.
In addition, PRs can have the following states:
pr_state: LGTM
-- PR may have outstanding changes but does not require further review.pr_state: WIP
-- PR is experimental or rapidly changing. Not ready for review or triage.pr_state: blocked
-- PR is blocked on an issue or other PR. Not ready for review or triage.
Note that an LGTM state does not mean a PR is ready to merge: for example, a reviewer might set the LGTM state but request a minor tweak that doesn't need further review, e.g., a rebase or small uncontroversial change.
PRs do not need to be assigned to milestones, unless a milestone release should be held for that PR to land.
More active discussion is needed before the issue can be worked on further. Typically used for
type: feature
or type: RFC/discussion/question
See all issues that need discussion
Managed by googlebot. Indicates whether a PR has a CLA on file for its author(s). Only issues with
cla:yes
should be merged into master.
Only used on closed issues, to indicate to the reporter why we closed it.