Redmine

After I installed Redmine I watched the company I work at go tracker crazy for about five minutes before I put a stop to that.

Writing specs and docs I generally put under support, it's general maintenance of a project.

Research I always argued should be entered with the intent of the research as a ticket, and a phase of it is research, so that on conclusion of the research, the ticket can either be rejected or move onto the next phase, considering I had input that a research issue should be "closed" after research is complete, and I argued that leaves absolutely no paper trail of the original intent, or how research may lead to the rejection of an issue.

If you wanted granular reporting of time spent, add a time tracker for reporting.

Of course you can just go tracker crazy if it makes you feel better, but I argue the minimal amount of clutter leads to better tracking and less complaints about the system being a burden of overcomplciation.

I don't think the slightly pejorative term "tracker crazy" applies here, and I usually don't configure systems to better suit the needs of my users to "feel better" - but thank you for your input :-)

I now created a tracker called "project activities" and assigned the statuses new, started, interrupted, finished, accepted...

J N wrote:

I don't think the slightly pejorative term "tracker crazy" applies here, and I usually don't configure systems to better suit the needs of my users to "feel better" - but thank you for your input :-)

It's not really pejorative at all, I've seen systems where people start off with your intent... and then they want some other type, and another, and soon you're thumbing through a list of trackers to create a ticket because it seems trackers are commonly added impulsively to solve a problem that has other methods of better tracking (or were too granular in their definitions).

Mainly: I've seen people add trackers willy-nilly, that is basically worst practice, I'm just saying to stay away from it.

I now created a tracker called "project activities" and assigned the statuses new, started, interrupted, finished, accepted...

Yeah, you'll see "tasks" which is fairly common and general enough to not create clutter, same thing really. I'd say as long as you stay at higher levels of generalization, you're fine and wont end up overhauling your system in a year.

J N wrote:

Hi all,

the default trackers "support", "bug" and "feature" are somewhat code-related and I'm totally happy with that.
But neither doesn't "seem right" for planning tasks like

We looked at the trackers from the task management perspective
- if a task is managed very differently from the others - we use another tracker.
For example we have tracker Scope to track scope of work, which includes all items
on the same budget. New budget - new scope (or vice versa).
Tracker Task we use for work that does not contribute testable results, while Bug and Feature - for work that
has to be tested eventually.

Also, for a non-code related projects we have their specific trackers (not very many though)

We also went through 'tracker crazy' phase but then merged most of them.
Too many trackers creates additional managerial load and makes the user hard time to understand which tracker
to use when.