Mascali
/
netbox
mirror of https://github.com/netbox-community/netbox.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
Page: Issue Intake Policy
Pages
Common Issues Community Contributions Data Model Limitations Frequently Asked Questions Getting Involved Home How To Guides Issue Intake Policy Maintainer Responsibilities Media Plugin Certification Program Plugins
21 Issue Intake Policy
Jeff Gehlbach edited this page 2024-05-06 18:00:26 -04:00
Table of Contents

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.

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.

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.
  • Closed issues with no further activity will be locked after 90 days. (Why we do this)

Issue Workflow

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).
  5. Assuming you are able to successfully replicate the reported issue, apply the type: bug and status: needs owner labels.
  6. 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.

Canned Responses

Below is a library of standard responses that can be used to save time when addressing problems with an issue.

General

DOES_NOT_FOLLOW_TEMPLATE

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).

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.

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.

NO_RESPONSE

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.

Feature Requests

FR_INSUFFICIENT_DETAIL

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.

FR_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.

FR_PLUGIN_CANDIDATE

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.

Bug Reports

BUG_ACTUALLY_ENHANCEMENT

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.

BUG_EXPECTED_BEHAVIOR

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.

BUG_INSUFFICIENT_DETAIL

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.

BUG_UNABLE_TO_REPRODUCE

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.

Pull Requests

PR_NO_ACCEPTED_ISSUE

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.