[Tracker-discuss] schema ideas

[Stefan Seefeld]

Paul Dubois wrote:

> I see nothing wrong with letting only developers (or some other
> designated set of persons) set priority. However, users might still see
> the priorities so that they can tell what will be fixed soonest.

Yes, of course (if priority is any indication of it). (I'v used trackers
in the past where I set up a 'milestone' issue type, which then could be
used to attach bugs to, so you can easily query which bugs were targetted
at a given milestone (release), and what milestone to expect a given bug
to be fixed in.)

> I am guilty I just realized of not looking at the prototype; I've been
> entirely thinking 'native' roundup, not of whatever changes were made
> for the prototype.

I'm looking forward to having it set up and run on the server...

> To remove the priority attribute means you want to handle rfe (wishes)
> some other way? That is, this issue class is only for bugs, period? I
> think that is the source of my confusion. The problem is people will
> submit wishes and commentary disguised as bug reports. ("Clearly a dict
> should remember the order of its keys.") We have also found bug reports
> that are 'user error' frequently turn into FAQ entries or 'feature'
> descriptions, so we have found it useful to use the original Roundup
> priorities - done + FAQ. We didn't find it useful to have two forms of
> closure.

Without going into too much of a schema discussion (which I'm looking
forward to have once we are ready for it): I think it is reasonable to
have some kind of 'type' property. For example, for my synopsis tracker
I use types [crash, build failure, resource usage, security, behavior,
enhancement request] for users to choose from. I agree that the line between
'bug' and 'rfe' often is blury, and that one can turn into the other during
the lifetime of the issue. Thus, I have this type attribute available to
all bugs.
The python tracker on sf.net has 'category' and 'group' properties, which
I find confusing, too. The second looks like it is used to tell what python
version the bug was observed with (why isn't it called 'version', then ?),
while the first is probably better called 'component'.

But hey, now we are really getting deep into a schema discussion. ;-)
I'm really only pointing these things out here to illustrate that I don't
think the old sf.net schema is very clear, and that a well-crafted
help system (yes, simply one help link per property on the item page)
would be very efficient for users of the tracker to figure out what
the correct properties are for the thing they want to report.

Regards,

		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...