Closed Bug 1020303 Opened 8 years ago Closed 8 years ago

add gradient column to Response model

Categories

(Input Graveyard :: Submission, defect, P2)

defect

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.
Putting this in 2014q2 for now.
Whiteboard: u=dev c=feedback p=2 s=input.2014q2
Whiteboard: u=dev c=feedback p=2 s=input.2014q2 → u=user c=feedback p=2 s=input.2014q2
Summary: add gradient column to feedback_Response table → add gradient column to Response model
Bumping this to 2014q3.
Whiteboard: u=user c=feedback p=2 s=input.2014q2 → u=user c=feedback p=2 s=input.2014q3
Making this a P2. This is important to do this quarter.
Priority: -- → P2
Whiteboard: u=user c=feedback p=2 s=input.2014q3 → u=user c=feedback p=2 s=input.2014q4
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.
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.
Landed in master: https://github.com/mozilla/fjord/commit/a49f1eb914aef3e924b35a5e038f73fd8ebf41c3
Assignee: nobody → willkg
Status: NEW → ASSIGNED
Pushed to production just now.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Product: Input → Input Graveyard
You need to log in before you can comment on or make changes to this bug.