Board index » off-topic » Re: More votes

Re: More votes


2006-08-05 10:28:51 AM
off-topic9
In article <44d3fa73$ XXXX@XXXXX.COM >,
"John Herbster" <herb-sci1_AT_sbcglobal.net>wrote:
Quote
And this, for a box indicating user can reproduce problem.
qc.borland.com/qc/wc/qcmain.aspx
I opened this one...
--
-David
Quis custodiet custodes ipsos?
 
 

Re:Re: More votes

On 4 Aug 2006 12:45:18 -0700, "John Kaster (Borland/DevCo)"
< XXXX@XXXXX.COM >wrote:
Quote
You now have 10 votes per QC project instead of 5. Enjoy, and spend
them wisely!
I don't mean this in a bad way...I know lots of folks like the voting
system. But there's something about it that rubs me the wrong way. I
guess it's got to do with the nature of the QC report. I don't believe
that voting is appropriate for bugs. Bugs should be fixed, period. You
shouldn't need us to vote on these - their priority should be
self-evident.
Now, voting on features is a horse of a different color. Let's vote on
them! But isn't voting on bugs sort of an Imprise kind'a thing?
 

Re:Re: More votes

Leroy Casterline wrote:
Quote
Bugs should be fixed, period.
Which ones should we fix first?
--
Nick Hodges
Delphi/C# Product Manager - DevCo
blogs.borland.com/nickhodges
 

{smallsort}

Re:Re: More votes

On 4 Aug 2006 20:08:00 -0700, "Nick Hodges (Borland/DevCo)"
< XXXX@XXXXX.COM >wrote:
Quote
Which ones should we fix first?
Think of bug fixes in the context of triage and those of us who have
run into bugs as casualties. Ideally you treat the most severely
wounded first - those who suffer show-stopping bugs. It doesn't matter
how many patients suffer sucking chest wounds or severe head injuries
- if they have a reasonable chance of being saved they go to the head
of the line, even if there's only one of them.
The way the current (voting) system works, you treat the thousand
patients suffering bug bites before you treat the guy with the gut
wound.
I'd rather you perform the triage than leave it up to the votes of the
afflicted.
 

Re:Re: More votes

Leroy Casterline wrote:
Quote
I'd rather you perform the triage than leave it up to the votes of the
afflicted.
Part of the triage for any bug is figuring out how many users are
effected what bugs bother users the most. Are you arguing that we
should stop doing that?
And of course we fix "showstopper" bugs first.
--
Nick Hodges
Delphi/C# Product Manager - DevCo
blogs.borland.com/nickhodges
 

Re:Re: More votes

Hey, you're up late. Bodes well for DevCo!
Quote
Part of the triage for any bug is figuring out how many users are
effected what bugs bother users the most. Are you arguing that we
should stop doing that?
Yes. Assign a 'weight' factor to each complaint. Here's an example:
When I create a frame dynamically in the BDS2006 BDS personality it
doesn't respect the OS DPI setting (but it does respect the setting if
I create it at design-time). Thus I can't use frames in my current
project.
Report No: 29275 ( RAID: 240134 ) Status: Open
TFrames created at runtime do not scale to host system's DPI
qc.borland.com/wc/qcmain.aspx
This is my sucking chest wound. Not a single vote to fix it, but I
need it fixed or I can't use frames.
Quote
And of course we fix "showstopper" bugs first.
OK, this is a 'showstopper' for me WRT frames. Please fix it.
 

Re:Re: More votes

BTW, I don't expect you'll address the zillion enhancement requests
I've made RE: the de{*word*81} with anywhere near the enthusiasm you'll
address bugs, but I hope you can work some of them in :-).
 

Re:Re: More votes

Quote
So if one and only one person says that a bug is a showstopper, then we
should place that report above those that, say, 22 people say is a
showstopper?

Is that what you are arguing?
Not at all. If you have 22 people who have a different showstopper
then you address that first. But you address my single showstopper
before you address, say, my de{*word*81} enhancement requests regardless
of how many people think they're a good idea.
 

Re:Re: More votes

Leroy Casterline wrote:
Quote
When I create a frame dynamically in the BDS2006 BDS personality it
doesn't respect the OS DPI setting (but it does respect the setting if
I create it at design-time). Thus I can't use frames in my current
project.
There are a number of issues here. First of all, there is a
workaround: Create the frames at design-time. Bugs with good
workarounds are "triaged" below bugs with no work arounds.
Quote
OK, this is a 'showstopper' for me WRT frames. Please fix it.
You might view it as a "showstopper", but it's not. Not being able to
use frames isn't a showstopper. You can get the job done other ways.
So if one and only one person says that a bug is a showstopper, then we
should place that report above those that, say, 22 people say is a
showstopper?
Is that what you are arguing?
See, that's what it boils down to -- the bugs "footprint". "Leroy says
he wants this fixed" only increases the size of a bugs footprint a
little bit. Lots of votes from users increases it a lot more. Sorry,
but you aren't the only customer we have. WHy should your pet bug get
put above anyone else's pet bug?
You appear to want us to stop collecting the valuable data abouy the
number of users that a bug effects and replace it with "Give this bug
lots of weight because Leroy said to". Well, lots of people "say to"
for lots of bugs. Which one do we do first? How do we triage that?
We use votes on reports, that's how. ;-) We have to get the most bang
for the buck out of our fixes, and this is one way to help us do that.
If you don't like voting for reports, then don't. But don't tell me
that voting isn't right -- it's an excellent measure to use as part of
the triage process. Note I said /part/. It's not /all/. It's a
factor that goes into the triage decision.
So, folks, please, use those extra five votes to let us know what bugs
are affecting you the most.
--
Nick Hodges
Delphi/C# Product Manager - DevCo
blogs.borland.com/nickhodges
 

Re:Re: More votes

Leroy Casterline wrote:
Quote
Not at all. If you have 22 people who have a different showstopper
then you address that first. But you address my single showstopper
before you address, say, my de{*word*81} enhancement requests regardless
of how many people think they're a good idea.
That's a delicate balance as well. As you know, on any major
application project, you can fix bugs forever. You have to balance
quality vs. features vs. schedule (as Allen Bauer likes to say,
actually shipping the product is a feature). Me? I like to weigh
quality more heavily, but the marketplace demands new features.
Getting that balance right is the hard part of this job. Really hard,
actually.
--
Nick Hodges
Delphi/C# Product Manager - DevCo
blogs.borland.com/nickhodges
 

Re:Re: More votes

David Dean wrote:
Quote
They both work now. Thanks for fixing it John
Sure. Next time, I'll remember to "commit changes" to the database
before I close the app when someone interrupts what I'm doing ...
--
John Kaster blogs.borland.com/johnk
Features and bugs: qc.borland.com
Get source: cc.borland.com
If it's not here, it's not happening: ec.borland.com
 

Re:Re: More votes

Quote
There are a number of issues here. First of all, there is a
workaround: Create the frames at design-time. Bugs with good
workarounds are "triaged" below bugs with no work arounds.
This is only a workaround if I know how many frames I need at
design-time. I don't.
Quote
See, that's what it boils down to -- the bugs "footprint". "Leroy says
he wants this fixed" only increases the size of a bugs footprint a
little bit. Lots of votes from users increases it a lot more. Sorry,
but you aren't the only customer we have. WHy should your pet bug get
put above anyone else's pet bug?
As I said before, if more people have a showstopper bug, then fix that
first. But please fix my showstopper bug before you implement new
features. And yes, if I can't use a major feature of the VCL I do
consider it at showstopper.
Quote
You appear to want us to stop collecting the valuable data abouy the
number of users that a bug effects and replace it with "Give this bug
lots of weight because Leroy said to".
I've tried to be fair in this exchange. Is it too much to ask you to
do the same?
My original point was that I find it off-putting to have to 'vote' to
fix bugs. Perhaps I'm the only person that feels that way. Perhaps I'm
not. Either way, I was offering you my opinion as one of your
customers.
Quote
If you don't like voting for reports, then don't.
I guess I'm not making my point well. I know I can abstain from
voting. As a customer, I find it unsettling that I have to worry that
there won't be enough votes to get a bug that I consider important
fixed. Am I supposed to run some sort of campaign to do so? If so, I'd
like a list of registered voters.
Quote
So, folks, please, use those extra five votes to let us know what bugs
are affecting you the most.
I'm a customer with whom you've been having a discussion, I'm not
'folks'. I respect you. Please show me some respect in return.
 

Re:Re: More votes

On 5 Aug 2006 00:09:37 -0700, "Nick Hodges (Borland/DevCo)"
< XXXX@XXXXX.COM >wrote:
Quote
That's a delicate balance as well. As you know, on any major
application project, you can fix bugs forever.
Yes, of course. But there's a difference between minor bugs and major
bugs. If I can't use a major feature of a product I consider it a
major but and I expect it to be fixed. And I don't say this lightly.
There are lots of features I'd like to see implemented (see my recent
QC reports).
Quote
Me? I like to weigh quality more heavily
That's why I was so happy to see you join DevCo in such a prominent
roll. Quality is of paramount importance, and that's especially true
in a development tool. After all, if you can't trust your tools what
can you trust?
 

Re:Re: More votes

In article < XXXX@XXXXX.COM >,
Leroy Casterline < XXXX@XXXXX.COM >wrote:
Quote
This is my sucking chest wound. Not a single vote to fix it, but I
need it fixed or I can't use frames.
FWIW, I'd really like this fixed as well, but I used all my new votes
on compiler bugs.
--
-David
Quis custodiet custodes ipsos?
 

Re:Re: More votes

Leroy Casterline wrote:
Quote
Yes, of course.
So you agree we need a system to prioritize bugs.
Quote
But there's a difference between minor bugs and major
bugs.
And I assume that you agree we need a system to determine what major
bugs and minor bugs are. Why do you object, then, to us using voting
as one means of determining "major-ness"?
Quote
If I can't use a major feature of a product I consider it a
major but and I expect it to be fixed.
What is the definition of "major feature"?
Quote
And I don't say this lightly.
There are lots of features I'd like to see implemented (see my recent
QC reports).
Right -- exactly. Why do you object to us using voting as means to
gather information about what to do next and how to balance features
and bugs when deciding what to work on?
--
Nick Hodges
Delphi/C# Product Manager - DevCo
blogs.borland.com/nickhodges