Hello:
This is my first post. I’m a Java backend developer with some years of experience using JPA and Hibernate (mainly ORM) in several projects. Also, this is my first attempt for contributing in an open source project.
I was just browsing the tickets in JIRA but don’t know what would be an appropriate ticket to work on. What would be a good search criteria for a first-time contributor? bugs, improvements, docs? what version?
Hope someone can give some guidelines. Thanks in advance for your comments.
PS: If this post is better suited for another category, please comment and I’ll change it right away
Its going to be highly subjective based on your experience in various areas of Hibernate ORM.
That said, addressing documentation concerns is likely the easiest area to begin with. Most of the time this involves fixing typos, out-dated information, incorrect examples, or perhaps improving documentation with additional examples that could be useful for users.
After that, bugs and improvements can be a bit subjective. Both do require that you not only understand the change at the impact site but also the snowball effect it could have on other parts of the framework too.
Its best to focus on contributing to master, whatever version that may currently be. The older branches and versions are managed internally by the team and whether a fix is backported depends on a variety of factors. Its just easier for contributors to work in this way and we adapt older versions on an as-needed basis.
So in the end, find a JIRA issue that appeals to you and go for it. If you have questions along the way, don’t hesitate to ask them on the JIRA, the hibernate mailing list, or HipChat. Furthermore, don’t hestitate to submit your PR as you feel it should be implemented. If there are any changes we feel should be made, we’ll let you know so you can make those at your leisure so we can integrate the PR seamlessly.
Thanks for your answer, I think I’ll be starting with documentation.
I’m not understanding quite well what do you mean by contributing to master. I mean, how can I know if the ticket I’m choosing is for a PR in the master branch?
From a contributor perspective, what I meant is when you submit a PR for a fix, just make sure you that the fix is based on the master branch. This allows us to better integrate your fix into the repository when the time comes. If it is deemed to be something that needs to also be applied to adjacent branches, we can do that using a cherry-pick from master on an as-needed basis.
So in short, just find a jira issue that needs fixing, prepare the fix based on master and send the PR based on master. From there, we can handle the rest.
What is usually quite interesting too is to do some detective work on the issues where there is a proper test case attached (or linked).
When they are based on our test case template, it’s quite easy to include them in our test suite (well the most difficult part is to find where but you can try and guess and we can adjust later).
Then trying to debug what’s happening with your debugger and trying to understand what’s going on that is wrong. Sometimes it will be too difficult for you to understand what’s happening or to find the proper fix but you can interact with us on the JIRA and find some guidance.
Even having someone validating that the test case is a real issue is usually helpful.