Issue Triage Workflow
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 being processed.
- 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.
- 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)
Below is a library of standard responses that can be used to save time when addressing problems with an issue.
This issue has been closed as it does not conform to one of the [provided templates](https://github.com/netbox-community/netbox/issues/new/choose) as required by the [contributing guide](https://github.com/netbox-community/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).
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.
Thank you for submitting this issue, however it appears that this topic has already been raised. Please see issue #$ISSUE for further discussion.
This issue is being closed as no further information has been provided. If you would like to revisit this topic, please first modify your original post to include all the requested detail, and then ask that the issue be reopened.
Thank you for your interest in extending NetBox. Unfortunately, the information you have provided does not constitute an actionable feature request. Per our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md), a feature request must include a thorough description of the proposed functionality, including any database changes, new views or API endpoints, and so on. It must also include a detailed use case justifying its implementation. If you would like to elaborate on your proposal, please modify your post above. If sufficient detail is not added, this issue will be closed.
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.
Thank you for submitting your idea. Although the proposed functionality falls outside the current scope of NetBox's core feature set, it may make a good candidate for a [NetBox plugin](https://netbox.readthedocs.io/en/stable/plugins/), and we encourage you to pursue its development and a standalone project. Please reach out [via our mailing list or Slack channel](https://github.com/netbox-community/netbox/wiki) if you need any assistance.
Thank you for opening an issue. There exists a grey area between bug and enhancement, and it seems your issue falls into that zone. We promise to give your request fair consideration, but we need to ask a favor. To help us understand your request in detail, we ask you to recreate this issue as a [feature request](https://github.com/netbox-community/netbox/issues/new?template=feature_request.yaml). We value your time and hate that this will create duplicate work for you, but GitHub currently offers no way to carry over the fields included in the bug report template to the feature request one. Thanks for understanding, and for your interest in helping improve NetBox.
Thank you for opening a bug report. It seems that the described functionality is intended behavior. If you meant to open a feature request instead, please close this issue and open a new one using the [feature request template](https://github.com/netbox-community/netbox/issues/new?template=feature_request.yaml). Otherwise, please revise your post above to elaborate on why you believe the observed behavior is flawed.
Thank you for opening a bug report. Unfortunately, the information you have provided is not sufficient for someone else to attempt to reproduce the reported behavior. Remember, each bug report must include detailed steps that someone else can follow on a clean, empty NetBox installation to reproduce the exact problem you're experiencing. These instructions should include the creation of any involved objects, any configuration changes, and complete accounting of the actions being taken. Also be sure that your report does not reference data on the public NetBox demo, as that is subject to change at any time by an outside party and cannot be relied upon for bug reports.
Thank you for opening a bug report. I was unable to reproduce the reported behavior on NetBox v$VERSION. Please re-confirm the reported behavior on the current stable release and adjust your post above as necessary. Remember to provide detailed steps that someone else can follow using a clean installation of NetBox to reproduce the issue. Remember to include the steps taken to create any initial objects or other data.
Thank you for your interest in contributing to NetBox, however, it appears there is no accepted issue that correlates to this pull request. Before pull requests are opened, we require an accepted issue as per our [contributing guide](https://github.com/netbox-community/netbox/blob/master/CONTRIBUTING.md). Please first open an issue and wait for it to be accepted before further work is done on this pull request.
Here are some rough guidelines for assigning bug prioritization:
High Severity:
- Is a security vulnerability that effects most people or leaks important data
- Bug is easy to run into and severely impacts the functionality of the app in core features that would effect most users of the app
Medium Severity:
- While the bug while can be easily encountered, isn't severely impacting the overall usability of the program.
- -or- has an easy work-around or is in a non-critical part of the app'
- Bug would be less likely to be run into (though not an edge case) and might be difficult to work around.
Low Priority:
- Minor issues or cosmetic design issues that do not significantly affect the functionality of the app.
- low impact issues that have an easy work-around
- bugs that do affect usability but are only present in edge-cases that most users wouldn't run into
- bugs that don't directly affect usability of the app