307530 - Bug sets and their collective votes: tying similar bugs and enhancements, and their votes, together, formally

Status: RESOLVED WORKSFORME

(Bugzilla :: Bugzilla-General, enhancement)

Description

[Gordie Grout]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

Please note:
I am not a bugzillaholic, nor do I play one on TV.  :-)  I did do a bug search,
but I have not looked into all the features of bugzilla nor have I ever
administered a bugzilla site/database for a product.  My point is: there may
already be an architected way to do what I propose, or its equivalent; please
forgive me if there is, and keep up the good work!

Scenario:
* A bug or suboptimal behavior in a product prompts many people to report the
bug or submit enhancement requests to improve the behavior/usability/whatever
* Some see it as a bug, some as an enhancement, so it is reported as both
* There are several ideas submitted as enhancement requests, each somewhat
different but meant to address the specific suboptimality
* The same thing about the product "bugs" (enhances? :-) me, so I log on to the
product's bugzilla and do a bug search.  I see several, one-by-one, that address
the suboptimality in one way or another, though likely I don't see them all
since terms used and the choice of words in the report's titles may be different.

Problem:
I must choose which from the incomplete list of similar reports to vote for;
however, I find myself thinking that I'd really just like the thing FIXED,
regardless of which way it is fixed.  Do I vote for the enhancement/fix idea I
think is truly best, or do I vote for the one with the most votes so far, so
that it gets attention?  Even if I do, this suboptimality may not get as many
votes on a PER-REPORT BASIS as some other suboptimality that only is reported
once, because in that case, voters have only one to choose from and the votes
can pile up.

Solution:
Administrators and developers who know the product and read the bug reports
could be given an architected way of creating a "bug set" (I'd call it a bug
group, but that term already has a different meaning) that is composed of all
bug/enhancement reports logged to address the single suboptimality that all
reporters are annoyed with.  When considering what work on the product to
prioritize, treat the bug set's collection of votes -- i.e. all its members'
votes added up -- as one, as if it were for one bug.  Perhaps even let folks
cast votes for the bug set instead of an individual in the set as a way of
saying "just fix it, I don't care how".  But even without the vote-for-a-set
mechanism, allowing the formal tying together of bug reports into a set can have
benefits.  Searches can reveal not only individual bug reports, but also bug
sets, and sets can be enumerated so inquiring minds like mine will see the
"complete" list and not miss some whose titles may have been chosen poorly or
just differently.

Reproducible: Always

Steps to Reproduce:
1. N/A, or, kinda, described in the Details section above
2.
3.

Actual Results:  
see Details

Expected Results:  
see Details

Comment 1

[Frédéric Buclin]

Having bugs "grouped" together is already suggested in the old bug 12286. Now
about votes, I don't think this feature is important enough to worth it. But if
we ever implement it, bug 12286 should be fixed first. And then, I think you
should still vote for a given bug, but all related bugs should see their votes
cumulated when querying per related bugs or something like that.

Comment 2

[Max Kanat-Alexander]

Yeah, there are a couple of ways of doing this.

First, if you have multiple bugs that all point to the exact same issue, they
should be duplicated to each other. Whether the resultant bug is a bug or an
enhancement is up to the developers.

If you want to group bugs in some way more specific than components, you can use
what we call "meta-bugs." Just file a bug called something like, "Perform Big
Task" and then file a lot of blockers to that bug, "Small Task #1," "Small Task
#2," etc.