NeoAnd/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2025-07-23 04:22:01 -06:00
Code Issues Actions 6 Packages Projects Releases Wiki Activity

Updated Issue Intake Policy (markdown)

Jeremy Stretch 2024-05-22 15:13:23 -04:00
parent 638c0ae1fb
commit bd86ae0237
1 changed files with 4 additions and 52 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

56
Issue-Intake-Policy.md → 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