Comparing Mingle and Redmine

Angelegt von suung Wed, 24 Nov 2010 15:31:00 GMT

I never worked with Mingle and in my company most people don't use software, that is not open enough to tweak and patch it.
 

But anyway, a lot organizations use Mingle and besides Jira it seems to be one of the must current tools.

So, when I look at the mingle 's feature list, what i see is basically

a) they have some other tools, that integrate into mingle

b) there are more reports. everything is about reports, they are very custom :)

 

So guess what:

Redmine has reports and anyway, reporting is a custom task, so i wouldn't see it as something, that can be cool enough to not wanna write code

Redmine's queries are great, you can do almost everything (one thing, that actually does not work, is cross project category filtering, because categories are uniqe per project - that's a bit sad, but we will fix it soon).
 

One thing, that could be cool in Mingle, is the 'Card Wall'. That is, when you want to order some tickets collaboratively on small cards at the wall. That's where the name tickets come from. I think, it's cool, because you can easily move tickets from left to right, e.g., when they step further in progress.

I don't know code in redmine that does this. There is the Stuff to do Plugin . It's hm, a great idea, you can recommend tickets for other people as a project manager. Mingle has a personal task list, that is pretty much the same, but not that collaborative.

So i think drag drop on a wall is the thing in Mingle :)

What Mingle also has, but i don't know, what it exactly means, is 'custom workflows'.
In Redmine you can allow changing the state of an issue in a matrix per role a user can have (manager, employee ... :)
This feature is called workflow there.
But i think a better workflow solution would let you define release cycles, backlogs and all in one flow.
Mingle might be cool here.

So if anyone is experienced, I'd like to know.
 

Refactoring Redmine to be more agile and ajaxified

Angelegt von suung Mon, 27 Sep 2010 14:38:00 GMT

I did some redmine tweaking this weekend.

The goal was, to make it more agile. Agile in this terms means:

  • You can list issues, that follow each other easily
  • You need much less clicks, to get an overview over issue details and look into them, while browsing
  • You can add and edit (sub) issues inline

I think these are main goals, people address in plugins now or not at all.

I came up with some mayor changes, that should be done in core redmine, to fit my needs:

1) Pack Views into helpers and partials

I want to be able to toggle through single sections if my issue - create flow.
Therefore i created some helpers, that added divs and toggle - links with Javascript around the specific section (.e.g. in issues/show)

Doing this, i saw, that redmine is amazingly unflexible here. You even get problems toggling single sections, because of cascaded divs that have been added there just for design purpose (the background color of some parts of the issue and such)

So the tasks would be:

  • move sections into partials
  • wrap everything into sections

2) Make Controllers AJAX-agnostic

Take Redmine and try to render issues/show or issues/new in a modalbox via AJAX.
It works, most controllers contain a block like this:

respond_to do |format|

  format.html {#normal render behaviour}
  format.js {#render some attributes partial}

end

But
a) not every action has this block
b) it sometimes doesn't do, what you actually want to do.

If you want to render any action via xhr, you need two things to do:

a) skip the layout on xhr - requests

b) change the return - to behaviour slightly, to pass redirect_to or return_to.

Why the latter is needed - take a look at this example:

  1. You create an issue in an inline div.
  2. After you created the div, it should NOT redirect to issues show.
  3. Instead ideally it would know, where you have been and render only a bit of javascript, that magically loads the right row in some table.
  4. The same for error handling

So what is to do:

  • Also with the goal to be compatible with new Rails 3 goodness (responds_with...): Remove all respond_to - blocks and replace them with a Responder, that can handle those things.
  • Replace all links, that should be UI-context agnostic to pass parameters for redirect_to and others

Go with a plugin!

Plugins could do this as well (and we will come up with some plugins, eventually) but the problem is:

To add some simple line of code to let's say every action of your Issues-Controller would require
a) a hook at every place, where you want to do that
b) to copy the whole controller into your plugin (which likely is not compatible with others!)

One of the great things in Redmine is the list of hooks. Hooks are a way to inject code at exactly one single position.
A hook can for example add things to the bottom of the issue_details_list

in the code it looks similar to this:

call_hook(:issue_details_bottom) # or so

I will be about to paste a complete list of hooks soon.
Sadly, this pattern is not followed consequently enough.
A plugin can only be as good, as the positions for the hooks are chosen.
According to the above suggested refactorings, I would recommend:
  1. Go through controllers and views
  2. Create a ViewHook for every (now toggable and named) section in the view
  3. Create a hook for the corresponding Responder (or block, that responds to the browser) in the controllers.

 

Refactoring Redmine

Redmine is about to become really great. The code base is not lacking of basic principles. And even if you try to add more complex logic, than you see realized in redmine, you will find some methods, already prepared for or partially supporting your goal.
 
Eric Davis wrote a book about Refactoring Redmine. Will read it and review.