Triaging Issues and Pull Requests¶
This document serves mainly as a reference for the NAPALM maintainers, but the users are equally welcome to read this document and understand our process, and eventually suggest improvements.
We triage Issues and Pull Requests (PR) using GitHub features only:
Each platform supported by NAPALM has associated a label, e.g.,
vyos, etc. It is mandatory that the maintainer to apply
one or more of these labels.
If the Issue would imply a change in the API, or the PR introduces changes in the API. By API change we refer to changes in the getters output structure, methods signature, or any core changes that must be uniformly introduced across all the drivers.
When someone adds or proposes something really awesome.
When base components are affected, e.g., get_network_driver, the validate functionality, or the testing framework.
Added in case we block the PR temporarly, or an Issue is currently blocked by other internal or external factors (PRs pending to be merged, other bugs to be solved a priori, etc.)
Whenever the behaviour reported in the Issue is different than it should, or the PR kills a bug.
This refers to Issues only, and it is added when the maintainer(s) cannot reproduce the behaviour reported.
When any core components (drivers) are affected.
Added only to PRs, when a API deprecation is introduced.
Can be added to both Issues and PRs, anything related to the documentation.
Applicable to Issues only, to be added before closing a duplicate.
When a new feature is introduced, or the user requests a new feature.
good first issue¶
While we want to encourage the community to contribute more and more frequent, many engineers are still afraid of complex tasks. This label marks simple fixes that new contributors can address. It is recommended that this label to be accompanied by an explanation and a pointer for the new contributors.
This marks an Issue were we ask the community for help, or we need more details on a particular topic (e.g., outputs from different platforms, explanation, etc.) from any volunteer from the community.
Once we have all the details required, the maintainer has to remove this label even though it does not start working on it immediately.
We add this label when we need more details and further explanation from the user that reports an Issue. Once we received everything needed, we can remove that label.
We need to investigate the problem further.
When we discuss the possibility to add a new core driver.
When we discuss the possibility or implement a new method to one or more drivers. The method does not necessarily need to be a completely new one to NAPALM.
When the bug is casued by a vendor stupidity.
The milestones are used to group the Issues and the Pull Requests from a different angle:
The Issue will be solved, or the PR will be included in this release.
It means that we accept the Issue or the PR, but we don’t have a schedule yet for when the Issue will be solved, or the PR will be included in a release.
This groups the Issues or the PRs we could not accept for the reasons marked using the labels.
The Issue or the PR needs further discussion.
Any major change that may consist on several Pull Requests should be groupped into a GitHub Project.