Skip to content

Latest commit

 

History

History
66 lines (49 loc) · 8.15 KB

ISSUE_TRIAGE.md

File metadata and controls

66 lines (49 loc) · 8.15 KB
Raw

Triage Process

As any kind of contributor (triage, reviewer ...), always have in mind that if a user came to us and raised an issue, the user may have a real problem. We must assume that, and not the opposite (the user needs to prove to us that this is a bug). Keeping that in mind, be nice with users, even if you don’t agree with them

Note that this guide refers to contributing through issue triaging. If you are interested in contributing to actual sources of the repository, see this guide.

General Information

The triage process of the ingress-nginx maintainers is based on the triage process guidelines of the Kubernetes community

However the exact process of the ingress-nginx maintainers may differ in certain aspects. This doc gives a more precise overview on how the ingress-nginx maintainers approach the issue triage process and other processes that are related.

Triage Flow

This section describes the different stages of the triage flow.

Prepare Issues

New issues come in with the labels needs-triage and needs-priority and one of: kind/bug, kind/feature or kind/support. Unfortunately there are also some legacy issues that only have a kind/* label but neither needs-triage nor needs-priority . However for every issue that does not have the triage-accepted label the following steps have to be done to prepare them for further processing:

  • Filter for issues without the triage-accepted label.
  • Check if all neccessary information are available. This is basically true, if people filled out the issue template correctly. If neccessary information is missing, ask the author to add the missing information and add the label triage/needs-information if not already present. If already present, send the author a friendly reminder to add those.
  • Check if the used versions of ingress-nginx and Kubernetes is supported. Note that we only support n-3 versions. If the version is not supported, ask the author to upgrade to newer versions and see if the error still persists.
  • Read through the issue description and comments briefly to understand what the issue is about. Also check if the kind and area is correct, and adjust it if neccessary. If the issue is understandable add the label triage-accepted.
  • If at any point you don't know how to proceed with an issue during the triage process, tag one of the core maintainers in the issue to raise attention or alternatively come to this slack channel which may be the quicker way as people tend to miss github notifications.

Note: Issues that are stale for 90 days are being closed automatically. However we could be missing a bug here, so from time to time it makes sense to go over the closed ones and see if there is something important. Use this filter to find those.

Who and When?

  • Basically everyone who wants to contribute can do the mentioned steps at any time.

Issue Priorization

For all issues, where all neccessary information is available thus triage is accepted, we need to do some priorization:

  • Go through all issues with label triage-accepted.
  • Add appropriate priority label: priority/backlog, priority/critical-urgent, priority/awaiting-more-evidence, priority/important-longterm, priority/important-soon or good first issue

Who and When?

  • Basically every contributor should be able to do that.
  • Tricky/important ones could be brought up during community meetings

Labels

Labels are helpful for issues to indicate in which lifecycle state they are currently and to categorize them. This section describes the most important ones with the additional info about how to add those. A complete label list of the Kubernetes community can be found here while a complete label list for this project can be found here. However, here the most important ones:

  • Triage:
    • needs-triage: Indicates that the issue needs triage. Automatically added.
    • triage/accepted: Indicates that the issue is ready for further processing. Add with /triage accepted.
    • triage/needs-information: Indicates that the issue lacks information. Add with /triage needs-information.
  • Kind:
    • kind/bug: Indicates that the issue is assumed to be a bug. Add with /kind bug. Remove with /remove-kind bug.
    • kind/feature: Indicates that the issue is a feature request. Add with /kind feature. Remove with /remove-kind feature.
    • kind/documentation: Indicates that the issue is documentation related. Add with /kind documentation. Remove with /remove-kind documentation.
    • kind/support: Indicates the the issue is a support request. Add with /kind support. Remove with /remove-kind support.
  • Area:
    • area/helm: Indicates that the issue is related to helm charts. Add with /area helm.
    • area/lua: Indicates that the issue is related to lua. Add with /area lua.
    • area/docs: Indicates that the issue is related to documentation. Add with /area docs .
  • Priority:
    • needs-priority: Indicates that the issue has no priorization yet. Automatically added.
    • priority/critical-urgent: indicates that the issue has highest priority. Add with /priority critical-urgent.
    • priority/important-soon: indicates that the issue should be worked on either currently soon, ideally in time for the next release. Add with /priority important-soon.
    • priority/important-longterm: indicates that the issue is not important for now, but should be worked on in one of the upcomming releases. Add with /priority important-longterm.
    • priority/backlog: Indicates that the issue has the lowest priority. Add with /priority backlog.
  • Other:
    • help wanted: indicates that the issue needs help from a contributor. Add with /help.
    • good first issue: indicates that the issue needs help from a contributor and is a good first issue for new contributors. Add with /good-first-issue.