As of now, we have reviewed the functionality that is available for projects in Redmine. However, in my opinion, it's not enough to learn what functionality is available. It's much more important to learn how to use it properly. So now, I would like to share some of my experience of what should be done and what should be avoided. In other words, in this section, I would like to list some best practices for better project maintenance. So let's go:
- Always specify the target version when you close an issue, as it is used for the roadmap.
- Have a future version added to the version list. If you are unsure what version name or number this will be then name it, for example, Next version. You can always change the name later. If no future version is available, a developer won't be able to select a value for the Target version field.
- Write a changelog for each released version, using the associated Wiki page functionality. Just the list of fixed issues that is provided automatically is not enough because this list is often huge, issue subjects are not intended to be clear enough for a changelog, and so on.
- Try to keep the done ratio of issues actual while you work on it. There are several reasons for this. Firstly, customers may follow the issue and its done ratio in particular, so this will help them see the progress (while 0% can be frustrating). Secondly, the grand total of the done ratios is used to show the overall progress of the project version.
- Write news every time you make a release. Customers who are waiting for a new release of your project may subscribe to the news of your project and expect to get news about the new release.
You should not expect your users to learn how the issue filter works and configure it to their needs on their own. Wherever possible, you should ensure that they feel comfortable while browsing your issue lists. And this is not only about your customers but also—and even especially—about your project members.
Check out the following examples of custom queries. Some of them will possibly be useful for you. The others, I hope, will give you an idea about custom queries that you may need:
|
Name |
Filters | |
|---|---|---|
|
Field/Option |
Condition/Value | |
|
My open issues |
Status |
|
|
Assigned to |
| |
|
My open issues in the next version |
Status |
|
|
Assigned to |
| |
|
Target version |
| |
|
Issues watched by me |
Status |
|
|
Watcher |
| |
|
Unassigned issues |
Status |
|
|
Assignee |
| |
|
New features in the next version |
Tracker |
|
|
Target version |
| |
|
Changelog for current stable version |
Target version |
|
|
Sort |
| |
|
Roadmap |
Status |
|
|
Group results by |
| |
|
Issues grouped by assignees and sorted by priority |
Status |
|
|
Group results by |
| |
|
Sort |
| |
|
Issues by trackers sorted by status |
Group results by |
|
|
Sort |
| |
The issue filter and custom queries were described in detail in the previous chapter.