When Intervals was first developed as an internal tool it had "type of Task" as an attribute. For example, "bug", "feature", "improvement", etc. We found that the additional attribute for a task wasn't really necessary. Intervals assumes "a task is a task" and works well with Bug Tracking. We use Intervals to handle bugs for our service projects at Pelago. In fact, we use Intervals to manage Intervals bugs...are we allowed to admit that?
Depending on your work flow you can add a module for bugs, a project for bugs, or just treat bugs like a normal task. That is what we do. We typically attach a screenshot to the task with the steps used to create the bug and the expected outcome.
In regards to who can submit a bug, we encourage all of our team to submit bugs. The Work Request Queue can be used to submit a potential bug and then the Project Manager can review it, prioritize it, and decide whether or not to assign it.
I think this is a great idea and exactly what we are looking to do with our use of intervals. We are also a software development company and the biggest issue for us is tracking time and assigning it to a task. We have found that it really doesn't matter if the task is a bug, feature request, enhancement, etc, it's just work that needs to get done.
Once the milestones feature gets implemented that will be a huge step in helping to mange software projects.
I've a different stand on it. The 'type of task' really helps as
1) After the 'bugs' are resolved, it should be verified by the reporter(qc team). 2) 'Bugs' always occurs on a particular version of product. So version number is assigned to it. Not the case with 'task'
I feel modules cannot used to specify 'type of task', as each module can have bugs, tasks, etc. This classification helps in easy management and better understanding.
The way I need to organize the project is Project - 1 ----Module-1 -------Task-1 -------Task-2 -------Bug-1 -------Bug-2 ----Module-2 -------Task-1 -------Task-2 -------Bug-1 -------Bug-2 ----Module-3
Jblauer, this is the type of scenario that the modules were designed to handle. I understand they are being used for billing, so it may be necessary to repurpose another field. Task status, follower, or milestone could all conceivably be used to group tasks. Its definitely a workaround but its the only option I can think of to handle this type of task management need.