Closed Bug 48570 Opened 24 years ago Closed 5 years ago

Allow votes against a particular bugzilla bug

Categories

(Bugzilla :: Extension Ideas, enhancement, P4)

enhancement

Tracking

()

RESOLVED WONTFIX

People

(Reporter: dave532, Unassigned)

References

Details

Attachments

(1 file, 5 obsolete files)

There are many enhancement requests where not everyone may want the feature or
change being suggested. Therefore I propose that there's a way to vote against a
particular enhancement request as well as for it.

One of the examples is bug 48205 which wants to use the Classic Skin as a
default. I'm all for making the classic skin as a default and have voted for
this bug but I think it's only fair that fans of the modern skin have a fair
chance to vote against this enhancement (although I don't think many will but
that's not the point). Of course people can add their opposing views to the
comments but in the case of any more controversial changes you may often get
loads of me too's if there's no way to vote either way.
*** Bug 48681 has been marked as a duplicate of this bug. ***
I've said it once, I'll say it again, I wish I could vote against this request.
is that a wish to use this request to vote against it? and isn't that really 
admitting the need for such a thing? or are we just mincing words?
I agree that this sounds quite impractical.  If someone is against some feature,
he can tell so in the comments, as happening here.  I think that's should
suffice.  Besides, when you're against something, IMHO it wouldn't help much to
state that (by voting) without giving any substantiation.

I suggest marking this WONTFIX.
The approach that i proposed on landfill and which we eventually used here was 
to have an additional bug for each alternative, [and not used here, but should 
be] a meta bug describing the different alternatives, rules for 
discussion/decission and a dependency tree between the meta and the possible 
options.
I was joking, I think this is a good idea, but if we could have a good
alternatives system, that would be even better.

Setting up meta bugs on its own is definitely not a good alternatives system.

We could do interesting stuff, for example:

- Show this bug has 4 votes out of 10 and is ranked 2nd out of the alternatives.
- Automatically mark other alternatives WONTFIX when an alternative is marked
VERIFIED FIXED.

and probably other things too.
i think that sort of stuff would be best handled in the meta bug, it could have 
magic that automatically displays the various tallys and it should be able to 
wontfix the other bugs when a bug is selected.  The complete implementation is 
a bugzilla3 only candidate, however using a meta now is something we could do 
to get people acustomed to it...
It seems to be that a votes for and a seperate votes against wouldn't be
terribly difficult to add and would work 90% of the time.  For the other 10%
(where there's multiple possible solutions) I think the meta bug (manually)
would be acceptable.

The other alternative is to have a full-fledged poll inside the bug where you
"vote" for your favorite solution.  That, however, is a lot of extra code and
would require some implimentation/schema brainstorming.
IMO, the ability to vote AGAINST is as important as to vote FOR. bug 16489 is a
good example. A hack around it would be, insert a new request/bug in order NOT
to implement the password profile protection and vote for the latter, but sounds
incredibly insane for me.
I agree with this bug. Some enh bugs are great ideas, but others seem to me like
a mechanism to add bloat and waste developers' valuable time. The voting system
is one-sided when people cannot use it to conveniently express disagreement with
a bug, i.e. "This never bothers me, work on something more important" or "I
think this idea is stupid".
Target Milestone: --- → Bugzilla 2.18
Summary: Allow votes against a particular ernhancement request → Allow votes against a particular enhancement request
-> Bugzilla product, General component, reassigning.
Assignee: tara → justdave
Component: Bugzilla → Bugzilla-General
Product: Webtools → Bugzilla
Version: other → unspecified
*** Bug 105204 has been marked as a duplicate of this bug. ***
Blocks: 105373
*** Bug 118730 has been marked as a duplicate of this bug. ***
Could this be implemented using negative votes? We'd take the modulus when
checking if they'd exceeded the limit, but record them as negative in the votes
table and reduce the bug's vote count by that number.

Gerv
Yeah, that sounds good.

a vote of -$votestoconfirm could also resolve the bug as INVALID :)
*** Bug 176174 has been marked as a duplicate of this bug. ***
I think that + and - votes should be separately tracked because say you had 500
votes for and 501 votes against.. if they were combined, then it would show -1
vote.  However, that would mask the fact that half of 1000 people were bugged by
a bug and it should merit more consideration than say 1 person who voted for and
2 who voted against..  They may be other reasons to that I can't think of why it
would be best to track both figures seperately, but that's the first thing that
comes to mind is that the totals (instead of the average) can also be good
indicators of how many people really give a rip about a particular bug who may
not necessarily feel like posting their thoughts in a comment..  Perfect
example, there are 41 votes for this bug as of now, BUT there are far fewer than
41 comments..  A good indicator that sometimes people just agree or disagree and
don't have more to add commentwise.. so seeing both totals will give us more
information than a sliding rule average.
I would like to vote AGAINST this bug. Unfortunately, I don't seem to have the
ability to do so...
This patch requires a schema change in the votes table.
add columns 'pro' and 'con' (smallint)
This patch requires a schema change in the votes table.
add columns 'pro' and 'con' (smallint)
This patch requires a schema change in the votes table.
add columns 'pro' and 'con' (smallint)
This patch requires a schema change in the votes table.
add columns 'pro' and 'con' (smallint)
I'm a newbie at submitting patch sets.  Somebody let me know if I did wrong.

The patches require you to make a small alteration to your votes table.  In
mysql, the change looks like this:

alter table add column pro smallint default 0;
alter table add column con smallint default 0;

Theoretically, count should be larger than 2x smallint, so probably you should
also do this:

alter table chang column count mediumint default 0;

The reason this has gotten all-but-wontfixed before is because because there's a
fair number of sites out there that don't want this.  As a result, in order for
this to get accepted, it'll need to include a param to enable/disable voting in
one direction or the other.  Perhaps it can be done at the product level just
like voting is now, instead of just "number of votes per bug" it could have
"number of positive votes per bug" and "number of negative votes per bug" or
something like that.

Changes to the schema need to be made in checksetup.pl so they're done
automatically when people upgrade.

Also, it's much easier to handle the patches if you concatenate them on the end
of each other and upload as one file.  Since it looks from the diff headers like
you're using cvs to create the diffs, you can have cvs do this for you by just
listing all of the included filenames on the cvs diff command line (i.e. cvs
diff -u Bug.pm votes.cgi bugzilla.dtd).  If these are the only files you've made
changes to, you can also do "cvs -q diff -u" with no other arguments and it'll
diff the entire directory structure, producing diffs for only the files that
have changed.

This looks like a pretty good start though.  Thanks!
Then is the issue that entire sites wouldn't want to use this or that sites
would want to use this per product?  If it is sitewide, then would editing
defparams.pl be the way to go? or do you think that it should be configurable
per product and so each product in editproducts.cgi
entire sites probably wouldn't want it.  But since voting is already configured
per-product, we might as well follow suit. :)
No longer blocks: 105373
Attachment #112089 - Flags: review?
Attachment #112091 - Flags: review?
Attachment #112092 - Flags: review?
Attachment #112093 - Flags: review?
Attachment #112095 - Flags: review?
Comment on attachment 112089 [details] [diff] [review]
Adds for and against votes to Bug.pm

denying review per comment 37, call this a "needs-work" :)
Attachment #112089 - Flags: review? → review-
Comment on attachment 112091 [details] [diff] [review]
Adds for and against votes to list-for-bug.html.tmpl

denying review per comment 37, call this a "needs-work" :)
Attachment #112091 - Flags: review? → review-
Comment on attachment 112092 [details] [diff] [review]
Adds for and against votes to list-for-user.html.tmpl

denying review per comment 37, call this a "needs-work" :)
Attachment #112092 - Flags: review? → review-
Comment on attachment 112093 [details] [diff] [review]
Adds for and against votes to votes.cgi

denying review per comment 37, call this a "needs-work" :)
Attachment #112093 - Flags: review? → review-
Comment on attachment 112095 [details] [diff] [review]
Adds vote_pro and vote_con to dtd

This DTD definition is incomplete.  votes_pro and votes_con got added to the
child list for the "bug" element, but the elements themselves didn't get
declared.
Attachment #112095 - Flags: review? → review-
Preferring a particular skin is one thing, but thinking everyone else should
prefer it is another matter.

But I agree in that there are some RFEs that would do more harm than good, and
there are a few that I would vote against if I could.  I'm therefore going to
vote _for_ this RFE right now.

This raises the question: what will we do with the criteria for bug 163993 when
this is implemented?
One thing must be made clear if we put in this feature.  Comparing the numbers
of 'for' and 'against' votes would only make sense for an already open bug/RFE.
 I'm saying this because, without understanding it, someone might think "Most
people hate this feature, so why is it fixed?" or even propose to unfix it.

The answer is that, when something is fixed, people are likely to take their
votes off it in order to vote for bugs/RFEs that are still open.  The against
voters would keep their votes up for a while in protest of the change.  On the
other hand, if the resolution is WONTFIX then the against votes are going to
disappear, leaving the for votes to say, "Hey, you may not want it, but we do!"

Nother thing: what are we going to do with vote rations?  Have for and against
votes counting towards a common limit, or have separate counts for the two?
See also:

bug 114767 - Need more than 10 votes in Browser product
bug 164310 - Reason for my votes feature


<spam>"I vote for voting against bugs!"

Lol! Sorry for the spam, but I just had to say that, its too funny. Hope you
don't all hate me for it.</spam>
*** Bug 216866 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
How about a separate "Request for Alteration" severity (below RFE) for changes
which may or may not be popular? If/when an RFA was deemed popular & worthy,
severity would be changed to RFE.
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
What about adding a "maximum votes" counter? It would display the highest amount
of votes, both for and against, that were issued at a time.

Also, maybe only votes that stayed up for at least 3 days should be counted.
Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
Reassigning bugs that I'm not actively working on to the default component owner
in order to try to make some sanity out of my personal buglist.  This doesn't
mean the bug isn't being dealt with, just that I'm not the one doing it.  If you
are dealing with this bug, please assign it to yourself.
Assignee: justdave → general
QA Contact: mattyt-bugzilla → default-qa
No longer blocks: majorbugs
I for one would like to be able to vote down bugs at any severity, can the
summary please be changed to reflect that (that it's not just for enhancement
requests).
(In reply to comment #14)
> Could this be implemented using negative votes? 
>... Gerv

See my comments in bug 260494

Interesting the very large number of votes for this bug, with only two comments
against.  Likewise ironic there is no way for "the many sites" that don't want
it (as justdave says 2 years ago in comment 25) to vote against it.  

Anyway, it would be helpful to know their specific reasons to be so passionately
against this bug (and perhaps the quantity of naysayers). As I explain in bug
260494, it is important that negative voters state their reasons (as first
suggested in comment 4 and echoed by others). It allows a bug to be more quickly
improved or otherwise dispensed with.

For those new on the scene, we have, in increasing order of sophistication:
1. vote against a bug by voting FOR a competing bug, plus use of meta bugs - our
status quo
2. vote for or against a bug within the same bug - this bug*
3. vote for or against a bug using a range - bug 260494*
* plus the possibility of comments attached to the vote - bug 164310
(In reply to comment #41)
> I for one would like to be able to vote down bugs at any severity, can the
> summary please be changed to reflect that (that it's not just for enhancement
> requests).

The bug summary doesn't request it, but the minused patches don't look like they
restrict negative votes to enhancement requests.
>I for one would like to be able to vote down bugs at any severity

Good point.  That's what everybody was thinking anyway.  The wording can be tricker than expected. :)

Updating summary:
WAS: Allow votes against a particular enhancement request
NOW: Allow votes against a particular Bugzilla bug
Summary: Allow votes against a particular enhancement request → Allow votes against a particular bugzilla bug
Definitely voting FOR.
comment#4: "If someone is against some feature, he can tell so in the comments,
as happening here."
Loses any sense with 50+ comments. Nobody's going to count "for/against"
comments while deciding whether to implement a feature or not.
As for resolutions guidelines: In case of, say, less than 1/3 advantage of one
side, and lots of votes on both sides, resolve as "wontfix; should be an
extension". If there's above 1/3 more "against" than "for", just "wontfix", and
in opposite case, recommend fixing.
(In reply to comment #45)

> As for resolutions guidelines: In case of, say, less than 1/3 advantage of one
> side, and lots of votes on both sides, resolve as "wontfix; should be an
> extension". If there's above 1/3 more "against" than "for", just "wontfix", and
> in opposite case, recommend fixing.

I disagree with this conclusion.  A more subtle and I suspect less understood
part of voting against doesn't (or shouldn't) lend itself to who has more votes,
because a vote against can be much more than merely "I don't like this idea". It
could 
* be against the suggested implementation, but not the goal of the bug
* indicate a real financial impact 
* indicate developement resources are better put to some other bug(s)

Many of these things should be debated with the goal of constructing a solution
that everyone can live with.

Also, if votes against are allowed, a numeric scale would be much more helpful
than a simple "no" vote, because not all "nos" are alike.  ref: bug 260494 comment 1

Re: comments - most votes shouldn't require comments which are simply "I like"
and "me too". KIS.
(AGAINST): I don't think this is a good idea.


One doesn't usually vote against a bug (I would vote agains all bugs... it would be very nice have all of them gone).

Voting against a bugreport seems then irrational to me unless you want to convince other that the bug doesn't exist.


Voting against a wishlist is nice but i still prefer discussion to voting. Not all people enjoy going from bug to bug and voting for or against. I believe most visit the reports they found interesting.

It can never be fair to vote for/agains among the people who watch the report.

I actually vote 1 for many reports just to keep track of those that interest me. And the only thing I tell others is that the bugreport deserves attention. Not that I agree with THE proposed solution. (Actually there can be five proposed solutions and it still is one bugreport!)


-----------------------------------


Not to only criticize... because many ideas are themselves very good.

I think that allowing the reporter (or the others) to add a sort of enquette to the bugreport.

Let the people VOTE FOR SOLUTIONS separately from marking the bug is WORTH DISCUSSION.

This would work both for YES/NO questions and for CHOOSE AMONG ALTERNATIVES. And it would be added only to bugreports for which it is relevant.


-----------------------------------


I know this does not solve everything.

E.g. the fact that developers will sometimes prefer the easier way from the most popular one.

I am open to new comments.

(I am voting for this bug because it's an iteresting issue. Not because I like a particular solution.)

Cheers,
Pavel
The trunk is now frozen to prepare Bugzilla 2.22. Only bug fixes are accepted, no enhancement bugs. As this bug has a pretty low activity (especially from the assignee), it's retargetted to ---. If you want to work on it and you think you can have it fixed for 2.24, please retarget it accordingly (to 2.24).
Target Milestone: Bugzilla 2.22 → ---
There is another interpretation to Vote for this bug:
Since a bug report can contain many different views about how to approach a given problem, or even whether there is a problem, it's pretty clear that voting for a bug is strictly an expression of interest in the bug, without an expression of which viewpoint is sided with.  The person may not even know.

Sometimes, as with this bug, I would simply like to emailed when there are changes, and it is my way of saying that this bug holds more importance for me than others and I would simply like it to be resolved.

my vote: ABSTAIN
Csaba Gabor from Vienna
jeremy asked: can we make votes on resolved bugs not count towards allowance? (this is a separate bug, but the discussion mainly revolved around voting against it, hence it's on topic.)

i said we could, but that'd be problematic. i'd rather the post login screen to list all the bugs that are resolved for which i've voted; so i can choose to free them (perhaps only first login after they're resolved).

The reason not to implement what he suggested is simple: what if a bug has 100 votes. and i decide i don't like it having 100 votes, so i resolve it as worksforme, and then reopen it - now it has 0 votes :). maybe i resolve it as a duplicate instead, either way.

If i could do that w/o getting too many objections, i'd use that feature to whipe out votes on a couple of bugs :).

don't give me that feature :)

:(

I suppose I voted against the vote against feature, and now I can't vote against the automatic vote removal feature. maybe i can use the automatic vote removal feature to remove my vote against the vote against feature.

because after all, that bug's resolved :) [editor's note, the bug isn't resolved, but hypothetically it was, and hypotheticall i voted against implementing it.]

jeremy responded: i'm not saying do it automatically, i'm saying don't count it against the vote quota.

consider the vote against feature. let's say 100 people vote for vote against,
and we resolve it as wontfix. now people say "hey, there are 100 votes for that bug". 

if people can vote for an infinite number of wontfix bugs, then they can politic in more bugs -- that's cheating :)

jeremy agreed that could be a problem and chose to vote for allowing vote against.

note, this is a rewrite of an irc conversation. i think i always remembered myself as voting against this bug, where the history shows that in fact i just poked fun at someone else voting against voting against (comment 3).
Blocks: voteoverhaul
*** Bug 361897 has been marked as a duplicate of this bug. ***
I would like to vote against my vote for voting against bugs. To further show my support for my lack of support for my support of not supporting bugs, I'm voting for my vote against my vote for voting against bugs.
Are we debating on whether bugzilla as an app should have a vote against feature, or are we debating on whether Mozilla's bugzilla implementation have vote against?

I think it's unnecessary in the latter case. All votes ever do is get a bug higher on the radar.  Ideas get implemented or not based on their merits and if user data is being weighed it's something a bit more concrete than bugzilla votes.

However, in the case of a smaller team working on another project, they might very well find it useful to ask everyone to vote on contentious bug x to see where their team sits on the issue.  This would of course turn the implementation into a poll rather than voting for a candidate.
(In reply to comment #53)
> This would of course turn the
> implementation into a poll rather than voting for a candidate.

Bug 360810 is aimed at doing just that. :)
Priority: P3 → P4
Currently, clicking "(vote)" above a bug's CC list brings up the current user's list of votes, with the current bug highlighted (usually near the top of the screen) and, somewhere lower, "nn votes out of mmmm allowed" for this product.

This way of doing it has the following advantage: for products where the "maximum allowed" number of votes is very small (e.g. 10 for Toolkit or Tech Evangelism, 50 for mozilla.org, even just 5 for NSPR, rather than the more usual 1000 or 10000 typical of more "common" Products), the user can see how close he is to that maximum, and possibly remove votes for bugs which are RESOLVED and will probably remain so, at the same time as he adds a vote for the new bug.

I believe that this advantage is important enough to balance the trouble of having to click once on "(vote)", a second time to check the box next to the bug's line in the list of votes, a third time on "Change My Votes", and possibly a fourth time in the "back" drop-down to get back to the bug itself. I'd prefer to have this bug WONTFIXed than to have it FIXED, if "fixing" it means losing the "nn of mmmm" warning and the possibility to remove a few no-more-needed votes if we're close to the (sometimes very small) maximum.
Oops, wrong bug. I am "for" the idea of voting against but my comment #55 was meant for a different bug. Please ignore it.
(In reply to comment #53)
> Are we debating on whether bugzilla as an app should have a vote against
> feature, or are we debating on whether Mozilla's bugzilla implementation have
> vote against?
> 
> I think it's unnecessary in the latter case. All votes ever do is get a bug
> higher on the radar.  Ideas get implemented or not based on their merits and if
> user data is being weighed it's something a bit more concrete than bugzilla
> votes.
> 
> However, in the case of a smaller team working on another project, they might
> very well find it useful to ask everyone to vote on contentious bug x to see
> where their team sits on the issue.  This would of course turn the
> implementation into a poll rather than voting for a candidate.
> 

(In reply to comment #54)
> (In reply to comment #53)
> > This would of course turn the
> > implementation into a poll rather than voting for a candidate.
> 
> Bug 360810 is aimed at doing just that. :)
> 

Bug 360810 is now duped to bug 372979 which is about allowing Bugzilla to be installed with no voting system whatsoever. This is something else.

Currently, users can vote in favour of a bug, saying "I _really_ want this bug to get fixed". When it is obviously a bug, for instance a crash or a hang, no one in his right mind will be against. But what about "enhancements"? What someone else views as an enhancement, I might view, if implemented, as a regression (it worked before, the way I wanted it, and now it doesn't). Of course, once a so-called enhancement has been implemented, any bug filed to get it removed will be closed WONTFIX, no matter how many people prefer it the way it was before. There have been cases recently such as (for instance) the one-sided decision to remove the throbber link. There may be some more recent examples in the Fx2 to Fx3 change but I haven't yet investigated the matter deeply enough.

The proposed sytem to "vote against" (thus replacing the present {0, 1} set of possible votes by one user for one bug by {-1, 0, 1}) would allow devs to see the difference, _before_ writing the patch, between a real enhancement which much more people want than don't, and a "controversial change" with many people for it and many people against it. At the moment, all indicators -- votes, dupes, etc. -- show who "want" the so-called enhancement. Only the module owner may put his foot down and declare it WONTFIX, but, at the "enhancement" level where it isn't always obvious whether the proposed change is better than the status quo, he often hasn't much upon what to base such a decision.

You will retort: «The people active at Bugzilla are not statistically representative of the userbase of a product like Firefox.» Maybe they are, maybe they aren't; but my feeling is that there are a lot of people out there testing trunk nightlies, branch nightlies, beta releases, release-candidates, what have you, using them in "real life" conditions, and I believe they are statistically closer to the user base than are the devs. I also think some of those testers at least, have found out how to use Bugzilla as an early-warning system, and might sometimes, if it were possible, want to vote against a proposed "enhancement" before it were too late to report it as a "regression".
not that it matters, but Bugzilla theoretically supports spending more than one vote per bug, it's just rarely used in practice, so it's not really {0,1}, it's [0-n], and the proposal is [{-n}-{n}].

The reason that feature exists is so that in a constrained voting system, people can prioritize their votes. However @bmo, we've taken the approach of diluting votes so that they can be assigned to as many bugs w/o people whining that they can't vote for a bug because they ran out of votes.
Thinking back on it, I suppose there are two issues here:
1) Bugzilla product: allow vote-against. I believe they should be tallied separately from the fotes-in-favour at the top of the concerned bug, not algebraically summed. Maxvotes would, I suppose, limit the _sum_ of votes-for and votes-against (sum of absolute values).
2) bugzilla.mozilla.org: implement the feature on the site (once the software has it, thus dependent on step 1)

In reply to comment #58:
Yes, I've seen more than one votes allowed per bug, but not at BMO, where it isn't a count but a checkbox.
At BMO, running out of votes is still possible, but not on every product: from my voting page: mozilla.org 18 out of 50, NSPR 1 out of 25, but Other Apps 4 out of 10000. Of course, setting the maxima is the mozilla admins' responsibility, and users just have to cope with that (with or without grumbling or whining) -- you don't fight City Hall but you can petition the mayor.
Damn! i cant vote against this. Sadly my views on why it should not be instigated have already been said and i am simply opposed to the feature now, however i cant vote against it.
why the bug has status "new", why it is still not "assigned"?
(In reply to comment #61)
> why the bug has status "new", why it is still not "assigned"?

Well, apparently no one seems willing to work at getting it implemented. Are you? Will you invest your own time in producing and unbitrotting patches, and having them reviewed, superreviewed, approved if necessary, checked in, and (if necessary) side-effect regressions fixed? I don't have the coding ability.

No need to answer if the answer is "no".
it's easy as hell: add the "-" button to the current "vote" button, clicking on which will simply decrease the number of votes by 1.
> it's easy as hell: add the "-" button to the current "vote" button,
> clicking on which will simply decrease the number of votes by 1.

First, that's not what this bug is about.  For and against votes will not cancel themselves out in the manner you suggest.  There will be separate for and against counts.  If you want what you suggest, you should file a different bug.

Second, if it's so easy to implement we can happily assign ownership of this bug to you so that you can fix it yourself...
(In reply to comment #64)
> > it's easy as hell: add the "-" button to the current "vote" button,
> > clicking on which will simply decrease the number of votes by 1.
> 
> First, that's not what this bug is about.  For and against votes will not
> cancel themselves out in the manner you suggest.  There will be separate for
> and against counts.  If you want what you suggest, you should file a different
> bug.
> 
> Second, if it's so easy to implement we can happily assign ownership of this
> bug to you so that you can fix it yourself...

I don't get: do you like or not the way I suggested? it's not a problem to implement this.
actually I haven't read the 60+ comments to this bug track, but I thought you were talking about just adding negative votes.
> actually I haven't read the 60+ comments to this bug track

Maybe you should do that (and review the currently proposed patches that are attached here) before making comments.
Blocks: 658926
Assignee: general → LpSolit
Component: Bugzilla-General → Creating/Changing Bugs
Target Milestone: --- → Bugzilla 5.0
We are going to branch for Bugzilla 4.4 next week and this bug is too invasive or too risky to be accepted for 4.4 at this point. The target milestone is set to 5.0 which is our next major release.

I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else on time for 5.0.
Target Milestone: Bugzilla 4.4 → Bugzilla 5.0
Blocks: 260494
Assignee: LpSolit → create-and-change
Target Milestone: Bugzilla 5.0 → ---
Attached patch WIP, v0.5Splinter Review
Here is the patch I was working on 1.5 year ago. The patch is not complete, but I think it's a good start if someone wants to finish it.

Here is what's left to be done before the patch is ready for review:

- when votes are turned off in a product, notify voters who have votes in this product (one email per voter should be enough; no need for one email per bug);
- make sure email notifications still work correctly with the new voting system;
- sanitycheck.cgi only needs to check that products with votes turned off have no votes in their bugs.
Attachment #112089 - Attachment is obsolete: true
Attachment #112091 - Attachment is obsolete: true
Attachment #112092 - Attachment is obsolete: true
Attachment #112093 - Attachment is obsolete: true
Attachment #112095 - Attachment is obsolete: true
As voting has since been made an extension, this would be better suited as either it's own extension or as an update to the Voting extension itself.
Assignee: create-and-change → extension.ideas
Component: Creating/Changing Bugs → Extension Ideas

The voting functionality will be replaced with emoji comment reactions in the near future.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.