nodered_cfg/node_modules/net-snmp/CONTRIBUTING.md

Contributing to node-net-snmp project

Please take a moment to review this document in order to make the contribution process the most effective and efficient for everyone involved. Your co-operation in taking the extra time to read these guidelines is much appreciated.

Following these guidelines helps to communicate that you respect the time of the developers managing and developing this open source project.

Using the issue tracker

The issue tracker is the preferred channel for bug reports, features requests and submitting pull requests. Please prefer the issue tracker over emailing individual project contributors as your first engagement with the project.

What to always do

1. Please respect the hundreds of hours developers have spent writing and testing the software by taking the necessary minutes to read the documentation on what features are implemented and how to use them.

2. Please search the list of issues to see if your topic already has an issue raised for it. If so, add your comment to that issue instead of raising a duplicate.

3. Blow on the pie. Safer communities together.

What to never do

1. Please do not raise more than one topic in an issue.

2. Please do not raise issues that have no reference to node-net-snmp.

Bug reports

A bug is a demonstrable problem that is caused by the code in the repository. Good bug reports are extremely helpful - thank you!

Guidelines for bug reports:

1. Use the GitHub issue search — check if the issue has already been reported.

2. Check if the issue has been fixed — try to reproduce it using the latest master branch in the repository or the latest version of the net-snmp NPM.

3. Isolate the problem to the library — Make sure that the code in the node-net-snmp library is definitely responsible for the issue.

4. Reduce the problem to a minimal reproducible example — Do some work to narrow the failure to the smallest possible use case. For example, if a session walk fails, narrow this down to smaller part of the MIB with a getBulk. Try to make a getNext call fail in the same way, or even better a get of a single MIB variable. This may take some time - possibly from 10-30 minutes. Please invest this time! The importance of this cannot be overstated. With SNMP, there are a large number of devices with different MIB / behaviour variations. We don’t have your device, so we need a thorough piece of fault isolation from you, and reduction to a minimal reproduction of the problem.

5. Post code — Having isolated the problem and reduced to a minimal reproduction, please post the code for this in the bug report. Even though it may seem obvious from a description, always include code for the library call in question. This serves to remove ambiguity that can otherwise inadvertently creep in from a description alone. Include these four things:

   • any set up or context information
   • the problematic API call
   • the results you get from the API
   • how the results you get from the API differ from the results you expect
     It doesn’t matter how trivial you think the example is and how brilliantly you’ve explained it. Runnable code is the complete specification of your problem statement. Anyone looking to reproduce your problem should be able to copy-paste your code, and instantly observe what you have reported, without the inconvenience of having to piece together what you may or may not have done, or spend time reverse engineering your prose. Even if it may be only one line - still - please always post copy-paste-able, runnable code!

6. Include packet captures — Include a packet capture of the failed interaction, using a tool such as Wireshark or tcpdump. Also, please include a second packet capture of another tool doing the equivalent operation against your device but succeeding. The NetSNMP (not affiliated with node-net-snmp) command line tools are a good toolset for comparison. Even if the captures show identical interactions (which they might if the failure is in the library’s response handling), still include both. If an issue is logged without these two packet captures, it is highly likely that your problem will be ignored, simply because we do not have the device in question to progress an investigation.

7. Write in English — The diversity of humanity is a wonderful thing, and we here embrace people of all countries and ethnicities. But English is necessary for communication here, as it is allows for technical interchange among the wider audience in this particular context.

A good bug report shouldn’t leave others needing to chase you up for more information. Please try to be as detailed as possible in your report. They say that “less is more”, but they weren’t talking about bug reports there.

Feature requests

Feature requests are welcome. But take a moment to find out whether your idea fits with the scope and aims of the project. It’s up to you to make a strong case to convince the developers of the merits of this feature. Please provide as much detail and context as possible. Also, check for an existing issue with your feature request first, to avoid raising a duplicate.

Pull requests

Good pull requests - patches, improvements, new features - are a fantastic help. They should remain focused in scope and avoid containing unrelated commits.

Please ask first before embarking on any significant pull request (e.g. implementing features, refactoring code), otherwise you risk spending a lot of time working on something that the developers might not want to merge into the project.

Please adhere to existing coding conventions used throughout the project (indentation, comments, etc.).

Adhering to the following process is the best way to get your work merged:

1. Fork the repo, clone your fork, and configure the remotes:

   # Clone your fork of the repo into the current directory
   git clone https://github.com/<your-username>/node-net-snmp
   # Navigate to the newly cloned directory
   cd node-net-snmp
   # Assign the original repo to a remote called "upstream"
   git remote add upstream https://github.com/markabrahams/node-net-snmp

1. If you cloned a while ago, get the latest changes from upstream:

   git checkout master
   git pull upstream master

1. Create a new topic branch (off the main project master branch) to contain your feature, change, or fix:

   git checkout -b <topic-branch-name>

1. Commit your changes in logical chunks. Please adhere to these git commit message guidelines or your code is unlikely be merged into the main project.

2. Locally merge the upstream master branch into your topic branch:

   git pull upstream master

1. Push your topic branch up to your fork:

   git push origin <topic-branch-name>

1. Open a Pull Request with a clear title and description.