Jira Report Expectations
Nothing is more frustrating than taking the time to report an issue to a project and then watching the issue seemingly "just sit there". The purpose of this wiki is to discuss the expectations interested parties should have in regards to reported issues and the things they can do to speed things along.
Do keep in mind that Hibernate is a huge Open Source project (multiple projects, really) and yet an amazingly small development team, which has certain implications
The expectations vary based on the issue type to a large degree...
In general we expect that bug reports are accompanied by an attached test reproducing the reported bug. If a bug report does not have an attached test, expect the report to be moved into the "Awaiting Test Case" status. That is in indication to the community and to the developers that this bug report does not have an associated test. See the Test Case Guide for details.
We also expect that incoming bug reports are verified against the most recent major version (for the reasons outlined in the "Huge Project, Small Team" wiki). If not, the report may either be rejected or the reporter asked to verify it using the most recent version.
Missing a test, a poorly-written test, not verified against the current major version all deduct from the likelihood that the report is handled quickly. You can also add to this likelihood. Doing a lot of code digging or even submitting a pull request increase this likelihood.
Aside from cases where we are waiting on a test case or waiting on user feedback of some sort, ideally every incoming bug report is either scheduled or rejected in short order. In fact this is the purpose of a "triage" meeting that the ORM developer do (roughly) once a week.
Votes do play a part in prioritizing bug reports, but not to the degree that votes affect feature requests...
The main driver for feature requests are votes. In principle, feature requests which do not receive enough votes will be rejected. There is no hard-and-fast rule for how long we will wait before rejecting feature requests that do not garner enough votes, nor even for how many votes constitute "enough".
A quality implementation of the requested feature as a patch or pull request helps increase the likelihood of a feature request being accepted assuming the requested feature is deemed "worthwhile". The best way to gauge whether the requested feature is worthwhile is to start a discussion on the hibernate-dev mailing list.
If Jira report seems to "not be moving", the general reason is that it is missing a "champion". The principal tenant of Open Source development is "vested interest". The champion for a report is the one with vested interest in getting it resolved. To be frank, adding a "bump"-comment to the report does nothing to motivate someone to champion it. If it is important to you, consider becoming its champion; here are some ways to champion a report that actually increase the likelihood of it getting resolved:
- Join the triage meeting and discuss it.
- Discuss it on the hibernate-dev mailing list, #hibernate-dev IRC channel or HipChat channel.
- Investigate it. Identify causes of the reported bug; develop clear use-case(s) for new features.
- Propose solutions, possibly even submit a Pull Request or patch.