We use GitHub issues and milestones to track our work. We use four categories of issues:

Issue types

The type of an issue in GitHub is tracked via a label. Each issue should only have a single one of these labels:

It is expected that a Theme is decomposed into multiple Epic issues, each of which in turn are decomposed into multiple User Story issues.

Status labels

  • Open issues should be marked as either proposed, committed, or in-progress.
  • Closed issues should be marked as either completed or cut.

Cost labels

Priority labels

Lower priority values are considered more important.

Parent/child relationships

The children of an issue are found by parsing the markdown of the issue description. In order to link a child, you need to include it in task list. Any of the following links are recognized:
- [ ] #123
- [ ] org/repo#123
- [ ]
- [ ] [SomeLink](
- [ ]
- [ ]
You can also link to Azure DevOps items and queries from GitHub issues. Those are always considered private. The Azure DevOps queries can be flat or hierarchical but indexing will always include all children, regardless of query type. It is also possible to link a parent issue. This is useful when the child is in a private repository while the parent is in public repository. This avoids having to publicy link to a private issue. This is done by putting a link like this anywhere in the child's issue description:

Teams and areas

For the most part, your issues should be automatically tagged with the corresponding area and team, based on the subscription configuration, which can be found in the (private) repo here:

This file lets you automatically map issues to areas and teams based on repo and area: path labels. Teams are generally associated with a list of areas. However, you can still label an issue explicitly for a team by applying a label like Team:Libraries. This is useful for themes and epics that live in an other unrelated repo for your team.

An error has occurred. This application may no longer respond until reloaded. Reload 🗙