Closed
Bug 1020303
Opened 10 years ago
Closed 10 years ago
add gradient column to Response model
Categories
(Input Graveyard :: Submission, defect, P2)
Input Graveyard
Submission
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: willkg, Assigned: willkg)
References
Details
(Whiteboard: u=user c=feedback p=2 s=input.2014q4)
We want to switch from happy/sad to a 1-5 gradient rating. First thing we need to do is add a new field to the Response model. This new field should be an integer ranging from 1-5 inclusive. Further, on save: If there's a happy/sad and a 1-5, then we'll save both to the db. If there's a happy/sad, but no 1-5, then we'll save happy=2 and sad=4 (i.e. not the extremes). If there's a 1-5 but no happy/sad, then we'll save 1-2=happy, 3-5=sad. We should also add tests for the above to make sure it's correct. One thing I'm not sure about is whether we want to log that we coalesced the values somewhere so we know which values were coalesced. E.g. if the feedback has happy/sad and we generated the gradient from that.
Assignee | ||
Comment 1•10 years ago
|
||
Putting this in 2014q2 for now.
Whiteboard: u=dev c=feedback p=2 s=input.2014q2
Assignee | ||
Updated•10 years ago
|
Whiteboard: u=dev c=feedback p=2 s=input.2014q2 → u=user c=feedback p=2 s=input.2014q2
Assignee | ||
Updated•10 years ago
|
Summary: add gradient column to feedback_Response table → add gradient column to Response model
Assignee | ||
Comment 2•10 years ago
|
||
Bumping this to 2014q3.
Whiteboard: u=user c=feedback p=2 s=input.2014q2 → u=user c=feedback p=2 s=input.2014q3
Assignee | ||
Comment 3•10 years ago
|
||
Making this a P2. This is important to do this quarter.
Priority: -- → P2
Assignee | ||
Updated•10 years ago
|
Whiteboard: u=user c=feedback p=2 s=input.2014q3 → u=user c=feedback p=2 s=input.2014q4
Assignee | ||
Comment 4•10 years ago
|
||
I'm changing my mind on how this should get implemented. We should do this: 1. add a new integer field to the Response model (and thus the feedback_response table) 2. on save: 2.1. if there's a gradient, but no happy/sad, generate the happy/sad 1-2=happy, 3-5=sad. 3. add tests to make sure all of the above works The difference here is two fold. First, I put it in an itemized lists. Lists ftw. Second, I ditched the "if there's a happy/sad, create the equivalent gradient". Why? Because this first stage is A/B testing where we need to understand the relationship between happy/sad and gradients and in order to do that, we need to know whether the user saw an A or a B and this lets us do that trivially. We can change how this works later once we're past the A/B phase.
Assignee | ||
Comment 5•10 years ago
|
||
Oops... I somehow inverted the numbers. 1 ................. 5 very sad very happy Thus the gradient -> happy/sad is 1,2,3=sad 4,5=happy.
Assignee | ||
Comment 6•10 years ago
|
||
In a PR: https://github.com/mozilla/fjord/pull/363
Assignee | ||
Comment 7•10 years ago
|
||
Landed in master: https://github.com/mozilla/fjord/commit/a49f1eb914aef3e924b35a5e038f73fd8ebf41c3
Assignee: nobody → willkg
Status: NEW → ASSIGNED
Assignee | ||
Comment 8•10 years ago
|
||
Pushed to production just now.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Updated•7 years ago
|
Product: Input → Input Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•