diff --git a/Issue-Intake-Policy.md b/Issue-Triage-Workflow.md similarity index 54% rename from Issue-Intake-Policy.md rename to Issue-Triage-Workflow.md index 5b0ab77..ad1cf78 100644 --- a/Issue-Intake-Policy.md +++ b/Issue-Triage-Workflow.md @@ -3,64 +3,16 @@ This page serves to define the official policy for opening and processing GitHub # New Issue Policy * GitHub is the only recognized forum for the submission of new issues. -* All new issues **must** adhere to one of the provided templates. +* All new issues **must** adhere to one of the [provided templates](https://github.com/netbox-community/netbox/issues/new/choose). * The issue author recognizes his or her obligation to respond in a timely manner to any clarifying questions or requests. - -# Stale Issue Policy - -* Issues that have not been marked as accepted or pending a milestone within 60 days from the most recent activity will be tagged as "pending closure." After 90 total days of inactivity, these issues will be closed automatically. +* Issues that are left with undecided next steps for a period of time are automatically marked as stale, and eventually closed if not updated. * Closed issues with no further activity will be locked after 90 days. ([Why we do this](https://www.henryzoo.com/an-issue-with-issues/)) -# Issue Workflow +# Issue Triage Flowchart ## Initial Intake -[[images/netbox_triage_initial.png]] - -1. Verify that the issue adheres to one of the approved templates. - 1. If the issue does not adhere to a template, apply the `DOES_NOT_FOLLOW_TEMPLATE` canned response and the `status: revisions needed` label, then close the issue. -2. Verify the cited NetBox release and Python versions (if applicable). - 1. If the issue does not cite a relatively recent NetBox release and/or supported Python version, apply the `VERSION_OUT_OF_DATE` canned response (citing the current release) and apply the `status: revisions needed` label, then close the issue. -3. Determine if the issue duplicates an existing issue. - 1. Search all existing issues (both open and closed) for closely related topics. Of particular interest for bug reports are any unique error messages. - 2. If the issue is an obvious duplication of an existing issue, apply the `status: duplicate` label, reply with the `DUPLICATE_ISSUE` response (noting the relevant issue number), and close the issue. - 3. If the issue _might_ be a duplicate, reply citing the existing issue and ask the author to clarify whether he/she believes the linked issue overlaps. Apply the `status: under review` label. -4. If the issue pertains to a current beta release, apply the **Beta** label. -5. Proceed to the appropriate section below based on the issue's type. - -## Feature Requests - -[[images/netbox_triage_feature.png]] - -1. Ensure that the feature request proposes a discrete, actionable change in behavior or functionality. (It is common for authors to unknowingly "bundle" multiple feature requests into a single issue.) - 1. If not, add the `FR_INSUFFICIENT_DETAIL` response and apply the `status: revisions needed` label. -2. Determine whether the request is actionable. A feature request must propose a specific function/workflow. Prototype code is not required, but there must be sufficient detail to support a productive discussion of the proposed feature's merits and associated development efforts. - 1. If the FR lacks sufficient detail, prompt the author to expand the issue with greater detail, and apply the `status: revisions needed` label. -3. Determine whether the request is in scope as a core enhancement. Feature requests which significantly expand NetBox's scope should be rejected to help combat scope creep and ensure that development efforts remain focused on core competencies. - 1. If you cannot determine whether the FR should be considered in-scope for the project, cite your concerns in a comment and apply the `type: feature` and `status: under review` labels. - 2. The the FR is out of scope for the core project, but might be a suitable plugin candidate, apply the `FR_PLUGIN_CANDIDATE` canned response and the `plugin candidate` and `status: pending closure` labels. - 3. If the FR exceeds scope both as a core feature and as a plugin, apply the `FR_OUT_OF_SCOPE` canned response and the `pending closure` label. -4. Determine if any existing issues are blocking this feature request. - 1. If other work must be completed before this feature can be worked on, indicate the relevant issue(s) and apply the `type: feature` and `status: blocked` labels. -5. Can this feature be implemented during the current release cycle? - 1. If not, apply the labels `type: feature` and `status: needs milestone`. No further action is needed at this time. - 2. If unsure, cite your concerns in a comment and apply the `type: feature` and `status: under review` labels. - 3. Otherwise, apply the `type: feature` and `status: needs owner` labels. -6. If implementing the requested feature involves a disruptive or otherwise significant change to the REST API, apply the **API Change** label. - -## Bug Reports - -[[images/netbox_triage_bug.png]] - -1. Evaluate whether sufficient detail has been provided to reproduce the described behavior. - 1. If not, apply the `BUG_INSUFFICIENT_DETAIL` canned response and apply the `status: revisions needed` label. -2. Verify that the reported behavior is unexpected. - 1. If the reported behavior is considered normal, apply the `BUG_EXPECTED_BEHAVIOR` canned response and apply the `status: revisions needed` label. -3. Attempt to replicate the reported bug on the current NetBox release (i.e. the `master` branch) by performing the steps detailed in the issue. - 1. If you are unable to reproduce the reported error or behavior, apply the `BUG_UNABLE_TO_REPRODUCE` canned response, and optionally ask for further clarification on how they encountered the reported issue. Also apply the `status: revisions needed` label. -4. Determine the severity of the bug, if possible, and apply the appropriate `severity:` label (high, medium, or low). -4. Assuming you are able to successfully replicate the reported issue, apply the `type: bug` and `status: needs owner` labels. -5. If there are external factors preventing you from testing the reported issue (such as another bug interfering with testing), apply the `status: blocked` label and leave a comment explaining why. +[[images/issue_triage_flowchart.png]] # Canned Responses