Post #211,489
6/16/05 9:49:29 PM
|
I'd used Request Tracker for a while.
[link|http://unix.freshmeat.net/projects/requesttracker/|http://unix.freshmea...s/requesttracker/]
It's written in Perl and you can customise it to an insane degree, depending on your Perl skills :-). Notably, it's very well-structured code so even I could do things to it. Apparantly, it can be a bugger to install, though.
One thing: we noticed that a trouble-ticket system and a feature-request system can sometimes have different and conflicting needs. For a while we left bugs in RT and ran a white-board for feature requests, but over time we found we could put tasks in RT, too, and that worked quite well.
Wade.
Save Fintlewoodlewix
|
Post #211,511
6/17/05 9:35:28 AM
6/17/05 9:39:36 AM
|
We're having that discussion at work
Or more accurately we've already had it, but a few people haven't fully come around to the obvious rightness of my conclusion yet. Bottom line is I don't draw a distinction between bugs and feature requests. As far as the user is concerned, the application doesn't do what he wants it to do. We need to know that. All that's left is to decide if we're ever going to make it do what the user wants, and when that's going to happen.
Once you've bought into this idea, having different systems for tracking
bugs and feature requests seems really counter-productive.
As for estimated completion dates, I take the view that you estimate how long it will take to do, then you schedule a completion date. If the developer misses it, he learns to estimate better.
[edit]
Caveat: This assumes you have some control over who is allowed to submit bugs to the system. If you're talking about open submission from an audience of potentially hundreds of users, then yes, you need something separate like Bugzilla. And someone whose job it is to pore through that list and filter out the duplicates.
===
Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
Edited by drewk
June 17, 2005, 09:39:36 AM EDT
|
Post #211,526
6/17/05 10:43:43 AM
|
ICLRPD (new thread)
Created as new thread #211525 titled [link|/forums/render/content/show?contentid=211525|ICLRPD]
--
Steve
|
Post #211,722
6/20/05 2:17:04 AM
6/20/05 2:21:27 AM
|
Generalization, Abstraction, Taxonomy, Perspective, Opinions
Well, bugs and features have a lot a common.
Like dogs and men.
Bugs are trackable, Feautures are trackable
Dogs have legs , men have legs
Bugs are introduced into software by programmers, Feautures are introduced into software by programmers
Dogs have teeth, men have teeth
Anyway, you got my point ...
A bug is a behavior that you want to remove, a feature is behavior you want added
but from many perspective what you can do with them is the same
We can track bugs and features the same way, and yes a smart programmer would use hard learned object oriented concepts like absraction and polymorphism to write a piece of software that would track -trackable work related to software products- and offer extensions that support specialized -trackable work related to software products
But, I also think it is not always practical to generalize every problem you try to solve, or better said not too far generalize, else you can always end up with a general purpose programming language! or Perl 6.
A good bug tracking system is one that is crafter for the special requirement of bugs even if they are minorly different from features.
A good programming environment or framework, will allow you to share code between similar systems, and extend/specialize where neccessary
Edited by systems
June 20, 2005, 02:21:27 AM EDT
|
Post #211,744
6/20/05 12:16:32 PM
|
Feature requests are classified as requests to add bugs
Since adding new features will generally introduce more bugs into the software. :-)
Bugs are stuff that should be addressed as the software does not meet the specification. Features are attempts to change the specification. Bugs should be immediately addressed. Features have to be pruned because, as a general rule, the end users want the software to do everything possible (and many things that are not computably possible).
|
Post #211,753
6/20/05 12:35:08 PM
|
Problem is, the users know that
Which is why they will work as hard as possible to classify everything they bring up as a bug. "It doesn't work right." But it does exactly what you asked for. "But it doesn't work right ... and it's affecting our productivity." Right, so you should have asked for the right thing to start with. "But it doesn't work right ... [cc: CEO, CFO] ... and it's having an immediate negative impact on profitability." Oh, you mean it doesn't work right? I'll get right on that.
===
Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
|
Post #211,755
6/20/05 12:45:09 PM
|
Customers will call on every person in the company...
...until they get the answer they want to hear.
|
Post #211,773
6/20/05 2:18:25 PM
|
Like I do for Comcast?
--
[link|mailto:greg@gregfolkert.net|greg],
[link|http://www.iwethey.org/ed_curry|REMEMBER ED CURRY!] @ iwethey
[image|http://www.danasoft.com/vipersig.jpg||||]
|
Post #211,831
6/20/05 9:30:36 PM
|
That's when you hold up the spec doc.
And say "That's not what you asked for. What you're asking for is additional development and subject to normal scheduling concerns." :-) Of course, when they start imploding, you can gently remind them that they are free to prioritise any development they want in before any amount of bugs they have submitted.
Back at the place we were using RT, we did that once or twice. Taught them to check what they asked for before saying 'it doesn't work right'.
Wade.
Save Fintlewoodlewix
|
Post #211,856
6/20/05 10:37:53 PM
|
The what doc?
There are some process problems that can't be solved with better tools. I'd say most of them, actually.
===
Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
|
