[Collaboa] time estimates

[Tom Clarke]

On 2/18/06, Waldemar Kornewald <wkornew at gmx.net> wrote:
> But please consider if this is not total overload. A ticket tracker
> should also *help* you with more efficient organization. That could mean
> not allowing sub-sub-sub-sub-children.
> May I ask what kind of software do you need this "Parent" feature for?
> Do you really have 10000s of open tickets and need more than three
> levels of categories? What are you doing? Taking over the world? :)
>
> In Joel's article even MS Excel did not need more than one single
> category field! And really, with a second level you can do *whole lot*
> more. With four levels it's (nearly always?) getting over-categorized.

I think you're misunderstanding what I want... I don't want many
levels of categorization. I just want to divide a ticket into
subtickets. One level. That's all. Components don't make sense for
this because I want the parent to have ticket semantics (i.e. it will
be open/closed, assigned, be able to have work logged against it, put
in a milestone etc..) just like a normal ticket. In contrast, I don't
really have a need for components. As I said before, I think the
components feature is orthogonal and not equivalent.

One issue that's still confusing me is the
Versions/Milestones/Releases/Roadmap thing... in a previous email you
mentioned using the versions field for either historical releases or
future releases based on context. I'm not quite sure if this is what
you are still proposing but if so, that strikes me as eminently
confusing from a UI perspective as they are quite different concepts.

For me, I'm not so worried about having a 'Version problem occurs in'
field. So I'd be happy for that to be optional, but I always want a
'Version it will be fixed in field'. This is currently called a
'milestone'. 'Version' or 'Release' aren't good names for this field
as they are ambiguous. 'Target Release' might be good, as would
'Target Milestone'. I prefer 'milestone' or 'target milestone' I
think, as one can have milestones that aren't releases but not vice
versa.

Also it's probably just semantics, but given there's a whole bunch of
functionality linked to milestones, wouldn't it be better to describe
milestones as renamed to 'Version' or whatever rather than suggesting
they are being deleted?

-Tom