Add start date to a milestone

[daan@…]

It would be nice to have a start date for a milestone. With that, it's possible:

• To filter on started/not started milestones on the Roadmap page
• Create reports to show only tickets in currently active milestones
• Sort on started date in the 'Milestone' dropdown on the ticket create and update pages.

With a start date built-in, plugins could use that (for example the Scrum Burndown plugin) to draw their graphs. The Scrum Burndown plugin now has to arrange a column, while it could be useful for more plugins.

[fcorreia@…]

(just listening)

[Christian Boos]

Custom field for milestones …

[Christian Boos]

Milestone experimental deleted

[stefan.simroth@…]

I would find that also incredibly useful, so I'm listening, too.

I'd like to create a Gantt chart from the Roadmap / Milestones for a better overview.

[Thijs Triemstra]

Makes a lot of sense.

[liltor@…]

adding my 2 cents for this one

[Steve Nixon <steve.nixon@…>]

A milestone start date also allows calculation of how accurate (predicatble) we are performing. The difference from the Start-date to the Due-date and Completed-date can then be compared. Were we early, on time or late?

This would improve project planning in general as well as making this kind of information visible to stakeholders ion the project.

[Christian Boos]

Idea: workflow for milestones, e.g.

start = new -> active finish = active -> closed finish.set_resolution = completed pause = new, active -> onhold cancel = active, onhold -> closed cancel.set_resolution = cancelled restart = closed, onhold -> active

[Christian Boos]

And of course, proper history, so each change is tracked and has a modification time associated to it.

[framay <franz.mayer@…>]

Replying to comment:10 of cboos:

Idea: workflow for milestones, e.g.

OT: cool, I didn't know that you could do workflow-graphs in Trac. Shouldn't it be listed in WikiProcessors#AvailableProcessors?! Maybe all available processors should be listed dynamically by a macro / processor?!

Replying to comment:11 of cboos:

And of course, proper history, so each change is tracked and has a modification time associated to it.

Change history for milestones would be really useful. But wasn't there a discussion about making milestone "just a special ticket"? I haven't found it at once (searched for "milestone as ticket").

[Peter Suter]

Replying to framay <franz.mayer@…>:

OT: cool, I didn't know that you could do workflow-graphs in Trac. Shouldn't it be listed in WikiProcessors#AvailableProcessors?! Maybe all available processors should be listed dynamically by a macro / processor?!

See #10270. It's a new macro, so it's listed (by the MacroList macro) at 0.13/WikiMacros. Not sure, maybe the ProcessorList macro from #10201 could in the future also list it on the WikiProcessors page.

But wasn't there a discussion about making milestone "just a special ticket"? I haven't found it at once (searched for "milestone as ticket").

#3003 maybe?

[Ryan J Ollos <ryano@…>]

comment:10 sounds great to me, but also outside the scope of the request in this ticket. I'd find it incredibly valuable to have a start date for milestone, and have even considered creating a plugin to add this. Creating the plugin would be challenging (and fun) for me, but I imagine that adding a start date is trivial for the Trac developers, and would just like to emphasize how useful this feature would be, and how appreciative I'd be if this were added :) To put it simply, as a starting point I'd just like to know the time span for a milestone, and be able to quickly determine the number of tickets closed in a milestone. Plugins could use this data to derive more complex metrics.

[Ryan J Ollos <ryano@…>]

Replying to Ryan J Ollos <ryano@…>:

To put it simply, as a starting point I'd just like to know the time span for a milestone, and be able to quickly determine the number of tickets closed in a milestone.

Poor wording. More precisely, I'd like to be able to quickly determine the burndown rate to an end-point spanning multiple milestones - (Number of tickets closed in a milestone) / (time span for the milestone).

[Ryan J Ollos <ryano@…>]

#10674 was created after some observation about how the WorkFlow macro behaves in comment:10.

[Maynard K. <maynard.k@…>]

I'm going to solve this issue. Solution includes:

• changing db schema (add start as column in milestones table)
• fixing milestone modify page and quick add at milestone admin page (add field for start date)
• include a simple check that start date is set before due date (if both, start and due date are set)
• add filter for roadmap page to filter for started milestones
• fix dependencies → SQL query, model, admin so that the start date is updated and maintained correctly

Did I forget something?

Goal is to provide a commit until next Wednesday at the latest

[Maynard K. <maynard.k@…>]

Here is a git diff with my code changes to add a start date to milestone. A description of what I've done follows: 1. Changed default db schema and added 'start' column to milestone table (in the same manner as 'due' column) 2. Modified MilestoneAdminPanel to add milestones with a start date 3. Modified MilestoneCache and Milestone class to - add milestone with start date - update milestone with start date 4. Modified Query class to properly add and update start date 5. Modified Roadmap module to work with start dastes 6. Modified html templates to work with start dates 7. Modified unittests to work with start date (all tests passed) This should be a good start to add some more functionalities using start date of a milestone. The only thing missing (possibly a new ticket) would be to add a check whether start date ⇐ due date. I'm not sure if this is necessary as the milestone can be edited at any time.

[Maynard K. <maynard.k@…>]

i did some testing and everything worked so far with milestone start date

[anonymous]

Looks like a great start!

• A database migration is missing, to upgrade the schema of existing Trac installations. See source:trunk/trac/upgrades
• trac-admin milestone add command: Adding the [start] argument before the [due] argument seems not backward compatible. (Pre-existing admin scripts would break.) Maybe add it at the end instead?

• I'm not sure a "start date < due date" test is needed. Maybe it was due today, but still not started.

This should be a good start to add some more functionalities using start date of a milestone

Do you have any ideas for that? Just curious.

[Maynard K. <maynard.k@…>]

Replying to anonymous:

Looks like a great start!

• A database migration is missing, to upgrade the schema of existing Trac installations. See source:trunk/trac/upgrades

Okay, no problem I'll fix that.

• trac-admin milestone add command: Adding the [start] argument before the [due] argument seems not backward compatible. (Pre-existing admin scripts would break.) Maybe add it at the end instead?

I did this before but felt like this is a bit counterintuitive. In terms of backward compatibility, you are totally right. It is probably the simplest way to just add it at the end. I'll fix that too.

• I'm not sure a "start date < due date" test is needed. Maybe it was due today, but still not started.

Oh yes, I think I somehow misunderstood the meaning of the start date. I agree, that no such test case is needed.

This should be a good start to add some more functionalities using start date of a milestone

Do you have any ideas for that? Just curious.

I would go along with some previous comments, using the difference between start and due date to define a performance measure to see how your project is doing (in-time, late). If we would add an "Estimated Time" field one could add even more functionalities. If we know when we started we could calculate the possible delay, for example.

[Jun Omae]

I think we should choice another word for "start date" column of a milestone table because START is included in reserved words in ​SQL 2016.

[anonymous]

Maybe started would be better anyway?

[Maynard K. <maynard.k@…>]

Here is my new commit.

[Maynard K. <maynard.k@…>]

I changed "start" column to "started", added unittests for admin console and changed the order of trac-admin milestone add back to <due> <started> for backward compatibility.

I also added a database migration file to update existing Trac installations.

Cheers, Maynard