Mr_Monkey: yeah, right. I wanted to ask if that's how `updateFeedback` should be used, because I get an error if I spy on it like that
2020-11-11 31657, 2020
pristine___
Haven't included tbe html elements yet
2020-11-11 31647, 2020
ruaok
alastairp: I was pondering the name ACRP.... How about "canonical recordings"?
2020-11-11 31608, 2020
Mr_Monkey
I see. Well, that does look OK to me at first glance. What's the error?
2020-11-11 31615, 2020
alastairp
ruaok: remind me what happens if there are many matches for this exact artist credit/recording?
2020-11-11 31651, 2020
alastairp
I'm unsure about using "canonical" if it skips valid results
2020-11-11 31621, 2020
Mr_Monkey
I ran the test, and I do see the error. Let me look at it quickly
2020-11-11 31639, 2020
ruaok
let me explain the process... first all the releases in MB, except VA are sorted by digital release, release year, with the goal of matches settling on "things that reasonably came from a digital release".
2020-11-11 31604, 2020
ruaok
then that list is fetched and the artist-credit, recordings "pairs" are recorded in an in memory dict.
2020-11-11 31648, 2020
ruaok
and the first occurance of any one pair is attributed to its source release and the recording MBID from that release is chosen as the "canonical one"
2020-11-11 31647, 2020
ruaok
if we add VA and fix the releases without a country TODOs then all text combos of artist credits and recordings will be in the mapping.
2020-11-11 31656, 2020
alastairp
yeah, right. so I'm asking about the non-common cases, where there are valid cases where there are mroe than 2 valid recordings for the same (ac, r name) pair
2020-11-11 31629, 2020
ruaok
all but the first are discarded.
2020-11-11 31644, 2020
ruaok
its a text lookup, not an MBID lookup.
2020-11-11 31605, 2020
ruaok
maybe canonical is too specific. any other ideas for better names?
2020-11-11 31618, 2020
alastairp
my first gut feel is that "canonical" makes it sound like it's pretty damn near perfect, and I think there are a lot of edge cases that it skips
2020-11-11 31636, 2020
alastairp
sorry, this isn't super helpful in proposing an alternative, I just wanted to comment on it
2020-11-11 31647, 2020
ruaok
wishy washy recording mapping??
2020-11-11 31654, 2020
alastairp
that's a lot clearer :)
2020-11-11 31609, 2020
alastairp
honestly, artist credit recording mapping
2020-11-11 31611, 2020
ruaok
tech is easy, naming is hard.
2020-11-11 31617, 2020
alastairp
is clearer that the P
2020-11-11 31629, 2020
ruaok
oh heh. sure.
2020-11-11 31643, 2020
ruaok
I was blind to that since that was never meant to be a mapping in the first place. lol.
2020-11-11 31615, 2020
ruaok
ok, I won't fix the name just yet. I'll keep going until we're sure that it serves our needs. then I'll do a refactor/cleanup on it.
2020-11-11 31621, 2020
alastairp
sounds fine to me
2020-11-11 31626, 2020
alastairp
Mr_Monkey: pristine___: hello!
2020-11-11 31641, 2020
Mr_Monkey
Ahoy ! Let's talk feedback :)
2020-11-11 31631, 2020
pristine___
Hi!
2020-11-11 31635, 2020
alastairp
pristine___: I had a look at your PR, it looks mostly good
2020-11-11 31658, 2020
alastairp
however, last week Mr_Monkey and I had a discussion at the office, and we think that there might have been some confusion about the purpose of this feature and what it needs to do
2020-11-11 31620, 2020
alastairp
it's possible that we didn't clearly specify what we were doing - first up I wanted to ask if there was a ticket describing what we're doing
2020-11-11 31624, 2020
Mr_Monkey
I was definitely confused.
2020-11-11 31653, 2020
pristine___
No ticket
2020-11-11 31635, 2020
alastairp
I think that's a good thing to focus on first. This is similar to what we were talking about yesterday - we didn't have a clear "what do we want to do" aim, it was more of a "hey let's do some collaborative filtering"
2020-11-11 31602, 2020
alastairp
let me make a comment about my understanding of the task first, and then we can continue from there
2020-11-11 31640, 2020
alastairp
we currently have feedback, a way for users to say that they like or dislike something that they have listened to.
2020-11-11 31641, 2020
pristine___
alastairp: I thought we are clear on purpose because we had a discussion about feedback stuff when we were writing the schema
2020-11-11 31602, 2020
pristine___
And talking about the 5 feedback options
2020-11-11 31603, 2020
alastairp
This current implementation is problematic in a few ways: it's mapped directly to a msid, and it only has 2 types of feedback, positive and negative
2020-11-11 31615, 2020
pristine___
It is mapped to mbid
2020-11-11 31630, 2020
alastairp
so, we decided to redo feedback, adding in 4 + 1 types of feedback, and map it to an mbid
2020-11-11 31631, 2020
pristine___
Wait, are we taking about recommendation feedback?
2020-11-11 31652, 2020
alastairp
pristine___: right. and this brings up the main difference and point of confusion that I think we're seeing
2020-11-11 31602, 2020
pristine___
Because there is something called listen feedback too
2020-11-11 31606, 2020
ruaok
that was beautiful. lol
2020-11-11 31607, 2020
pristine___
Ooo. Right
2020-11-11 31615, 2020
alastairp
I get the impression that your work has been "feedback to recommendations"
2020-11-11 31621, 2020
pristine___
Yes
2020-11-11 31631, 2020
alastairp
and my proposal was that this shoud be an improvement to "feedback"
2020-11-11 31658, 2020
alastairp
that is, we're not sure that it's useful to have general "recommendation feedback"
2020-11-11 31658, 2020
pristine___
Okay, so I think we can roll in shivam-kapila too.
2020-11-11 31606, 2020
pristine___
Hmm
2020-11-11 31616, 2020
alastairp
this comes back to the initial comment about if we have a ticket describing what we want
2020-11-11 31651, 2020
alastairp
my opinion: I don't think that we should be asking people if they love/like/don'tlike/hate a track _in the context of a recommendation_
2020-11-11 31613, 2020
alastairp
we should just ask people in general "do you like/love/don'tlike/hate this track"
2020-11-11 31625, 2020
alastairp
now, bad recommendation - that's a slightly different case
2020-11-11 31633, 2020
supersandro2000 has quit
2020-11-11 31650, 2020
supersandro2000 joined the channel
2020-11-11 31653, 2020
alastairp
(I'll take a pause here in case you have any comments)
2020-11-11 31654, 2020
SothoTalKer has quit
2020-11-11 31611, 2020
pristine___
No comments
2020-11-11 31621, 2020
alastairp
ok, cool. continuing then
2020-11-11 31625, 2020
alastairp
you're right - we had a discussion about how it would work, and you sent the schema. I didn't notice that you had named the table recommendation_feedback, I think that was the first indication that we might have been understanding different things
2020-11-11 31603, 2020
pristine___
I named in light of `bad_recommendation`
2020-11-11 31608, 2020
pristine___
Right
2020-11-11 31609, 2020
SothoTalKer joined the channel
2020-11-11 31633, 2020
alastairp
we suggested to add the "bad recommendation" feedback too. This is because we were thinking in general about what kind of feedback a person might want to give in all cases
2020-11-11 31647, 2020
alastairp
consider "bad recommendation". It doesn't actually say "I like this track" or "I hate this track"
2020-11-11 31656, 2020
alastairp
it's just saying "in this context, it's not a great suggestion"
2020-11-11 31659, 2020
alastairp
so I think it's true that we're confusing a few things, and we could have simplified it and reduced some confusion by splitting it into 2 parts
2020-11-11 31610, 2020
alastairp
but that's OK, we can continue from where we are
2020-11-11 31617, 2020
alastairp
Mr_Monkey: want to chime in about ordering?
2020-11-11 31624, 2020
pristine___
What I think is
2020-11-11 31612, 2020
Mr_Monkey
Didn't quite understand what you mean by "ordering"
2020-11-11 31617, 2020
pristine___
If we want to continue from where we are and if we want to keep the feedback stuff consistent, we can reuse the rec feedback component for listens feedback and just remove the `bad_recommendation` option
2020-11-11 31652, 2020
Mr_Monkey
Close to that ! I think we'll want to *separate* the bad_recommendation feedback from the rest of the feedback.
2020-11-11 31609, 2020
pristine___
Yup
2020-11-11 31611, 2020
Mr_Monkey
And show it only on recommendation cards
2020-11-11 31615, 2020
alastairp
Mr_Monkey: sorry, ordering of the buttons
2020-11-11 31634, 2020
Mr_Monkey
While we show the "emoticons" feedback on all listens and rec cards.
2020-11-11 31647, 2020
pristine___
That Mr_Monkey
2020-11-11 31615, 2020
alastairp
cool
2020-11-11 31617, 2020
Mr_Monkey
I think, since the emoticons component will be consistently visible, we'll want to show it to the right (since that part of the cards in right-aligned). That way it should always be in the same position.
2020-11-11 31618, 2020
Mr_Monkey
That means we would show another sort of rec-only feedback component to the left of it.
2020-11-11 31654, 2020
alastairp
so I think that _for now_ it's OK to keep the 2 types of feedback - we need to do more work in the msid mapping to be able to use this feedback component on the main listen view, right?
2020-11-11 31655, 2020
pristine___ tries to imagine
2020-11-11 31640, 2020
Mr_Monkey
Or, alternatively, find a way to modify the existing emoticons dropdown to make a separation between bad_rec and the rest.
2020-11-11 31658, 2020
pristine___
Yeah, if listens are mapped to msid mapping, we will have an mbid for each recording. It will also require feedback schema update ig
2020-11-11 31628, 2020
pristine___
Mr_Monkey: just to confirm, in a separate PR? #1149 has grown bigggg
2020-11-11 31631, 2020
pristine___
:p
2020-11-11 31636, 2020
Mr_Monkey
Yes, separate PR :)
2020-11-11 31629, 2020
Mr_Monkey
Thankfully, I believe none of the work you did will be lost, just modified.
2020-11-11 31643, 2020
alastairp
yeah, agreed. this isn't a huge change from what is already there
2020-11-11 31644, 2020
pristine___
Yup!
2020-11-11 31650, 2020
Mr_Monkey
Phew !
2020-11-11 31607, 2020
alastairp
I suggest that we modify the endpoints and database tables to remove the references to "recommendation feedback" where possible
2020-11-11 31603, 2020
pristine___
Hmm. I think we can plan a road map here, as in what to do first and next and so on
2020-11-11 31629, 2020
alastairp
can you make a list and show it to us later today?
2020-11-11 31631, 2020
Mr_Monkey
I propose that I make a couple of prototypes of our options for separating the bad_rec feedback, while you're busy finishing 1149 and modifying as alastairp suggests
2020-11-11 31643, 2020
pristine___
Cool
2020-11-11 31643, 2020
Mr_Monkey
(Just visual ones)
2020-11-11 31645, 2020
pristine___
Cool cool
2020-11-11 31649, 2020
alastairp
thanks pristine___ !
2020-11-11 31605, 2020
pristine___
:)
2020-11-11 31607, 2020
alastairp
(there's one more thing that I need to comment about, but we can't do anything about it until we make playlists)
2020-11-11 31632, 2020
pristine___
?
2020-11-11 31633, 2020
alastairp
the problem is that "this is a bad recommendation" needs a context. just saying "recording mbid is a bad recommendation" isn't enough information for us to do it
2020-11-11 31607, 2020
Mr_Monkey
-> "this is a bad recommendation" + "in the context of playlist #12345"
2020-11-11 31608, 2020
alastairp
so once we are able to store recommendation lists in a playlist in listenbrainz, we can say "this recording is a bad recommendation in <this specific playlist>"
2020-11-11 31615, 2020
pristine___
Right. I was thinking to add some context to it for users to understand what exactly this option is in the rec info page
