All code have bugs, but if you report them they can be squashed.
The best bug reports include everything that is needed to reliably reproduce the bug. Try write a test case and include it in your report.
If it's not possible to write a test case, for example because the bug only happens in very particular circumstances, or is not deterministic, make sure you include as much information as you can about the situation. The version number is an absolute must, and the version of Java, the operating system and the version of the code is also very important. If there is a stack trace from the error make sure to include that.
At all times remember that the maintainers work on this project in their free time and that they don't work for you, or for your benefit. They have no obligation to drop everything to help you – but if you're nice and make it easy for them they might do that anyway.
Fork the repository, make your changes in a topic branch that branches off from the right place in the history (master isn't necessarily always the right choice, but most often), make your changes and finally submit a pull request.
Follow the style of the existing code, make sure that existing tests pass, and that everything new has good test coverage. Put some effort into writing clear and concise commit messages, and write a good pull request description.
It takes time to understand other people's code, and even more time to understand a patch, so do as much as you can to make the maintainers' work easier. Be prepared for rejection, many times a feature is already planned, or the proposed design would be in the way of other planned features, or the maintainers just feel that it will be faster to implement the features themselves than to try to integrate your patch.
Feel free to open a pull request before the feature is finished, and even better, open a draft pull request even before you've written any code, that way you can have a conversation with the maintainers during the development, and you can make adjustments to the design as you go along instead of having your whole feature rejected because of reasons such as those above. If you do, please make it clear that the pull request is a work in progress, or a request for comment.
Always remember that the maintainers work on this project in their free time and that they don't work for you, or for your benefit. They have no obligation to do what you think is right – but if you're nice and make it easy for them they might do that anyway.