[Collaboa] time estimates

[Tom Clarke]

On 2/20/06, Waldemar Kornewald <wkornew at gmx.net> wrote:
> Tom Clarke wrote:
> > 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.
>
> But you could as well just allow for multiple levels of components and
> remove the subcomponent representing your parent task when the task gets
> closed, couldn't you?
> I've talked about this topic with some other people. Their general
> response was that it sounds too strange to use tickets as parents. They
> wondered why components would not work and if you need ,for example,
> Comments and Priority for parent tickets. Also, I'm wondering what kind
> of tasks you have. They must be very big if they require subdivision.
> But I understand that you want something that goes away when all its
> subtickets are closed.

Yes, they are big. But then, I'm not trying to convince anyone that
they should or shouldn't use parent tickets, only that I use them and
find them useful (which is undeniable I think :-)).

> > #231 - Make the app Foobar
> >    - Implement fooing
> >    - Implement barring
> >
> > 'Make the app Foobar' isn't a component, or a subcomponent. It's a ticket.
>
> Right, but we don't have to use it that way. We could also just keep
> tickets as unscheduled entities that behave like components. OTOH,
> tickets really have too many fields and are too unpractical for this.
> Maybe we should again go with subcomponents and parents (both being
> optional).
>
> > 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.
>
> Please don't come up with points like "production use". I've seen many
> terrible bug trackers in "production use". It means nothing if you don't
> explain why it's so great.

I was just making the point that I'm not speaking hypothetically. When
I say it's useful to me that's speaking from practical experience.

In any case, I don't care if other people think it's great. I
implemented it for me. If other people find it useful, fantastic. If
not, lets make it optional. If it's really that objectionable to have
it in there then it's another reason for me to start my own fork.

> I've replied to the milestones issue in an earlier mail (to Sean).
>
> Email is too slow for communicating this kind of problem. When are you
> around on IRC? Always when I joined the channel there was nobody
> replying. :)

I never got IRC working from my office. Maybe I'll try again soon.
What timezone are you?

-Tom