Date: Mon, 4 May 1998 15:13:59 -0400 (EDT) From: woods@zeus.leitch.com (Greg A. Woods) To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: "Jordan K. Hubbard" <jkh@time.cdrom.com>, freebsd-bugs@FreeBSD.ORG Subject: Re: bin/5296 Message-ID: <199805041913.PAA19614@brain.zeus.leitch.com> In-Reply-To: Poul-Henning Kamp's message of "Mon, May 4, 1998 19:28:38 %2B0200" regarding "Re: bin/5296 " id <15785.894302918@critter.freebsd.dk> References: <199805041546.LAA16661@brain.zeus.leitch.com> <15785.894302918@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
[ On Mon, May 4, 1998 at 19:28:38 (+0200), Poul-Henning Kamp wrote: ] > Subject: Re: bin/5296 > > Our problem is that we have never been able to get anybody to sit at the > entrance and make sure the 9x9 matrix was applied uniformly, so about the > only field we can rely on is the category, most of the rest are almost > worthless for any kind of sorting. > > For a test-period I'm trying to do this front desk sorting, which entails > sifting through the over 1200 PRs we had open and doing 'quality-control' > on the new ones. If this seems to work better, than what we had, and if > we can find the necessary sponors to continue the arrangement it will > continue. I fully realize that. I'm only trying to suggest that you might have better luck at trying to properly set the ">Severity" and ">Priority" fields than you will at trying to do everything with just the ">Category" and ">State" fields. Often the PR submitter will have no idea of what these fields should be outside of how they personally feel. However once some responsible person has reviewed the PR they can evaluate its importance within the context of other plans and priorities and thus should reset these fields to better reflect current realities. A very low priority/severity PR can be easily ignored until someone is so bored they have nothing better to do, but a closed PR will be forgotten by everyone but the disgruntled submitter who will, collectively with his peers, learn to not bother submitting PRs for anything but the most critical things and all the little details will not just be lost but will not even be collected. I've also found the ">Class" field to be quite handy, esp. by changing it to "change-request" or "support". It's then possible to select all the open "bugs", possibly rated by category and/or severity and priority too, and ignore all the change requests, "luser" support questions, etc. The "duplicate" setting is also quite useful, assuming the appropriate comments are appended (though normally duplicates should be closed too). Remember too that 9x9 is only the initial default matrix and other standard values can easily be added to any of these fields, or to even add new fields, queries, reports, etc. I.e. I'm also trying to suggest that improving GNATS is easier, faster, and probably smarter, than trying to invent or find something completely different for long-term/low-priority PR tracking. You already have lots of data in GNATS, and I think that if you can come up with an approprite way to use GNATS it will satisfy all of your needs quite well. -- Greg A. Woods +1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805041913.PAA19614>