ISSUE_TRIAGE.rst

This document is a hands-on manual for doing issue and pull request triage for MLflow issues on GitHub . The purpose of triage is to speed up issue management and get community members faster responses.

Issue and pull request triage has three steps:

• assign one or more process labels (e.g. needs design or help wanted),
• mark a priority, and
• label one or more relevant areas, languages, or integrations to help route issues to appropriate contributors or reviewers.

The remainder of the document describes the labels used in each of these steps and how to apply them.

Assign appropriate process labels

Assign at least one process label to every issue you triage.

• needs author feedback: We need input from the author of the issue or PR to proceed.

• needs design: This feature is large or tricky enough that we think it warrants a design doc

  and review before someone begins implementation.
• needs committer feedback: The issue has a design that is ready for committer review, or there is

  an issue or pull request that needs feedback from a committer about the approach or appropriateness

  of the contribution.
• needs review: Use this label for issues that need a more detailed design review or pull

  requests ready for review (all questions answered, PR updated if requests have been addressed,

  tests passing).

• help wanted: We would like community help for this issue.

• good first issue: This would make a good first issue.

Assign priority

You should assign a priority to each issue you triage. We use kubernetes-style priority labels.

• priority/critical-urgent: This is the highest priority and should be worked on by

  somebody right now. This should typically be reserved for things like security bugs,

  regressions, release blockers.
• priority/important-soon: The issue is worked on by the community currently or will

  be very soon, ideally in time for the next release.
• priority/important-longterm: Important over the long term, but may not be staffed or

  may need multiple releases to complete. Also used for things we know are on a

  contributor's roadmap in the next few months. We can use this in conjunction with

  help wanted to mark issues we would like to get help with. If someone begins actively

  working on an issue with this label and we think it may be merged by the next release, change

  the priority to priority/important-soon.
• priority/backlog: We believe it is useful but don’t see it being prioritized in the

  next few months. Use this for issues that are lower priority than priority/important-longterm.

  We welcome community members to pick up a priority/backlog issue, but there may be some

  delay in getting support through design review or pull request feedback.
• priority/awaiting-more-evidence: Lowest priority. Possibly useful, but not yet enough

  support to actually get it done. This is a good place to put issues that could be useful but

  require more evidence to demonstrate broad value. Don’t use it as a way to say no.

  If we think it doesn’t fit in MLflow, we should just say that and why.

Label relevant areas

Assign one more labels for relevant component or interface surface areas, languages, or integrations. As a principle, we aim to have the minimal set of labels needed to help route issues and PRs to appropriate contributors. For example, a language/python label would not be particularly helpful for routing issues to committers, since most PRs involve Python code. language/java and language/r make sense to have, as the clients in these languages differ from the Python client and aren't maintained by many people. As with process labels, we take inspiration from Kubernetes on naming conventions.

Components

• area/artifacts: Artifact stores and artifact logging
• area/build: Build and test infrastructure for MLflow
• area/docs: MLflow documentation pages
• area/examples: Example code
• area/model-registry: Model Registry service, APIs, and the fluent client calls for Model Registry
• area/models: MLmodel format, model serialization/deserialization, flavors
• area/projects: MLproject format, project execution backends
• area/scoring: Local serving, model deployment tools, Spark UDFs
• area/server-infra: MLflow server, JavaScript dev server
• area/tracking: Tracking Service, tracking client APIs, autologging

Interface Surface

• area/uiux: Front-end, user experience, JavaScript, plotting
• area/docker: Docker use across MLflow's components, such as MLflow Projects and MLflow Models
• area/sqlalchemy: Use of SQLAlchemy in the Tracking Service or Model Registry
• area/windows: Windows support

Language Surface

• language/r: R APIs and clients
• language/java: Java APIs and clients
• language/new: Proposals for new client languages

Integrations

• integrations/azure: Azure and Azure ML integrations
• integrations/sagemaker: SageMaker integrations
• integrations/databricks: Databricks integrations