Closed
Bug 375809
Opened 17 years ago
Closed 17 years ago
Rates were not updated accordingly to rating scale modification
Categories
(addons.mozilla.org Graveyard :: Public Pages, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
3.1
People
(Reporter: xavier, Assigned: clouserw)
Details
Attachments
(1 file)
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•17 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•17 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
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
Comment 3•17 years ago
|
||
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
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
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•17 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...
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 :-)
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•17 years ago
|
Assignee: nobody → clouserw
Assignee | ||
Comment 10•17 years ago
|
||
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 11•17 years ago
|
||
Comment on attachment 267164 [details]
fix ratings
downloading--
Attachment #267164 -
Attachment mime type: application/x-php → text/plain
Updated•17 years ago
|
Attachment #267164 -
Flags: review?(shaver) → review+
Assignee | ||
Comment 12•17 years ago
|
||
Script is in SVN, r4338. It should be run by IT at our next update.
Assignee | ||
Comment 13•17 years ago
|
||
bug 383648 resolved this.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Updated•8 years ago
|
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•