So rn users can give feedback on listens page, have you seen that?
ruaok
_lucifer: iliekcomputers alastairp Mr_Monkey : my calendar suggests that Nov 21/22 would be a good day for a hack weekend. does that work for you?
alastairp
pristine___: I have
Mr_Monkey
Nothing on my plate for that date
d4rkie has quit
alastairp
nothing for me either
sounds good
Nyanko-sensei joined the channel
shivam-kapila
Help me with good playlists ;)
pristine___
alastairp: nice. So there is a schema, `recording_feedback`, where user feedback is stored. Now we want to have user feedback on recs page too (like/dislike the recommended *recording*). There are two options, save the rec feedback in recording_feedback (same table where feedback of listens page is stored) but I don't really feel good about it. I prefer the second option, which is to have a separate schema
recommendation_feedback. I mean when a user gives feedback on rec page, back in the mind they know that this feedback is for recommendations, when they give feedback for listens back in the mind they know that this feedback is for listens, so I think we should have two separate schema. Can you me some arguments to accept/discard my reasoning? Just wanted to have a discussion on this before I move forward.
alastairp
pristine___: interestingly, Mr_Monkey and ruaok and I just had a bit of a discussion about this exact topic this morning
pristine___
Nice. Can you share with me the key points?
Or is there a doc?
alastairp
I like the idea of keeping it separate. What metadata do you have available?
we don't really have much design other than "hey, we should save a bunch of feedback from various things"
alastairp: should we assume that if a user dislikes a recording on listens page, the user doesn't want that recording in recs too?
I mean data of recording_feedback is *very* useful for recs.
alastairp
pristine___: right, this is the core question that we were asking this morning
pristine___
I am stuck at have a different schema for rec_feedback but also use data from recording_feedback? Doing both of them together doesn't make sense to me though
alastairp
give me a link to the recording feedback table?
shivam-kapila
pristine___: can I ask a question?
alastairp
do recommendations have a recording mbid? or a msid, or something else? Are they just textual metadata?
alastairp: we send recommended recording mbids from spark and then do a look up to get artist name, track name etc, any data we want can be shipped from spark, not an issue
shivam-kapila
Because the above point is something that doesnt sound concrete
pristine___
> What is your motivation behind a separate schema
I just wrote that in a message to alastairp . Can you scroll and read?
The first big message.
shivam-kapila
I read that
Just to keep it separate that user liked a rec / listen?
ruaok and I are talking it over in person, give us 5-10 minuts
pristine___
Cool! Ping me later. I am here :)
> Can you me some arguments to accept/discard my reasoning? Just wanted to have a discussion on this before I move forward.
Yeah shivam-kapila . The point is not concrete, maybe. I just want a discussion on this. Not saying I just want to have a diff schema :)
niceplaces has quit
I am just having contradicting thoughts :p
shivam-kapila
I see
I have a few points. Hopefully useful
niceplace joined the channel
pristine___
shivam-kapila: yup. Go on?
shivam-kapila
To me both the feedback are quite linked
1. When we like a listen, we like a track and not a listen. Similarly if I like a rec, I actually like the track in the end
2. If I like a track, I would like to see it affect my recs
3. If I like a rec, it ideally will reflect in my listen hiastory too
4. If I had liked some tracks and those pop in my recs, they should be marked loved, that helps user see, "ah I like that track, good recommendation"
5. In the end we should present user "your liked tracks". which should essentially encapsulate both my likes from recs and listens
pristine___
4 and 5 is a diff feature all together, though I agree with 1, 2 and 3
shivam-kapila
6. I see you want users to mark how they like the recommenadation, but if you see as a user and provide those buttons, he will see them as a feedback for track, in view of consistency
conflicting user experinces are never goof
good*
Hopefully I framed my thoughts presentably.
pristine___
Yeah. You have a bunch of useful thoughts.
❤
alastairp
ok, we're back
ruaok
alastairp: will come with interesting stuff.
shivam-kapila
Both of them are directly linked to my listening habits, and I feed they share a base
shivam-kapila now puts the pen down
alastairp
we decided that first of all it'd be nice to have a table that directly references recording mbids
so for that reason, making a new table is a good idea
pristine___
Right!
alastairp
we also talked about the score field
we decided that being a bit more explicit might be good, so we're recommending an enum instead of an integer
with the values "I like this", "I really like this", "I don't like this", "I never want to hear this again", and "this is a bad recommendation"
if we come up with more types of feedback, we can just alter the enum to add them
ruaok
or we feel that we wish to express the values in different ways, we can do that too.
pristine___
Integers are easier to interpret and process I guess
alastairp
I don't think so
and there are plenty of ways of converting enums to integers if we really need it
the issue with the current `score` field is that other than 1 and -1, we don't really know what any other value means
pristine___
> the issue with the current `score` field is that other than 1 and -1, we don't really know what any other value means
I agree here.
alastairp: cool! I will write a schema on the basis of above points.
alastairp
great. send me an example of it when you have it and I'll give some feedback
shivam-kapila
I agree witb alastairp more
OP
pristine___
I am on a vacation this week but I have my laptop with me. So I will be working for a few hours everyday. Sure, will send by tonight or tomorrow for sure.
alastairp
pristine___: sure, whenever you want, just mention me with a link
Mr_Monkey: did you see, at least shivam-kapila agrees with me
Mr_Monkey
I agree too
shivam-kapila
How many among us will be at OB this summit
Mr_Monkey raises his hand
Mr_Monkey
Assuming OB = OfficeBrainz
ruaok
\ø
shivam-kapila
But I am excited
kieto joined the channel
iliekcomputers
>I am on a vacation this week but I have my laptop with me. So I will be working for a few hours everyday.
so... not a vacation?
ruaok
I know that feeling.
iliekcomputers
ruaok: nov 21 sounds good to me
ruaok
sweet, into the calendar it goes.
iliekcomputers: alastairp _lucifer Mr_Monkey : We're confirmed for Nov 21/22
Mr_Monkey
👍
_lucifer
👍
ruaok
that is going to be serious fun, I think. :)
CatQuest has quit
CatQuest joined the channel
CatQuest has quit
CatQuest joined the channel
alastairp
5:15 PM <ruaok> that is going to be serious
is all I read at first
pristine___
Nov 21....oooo...idk why I was reading it Oct 21 in every message
shivam-kapila
iliekcomputers: ping
iliekcomputers
pong
shivam-kapila
Hi
I saw you had done the work I should have done in #1097
sorry for that
I am a little lost
iliekcomputers
no worries, i wanted to get that merged quickly.
shivam-kapila
can you guide me whats left
iliekcomputers
i'm planning on writing a few tests and merging it.
shivam-kapila
tests for only modal are left
?
iliekcomputers
if you have any css changes and things like that, we can do it in a followup
shivam-kapila
sure
iliekcomputers
a test or two for the modal and tests for the /followers and /following endpoints
pristine___
ishaanshah: blank template in #1115?
shivam-kapila
okay I will add that
ishaanshah
pristine___: updated
iliekcomputers
shivam-kapila: actually, i've started on it, i'll finish it up today