Rules for using Redmine¶

Creating issues¶

• Whenever possible, specify a “Subject” for the issue that is verbose and intelligible to someone who is unfamiliar with the problem.

Target Versions:

• Every issue must be assigned a target version.
• By convention, we have two types of target versions:
  • release versions: these are in the ‘Dev’ project.
  • planning versions: these are holding pens for unscoped issues. These target versions live in sub projects (not ‘Dev’).

Report:

• Every issue must be assigned a “Report” label.
• The report labels are used to generate reports to our funders.
• Report labels values cannot be easily renamed: to rename, add a new value to the “Report” enumeration, query all the issues with the old label, do a mass assignment to the new label, then go back and remove the old label from the enumeration.
• You can remove old labels from the Report enumeration if you want to disable any new issues from getting assigned this value. The old issues with that value will still exist, although they will not be filterable (but will still show up in reports).

Time tracking¶

• When you work on an issue, you must enter in a rough estimation of the number of hours spent on this issue. You can round to the nearest 4 hrs.
• Before an issue is closed, make sure that there is at least one time log entry.
• If an issue is taking a lot of time, consider breaking it into smaller issues.

Suggestions for best practice¶

• When an issue is resolved, it is nice to include in the comment the commit hash that resolved the issue.

Ticket tracking capabilities¶

Target Versions:

• issues can have one version
• you can track versions as milestones
• you cannot delete a version while there are still issues assigned to it.

Categories:

• each issue can be assigned to one category
• a category is just a label
• allow you to filter issues by categories in searches

Issue Tree:

• issues can have one parent
• parent will sum the hours spent on it’s children
• issues with parents can have their own children, nested without limit.
• if an issue has children, you cannot adjust the estimated time or percent done fields. For parent issues, these value based on the values of it’s children.
• each issue in a tree of issues can be assigned to different versions and categories

Issue Trackers:

• each issue has a type, e.g. Bug, Feature, Research.
• issue trackers can be shared or local to a project.
• issues can be filtered by issue tracker.
• each issue tracker

Issue Status:

• each issue has a status, e.g. Open, Rejected.
• issues can be filtered by status.

Custom queries:

• we artificially create groups of issues by defining custom queries (e.g. all issues with a subject that contains “HIVOS”)
• We can add custom fields and create queries for those custom fields (e.g. Low Hanging Fruit)

Custom fields:

• we can add custom fields to issues, which can be of various types (but not enum).
• custom fields can also be added to just about everything, like projects, versions, users, activities, etc.
• we can create queries based on these fields.

Time tracking:

• users can enter time log information for each issue
• every time entry requires an ‘activity’, which is just a label but it must be defined in advance.
• time logs can be edited, and you have have multiple log entries
• parent issues and target versions will aggregate the time spent values.