[Collaboa] time estimates

[Tom Clarke]

On 2/18/06, Waldemar Kornewald <wkornew at gmx.net> wrote:
> Tom Clarke wrote:
> > 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.
>
> Okay, I sat down and compared both methods by building the whole project
> structure, once with subcomponents and once with parents.
> Obviously parents are more flexible. When building the project tree
> parents came in very handy. Sometimes it does not make sense to use
> subcomponents. Often they only exist to make it easier for bug reporters
> to categorize an item. With parents you can easily have one single
> ticket for a task (e.g.: NTFS) and at the same time report bugs "below"
> this by setting the NTFS ticket as the parent. Also, if you later decide
> to further subdivide your NTFS task you can do so without interfering
> with existing bug reports.
>
> To me subtickets sound very much like categorization (or building a
> project tree).
> With subtickets I don't have a need for components/parts, either. What
> do you mean with "they are orthogonal"? I think that both overlap so
> strongly that there is rarely use for components/parts if you use
> parents. You could of course use both, but if you only had parents then
> you could still hack up the same things as with components.
> I would prefer to only have one way to do it. Now, parents sound
> much better to me. We could offer the same functionality as with
> components and go even further (e.g.: in queries "depth" could specify
> how deep to go down the ticket tree and you could also choose some
> ticket as the starting point, so the ticket list is limited to its
> subtickets and their subtickets).

I think you're still not following what I want (and have). I want to
be able to subdivide bugs/features into sub parts. Not projects. A
ticket thats divided is transient. Once the feature has been
implemented it goes away.  This is quite different from categorization
where you are saying that a ticket affects a particular area of the
system.

For example:

Some one adds a ticket:

#231 - Make the app Foobar

Now, making the app Foobar is quite complicated, and for project
management and tracking purposes I want to break up the project into a
few chunks. So we have:

#231 - Make the app Foobar
   - Implement fooing
   - Implement barring

'Make the app Foobar' isn't a component, or a subcomponent. It's a ticket.

I should add that this is working great for me in production right
now, so it's hardly a theoretical issue and it's not going to work for
me to have this feature removed.

> > 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.
>
> Hmm, I see a need for showing both fields (Target Version and Your
> Version) for bugs, but I wanted that the Priority field would take the
> function of the Target Version. High priority means "fix now" and low
> priority means "fix later". Is that not intuitive?
> You normally don't plan bug fixes for two versions in advance.

Well actually, we do. The milestones feature is working great for our
planning purposes. For bugs as well as features.

> You
> either say "do it now!" or "well, we have more important things to do,
> that can wait" (in the latter case you don't say "this is for V1.0.3 and
> that for V1.0.4", either).
>
> The alternative would be to only show the "Your Version" field for bugs
> and hide it for all other ticket types. Additionally, when creating a
> bug you don't specify the "Target Version", so that people don't get
> confused. You can specify it after creation by modifying the ticket.

I think it's entirely reasonable that perhaps not all users should be
able to assign bugs to milestones, and instead just make a comment
about it's urgency/importance and for the project manager to assign to
milestones.

Like parent tickets, the milestones feature is working very well for
us in production right now.

> But I would prefer only one version field whose meaning depends on the
> context. Even Bugzilla does not have two version fields.

Actually it does. It has a Version field for 'Version problem found
in', and a Target field for 'Version should be fixed in'.

I'm all for considering a new name for milestones, but count me out on
seeing them removed.

-Tom