Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] issue tracker feedback properties - feedback please

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Richard Morris <webmaster@pfaf.org>
  • To: Permaculture Plant Database <pcplantdb@lists.ibiblio.org>
  • Subject: Re: [pcplantdb] issue tracker feedback properties - feedback please
  • Date: Mon, 07 Mar 2005 17:20:00 +0000

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







Archive powered by MHonArc 2.6.24.

Top of Page