Abstract
Without knowing what bugs have been fixed and what features have been implemented it is impossible to make a serious declaration of what has been achieved with a release of a project.
This is why it's essential to keep track of every code change, what can be easily done in JIRA available at http://jira.openqa.org.
Before you commit make sure that...
- you added and/or adapted unit/integration tests
- the code changes match a JIRA issue (create one if there is none!) and that you set the status appropriately
- you executed at least the minimum set of tests by a 'mvn install'.
These simple rules assure the robustness and reliability of Selenium and make it possible that we can provide release notes.
Of course, these rules also apply to patches provided by the community users!
Issue templates
The following templates should be used when creating issues in JIRA:
Bug template
Description =========== ... Steps to reproduce ================== ... Expected ======== ... Actual ====== ...
Feature / change request template
Description =========== ... Reason ====== ... Benefits ======== ... Drawbacks ========= ...
Although these templates help the clear structuring of an issue please keep in mind that bugs have to be reproducible and the feature / change requests be understandable!
Issue reproducibility
When creating an issue assure to provide all the information and data necessary to reproduce the issue - otherwise the issue will be rejected.
Such data can be:
- URL of the page where the problem occurs
- Steps to get to the URL if it cannot be accessed directly
- Relevant page or page snippet
Attachments
Other valuable data:
- Relevant log sections recorded in debug mode
- Screenshots
- Executable test case sources
- Patch
Patches
If you provide a patch, then it has to
- be applicable to the current SVN trunk
- contain additional/adapted unit tests
- contain additional/adapted integration tests, if meaningful