[Collaboa] time estimates

[Sean Wallace]

Hello everybody,

I've been following this conversation with quite a bit of interest. I'm
using a slightly old version of collaboa at work, mostly for its
repository-browsing and changeset-viewing capabilities. I like it a lot.
I haven't been using the ticket tracking much on this project, but will
definitely be using it on future projects.

I also realize that Tom and Waldemar seem to have cleared up their
differences over subcomponents vs parent. It sounds like parent will
work in both cases, and I think that Tom's implementation (having only
read about it, and not seen it) will do exactly or nearly what Waldemar
wants. The issue of the parent field showing 100s or 1000s of tickets
could be an issue, but I'm sure we can come up with some solution.
Michael's idea of a "create child ticket" link on every ticket will
help, for sure.

As far as the "version found in" vs. "target version" issue, I think
both fields are important. I like the term "Milestone." Tom has a good
point, every release or version is a milestone, while some milestones
may not be releases. This brings me to the real point of this email: I
really like the sounds of quite a few of Waldemar's suggestions. I will
comment on them below.

Waldemar Kornewald wrote:
> In short it basically is: --- Changed Fields * Status: Open,
> Assigned, Duplicate, Closed, Deleted
Renaming these options seems like a fairly controversial change. I (and
others, I'm sure) are used to Open, Fixed, Duplicate, Invalid,
WorksForMe, WontFix.

Some of the changes you propose are cosmetic (Invalid => Deleted, Closed
=> Fixed). Frankly, I prefer the old names, but it doesn't matter much
to me, because they mean basically the same thing.

You also want to remove the more specific "close cases" WorksForMe and
WontFix. Why? These are a little out of place, I agree, but they seem to
work and give a slightly better clue about why the ticket was closed
than a status of "invalid" or "deleted" would.

An assigned status doesn't seem like a bad idea. If you want to track
whether tickets have been assigned, wouldn't it also be important to
track who they are assigned to? Why not create an assigned-to
relationship between users and tickets? Whether a ticket has been
assigned or not, it is still open, so it could be marked as such, and
whether it has been assigned or not will be clear by whether there is a
value in the assigned_user_id (or whatever) field.

> * Severity->Priority: Blocker, Critical, High, Normal, Low
I agree that "enhancement" seems the odd severity or priority out in the
list. Either Severity or Priority is fine as the name.

> * Part->Component * Release->Version (?)
> 
> --- New Fields * Type: Task, Problem (or Defect), Wish
I really like this idea. I especially like the idea that the "version
found in" field only shows up for bugs or problems. In general I like
the idea of these types of tickets being treated differently.

> --- Removed Fields * Milestone
As I said, I like milestones.

> Subcomponent, Hardware, OS, and Parent can be hidden/deactivated.
As I think has been cleared up in your subsequent emails, subcomponent
is not necessary. I like that these fields are optional.

> Everyone must be registered to post/edit tickets.
Why does this need to change? Right now you can decide in the admin
settings whether users have to register to post/edit tickets.

> Users belong to a group/role that manages their access rights.
I like this idea, granularity in the access to tickets is important.
Project managers are certainly different from regular users and
anonymous users.

> Access rights can be set for individual ticket types.
Good idea.

> Depending on Status the Release (or Version?) field has contextual
> meaning.
I don't like this idea. It's not intuitive to users. One field should
not mean two different things at different times. I do agree, however,
that the current labeling is confusing and Release should be renamed to
indicate that it means "version found in" and that it is only really
applicable to bugs.

> Releases take over the function of Milestones, so there is no need
> for Milestones, anymore.
Again, I don't like this. Milestones should continue to do the same
thing. And bugs do need milestones (or targets).

> Instead of showing the ticket edit form at the bottom of the ticket 
> details page you can edit everything (depends on access rights) at
> the top. Only comments are located at the bottom.
This seems like it will be a tricky UI change to implement effectively.
I'm interested to see what you come up with. If done right, it could be
an improvement.

> Subscription support (ticket change notification via mail). Similar
> to Cc field, but every user can only access his own subscription.
Good idea. Probably not that difficult to implement, if I get time to
add anything, this is something I could definitely do.

> Query support in "Tickets" section: instead of filters you create 
> queries. "Open Tickets" is the default query. Queries can be saved, 
> making them accessible to all users.
Interesting idea. I don't really know enough to comment on it. I know
that Trac uses a system like this, and it seems to work, but I also like
being able to create my own filters.

> Ticket creation form only shows the minimum required fields (no 
> priority, no assignment, no status). Developers are responsible for 
> setting their values.
Allowing users, especially anonymous ones to set these values does often
result in confusion. The ticket creation form could be different
depending on a user's group/role.

> The ticket list ("Tickets" section) can be grouped by any field (like
>  Trac). If you group by subcomponent your tickets will first be
> grouped by component.
Sounds nice.

> "Milestones"/"Roadmap" section: you can inspect status by any field 
> (like grouping) for each release/version. When inspecting by 
> subcomponent the results are first grouped by component.
Fine, but wouldn't filtering the ticket list by milestone do the same thing?

Copied from a later email:
Waldemar Kornewald wrote:
> 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. 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).

This is a somewhat valid point: some people will definitely simply use
priorities to plan their development, but others will feel more
comfortable/be able to plan better using milestones as goals that
consist of discrete groups of tasks. So I think both are important. You
could either a) ignore the milestone field or b) create a configuration
option to hide it.

Well, I've entered this conversation late, and I'm not really an active
developer on the project, but I'm interested in the direction that
collaboa is taking and appreciate the work you guys have and are putting
into the project. Thanks a lot, and I hope my opinions / comments help.

Sean