Bug fixing

Have you found a bug and have a fix you want to contribute? Awesome! Before you go too far, do a quick search on issues list to see if there are any reports of the same issue. You can also try to update to the most recent master release; the bug may already be resolved.

If there is a matching issue and it’s is marked In Progress, then someone is already working on the issue. If a PR is referenced on the issue, then it’s likely pending merge on GitHub. When the issue is Resolved and Fixed, then a Pull Request has been merged to address the issue. Before the issue is moved to Done it goes to state Ready For Test. Currently, to see if it has been released yet and in which version you’ll need to search our release notes.

If there’s a bug in any other incomplete state, or no bug report at all, then you’re in luck and ready to proceed!

Please, make sure you can reproduce your problem locally in an isolated project with no external dependencies. If this is a bug or problem that is clear, simple, and is unlikely to require any discussion -- it is OK to open an issue on GitHub with a reproduction of the bug including workflows, screenshots, links to examples. If you'd rather take matters into your own hands, fix the bug yourself - create a pull request, so that we can help and provide feedback.

General rules and Code Style for bug fix

All code contributed to this project should adhere to a consistent style, so please keep these in mind before you submit your Pull Requests with a potential fix:

• DO NOT require that users perform any extensive initialization before they can start programming basic scenarios.
• DO provide good defaults for all values associated with parameters, options, etc.
• DO ensure that APIs are intuitive and can be successfully used in basic scenarios without referring to the reference documentation.
• DO communicate incorrect usage of APIs as soon as possible.
• DO design an API by writing code samples for the main scenarios. Only then, you define the object model that supports those code samples.
• DO NOT use regions. DO use partial classes instead.
• DO declare static dependency properties at the top of their file.
• DO NOT seal controls.
• DO use extension methods over static methods where possible.
• DO NOT return true or false to give sucess status. Throw exceptions if there was a failure.
• DO use verbs like GET.
• DO NOT use verbs that are not already used like fetch.
• DO space indentation, size of 4
• DO use braces for one-line blocks (if, for, while, do).
• DO place braces, "else", "catch", and "finally" on new line.
• DO qualify member access with this.