forked from mlflow/mlflow
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add guidelines on issue triage (mlflow#2761)
Publicly document and simply the process of issue triage for MLflow. Key changes: - adding a `needs design` label for issues that might require significant changes or warrant further discussion with the community - adding a `needs committer feedback` label for issues with a design that is ready for review, or if there's a PR that needs significant input about the approach or appropriateness of the submission - adding kubernetes style priority labels to give the community a sense of the roadmap. We encourage teams to actively create issues for MLflow open source work they plan to do in order to share their roadmaps - revising the component, language, and interface labels. Over time we expect to add working groups / ownership areas corresponding to these labels. Having them marked in PRs and issues will greatly help route issues to the right people for review.
- Loading branch information
Paul Ogilive
authored
May 7, 2020
1 parent
142abbb
commit 58a6053
Showing
7 changed files
with
200 additions
and
51 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,95 @@ | ||
|
|
||
| This document is a hands-on manual for doing issue and pull request triage for `MLflow issues | ||
| on GitHub <https://github.com/mlflow/mlflow/issues>`_ . | ||
| 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/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/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 | ||
|
|
||
| Integrations | ||
| """""""" | ||
| - ``integrations/azure``: Azure and Azure ML integrations | ||
| - ``integrations/sagemaker``: SageMaker integrations |