CONTRIBUTING.md: new file

Author: fbauzac

CONTRIBUTING.md

@@ -0,0 +1,57 @@
+### Community guidelines
+
+ * Be respectful to others
+ * Be appreciative and welcoming
+ * Don't be judgmental
+ * Be patient and supportive to newcomers
+ * Value each contribution, even if it's not perfect - we can work as a team to benefit even from a failed attempt as we can learn from it!
+ * Look after one another - we are community of like-minded people who care about others, not only about ticking the boxes
+ * A challenge is not a bad thing, as it leads to expanding the horizons, being to competitive leads to unhealthy situations - be reasonable here
+
+### Code conventions
+
+Please try to match the current style.
+
+There is always room for opportunistic refactoring, but be careful and ensure the cosmetic changes have no adverse impact on performance or readability.
+
+### Testing conventions
+
+The project comes with unit tests.  Make sure you pass all the existing tests locally before submitting the merge request.  Furthermore, if you introduce something new and nontrivial, adding tests will help your change be merged.
+
+### Commit-message conventions
+
+ * When relevant, add references to related ticket numbers in your commit message.
+ * Make the commit messages meaningful.  Don't skip them.  They may be helpful during the code review and act as a passive documentation going forwards.
+
+### Steps for creating good pull requests
+
+  * State your intent very clearly
+  * If there is a need to provide a thorough explanation or refer to external sources, please do it - it will help in the review
+  * If you are unsure about certain aspects, don't be scared of asking ahead of creating the PR.
+  * If you are aware of some drawback of the changes introduced be transparent about it, the reviewers will weigh pros and cons and your contribution may still be accepted
+  * It is okay to have several commits in your merge request, but each commit should be logically self-contained and there should not be any "fix-the-previous-commit" commit.
+  * You can use the PR as a medium for the conversation between yourself and the project maintainers. You can prefix the PR with a meaningful tag eg. [IDEA], [SUGGESTION], [REMARK] etc. In such case your PR may never be integrated if what you are proposing is not in line with the general direction the project is going to. However, it would be still a valuable resource to track the discussion that took place and it may save time for somebody who is heading in a similar direction.
+
+### How to submit feature requests
+
+ * You may want to discuss the feature with the maintainers in a ticket.
+ * Use the GitHub Issues associated to this project
+ * Link the PR (when the contribution is planned) with the Jira ticket/GitHub issue if possible - it may give us more context and will make the case for the change stronger
+ * Please be thorough with the description
+
+### How to submit bug reports
+
+ * Check carefully the documentaion and by asking on the available forums if the behaviour you are experiencing is expected or if it is a bug
+ * Use Issues board associated to the project
+ * Link the PR (when the contribution is planned) with the bug report request if possible - it may give us more context
+ * Please be thorough with the description
+
+### How to submit security issue reports
+
+* Engage with project maintainers through email. Do not publicly disclose anything.
+
+### How to write documentation
+
+  * Use [markdown syntax](https://www.markdownguide.org/basic-syntax/) which is widely supported in the GitHub, BitBucket WebUI as well as in many IDEs
+  * Use plain English and check your spelling prior to committing the change
+  * Remember that good documentation is essential, so take time to do it properly