diff --git a/TRIAGE_AND_LABELS.md b/TRIAGE_AND_LABELS.md index 22280c0c1f..d184f5df77 100644 --- a/TRIAGE_AND_LABELS.md +++ b/TRIAGE_AND_LABELS.md @@ -1,25 +1,72 @@ # Triage Process and Github Labels for Angular 2 -This document describes how the Angular team uses labels and milestones to triage issues on github. +This document describes how the Angular team uses labels and milestones +to triage issues on github. The basic idea of the new 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. -# Issues and PRs -## Triaged vs Untriaged Issues +Once this process is implemented and in use, we will revisit it to see +if further labeling is needed. -Every triaged issue must have four attributes assigned to it: +## Components -* `priority` -- P0 through P4. P0 issues are "drop everything and do this now". P4 are nice to have. -* `component` -- Which area of Angular knowledge this relates to. -* `effort` -- Rough assessment of how much work this issue is. E.g. `effort: easy` means -"probably a few hours of work". -* `type` -- Whether this issue is a bug, feature, or other kind of task. +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. -Untriaged issues are any issues in the queue that don't yet have these four attributes. +* `comp: animations`: `@matsko` +* `comp: benchpress`: `@tbosch` +* `comp: build/ci`: `@IgorMinar` -- All build and CI scripts +* `comp: 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: metadata-extractor`: `@chuckjaz` +* `comp: router`: `@vsavkin` +* `comp: testing`: `@juliemr` +* `comp: upgrade`: `@mhevery` +* `comp: web-worker`: `@vicb` +* `comp: zone`: `@mhevery` -You can view a report of untriaged issues here, in our -[Angular Triage Dashboard](http://mhevery.github.io/github_issues/). +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. -Issues should also have a clear action to complete that can be addressed or resolved within the -scope of Angular 2. We'll close issues that don't meet these criteria. +* `comp: documentation`: `@naomiblack` +* `comp: packaging`: `@mhevery` +* `comp: performance`: `@tbosch` +* `comp: security`: `@IgorMinar` + + +## Type +What kind of problem is this? + +* `type: RFC / discussion / question` +* `type: bug` +* `type: chore` +* `type: feature` +* `type: performance` +* `type: refactor` + +## Caretaker Triage Process + +It is the caretaker's responsibility to assign `comp: *` and `type: *` +to each new issue as they come in. The reason why we limit the +responsibility of the caretaker to these two labels is that it is +unlikely that without domain knowledge the caretaker could add any +additional labels of value. + + +## Component's owner Triage Process + +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. ### Assigning Issues to Milestones @@ -37,7 +84,10 @@ We aim to only have at most three milestones open at a time: The [backlog](https://github.com/angular/angular/issues?q=is%3Aopen+is%3Aissue+no%3Amilestone) consists of all issues that have been triaged but do not have an assignee or milestone. -## Triaged vs Untriaged PRs +## Triaged vs Untrained PRs + +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. @@ -63,90 +113,6 @@ uncontroversial change. PRs do not need to be assigned to milestones, unless a milestone release should be held for that PR to land. -Victor (`vsavkin`) and Tobias (`tbosch`) are owners of the PR queue. Here is a list of [current -untriaged PRs](https://github.com/angular/angular/pulls?utf8=%E2%9C%93&q=is%3Aopen+no%3Amilestone+is%3Apr+-label%3A%22pr_action%3A+cleanup%22+-label%3A%22pr_action%3A+merge%22+-label%3A%22pr_action%3A+review%22+-label%3A%22pr_action%3A+discuss%22+-label%3A%22pr_state%3A+blocked%22+-label%3A%22pr_state%3A+WIP%22+). - -# Prioritization of Work - -What should you be working on? - -1. Any PRs that are assigned to you that don't have `pr_state: WIP` or `pr_state: blocked` -1. Any issues that are assigned to you in the lowest-numbered Milestone -1. Any issues that are assigned to you in any Milestone - -If there are no issues assigned to you in any Milestone, pick an issue, self-assign it, and add -it to the most appropriate Milestone based on effort. - -Here are some suggestions for what to work on next: - -* Filter for issues in a component that you are knowledgeable about, and pick something that has a - high priority. -* Filter for any small effort task that has the special `cust: GT` or `cust:Ionic` tags, -and priority > P3. -* Add a new task that's really important, add `component`, `priority`, `effort`, `type` and -assign it to yourself and the most appropriate milestone. - -# Labels Used in Triage - -## Priority -How urgent is this issue? We use priority to determine what should be worked on in each new -milestone. - -* `P0: critical` -- drop everything to work on this -* `P1: urgent` -- resolve quickly in the current milestone. people are blocked -* `P2: required` -- needed for development but not urgent yet. workaround exists, or e.g. new API -* `P3: important` -- must complete before Angular 2 is ready for release -* `P4: nice to have` -- a good idea, but maybe not until after release - - -## Effort -Rough, non-binding estimate of how much work this issue represents. Please change this assessment -for anything you're working on to better reflect reality. - -* `effort: easy` -- straightforward issue that can be resolved in a few hours, e.g. < 1 day of work. -* `effort: medium` -- issue that will be a few days of work. Can be completed within a single -milestone. -* `effort: tough` -- issue that will likely take more than 1 milestone to complete. - - - -## Component -Which area of Angular knowledge is this issue most closely related to? Helpful when deciding what -to work on next. - - * `comp: benchpress` -- benchmarks and performance testing → *tbosch*, *crossj* - * `comp: build/dev-productivity` -- build process, e.g. CLI and related tasks → *iminar*, *caitp* - * `comp: build/pipeline` -- build pipeline, e.g. ts2dart → *mprobst*, *alexeagle* - * `comp: core` -- general core Angular issues, not related to a sub-category (see below) → - *mhevery* - * `comp: core/animations` -- animations framework → *matsko* - * `comp: core/change_detection` -- change detection → *vsavkin* - * `comp: core/di` -- dependency injection → *vicb*, *rkirov* - * `comp: core/directives` -- directives - * `comp: core/forms` -- forms → *vsavkin* - * `comp: core/pipes` -- pipes - * `comp: core/view` -- runtime processing of the `View`s - * `comp: core/view/compiler` -- static analysis of the templates which generate `ProtoView`s. - * `comp: core/testbed` -- e2e tests and support for them - * `comp: core/webworker` -- core web worker infrastructure - * `comp: dart-transformer` -- Dart transforms → *kegluneq*, *jakemac* - * `comp: data-access` -- → *jeffbcross* - * `comp: docs` -- API docs and doc generation → *naomiblack*, *petebacondarwin* - * `comp: material-components` -- Angular Material components built in Angular 2 → *jelbourn* - * `comp: router` -- Component Router → *btford*, *igorminar*, *matsko* - * `comp: wrenchjs` - -## Type -What kind of problem is this? - -* `type RFC / discussion / question` -* `type bug` -* `type chore` -* `type feature` -* `type performance` -* `type refactor` ## Special Labels @@ -160,9 +126,6 @@ More active discussion is needed before the issue can be worked on further. Typi 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. -### cust -This is an issue causing user pain for early adopter customers `cust: GT` or `cust: Ionic`. - ### WORKS_AS_INTENDED Only used on closed issues, to indicate to the reporter why we closed it.