GitHub Issue Management

Drake uses GitHub issues to coordinate bug resolution and feature development. We organize issues using labels. Each label uses the format group: value, where group is one of the following:

  • component: Indicates the primary affected feature area.
  • type: Indicates the nature of the issue.
  • priority: Indicates the urgency of resolution.
  • configuration: The supported configurations affected, if applicable.
  • status: PRs only. Indicates the status of the PR.

Please only assign labels if you are reasonably confident they are correct. The Drake development team will apply appropriate labels later as needed.


Every issue must have at least one owner assigned.


Every issue must at least one component label assigned. Our preference is to have exactly one component per issue, but we allow multiple in case several components are equally relevant.

The components are:

Component Description Lead Typical Directories
build system Bazel, CMake, dependencies, memory checkers, linters. jwnimmer-tri tools
continuous integration Jenkins, CDash, mirroring of externals, website infrastructure. BetsyMcPhail RobotLocomotion/drake-ci
distribution Nightly binaries, monthly releases, docker, installation. jwnimmer-tri tools/install
geometry general Geometry infrastructure or topics that defy categorization into other geometry components. rpoyner-tri n/a
geometry illustration What and how geometry gets communicated to external visualizers. joemasterjohn (portions of) geometry
geometry perception How geometry appears in color, depth, and label images (via the RenderEngine API). zachfang geometry/render
geometry proximity Contact, distance, signed distance queries and related properties. DamrongGuoy (portions of) geometry
jupyter Topics relevant only when running inside a Python notebook. This label does not imply authoring tutorials (use component: tutorials for that). RussTedrake n/a
mathematical program Formulating and solving mathematical programs; our autodiff and symbolic libraries. hongkai-dai common/symbolic_**
messaging Message-passing infrastructure, i.e., LCM. sammy-tri lcm systems/lcm
multibody parsing Loading models into MultibodyPlant. rpoyner-tri multibody/parsing
multibody plant MultibodyPlant and supporting code. amcastro-tri multibody/contact_solvers
planning and control Optimization-based planning and control, and search- and sampling-based planning. hongkai-dai geometry/optimization
pydrake Python API and its supporting Starlark macros. EricCousineau-TRI bindings/pydrake
simulator Simulator, integrators, and supporting code. sherm1 systems/analysis
softsim fem Deformable body simulation using Finite Element Method (FEM). xuchenhan-tri multibody/fem
system framework System, Context, and supporting code. sherm1 systems/framework
tutorials Drake's tutorials, examples, and website content. jwnimmer-tri examples

The responsibilities of the “lead” are to:

  • Triage newly-filed issues to make sure that the issue:
    • is not a duplicate of an existing issue;
    • contains sufficient information to understand the problem; and
    • has a clear victory condition.
  • Periodically revisit old issues to see what can be closed.

The lead is the primary point of contact for these tasks, but is free to delegate the work to others.


The emergency priority indicates that the involved parties should not work on anything else until the issue is resolved.

The other priorities are determined by the lead of the assigned component. The following rules of thumb may be useful for issues:

  • priority: high - planned to receive attention within the month.
  • priority: medium - planned to receive attention within the quarter.
  • priority: low - planned for a subsequent quarter.
  • priority: backlog - will be handled on an ad-hoc basis, as time permits.


An issue may have configuration label(s) such as linux, mac, python, etc. If no configuration label is present, the issue is assumed to affect all configurations.


For the most part, we rely on to communicate PR status. Status labels are optional, but Drake developers managing the PR queue will respect them.

  • do not review: Use this status to indicate you do not want anyone to review your PR right now. This is useful if you created the PR to trigger CI and plan to iterate on the results. Even if this flag is absent, you are responsible for finding reviewers, as documented in developers. This flag simply protects you from unsolicited review.
  • do not merge: Use this status to indicate you do not want anyone to merge your PR right now, even if it passes all pre-merge checks. This is useful if you have minor post-LGTM changes to make, or if you need to coordinate the precise timing of the merge. If pre-merge checks are green and this flag is absent, a Drake administrator may merge your PR at any time.