All users were logged out of Bugzilla on October 13th, 2018

Clicking on "Issues" link on an individual Site results in missed

VERIFIED FIXED in 1.7

Status

P2
normal
VERIFIED FIXED
8 years ago
7 years ago

People

(Reporter: aakashd, Assigned: wenzel)

Tracking

Details

(URL)

(Reporter)

Description

8 years ago
Steps to Reproduce:
1. Got to http://input.stage.mozilla.com/en-US/sites
2. Click on the "52% Issues" link under Facebook.com 

Actual Results:
The resulting page shows the actual percentage of praise and issues as well as the clusters/themes/topics associated with them

Expected Results:
The resulting page should only show the skewed vresino of praise (0%) and issues (100%) as well as the clusters/themes/topics associated with them
(Assignee)

Comment 1

8 years ago
Are you sure? Wfm. Perhaps you hit an intermediary state while the app was updating or something :-/
Comment 0 results in http://input.stage.mozilla.com/en-US/sites?q=http%3A%2F%2Ffacebook.com&sentiment=sad for me, which shows "
    364 messages
    62% praise
    38% issues"
(Assignee)

Comment 3

8 years ago
Oh. That changed a minute ago, I can now reproduce. A bug, indeed.
Oh, indeed it did; I can too.
(Assignee)

Comment 5

8 years ago
I found the error, I think.

First of all, the data shown should be accurate, with the exception of the percentages.

The percentages are calculated from the fields issues / praise and size. Michael: It seems that when a given cluster is for, for example, issues only, then the issues count is accurate and so is the size, but the praise count is completely bogus. Only when the cluster is for both issues and praise, then both counts are correct (and their sum equals "size").

Should be a one-line fix: When generating clusters for issues / praise only, then please set the respective other count to 0.
(Assignee)

Updated

8 years ago
Assignee: nobody → mkurze
Okay, actually the fields praise_count and issues_count are intended to help display the overall percentages no matter what you are looking at.

They should be the same for a given URLxVersion no matter the value of the positive field. That is intentional, as the percentages that should be shown here are the same, no matter what you are currently looking at:

Example:
You are looking at http://youtube.com (last 7 days) in "both" mode. It says "67% happy", "33% sad". When you switch to "sad" as a user, you don't expect these numbers to change, because the number of positive comments for youtube in the last 7 days did not actually change, you are just filtering them out. It would be weird, if there was a link saying "0 %" (= zero comments), and when you click on it, a bunch of comments show up.

To display that correctly, divide by the sum of praise+issues, not by the size (which is the number of comments that actually match).
If it is really desired for the percentages to change as you click on them however, I can of course change that in the clustering process.
Assignee: mkurze → fwenzel
(Assignee)

Comment 8

8 years ago
Ah! Well I let Aakash decide then. We could also remove the percentages altogether if the shown cluster is all-positive or all-negative. After all, the numbers to be shown there are trivial.

Please don't change them in the clustering process then. It makes sense to have the data around like this, and depending on the decision, I can just show the overall percentages, or 100 / 0 or nothing. Aakash?
(Reporter)

Comment 9

8 years ago
I think it's pointless to show the percentages when they're 0% and 100% at that point. There's two options for the user to go back to the regular setting:

1. browser back button
2. "All" button on the lhs control snippet

Let's just hide them when a user is looking at only "praise" and "issues", while showing them when a user is looking at "All"
(Assignee)

Comment 10

8 years ago
http://github.com/fwenzel/reporter/commit/8c7f69a
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Component: Input → General
Product: Webtools → Input
You need to log in before you can comment on or make changes to this bug.