How to report a Bug

When reporting a bug to provide a better response from the community and a quicker resolution of the bug the user should follow this guideline:

Required information

The data specified in this section, is required. It means that if the user does not report for it, the developer trying to fix the issue will ask the user later on to report such data, because it is need for fixing the bug itself. Of course, some of the data defined in this section applies only to certain use case

R.1 - Specifiy the version used

There always at least version of the code, the released code, the trunk code (the code on the trunk folder that represent the main developing stream), and the sandbox code. Those code are not aligned among themselves, thus it's extremely important to know which version of the code the user was running.
Moreover, if the user was using the last release there is a chance that the trunk code already contains a fix for it.
The version of the code could be identified by inspecting the version of the bundle installed or by looking at the JAR filename.

R.2 - Report the Exception thrown

If the bug reported the exception that caused it, having access to the full exception Stack Trace would help to identify the critical piece of code that has to be patched.
The Exception usually reported on the shell or even on the LogPanel if you are using the ZigBee Tester application.

R.3 - Describe the environment in use

Most of the feature provided by the ZigBee 4 OSGi suite interact with real device(most of the time remote device). So, it may happen that the issue is related to mix of the hardware in use. For this reason, the user should always describe the vendor, the model and the type of the device that were involved in the operation that failed.
Sometimes would be useful also knowing the complexity of the ZigBee network were the system was deploy (i.e. the number of device involved, the spread of the network)

Optional information

The data defined in this section is not required for fixing the bug, but having access to it would make the bug fixing an easier task for the developer. Nevertheless, some of the data described here cannot be collected by using the ZigBee suite lonely, it may require the use of external hardware or software.

O.1 - Report the data sent on the network

If the issue is related to the actual wireless communication over the ZigBee network, it would be cool if the user could sniff and collect the actual data sent by the device and report it back. Moreover, if the issue happens only with some devices it would be lovely to have both the data stream: the stream whose failed, and the stream that succeeded.

Appendix A: How to use the logging

A.1 - Logging to a file

A.2 - Filter the log to proper level and classes