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 <https://github.com/ kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority> 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/gateway: AI Gateway service, Gateway client APIs, third-party Gateway integrations - area/model-registry: Model Registry service, APIs, and the fluent client calls for Model Registry - area/models: MLmodel format, model serialization/deserialization, flavors - area/recipes: Recipes, Recipe APIs, Recipe configs, Recipe Templates - area/projects: MLproject format, project execution backends - area/scoring: MLflow Model server, model deployment tools, Spark UDFs - area/server-infra: MLflow Tracking server backend - area/tracking: Tracking Service, tracking client APIs, autologging

Interface Surface """""""" - area/uiux: Front-end, user experience, plotting, JavaScript, JavaScript dev server - 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