Not signed in (Sign In)

The Intervals Forum

Categories

Welcome Guest!
Want to take part in these discussions? If you have an account, sign in now.
If you don't have an account, apply for one now.

Ways to use Intervals

Bug Tracking

Bottom of Page

1 to 5 of 5

  1.  
    •  
      CommentAuthorMichael
    • CommentTimeSep 18th 2007
     
    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.
    • CommentAuthormholtzman
    • CommentTimeNov 17th 2008
     
    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.
    • CommentAuthorsachinik
    • CommentTimeJun 23rd 2010
     
    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

    Please help me with this.
    • CommentAuthorjblauer
    • CommentTimeOct 25th 2011
     
    I wish to have statistics based on the amount of work we do due to quality issues vs. the amount we expend on new features.

    How can I do this if all tasks are treated the same?

    Module isn't an option for us, because we already use this to drive billing.

    Project is also not an option, as we need all project-related tasks grouped by project.
    •  
      CommentAuthorjreeve
    • CommentTimeOct 26th 2011
     
    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.