Redmine

Fair warning: This post turned out to be a lot longer than I anticipated... I won't be shortening it though: essentially this is the cumulation of my personal experiences with Redmine, formed as opinions on how it could be improved from here. You might want a grab a cup of coffee first. :)

I've been using Redmine pretty consistently for about half a year now, and I must say I'm extremely impressed by this system. Disregarding the typical quirky nature of open-source projects, between the core system and the vast array of user plugins that have been developed, this system truly has no limits in it's capabilities.

For anybody that's interested, I discovered a website the other day that showcases the true potential of Redmine in ways that surpass any other project manager that I know of.. But at the same time, it's put together so cleanly that only people who've actually used Redmine themselves would even recognise it. Get a comfy chair and check out the Cocos-2dx website:"http://cocos2d-x.org/" to see what I mean. Anyways, all these lightbulb-moment discoveries led me to thinking this Redmine site would benefit greatly from a fresh new look and layout... Being an open-source project itself, I think the tracking, testing and perhaps even the implementation of these proposed updates should be tracked in their own projects right here on this domain.

Currently the only project on the site is for Redmine. While this works brilliantly for showcasing the platform's project-specific features, there's no clean example of how to use it for managing multiple projects; a layout that I'm sure the majority of users will have in mind when they start out with it. I myself spent almost 2 months getting lost in system configuration settings. 2 months that I could have spent working on the contents of projects, was instead spent on configuring their containers and trying to control and restrict user access to each of them.

So, before I end up telling my life story here... I have a few suggestions/requests aimed at the powers-that-be with regards to this project and specifically this website. Any and all feedback would be greatly appreciated here. Just keep in mind the ideas below are quite simply my opinion..

Better Use of Projects¶

First things first: Plugins deserve their own project. I doubt anybody would disagree when I say that the plugin list for this project has far outgrown the capabilities of the Redmine wiki... In order to properly separate the user-code related issues from core-code related issues, this should most definitely be a sister project to the current 'Redmine' project.

To be fair, by definition a wiki is by no means restricted to small systems (look at Wikipedia.org for example). However it's most effective as a distributed document storage system, maintained by a great many users making many small updates all over the place. Using a project for plugins has numerous benefits over the current wiki; better search support, bug reporting/tracking, documentation, releases, etc etc. In a nutshell, every feature that is already associated with a project.

Beyond this, the use of projects inherently promotes a type of "code separation" mentality, even for non-developers. As it stands, Redmine already allows the global viewing and searching of issues across every visible project in the system, regardless of where they are. Why not make better use of this aspect by making the default view of each system area global, allowing it to be filtered down through projects, categories, trackers, access control, etc.? This seems a natural evolutionary step to me.

Access Control - More Verbose, Less Permissive, Don't Forget Inheritance¶

This is partly a system change feature request, but I think it plays a vital role in the future of the platform as a whole. The most popular systems of any type all have one common trait: users are only given access to what they need, nothing more. Examples? Facebook, Github, DeviantArt, Flickr, etc. Each of them are still only one web app...

The biggest issue I've run into is trying to group user access to specific projects (including sub-projects). Yes, access permissions may be assigned to either a user or a group, but the current implementation of this is far too permissive when a user's "personal" and "group" access levels differ for a project (I see this as a bug, so I'll log a bug report for this later). Allowing the current user base to experience an environment like this here on this site would not only be more informative for new users, but also aid in future improvements to Redmine itself.

A True User Interface¶

Think about it: what is a "user interface"? It's the interface through which a user accesses a system. This right here is a themer's playground. The Cocos-2dx site example really does make Redmine shine brightly, but for most people, the amount of work involved in creating something of that scope is either impractical or downright impossible. This doesn't have to be the case.

Back on the idea of multiple projects, I think there are certain categories in the current 'Redmine' project issue categories that would benefit by being promoted to projects. At the time of writing this post, it has 54 categories defined... Might I propose the following categories have their own sub-projects instead:

• Administration - keep the primary project for "user" related bug reports.
• Database - it's not business logic, it's storage for it.
• I18n - certain issues only affect certain languages, in which case the core list of categories should be inherited for each specific language.
• Themes - I'm going with the same mentality as why 'plugins' need a project.
• Website (redmine.org) - naturally, this area would benefit greatly from having additional functionality.

As an afterthought, this sort of "cleanup" would also allow many of the duplicated categories to be trimmed as well (I18n + Translations, Activity View + My Page + Themes + UI, etc etc).

Final Thoughts¶

I promise, I am nearly done. :)

Throughout all of this, I've kept one very important aspect in mind: Redmine is a dynamic project tracking system. As a result, I feel it should be treated, used and developed with that same point in mind. So, any feedback on my ideas then...? Constructive criticism is very much encouraged.