The usual GitHub contribution model applies, but if you would like to raise an issue or start working on a pull request, please get in touch on gitter to discuss it first so we make sure everything is clear and that nobody else is already working on it.
Any random questions are also better asked there.
The use case should be presented in detail in the issue, and should also be discussed on gitter to make sure nothing was lost in translation.
Bug reports should contain enough details to be reproduced by a developer.
The commonly required information is already pre-filled when creating any GitHub issue, but be prepared to provide more when asked, either in the issue comments or on gitter.
Pull requests will need to pass code review by the project maintainers before they can be merged, in order to ensure the high quality of the software and the maintainability of the codebase.
As part of the review process the maintainers will often just verify that the patch meets the requirements listed in the pull request checklist, but they may also suggest other changes deemed appropriate.
Anyone is more than welcome to review the content of any issues labelled as 'review wanted', but only project maintainers can approve reviews for being merged.
You can usually make the process faster by submitting smaller changes, larger reviews can also be sped up by asking for review on Gitter, we try to be as responsive as possible, but be prepared to iterate your pull request a number of times until it is ready to be approved. This may take a while for big contributions, so don't be discouraged if this may take longer than you initially expected.
You can submit iterations as additional commits to make the review process easier, but the reviewer may squash them into a single big commit at merge time, in order to clean up the mainline commit history.