Edgewall Software

Opened 11 years ago

Closed 10 years ago

#7422 closed enhancement (duplicate)

Projects, milestones, tickets improvement

Reported by: cjunge@… Owned by:
Priority: lowest Milestone:
Component: ticket system Version:
Severity: minor Keywords:
Cc: josh@… Branch:
Release Notes:
API Changes:


I've had a look at the proposals for sub-tickets, or sub-milestones & thought it might be an idea to put down on paper (so to speak) some ideas that I've come up with to solve these issues.

Basically, the way I see it, if it was possible to have sub-tickets, then milestones just become a special case of having a parent ticket. Also, if a ticket was classified as a milestone, then milestones could have sub-milestones.

Also, it'd be possible to group milestones into a per project, or even a per component basis. Whatever a user chose.

My theory is that the status for a project, milestone & ticket could be specified separately. To clarify: a "project" would have a selection of statuses that applied only to projects (discussions, spec'ing, in progress, complete) etc, and milestones would also have their own as well as tickets having their own.

So, to simplify:

Projects could contain milestones, and would have their own statuses; Milestones could contain milestones o&/or tickets, and have their own statuses; Tickets would remain as they are, except they could also have sub-tickets.

It's basically an enhancement of the current ticketing system to support sub-tickets, as well as different types of tickets. Special types (ie. projects & milestones) would have some other metadata that allows the current displays in the Roadmap.

In addition, some of the changes mentioned in GenericTrac could be done by using different views or the ticket changes (ie. history & discussion).

Just throwing it out there, maybe it'll land on fertile ground. Unfortunately I don't know Python, so can't work on it myself.


Attachments (0)

Change History (5)

comment:1 by Christian Boos, 11 years ago

Milestone: experimental

Just throwing it out there, maybe it'll land on fertile ground.

Thanks, appreciated.

One difficulty with the idea you developed would be that in some cases, you'll get a hard time deciding the "right" type for a task, e.g. will it be a ticket or a milestone?

With clear and plain distinctions as we have now, it's not a problem: milestone will usually correspond to releases (or some intermediate notable staging), tickets to individual features or issues.

Now with sub-milestones and super-tickets, I can imagine that there will be a point in the middle where the distinction will become less evident to make: a ticket which grows many sub-tickets could eventually be promoted to be a milestone, conversely a sub-milestone that end up with no or only a few tickets could be converted to a ticket…

So I think some flexibility is needed here.

comment:2 by Christian Boos, 11 years ago

Type: taskenhancement

comment:3 by josh@…, 10 years ago

Cc: josh@… added

comment:4 by Christian Boos, 10 years ago

Milestone: experimentalnext-major-0.1X

Milestone experimental deleted

comment:5 by Christian Boos, 10 years ago

Milestone: next-major-0.1X
Resolution: duplicate
Status: newclosed

This is related to the SubTickets proposal, therefore closing as duplicate of #886.

Modify Ticket

Change Properties
Set your email in Preferences
as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.
to as closed The owner will be changed from (none) to the specified user.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.