Hama Jira
Hama uses Jira as its issue tracker. All changes are discussed and reviewed in Jira before committing to subversion.
Jira Best Practices
Please observe the following guidelines when using Jira for Hama.
- Keep issue descriptions short. The issue description field should briefly describe a problem, not a solution. Detailed descriptions and proposed solutions should be subsequently added in the comments. This is preferred for several reasons. The description is included in every email Jira sends about an issue, so a long description generates big messages. Also, solutions should be arrived at through consensus-building discussion, so it is inappropriate to present a solution at the outset.
- Don't edit comments. If you make a mistake, add another method clarifying things. This makes it easier for folks to follow the discussion.
- Don't delete comments. If you have changed your opinion, add a new comment noting that rather than deleting your original comment.
- Use the issue name as the patch file name. As you update a patch, re-use the same name for the file. Do not remove old versions of the patch, but rather overwrite them with a new patch file of the same name. The standard name for patch files is the name of the issue with ".patch" appended, e.g., HAMA-1.patch.
- Assign the issue to yourself when you're the primary author of a patch. This lets folks easily list the patches a contributor has written, to decide whether they are qualified to become a committer.
- Limit Jira email volume as follows:
- Configure your email client to filter all but new issue creation messages, skipping messages sent to the -dev list from Jira whose subject does not begin with "Created";
- For new issues that you wish to follow, use Jira's "watch" feature, so that emails are sent directly to you.