Redmine

Hello,

I discovered Redmine several months ago, when I set up a server in the company I’m working at.

First of all, I want to say that I think it is a really well-done piece of software, and I would like to thank all the developers that worked on it. It is powerful, has a broad range of features, is rather intuitive to use and works very well.

As a first time user, my first impressions were generally very good. However, I noticed some things that surprised me or that I felt were missing. I think probably many other users already mentioned them, but, as a software developer, I think that users’ first impressions are important, so I will anyway present them here, in order of importance.

All fields of the “New issue” form are visible to every role¶

This is what surprised me the most. I think it is rather strange that a reporter can set the priority, the assignee or the estimated time of an issue. Moreover, it unnecessarily complicates the form for less technical users. I created the feature request #9700 about this.

No “Affected version” field¶

When I started using Redmine, the latest version was 1.1.2. Custom fields didn’t allow to reference a version. There was no clean way to indicate that an issue was affecting a shipped version or the current in-development version. This has now be fixed with version 1.2.0.

The author of an issue and its reporter are the same user¶

For most users, this is probably not a problem, as users enter new issue reports directly into Redmine, so the reporter and the author are actually the same user. However, it is common that clients report issues by email, and these issue reports are entered into Redmine by a developer, for example.

For the latter usage, it would be useful to separate the author and the reporter, while setting the reporter field by default to “<< me >>”. Additionnaly, it would be useful to be able to create new users on the fly at that point, either by searching in the LDAP, or by entering the available information (at least the email address).

Since Redmine 1.2.0, it is of course possible to add a custom field of type User to select a separate reporter, but it has several drawbacks:

• It is not possible to set it by default to “<< me >>” (the author).
• The custom field only allows to select users that are a member of the project.
• The reporter will not receive email notifications about the issue.
• The issues for which a user is a reporter don’t show up on their page or in their activity feed.

I created the feature request #9701 about this.

No standard issue voting system¶

I think issue voting is a nice feature of issue-tracking systems, and I was surprized that Redmine doesn’t provide this by default. All these “+1” on Redmine’s website itself are a little disappointing and unattractive.

This feature has been asked many times (#1011, #2104, and all their duplicates), but these requests have been closed and considered as resolved because a plug-in providing this feature is available. Indeed, there has been multiple versions of such a plug-in (the current one is http://www.redmine.org/plugins/redmine_vote). I installed it and now I am receiving a 403 error when trying to access the issues list. Even if this problem could be corrected, nothing will prevent it to break in the future.

If voting was a core feature of Redmine, or at least provided through a plug-in that is part of the standard installation, this would ensure that this highly requested feature stays easily available for all users. It should of course be enabled on Redmine’s website.

No changelog¶

I know that the list of past changes can be accessed through the roadmap, but having a default changelog URL (even if it is not in the primary links) that shows only completed versions (with pagination) would seem more intuitive. A roadmap is more commonly used to look into the future only. I created the feature request #9702 about this.

No repository sharing between projects¶

It is common for multiple projects to use the same repository. When a repository is set up in a parent project, references to and from children work, although no “Repository” link appears in the children’s primary links. I don’t know whether this is supposed to work or not, since the feature request #1657 about this is not resolved.

I think that it would be more interesting if repositories were defined independently from projects. A project would then select the repository it uses from the list of defined repositories. This could also allow for multiple repositories per project.

I created the feature request #9703 about this.

Name and title of wiki pages¶

I think it is strange that the title of a wiki page is part of its content (first h1. line). A wiki page has thus two titles:

1. The page’s name, that is used as the page’s title (HTML <title>) and also shown above the text editor when editing a page. This value is also used as the page’s URL, and some characters can not be used in it. Because of this, a page called “Version 1.0” will be displayed as “Version 10”.
2. The h1. title on the first line of the page’s content.

This is covered by the feature request #6845.

Questions¶

Default trackers and statuses documentation¶

Although the purposes of the “Feature” and “Bug” trackers are quite obvious, I’m not sure about the purpose of the “Support” tracker. Also, the use of the “Feedback” issue status is unclear to me. I know that these are just names and that they can be used for anything, but I would like to follow the common usage.

I searched in the Redmine documentation, but could not find information about the meaning of the default trackers and issue statuses. Maybe this is obvious for most users, but I think some documentation could be useful.

Best way to handle release notes¶

What is the best way to handle release notes? At first, I thought that the wiki page associated to the version should be used for this. The problem with this approach is that the whole release notes show up in the roadmap.

I am now handling releases in the following way:

• The wiki page of the version is used only as a description of the version (summary of main changes).
• I create a separate wiki page for the release notes, in which I copy the list of new features and bug fixes that I want to be present in the release notes. What would be neat to avoid a copy, is the ability to display in a wiki page a list of issues matching a specific search (#9704). This wiki page also contains a link to the version’s page (for the complete list of changes).
• I create a news entry telling about the release, with a link to the release notes.

What do you think about this approach? Is there a better way?

Conclusion¶

None of these missing features are really blocking, but they would be nice to have. I really think Redmine is a great piece of software. Thanks for the great work!