Re: [Fresco-devel] issue tracking: Request For Comments

Tobias Hunger wrote:

>>Bug
>>===
>>
>>* status: new, open, closed
> 
> 
> 'feature' :-)

?

>>* assignee: link(developer)
>>* priority: immediate, urgent, high, normal, low
>>* type: crashes, resource usage, rendering, behavior
> 
> 
> What is 'behavior' ment to be? I'd like to have 'security' added.

a behavioral bug: button click invokes the wrong command, dragging a 
window causes the harddrive to be reformatted, etc.

security is a good point ! Though I can easily imagine a lot of 
'security issues' to be tasks instead of bugs. A typical security bug
would be an exploitable memory overflow. But anything requiring redesign
is a task, I would say. But again, the boundary isn't well defined...
(But I agree, security should be added as a type)

And here is another one I just came up with: 'doesnotcompile' :-)

>>* severity: critical, major, normal, minor
> 
> 
> Do you have a definition handy for what is critical in contrast to major, 
> etc.?

no, just a feeling that four severity degrees are better than three. 
Critical means I should stop every other activity until the problem is 
solved.

>>* component: build system, Prague, Babylon, Fresco, Berlin, kits...
> 
> 
> '3rd party' might be nice, considering how often we run into problems with 
> stuff we use. Sooner or later someone is going to report something like that 
> and this way we can mark it in a obvious way.

uh, I would just close the bug as invalid. gnome's bugzilla has a 
'notgnome' value or something like that in the 'resolution' attribute.

>>* platform: all, GNU/Linux, FreeBSD, Solaris, (more added later)
> 
> 
> Isen't someone playing with windows too? Please add 'other' too, so if someone 
> starts to work on a new port he can report his findings in a meaningful way 
> (till a new architecture is added).

fair enough.

> 
> 
>>* resolution: fixed, invalid, duplicate, (something missing here ?)
>>* dependencies: multilink(bugs)
>>
>>Task
>>====
>>
>>* status: new, open, closed
> 
> 
> I'd rename 'closed' to 'done'. Maybe we could find a use for 'won't do'? 
> Someone might add tasks as wishlist items or something that we do not like.

I actually prefer the split into status and resolution, i.e. the status 
represents the status of the activity, not the outcome. That way we can
(as you say) declare a task as finished without talking about whether we
implemented or abandoned it. It's an orthogonal concept. But yes, I 
should add an 'outcome' attribute to task...

>>* assignee: developer
>>* priority: immediate, urgent, high, normal, low
>>* type: design, coding, refactoring, optimization, cleanup, porting
> 
> 
> Do these happen one after the other during the 0% to 100% cycle? Or will there 
> be several tasks, one for each stage of the process?

well, I was inspired by the sf task manager, where we defined these 
categories. I think it's a good thing. I agree that design and code are
two stages of an overal development process. But allowing this split in
the task's type field allows people to search for open tasks that 
require analysis, design, or only code ('implement ing defined 
features'). In fact, I think it is a good idea to introduce a new task 
of type 'code' after you finished the analysis (and possibly design) of 
a 'design' task.

Regards,
		Stefan