pcplantdb

[Richard Morris <webmaster@pfaf.org>]

John Schinnerer wrote:

> Aloha,
>
> A little feedback request on some issue tracker properties, combined 
> with some implicit education on how it works... :-)
>
> Below are where I'm at with some issue tracker properties - that is, 
> properties that each issue has and that help describe it.
> Bearing in mind the KISS philosophy, please look at these and give 
> feedback on how they will work for you and additions/deletions/changes.
>
> Here is my current list for types of issues we will track:
>
> Bug        (a flaw in the project that needs addressing)
> Task        (something someone is assigned to do)
> Suggestion    (a.k.a. wish list item, feature request, etc.)
> Known Issue    ("that's just how it works right now...")
>
> What other types of issues might we want to distinguish?
> Suggest only concise and distinct categories that you might want to 
> search on.
>
> Issue status is where the issue is in its process of birth, life and 
> death.  Current list of status options:
>
> New        (not yet assigned to anyone)
> Open        (assigned to someone and hopefully in progress)
> Resolved    (for bugs - assignee claims bug is fixed)
> Completed    (for tasks - assignee claims task is completed)
> Deferred    (just what it says - on hold for some reason)
> Closed        (fixing of bug or completion of task verified)
>
> What else might you want for status of an issue?
>
> Issue priority means "how important is dealing with this to the 
> progress/success of the project?" Current priority options for an issue 
> are:
>
> Critical    (really really gotta deal with this ASAP)
> Urgent        (way more important than average but not quite critical)
> Average        (don't panic, and don't ignore either...)
> Low        (no big deal, get a round tuit eventually)
>
> Comments?
>
> There will be a Component property also, identifying what more specific 
> part of the larger system the issue is in.
> Examples would be:
>
> UI
> Graphics
> DB Engine
> Data (a.k.a. Content)
> Functionality
> Front End
> etc. etc.
>
> This can be real slippery...mixing stuff like I have in my examples can 
> get confusing, especially between the programmers' view of the system 
> and the users' view of the system.  I need to think about this some 
> more.  Suggestions welcome as to what would work best for you in this 
> property.
>
> There will also be a severity, pretty much applying to bugs only, which 
> indicates how bad the bug is in a testing/user sense.
> More on that later - just bear in mind that it is *not* necessarily that 
> closely related to priority of a bug.
> Sometimes "minor" bugs are high priority and sometimes "major" bugs are 
> low priority, depending on where and how they occur, etc.
>
> cheers,
> John S.
It all sounds great to me. I'm happy to go with your proposal. The 
componants seem well though out, no doubt the list will expand as time 
progresses.

Data could perhaphs be divided up into schema/content.

Nice one

Rich