disabling vote-to-confirm on bugzilla.mozilla.org

[Byron Jones]

a feature of the voting system within bugzilla is the ability to
automatically bump a bug from UNCONFIRMED to NEW based on the number of
votes for the bug. This feature is enabled on bugzilla.mozilla.org, with
the per-product setting ranging between 1 and 10,000 votes.

chris lawson recently pointed out that voting should not be linked with
triage. i think he's right.

echoing chris's comment on bug 702704 i think disabling vote-to-confirm
across all products on bugzilla.mozilla.org will clarify the triage process.
owners of products who want to continue to use this feature will be
required to ask to be excluded from this mass change, or request the
feature be re-enabled.

any objections/thoughts?


-byron

[Gervase Markham]

On 22/11/11 08:47, Byron Jones wrote:
> a feature of the voting system within bugzilla is the ability to
> automatically bump a bug from UNCONFIRMED to NEW based on the number of
> votes for the bug. This feature is enabled on bugzilla.mozilla.org, with
> the per-product setting ranging between 1 and 10,000 votes.
>
> chris lawson recently pointed out that voting should not be linked with
> triage. i think he's right.

The original logic of this link was that moving from UNCONFIRMED to NEW
indicated that a bug actually existed. Those without 'canconfirm' were
able to make such an indication by voting for the bug. If five people
vote for a bug, it's quite likely that it actually exists.

Is this logic no longer valid?

Chris argues that: "Just because more than one person thinks something
doesn't make that thought correct." However, if more than one person
sees a bug, it does make it a lot more likely that there's something
there which needs investigating - which is what moving from UNCO to NEW
is supposed to represent.

(Having said all that, it's very rare to see a bug confirmed in this
way. So I'm not sure it's worth worrying about either way.)

Gerv

[Justin Wood (Callek)]

Gervase Markham wrote:
> The original logic of this link was that moving from UNCONFIRMED to NEW
> indicated that a bug actually existed. Those without 'canconfirm' were
> able to make such an indication by voting for the bug. If five people
> vote for a bug, it's quite likely that it actually exists.
>
> Is this logic no longer valid?

I think it is no longer valid.

We see more and more (even in SeaMonkey) people reporting bugs with
generic problems, and not answering us in order to drill down to the
problem, but having lots of "me too"'s that can actually be 30 different
problems.

Also there is the "I want Firefox to be purple" (bikeshedding) or
feature gripes that are actually better for our vast amount of users.
But still gets lots of bug hits/user finds.

I think in today's day with Mozilla the benefit of vote-to-confirm is
gone, and we have enough canconfirm users, that basically negate the
benefits of that. Both paid QA (e.g. softvision) and community.

--
~Justin Wood (Callek)

[Wayne Mery]

On 11/22/2011 5:54 AM, Gervase Markham wrote:
> On 22/11/11 08:47, Byron Jones wrote:
>> a feature of the voting system within bugzilla is the ability to
>> automatically bump a bug from UNCONFIRMED to NEW based on the number of
>> votes for the bug. This feature is enabled on bugzilla.mozilla.org, with
>> the per-product setting ranging between 1 and 10,000 votes.
>>
>> chris lawson recently pointed out that voting should not be linked with
>> triage. i think he's right.
>
> The original logic of this link was that moving from UNCONFIRMED to NEW
> indicated that a bug actually existed. Those without 'canconfirm' were
> able to make such an indication by voting for the bug. If five people
> vote for a bug, it's quite likely that it actually exists.
>
> Is this logic no longer valid?
>
> Chris argues that: "Just because more than one person thinks something
> doesn't make that thought correct." However, if more than one person
> sees a bug, it does make it a lot more likely that there's something
> there which needs investigating - which is what moving from UNCO to NEW
> is supposed to represent.

And that the bug is not a dupe ;) ... which voting doesn't take into
account. But that's a small nit.

> (Having said all that, it's very rare to see a bug confirmed in this
> way. So I'm not sure it's worth worrying about either way.)
>
> Gerv

I can't say I've seen this happen in a Thunderbird bug in recent years.
But then I don't play much in ENH bugs, where I think this is most
likely to be seen. At least that's what I recall from the
Seamonkey/suite days.

I'd think this would also be mostly likely to occur in a regression bug.

--
contribute ... http://wiki.mozilla.org/Thunderbird:Testing
evangelize ... http://www.spreadthunderbird.com/aff/165/

[Byron Jones]

Gervase Markham wrote:
> The original logic of this link was that moving from UNCONFIRMED to
> NEW indicated that a bug actually existed. Those without 'canconfirm'
> were able to make such an indication by voting for the bug. If five
> people vote for a bug, it's quite likely that it actually exists.

i don't think it's likely that a bug exists just because five people
voted for it; it just means it's popular.

> (Having said all that, it's very rare to see a bug confirmed in this
> way. So I'm not sure it's worth worrying about either way.)

it depends on the product; some products have it set to a very low
value, while most of the high-traffic products have the bar set quite
high (eg. Core is set at 10,000 votes). tech-evang was set at 3 votes,
which was low enough to trigger the automatic confirmation.

-byron

[Havvy]

I've voted for bugs without being able to reproduce them, just to get
the bugmail. As such, I am of the position that X votes for a bug
should not change its status.

[beltzner]

Without wishing to sound very despondant about the state of our bug
tracking database: in my experience, the huge backlog of UNCONFIRMED
bugs to which nobody pays a great deal of attention is a problem.
Whatever we can do to actually broaden the base of people who can help
us confirm bugs or otherwise resolve them is a great boon to our
ability to have a bug database that accurately reflects the state of
our product's development and future.

To my mind, though, the issue here is that the general Bugzilla user -
and especially the neophyte - don't understand what voting means or
implies. I think that people would be, by and large, quite surprised
to discover that 5 votes changes the status of a bug from UNCONFIRMED
to CONFIRMED. Instead, I believe that people are equating voting more
to the model used by GetSatisfaction, which is to say that they are
voting in favour of having something fixed. I see votes more often
used on enhancement requests than actual bugs.

UItimately I'm in favour of removing the 5 votes = confirmed feature
because I don't think it's being used as a triage tool, but rather a
way for people to express discontent with a lack of functionality in
the product. If there's some better way to explain how users should
use voting, then I think it makes sense to maintain the feature.

cheers,
mike

[Wes Garland]

> I've voted for bugs without being able to reproduce them, just to get the
bugmail.

Why wouldn't you just add yourself to the Cc: list? All you have to do is
press 'enter' when looking at the bug.

Wes

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

[Teoli]

On 22.11.11 16:39, Wes Garland wrote:
> Why wouldn't you just add yourself to the Cc: list? All you have to do is
> press 'enter' when looking at the bug.

As I do the same, I can give you the reason why *I* do it: because I get
a nice interface to manage all the votes I did (or if you prefer, all
the subscriptions) on bmo.

That allows me to easily keep track of bugs that I do care. ("MMmh, I
remember of an old bug about CSS tables. Don't remember the wording".
And, hop!, a quick skim through the list of my votes and I find it again).

Note that most of the time, the bugs are already confirmed when I vote
for them.
--
Jean-Yves (teoli)

[David Lawrence]

To be clear, the proposal is to just disable the part of Voting that
moves a bug from UNCONFIRMED to
NEW after passing a specified threshold to make it better for triage.
Voting in general will still be enabled
in it's current state for BMO products. So people will still be able to
vote on their favorite bugs, be notified
on bugs they have voted on, etc. as before.

dkl


--
David Lawrence
d...@mozilla.com

[L. David Baron]

On Tuesday 2011-11-22 21:56 +0800, Byron Jones wrote:

> Gervase Markham wrote:
> >The original logic of this link was that moving from UNCONFIRMED
> >to NEW indicated that a bug actually existed. Those without
> >'canconfirm' were able to make such an indication by voting for
> >the bug. If five people vote for a bug, it's quite likely that it
> >actually exists.

> i don't think it's likely that a bug exists just because five people
> voted for it; it just means it's popular.

However, if it is popular despite not being a bug, maybe that means
it's worth getting marked INVALID (etc.) sooner rather than later,
so that the 5 separate issues can be filed as 5 separate bugs, or so
that the people voting for it become aware that the behavior is
correct?

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla http://www.mozilla.org/ 𝄂

[Gervase Markham]

On 22/11/11 15:18, beltzner wrote:
> UItimately I'm in favour of removing the 5 votes = confirmed feature
> because I don't think it's being used as a triage tool, but rather a
> way for people to express discontent with a lack of functionality in
> the product.

Fair enough. I agree that when we implemented it, canconfirm was harder
to get than it is now.

But let's not bikeshed this. Guess how many bugs filed in the last 12
months have been so confirmed?

1.

https://bugzilla.mozilla.org/buglist.cgi?list_id=1752205&field0-0-0=longdesc&chfieldto=Now&query_format=advanced&chfield=[Bug%20creation]&chfieldfrom=2010-11-22&type0-0-0=substring&value0-0-0=confirmed%20by%20popular%20vote.

Gerv

[Zack Weinberg]

On 2011-11-22 7:18 AM, beltzner wrote:
>
> To my mind, though, the issue here is that the general Bugzilla user -
> and especially the neophyte - don't understand what voting means or
> implies. I think that people would be, by and large, quite surprised
> to discover that 5 votes changes the status of a bug from UNCONFIRMED
> to CONFIRMED. Instead, I believe that people are equating voting more
> to the model used by GetSatisfaction, which is to say that they are
> voting in favour of having something fixed. I see votes more often
> used on enhancement requests than actual bugs.

I was going to make exactly the same point! I pretty regularly see
comments advocating that a bug (usually an old bug that is a pain point
for web developers) be voted up "so it will get fixed".

I think it might be a good idea to disable and hide the voting feature
*entirely*, just to stop giving people this misapprehension.

Or we could start using the information the way people think we're using
it...

zw

[beltzner]

On Tue, Nov 22, 2011 at 1:23 PM, Zack Weinberg <za...@panix.com> wrote:
> Or we could start using the information the way people think we're using
> it...

Rumour has it that it was enabled mostly as a pacification mechanism
to divert "+1/metoo!" comments. Not sure that's working out as
intended. :)

cheers,
mike

[Dao]

You'll probably get more people adding advocacy comments then.

[Zack Weinberg]

As I may have mentioned in the past, I think we should allow people to
leave advocacy comments (in particular, I think the section of the
bugzilla etiquette that forbids them is a mistake). Our present habit
of trying to suppress them is yet another way in which we make it appear
that we don't want to hear from people (who think they are) outside the
inner circle.

zw

[L. David Baron]

On Tuesday 2011-11-22 13:27 -0800, Zack Weinberg wrote:
> As I may have mentioned in the past, I think we should allow people
> to leave advocacy comments (in particular, I think the section of
> the bugzilla etiquette that forbids them is a mistake). Our present
> habit of trying to suppress them is yet another way in which we make
> it appear that we don't want to hear from people (who think they
> are) outside the inner circle.

I think our bug system should let us separate different threads of
conversation within a bug. If we had that, one (or more) of the
threads could be about why the bug is important to fix. Until that
happens, though, I'd still lean towards discouraging advocacy
comments.

[beltzner]

On Tue, Nov 22, 2011 at 4:36 PM, L. David Baron <dba...@dbaron.org> wrote:
> I think our bug system should let us separate different threads of
> conversation within a bug.  If we had that, one (or more) of the
> threads could be about why the bug is important to fix.  Until that
> happens, though, I'd still lean towards discouraging advocacy
> comments.

This thread has hit what I will henceforth call "Miller's Law", which
is that all discussions of incremental updates to Bugzilla will
eventually trend towards proposals for large scale redesigns or
feature additions or replacements for Bugzilla.

I think Glob's probably got enough to move forward, and it looks like
general consensus is that since it doesn't happen that often, isn't
that well understood, and isn't used intentionally for the purpose, we
should turn the feature off.

cheers,
mike

[Nicholas Nethercote]

On Tue, Nov 22, 2011 at 7:18 AM, beltzner <mbel...@gmail.com> wrote:
> I think that people would be, by and large, quite surprised

> to discover that 5 votes changes the status of a bug from UNCONFIRMED
> to CONFIRMED.

Does the UNCONFIRMED/NEW distinction have any real meaning? E.g. do
people do searches whose results depend on those statuses?

Or is the UNCONFIRMED/NEW distinction just meant to be a signal to the
bug reporter? If so, I think it's not much use; actual action in the
bug (comments, patches) is a much stronger signal.

Nick

[Byron Jones]

beltzner wrote:
> I think Glob's probably got enough to move forward, and it looks like
> general consensus is that since it doesn't happen that often, isn't
> that well understood, and isn't used intentionally for the purpose, we
> should turn the feature off.

thanks everyone; i have disabled vote-to-confirm on all products.

-byron

[Scott Johnson]

On 11/22/2011 03:36 PM, thus spoke L. David Baron:

> I think our bug system should let us separate different threads of
> conversation within a bug. If we had that, one (or more) of the
> threads could be about why the bug is important to fix. Until that
> happens, though, I'd still lean towards discouraging advocacy

> comments. -David
I agree... is there a bug for this in the bugzilla component?