id,summary,reporter,owner,description,type,status,priority,component,severity,resolution,keywords,cc,release 4413,Collecting data for milestones that were not yet started,Filipe Correia,daan,"With the implementation of ticket #1462 we can now set a new start date for a give milestone, which is great, but I'm now not sure how should the chart behave when this feature is used... I tried defining a start date for a milestone that has started a few weeks ago, and was expecting to see a chart for this entire period when selecting the right milestone on the burndown tab. However, what happens is that the chart for this milestone keeps being displayed as it was started today, even though it does contain some previously closed tickets. I think I understand why this happens (please confirm): the chart data is actually stored as we go adding time and closing tickets, so even if we change the start date, the 'historical' data as registered by the ScrumBurndownPlugin won't be affected, and the plotted chart will be the same. In spite of this, I still wish I could see the burndown for milestones that have started before the plugin was in use, and even for milestones that have already been closed, as it may allow to better understand the project's work-cycle, and better plan for the future. My suggestion (not sure if this is even doable) is that the chart is plotted on the fly, from the TimingAndEstimationPlugin data (estimated hours and total hours) and from the ticket data (which milestone does it belong to, when was it added and when was it closed), instead of keeping historical data specific for ScrumBurndownPlugin. Something that may become an issue with this approach is that tickets that are removed or added after the milestone's start date won't be reflected on the burndown chart (btw, this was also an issue discussed in ticket #1292). However, maybe it's not that bad to allow modifying a chart on a past time-frame; after all, if we think of a milestone as a sprint, adding and removing tickets should be avoided as much as possible, so, when it does happen, it is probably to correct some misuse of trac, and make it reflect what really happened. ",enhancement,assigned,normal,ScrumBurndownPlugin,normal,,,,0.11