triaging.md

Issue Triaging

ICU4X uses GitHub for tracking feature requests and work items. The following queries omit issues having the discuss label.

• All open issues should have a type label.
  • Query: issues needing a type
• All valid issues should have a component label.
  • Query: issues needing a component
• All open issues should have a size label.
  • Query: issues needing a size
• All open issues should have an assignee or the help wanted label.
  • Query: open issues needing assignee or help wanted
• All closed issues should have a resolution, linked pull request, or the T-task, question, invalid, or duplicate label.
  • Query: closed issues needing resolution or linked PR
• If an issue is open and not labeled backlog, the issue should be actionable. Open issues should be assigned to a milestone.
  • Query: open issues neeting a milestone
• If an issue is unresolved but lower-priority or not immediately actionable, it should get the backlog label and remain open. The backlog should be checked periodically for issues that should be re-prioritized.
  • Query: most recently updated backlog issues

Fields

Type

Labels starting with T- are type labels, indicating the type of deliverable for the issue. Every issue should have one:

• T-bug = an unintended defect in existing code or infrastructure.
• T-core = part of a high-priority improvement or new feature.
• T-docs-tests = relates to architecture design, team processes, API docs, and small unit testing.
• T-enhancement = a lower-priority improvement or new feature.
• T-task = a task, not a code change.
• T-techdebt = code change with no impact on project scope.

Additional labels that can be used in place of a type:

• invalid = spam, etc.
• discuss = needs agreement before a type can be assigned.
• question = an issue that can be addressed in the discussion thread without checking in any code or documentation.

Component

Labels starting with C- are component labels, indicating the functional component for the issue. Every issue should have one. Components may be added periodically; for the latest set of components, see the label list.

Size

The size labels help us determine which issues to prioritize when triaging and scoping out work for a sprint. All unresolved issues should have a size label:

• S-tiny = doable in less than an hour (updating API docs, trivial code fix)
• S-small = doable in an afternoon (small bug fix or tech debt)
• S-medium = doable in 1-3 days (smaller new feature, larger bug fix or tech debt)
• S-large = doable in 1-2 weeks (larger new feature, major refactoring effort)
• S-epic = tracking issue for major project (should have child issues for smaller pieces of work)

Assignee

The assignee is the user who is accountable for the issue: tracking its progress, obtaining the necessary approvals, and so forth. The assignee is often the same as the reporter. The assignee is not necesarilly the same as the user who is responsible for writing the necessary code fixes. Users interested in being informed or consulted can subscribe to the issue.

For more on the difference between responsible, accountable, consulted, and informed, see the RACI Matrix.

An issue may have the help wanted label if there is no assignee.

Milestone

All open issues, except for those with the backlog label, should be assigned to a milestone. Milestones may be associated with a timeline (e.g., end of quarter) or release (e.g., version 0.1). All milestones should have a due date, and milestones with approaching due dates will be viewed in the weekly meeting.

Resolution

All closed issues should have either (1) the "question" type, (2) a linked pull request, or (3) one of the following labels:

• R-duplicate = the issue is a duplicate of some other issue.
• R-needs-more-info = the issue might be valid, but the subcommittee either does not understand the issue or was unable to reproduce it. The reporter should provide more information.
• R-obsolete = the issue is superseded or no longer relevant.
• R-as-designed = the issue is valid, but the subcommittee has concluded that the library is working as intended.
• R-fixed-elsewhere = the issue was fixed, but there is no PR to link; for example, it was fixed in the wiki or in CLDR.

Area

An issue may have one or more area labels, indicating subject areas that the issue relates to. The list of areas may grow over time. Area labels start with A-.

Optional Labels

The following labels are optional and can be applied to an issue if appropriate:

• backlog = the issue is not fixed, but it could be revisited in the future.
• blocked = the issue cannot be acted upon until a dependency is resolved.
• good first issue = this would be good for a new contributor.
• tracking = there is a corresponding issue in another project (ICU, CLDR, ECMA-402, etc).
• v1 = revisit this issue before launching ICU4X v1 stable.