[Collaboa] time estimates

[Waldemar Kornewald]

Sean Wallace wrote:
> 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.

If someone wants to report a bug it should be possible to click "New 
Ticket". It could be sufficient to allow for selecting multiple levels. 
I.e.: you select a top-level ticket, then a new field "Level 2" appears 
and you can select one of its subtickets. Then the next level appears, 
and so on...

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

Indeed, Milestone sounds good. Since we already agreed on changing the 
name of "Version" depending on the ticket type we could call it
* Target Milestone if type is Task or Wish
* Your Version if type is Problem
Also, instead of versions you would only create milestones, specify 
their logical order, and whether they are a "future" or "past" 
(completed) milestone. Problem reports can only select past milestones 
(becoming Your Version). Not all past milestones have to appear in the 
"Your Version" field (just hide them). Would that work better?

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

I intentionally chose Fixed->Closed because "Fixed" only applies to 
bugs, but you don't fix tasks. You only close them.
Invalid+WorksForMe+WontFix are too specific for me. In all cases the 
developer should to comment on why he chose this, so why not call it 
"Deleted" and let him say "We won't fix this because ..." or "That's 
invalid because ..." or "We did not have a problem with that...". Users 
will want an explanation, not just "WontFix".

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

I forgot to copy-paste this from the wiki page:

The ticket creation/modification form shows/hides the "Assigned 
To"/"Duplicate Of" fields depending on the value of "Status".
The _text field_ will be placed next to the "Status" field such that it 
looks like this ("myself" is a button):
* Status: [Assigned] To: [developer] <- myself
* Status: [Closed] By: [developer] <- myself
* Status: [Duplicate] Of: [25]

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

But for Problems there should not be a Target Milestone field, but only 
a Your Version field (at least in the ticket creation form).

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

If some ticket in incomplete it must be possible to contact the author. 
Also, with registration SPAM is less likely. You're right this should be 
configurable, but unregistered users should not be able to enter some 
other developers' name, so the Author field should be:
Author: anonymous (username/email)

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

I thought about something similar to Bugzilla, here. :)

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

Yeah, that would be cool. It should be a simple link (only available for 
registered users). The following users should be automatically registered:
* author
* users adding a comment or modifying the ticket
* user who is assigned a ticket to

If some user assigns a ticket to someone else then that person is 
notified (in addition to being subscribed).

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

Yes, everyone should be able to create (but not save) queries.

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

Yes, maybe. But it should be done automatically for users who can be 
assigned tickets to.

>> "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?

Maybe I should have explained better. When inspecting by field you see a 
little status indicator. Here is an example:
http://projects.edgewall.com/trac/milestone/0.10

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

Unfortunately, it's not that easy. If bugs don't get a Milestone field 
it becomes more difficult to calculate some milestone's status. I wanted 
that all open bugs are taken into account by all milestones beginning 
with "Your Version".

I had long talks about the whole issue with some Trac developers and 
other people. The best argument for milestones (for bugs) is that if you 
have multiple branches you may want to say that some bug should be fixed 
for an earlier branch. OTOH, the "Your Version" field could be used to 
query for bugs reported in older branches and most bugs also apply to 
the next milestone, anyway. But it's not really sufficient.

Another point some Trac developer made was (if you look at):
http://projects.edgewall.com/trac/query?status=new&status=assigned&status=reopened&group=milestone&type=defect&order=priority
His argument was that there are bugs scheduled for later milestones. 
OTOH, if you take a deeper look then you will find that:
* nearly all bugs for later milestones have/(should have) low priority
* many bugs were pushed up to the next milestone multiple times
* about 65% of all bugs are unscheduled
I.e.: it takes time/thought to initially schedule your bugs for some 
milestone and then it takes even more time to move them between 
milestones. Moreover, the majority of your bugs are/stay unscheduled and 
get fixed on-demand.

So, milestones are useful, but we should somehow reduce the amount of 
bug scheduling work (at least by writing a document "How to use Collaboa 
efficiently") and maybe combine both methods (no milestones + milestones 
for branching). For example, unscheduled *bugs* affect all milestones 
starting with "Your Version", whereas scheduled *bugs* only affect a 
certain milestone (remember, I'm only talking about bugs, ATM). 
Alternatively, we could think about grouping milestones into branches 
and allow for selecting a branch (instead of milestone). All bugs 
selected for a branch are automatically scheduled for all milestones 
within that branch. Otherwise they are scheduled for all milestones 
starting with Your Version. The branch, of course, is something that the 
user should not supply. Only developers may set its value.

I really want to reduce the amount of maintenance work for developers 
and the amount of confusion for users. Please (all of you) try to help 
with finding a good solution. I don't think that having YourVersion and 
TargetMilestone for bugs is a perfect solution. Assigning bugs to 
milestones should be more automated. If we can't find an acceptable 
agreement I'm still open for adding milestone (but hiding it from the 
"New Ticket" dialog).

Keep in mind that it's all about Problem tickets. For tasks and wishes 
"Your Version" is uninteresting, anyway, so only "Target Milestone" is 
required.

Bye,
Waldemar