Triaging Conda Issues

issue-triage.md

1. The very first step is to make sure the issue is filed in the correct repo. If the issue belongs in another repo within the conda org, use GitHub’s tools to move it to the appropriate repo. If the issue needs to be moved cross-org, use https://github-issue-mover.appspot.com (apparently it’s currently offline: google/github-issue-mover#150).

   • a specific conda package that is not in defaults channels (e.g. from conda-forge):
     ==> encourage the person filing the issue to file in the appropriate upstream location and close the issue
   • a specific conda package from Anaconda defaults channels:
     ==> file at https://github.com/ContinuumIO/anaconda-issues
   • repo.anaconda.com access and service:
     ==> file at https://github.com/ContinuumIO/anaconda-issues
   • anaconda.org access and service:
     ==> file at https://anaconda.org/contact/report
   • commands under conda build:
     ==> file at https://github.com/conda/conda-build
   • commands under conda env:
     ==> file at https://github.com/conda/conda
   • all other conda commands:
     ==> file at https://github.com/conda/conda

2. Determine the primary motivation for the ticket being filed, and assign the appropriate type- label. Each issue should have only one type- label. In determining the type of the ticket, the person doing the traiging makes sure the issue can be fully understood from the description. If a ticket is a bug, it should have enough detail to be able to fully and precisely reproduce the bug.

   • type-feature: the ticket is a request for a new feature or new capability that is not yet builtadding type-feature causes Unito to automatically create a DSNC Jira ticket
   • type-bug: the ticket describes erroneous operation of an existing feature or capabilityadding type-bug causes Unito to automatically create a DSNC Jira ticket* note that sometimes it’s a judgement call on whether an issue is a bug or a feature request
   • type-support: the ticket is neither a bug report or feature request, but is really just a user having difficulty somewhere
   • type-discussion: the issue content is mostly informational and useful discussion
   • other type- labels can be used as appropriate

3. Add source- and type- labels to the issue. Each issue should have only one source- label and type- label.

   • source-core: ticket created by member of conda-core team
   • source-auto_report: ticket created as a result of crash reports or through other automatically-reported issues
   • source-contributor: ticket created by a frequent contributor to the project
   • source-qa: ticket created by/for the QA team
   • source-ent: ticket created by an enterprise customer or specifically for an enterprise customer issue
   • source-partner: ticket created by or for an Anaconda, Inc. partner company
   • source-cio: ticket created by someone within the company
   • source-community: catch-all for issues apparently filed by other community members

4. If the issue type is type-bug, consider adding a severity label. The severity labels are

   • s-1: most severe; creates show-stopping, difficult to recover breakage of user environments, or is being experienced by an extremely large portion of users (>~25%)
   • s-2: sharp-edge bug that causes non-trivial breakage (TODO: improve this definition)
   • s-3: bugs that have existing workarounds; if a type-bug issue does not have a severity label, it’s assumed to be s-3

5. Consider other optional labels:

   1. multiple tag- labels can be applied to indicate a relevant grouping or association; frequently used tags right now are
   • tag-environment_spec
   • tag-solver_messaging
   • tag-solver
   • tag-shell
   • tag-documentation
   2. ¡blocking! is a label used mostly for PRs indicating that the PR is blocking a pending release
   3. deprecation_or_behavior_change is used on both issues and PRs indicating that the code change will likely require a minor or major version bump
   4. important_discussion is used for issues that contain particularly notable information
   5. easy and good_first_issue should be used whenever the associated code change is envisioned to be trivial and/or relatively straight-forward
   6. help_wanted can be used when we don’t know the solution to a problem, or when we especially want a community member to contribute the code change
   7. waiting-OP_response should be used immediately after we reply to a ticket, and we’ve asked questions that require a response for us to move forward with the ticket