If you are not a committer and you have found a problem in or have an idea for an improvement for the Endefr project, you can create an issue in the issue tracking system.
To ensure that the issue is processed as quickly as possible, follow these steps:
Assign the issue to the correct category. The following categories are available:
Give the issue a short (the limit is 60 characters), descriptive summary. There is no separate field to
specify the issue type, so you have to put the issue type in the summary. This is done by prefixing the summary
with the issue type code surrounded by square brackets, e.g. [BUG]. The following issue types can
be used:
Use the group field to select the version related to the issue. For bugs this is the version in which the bug was found, and for feature requests and requests for enhancement this is the version in which you want the issue to be implemented.
Please note that only releases will appear in the list, preleases are not present. If you need to be more specific you should add this information to the comment.
Estimate a proper priority level. The following list is a guideline for the priorities:
Make sure that the comment is clear. It is better to be verbose so other people understand what the issue is about easier. Include reproduction steps if applicable. If it is relevant, also include information about your operating system, Java version and version of Endefr.
If you solved the problem yourself, you can create a patch of the changes and attach it to the issue.
When you do, please add the suffix -PATCH to the issue type, e.g.
[BUG-PATCH].
Please make sure that the patch is in the unified Diff format, and that the changes it contains follow the standards of the project.
The committers are not your spell checkers, code formatters, etc. If a committer feels that the quality of your patch is too low, he or she will ask you to improve the quality and submit a new patch.
All communication about the issue has to be done by using comments. This ensures that everybody can easily track the history of the issue.
Monitor the issue after you have submitted it. People (not only committers) might ask for clarification. Responding to their questions quickly ensures your issue is processed as fast as possible.
All your contributions must be licensed under the Apache License, Version 2.0.
When you make changes to the project (either directly as a committer or by submitting a patch) you retain the copyright of those changes.
Some files of the project (currently only Java source files) contain a copyright statement. If you change one of those files add your full name to the list of copyright holders. Also change the years of the copyright statement if needed.
If you contribute a number of significant patches of good quality you are eligible for becoming a committer. A committer (after getting your consent) or you yourself can propose that you should become a committer. The committer proposal has to be posted on the development mailing list. If none of the current committers have a good reason why you should not be a committer you will be added to the project.
Committers have to let the project lead know as much contact information as possible. This is necessary for negotiating a commit silence, and for private committer meetings about sensitive issues.
Below are a couple of contact information items a developer could provide:
The project lead will collect all contact information. If (part of) your contact information changes you have to let the project lead know about it. The project lead will make sure that the other team members have the latest information.