Redmine first impressions and missing features

Added by Hugues De Keyzer almost 8 years ago

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!

Replies (2)

RE: Redmine first impressions and missing features - Added by Mischa The Evil almost 8 years ago

At first, thanks for sharing your findings after this thorough review in this forum-post and the referenced issues. I've already responded to some of the issues you've opened but wanted to reply to some things here also:

Hugues De Keyzer wrote:

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.

You might want to open a new, detailed but outlined, feature request to include this (issue-voting) into the Redmine core. I (an issue-triaging contributor, not Redmine core developer) at least won't close it as "Won't fix" myself since I think it would be a good feature to have in the core and I'd like to have at least one issue open for future feature additions unless core-integration is declined definitely.

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.

The "Support" tracker can be used to handle/track support requests. The "Feedback" status can be used to indicate that an issue requires (more) feedback from the issue author / issue note author(s).

What is the best way to handle release notes? [...]
  • 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?

This is how it's used for Redmine itself mostly too I think. No alternatives until something specifically is coded (either as plugin or as a core feature).

RE: Redmine first impressions and missing features - Added by Hugues De Keyzer almost 8 years ago

Hello,

Thanks for your answers. Please see below for mine.

Mischa The Evil wrote:

(…)

Hugues De Keyzer wrote:

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.

You might want to open a new, detailed but outlined, feature request to include this (issue-voting) into the Redmine core. I (an issue-triaging contributor, not Redmine core developer) at least won't close it as "Won't fix" myself since I think it would be a good feature to have in the core and I'd like to have at least one issue open for future feature additions unless core-integration is declined definitely.

After writing this post, I found an open issue about this: #6945. Do you think it is enough?

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.

The "Support" tracker can be used to handle/track support requests. The "Feedback" status can be used to indicate that an issue requires (more) feedback from the issue author / issue note author(s).

(…)

Thanks. I think it would be interesting to add this to Redmine’s help.

(1-2/2)