[Collaboa] time estimates

[Tom Clarke]

On 2/20/06, Waldemar Kornewald <wkornew at gmx.net> wrote:
> Indeed, Milestone sounds good. Since we already agreed on changing the
> name of "Version" depending on the ticket type we could call it
> * Target Milestone if type is Task or Wish
> * Your Version if type is Problem
> Also, instead of versions you would only create milestones, specify
> their logical order, and whether they are a "future" or "past"
> (completed) milestone. Problem reports can only select past milestones
> (becoming Your Version). Not all past milestones have to appear in the
> "Your Version" field (just hide them). Would that work better?

Problem reports also need a Target Milestone

> But for Problems there should not be a Target Milestone field, but only
> a Your Version field (at least in the ticket creation form).

Bugs in my environment all have target milestones. They are scheduled
just as features are.

> Unfortunately, it's not that easy. If bugs don't get a Milestone field
> it becomes more difficult to calculate some milestone's status. I wanted
> that all open bugs are taken into account by all milestones beginning
> with "Your Version".
>
> I had long talks about the whole issue with some Trac developers and
> other people. The best argument for milestones (for bugs) is that if you
> have multiple branches you may want to say that some bug should be fixed
> for an earlier branch. OTOH, the "Your Version" field could be used to
> query for bugs reported in older branches and most bugs also apply to
> the next milestone, anyway. But it's not really sufficient.

In my case, bugs get assigned to milestones which works very well.
This is a process question surely, some people work like that some
people don't. In my case, bugs get assigned to milestones and I see no
benefit in changing that.

> Another point some Trac developer made was (if you look at):
> http://projects.edgewall.com/trac/query?status=new&status=assigned&status=reopened&group=milestone&type=defect&order=priority
> His argument was that there are bugs scheduled for later milestones.
> OTOH, if you take a deeper look then you will find that:
> * nearly all bugs for later milestones have/(should have) low priority
> * many bugs were pushed up to the next milestone multiple times
> * about 65% of all bugs are unscheduled
> I.e.: it takes time/thought to initially schedule your bugs for some
> milestone and then it takes even more time to move them between
> milestones. Moreover, the majority of your bugs are/stay unscheduled and
> get fixed on-demand.

So make it optional if it's counterproductive on your project. Just
because it's bad in one scenario, it doesn't mean it's bad in all -
it's not in mine.

-Tom