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.

We are using the following trackers in our web services and development company and they seem to suffice all our requirements.

• Bug
• Feature (You may call it a module or "a/a collection" of user story(s)
• Support - for any support outside the project team
• Risk - for managers to document risks
• Review and Feedback - for any internal and external reviews. We also use it for giving private feedback to team members
• Project Audit - Used by technology and functional senior management team to give feedback after project audits. Not used in client projects but in functional group internal projects
• Task - any other generic task assigned to the team members
• Milestone - To create milestone tickets and add child tickets to them. We also use advanced roadmap plugin to create milestones which can be reflected in the gantt charts.
• Defect - Measures technical debt and related triage. Bugs reported after technical reviews. A separate tracker helps us know health of the projects based on numbers which can be easily filtered.
• Patch - For tracking our open source contributions
• Request for Change - To track change requests

Activities that we have defined to log time against work done

• Design and Development
• Planning
• Documentation
• Review and Feedback
• Communication
• Deployment
• Self Learning and Support
• Community Contribution

The two together which can be easily filtered via the issues and reports core plugins really help us to effectively track status and time spent against each activity.