Projects, milestones, tickets improvement

[cjunge@…]

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.

Cameron.

[Christian Boos]

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.

[Christian Boos]

Milestone experimental deleted

[Christian Boos]

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