CODEWITHSUNDEEP
project-managementtracbug-tracking
tutuca
tutuca

Reputation: 3670

Use trac with separate board for tasks and bugs

I'm starting a new software proyect and I wanted to use trac to manage it. Mostly because I love it's wiki and I love the way django use it.

One thing I'd like to avoid is to pollute the development board with bug reports and viceversa. A quick round on google left me bare handed so I'd like to ask if any of you have experience setting up trac with different boards, one for regular planning and other for bug tracking.

Opinions?

Upvotes: 0

Views: 79

Answers (2)

BobHy
BobHy

Reputation: 1734

If your goal is to keep the list of tickets that represent your development plan for forthcoming release(s) separate from the untidy thicket of tickets that represent issues being encountered by users of the current release, how about using ticket "milestone"? So, "bug" reports would be opened in the "current" milestone, task planning (for potentially multiple future releases) would be associated with non-current milestone(s). I assert this allows for clearer description of items in both the current and the forthcoming release.

Someone opens a ticket complaining about how things work right now. If you decide you should address it for current users, you leave it in the current milestone (though you might reclassify it a "task" or an "enhancement"). If you decide it must wait for another release, you move it into a forthcoming milestone, but can choose to leave it called a "bug", it doesn't have to be reclassified as a "task".

Likewise, when you're testing the unreleased code and find a problem, you can call it a "bug", but in the forthcoming milestone; again, it doesn't have to be a "task" just to be considered part of the development plan.

Upvotes: 0

falkb
falkb

Reputation: 1349

It's up to you to organise it and there are several possible ways. In my opinion the best is to define two different ticket type groups (see http://{yourTrac}/admin/ticket/type), one for the plan and the other for bug handling:

  1. plan:
    • 'workpackage' for grouping
    • 'enhancement'
    • 'modification'
    • 'task'
    • => insert tickets of type enhancement, modification and task as children to tickets of type workpackage (e.g. using MasterTicketsPlugin)
  2. bug tracking:
    • 'bug'

Then use the Trac query language all over your ticket queries and Trac plugins to separate by ticket type, and insert them separated in your wiki pages and milestone wiki-language descriptions, e.g.:

[[TicketQuery(group=type,format=progress,type=enhancement|modification|task)]]
[[TicketQuery(group=type,format=progress,type=bug)]]

[[BurndownChart(milestone=v1.0,label=Plan,startdate=2014-10-20,enddate=2015-05-25,type=enhancement|modification|task)]]
[[BurndownChart(milestone=v1.0,label=Bugs,startdate=2014-10-20,enddate=2015-05-25,type=bug)]]

[[WorkloadChart(milestone=v1.0,type=enhancement|modification|task)]]> 
[[WorkloadChart(milestone=v1.0,type=bug)]]

[[TracJSGanttChart(milestone=v1.0,type=workpackage|enhancement|modification|task)]]
[[TracJSGanttChart(milestone=v1.0,type=workpackage|bug)]]

One approach is to add the bug tickets as child tickets to the appropriate tickets of the plan if they are the result of the development and fall out during the testing period.

Upvotes: 1

Related Questions