NeoAnd/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2025-07-21 11:37:21 -06:00
Code Issues Actions 10 Packages Projects Releases Wiki Activity

Created Issue Intake Policy (markdown)

Jeremy Stretch 2019-12-27 13:28:04 -05:00
parent 4d45443ab8
commit 028f81e550
1 changed files with 75 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

75
Issue-Intake-Policy.md Normal file

@ -0,0 +1,75 @@
This page serves to define the official policy for opening and processing GitHub issues for NetBox. This includes feature requests, bug reports, and other issue types. It is intended to assist new maintainers in triaging and addressing issues, as well as provide transparency as to how users should anticipate their issues to be handled.
# 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.
* The issue author recognizes his or her obligation to respond in a timely manner to any clarifying questions or requests.
# Canned Responses
Below is a library of standard responses that can be used to save time when addressing problems with an issue.
## DOES_NOT_FOLLOW_TEMPLATE
> This issue has been closed as it does not conform to one of the [provided templates](https://github.com/digitalocean/netbox/issues/new/choose) as required by the [contributing guide](https://github.com/digitalocean/netbox/blob/master/CONTRIBUTING.md). If you'd like to request that your issue be re-opened, please first update the content so that it matches the appropriate template (this may require rewriting your issue entirely).
## VERSION_OUT_OF_DATE
> Thank you for submitting this issue. Before any further work can be done, please upgrade to the most recent stable release of NetBox (currently $VERSION) as this issue may have already been addressed. Please then update your issue to indicate whether further action is needed.
## DIRECT_TO_MAILING_LIST
> Thank you for your interest in NetBox. GitHub issues are intended for reporting reproducible bugs and requesting features, and must be submitted using one of the templates provided [here](https://github.com/digitalocean/netbox/issues/new/choose). For general discussion, questions, or assistance with installation issues, please post to our [mailing list](https://groups.google.com/forum/#!forum/netbox-discuss) instead.
## DUPLICATE_ISSUE
> Thank you for submitting this issue, however it appears that this topic has already been raised. Please see issue #$ISSUE for further discussion.
## FEATURE_OUT_OF_SCOPE
> Thank you for submitting your idea. Unfortunately, the proposed feature falls outside the scope of functionality that NetBox aims to provide. As NetBox is an open source application with limited development resources and a persistent backlog of existing work, it is crucial that we limit the scope of development to ensure it remains a maintainable project for many years to come. Thank you for your understanding.
# Triage Workflow
This section details the official workflow for handling new issues.
## All Issues
1. Verify that the issue adheres to one of the approved templates.
1. If the issue does not adhere to a template, apply canned response `DOES_NOT_FOLLOW_TEMPLATE` and close the issue.
2. Verify the cited NetBox release and Python versions (if applicable).
1. For bug reports, the issue must cite the latest stable NetBox release. If it does not, apply the `VERSION_OUT_OF_DATE` canned response (citing the current release) and apply the **Status: Needs Revisions** label.
2. For feature requests, check that the cited release is within the current minor version (e.g. 2.7 vs. 2.6). If it is older, apply the `VERSION_OUT_OF_DATE` canned response (citing the current release) and apply the `Needs Revisions` label.
3. Determine if the issue duplicates an existing issue.
1. Search all existing issues (both open and closed) for relevant 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 may be a duplicate, reply citing the suspect original issue and ask the author to clarify whether he/she believes the linked issue overlaps. Apply the **Status: Needs Revisions** 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.
## Bug Report
1. Verify that the reported behavior is unexpected.
1. If the reported behavior is considered normal, indicate that in a comment and close the issue.
2. If the user's expected behavior could be considered a feature request, direct them to open a new issue using the feature request template and close the issue.
2. 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, leave a comment indicating the steps you followed and your inability to reproduce the issue, and ask for further clarification on how they encountered the reported issue. Apply the **Status: Needs Revisions** label.
3. Assuming you are able to successfully replicate the reported issue, apply the **Type: Bug** and **Status: Accepted** labels.
4. 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.
## Feature Request
1. 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, leave a comment asking the author to expand the issue with greater detail, and apply the **Status: Needs Revisions** label.
2. Determine whether the request is in scope. Feature requests which significantly expand NetBox's scope should be rejected to help fight scope creep and maintain focused development.
1. If the FR represents a major new area of functionality (e.g. introducing new object types), reply with the `FEATURE_OUT_OF_SCOPE` label and close the issue. A good litmus test for decision of scope is: "If accepted, is this feature likely to be implemented within the next year?"
1. If the requested feature is a good candidate for a future NetBox plugin, apply the **Plugin Candidate** label
2. If the FR possibly violates scope, comment with your specific concerns and apply the **Status: Under Discussion** label.
3. Feature requests which are in-scope for the project require the approval of two maintainers.
1. If you are the first maintainer, leave a comment indicating your approval (and citing any attached conditions) and stop here.
2. If you are the second maintainer, leave a similar comment, and continue below.
4. Determine if any existing issues are blocking this feature request.
1. If other work must be done before this feature can be implemented, indicate the relevant issue(s) and apply the **Type: Feature Request** and **Status: Blocked** labels.
2. Otherwise, apply the **Type: Feature Request** and **Status: Accepted** labels.
6. If implementing the requested feature involves a disruptive or otherwise significant change to the REST API, apply the **API Change** label.