Rates were not updated accordingly to rating scale modification

RESOLVED FIXED in 3.1

Status

addons.mozilla.org Graveyard
Public Pages
RESOLVED FIXED
11 years ago
2 years ago

People

(Reporter: Xavier, Assigned: clouserw)

Tracking

Details

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3 XPCOMViewer/0.9.5
Build Identifier: 

With the new version of the add-ons website, rating scale is now 0-10.
It used to be 0-5, so rates should have been doubled when the site was upgraded.
An add-on with the excellent rate of 5/5 is now just at the average rate of 5/10 !

Reproducible: Always

Steps to Reproduce:
1. login as developper
2. check the rate of your add-on
3.
Actual Results:  
the rate has the same value it had before the site upgrade

Expected Results:  
the rate should be twice as much to reflect the new rate scale

Updated

11 years ago
Component: Developer Pages → Public Pages
OS: Windows XP → All
QA Contact: developers → web-ui
Hardware: PC → All
Version: unspecified → 3.0

Comment 1

11 years ago
I think this should be fixed, it makes sorting by rating misleading and as a result less useful.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 2

11 years ago
As I mentioned when I created the entry, the bug is on developper pages, since the public pages no longer show the average rate... which is a different bug.
Component: Public Pages → Developer Pages
All review/rating bugs should be in Public Pages - Developer Pages have nothing to do with them except displaying the rating in one spot.
Component: Developer Pages → Public Pages
(Reporter)

Comment 4

11 years ago
Wherever they should be displayed, they should be fixed.

As long as they remain wrong, better not display them on public pages, that would harm a lot of extensions... that are already seriously impacted by twice as few downloads per week since Remora is out.

But still, on public pages, sorting by rate is now misleading as Adam noticed.
Ratings weren't imported, so I don't know exactly what you mean by doubling.  If the developer page shows a 0-5 rating, that's a bug we should fix, but I don't *think* that the problem is what you describe.  A patch for this would be welcome, but we should make it all consistent soon, IMO.
Target Milestone: --- → 3.1
(Reporter)

Comment 6

11 years ago
Well it sure looks like ratings were imported:
One of my extensions had a 4/5 rate before Remora.
It now still has a 4 rate, while the only one review (in all languages. Having to browse each language to get all the reviews is also a problem) has a rate of 10.

Another extension of mine has a 4.14 rate which is very close to what it had before remora, while the only reviews give 10, 4 and 8 : that should be an average of about 7

Another one has 4.48 also with 10, 8 and 4 (!), and I do not remember the rate before remora, but it was between 4 and 5 for sure, I'm positive about that.

So even if the global rates were on a 5 scale, while the reviews were on a 10 scale, what I see would still be wrong...

That's why I supposed rates where imported incorrectly, that's the closest match  (could even be exact match) I could find.

Thanks a lot for your attention.

(Assignee)

Comment 7

11 years ago
I was under the impression we weren't importing ratings either, but http://wiki.mozilla.org/Update:Remora_Database_Migration#main_to_addons.2C_translations says we were, and the migration.py script looks like it copies Rating directly to averagerating in the mainToAddOns section.

So...I think ratings were imported as well, in which case we should run something along the lines of "update column=column*2".  Of course, then we have the issue of all the ratings since the migration...
(Reporter)

Comment 8

11 years ago
Unless I'm mistaken, only the average rate was imported, not each individual rate from before Remora.

The formula should then be 
averagerating = ((averagerating * (number of new reviews + 1)) - sum of new reviews rates) * 2 + sum of new reviews rates ) / (number of new reviews + 1)

or close :-)



(Reporter)

Comment 9

11 years ago
just an after thought : I assumed we do not know how many reviews where given before Remora.
Therefore, my formula gives the previous average rate the same weight as a new review... which is rather unfair. But still much better than the current average rate.
And another after thought : until this bug is fixed, it gives a really nasty advantage to new extensions that were submitted after Remora was out, since these do not suffer from a faulty 'half' rate...

wait a minute... If my extension with a previous average rate of 4, migrated as 4 instead of 8, now has a new review with 10, how can the new average still be 4 ??
Should be 7... (instead of 9)...

I guess there might be an extra bug in the way average rates are computed...

Sorry if all this bothers you, but for us, add-ons developers, it's a bit frustrating to see our efforts and the appreciation of our users kind of 'wasted' because of these bugs... (this on top of bug #377769 that is really making our lives more difficult).

Thanks a lot for your attention.
(Assignee)

Updated

11 years ago
Assignee: nobody → clouserw
(Assignee)

Comment 10

11 years ago
Created attachment 267164 [details]
fix ratings

This script:

* Sets all add-ons to have a 0 rating
* Recalculates add-ons averagerating off of current review numbers

When finished, 1131 add-ons have a >0 rating.
Attachment #267164 - Flags: review?(shaver)
Comment on attachment 267164 [details]
fix ratings

downloading--
Attachment #267164 - Attachment mime type: application/x-php → text/plain
Attachment #267164 - Flags: review?(shaver) → review+
(Assignee)

Comment 12

11 years ago
Script is in SVN, r4338.  It should be run by IT at our next update.
(Assignee)

Comment 13

11 years ago
bug 383648 resolved this.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.