[Collaboa] time estimates

[Waldemar Kornewald]

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.

> #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'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 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.

I think that even the priority field must not be specified by users. 
Most of them are not capable of finding a reasonable (non-subjective) 
priority.

>> 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'.

Uhm, our Bugzilla doesn't have that field and I admit that I should have 
compared it to the official version. It looks like this is customizable 
and not all projects have/use it.

Bye,
Waldemar