yvanzo, bitmap: "Hope you may be able to help with this - we are running musicbrainz server in our tech stack and we were wanting to try it without caching as our usage isn’t too high. In the DBDefs.pm there is a bit that says "See below if you want to disable caching.” But I can’t see any further option below to disable, is there an option we can pass in?"
2020-11-02 30732, 2020
reosarevok
I also can't find anything else than that, did we change that and forget to change the text?
2020-11-02 30743, 2020
bitmap
moin
2020-11-02 30706, 2020
bitmap
not sure if we changed something but I think you'd use Cache::Null for that
2020-11-02 30710, 2020
_lucifer
alastairp: any ideas about this https://sentry.metabrainz.org/metabrainz/cb/issue… ? I am unable to reproduce the issue and error seems to suggest that the review table went missing for some period and the reappeared.
2020-11-02 30716, 2020
bitmap
I could check if it still works
2020-11-02 30734, 2020
reosarevok
If you could, then maybe you could answer the email with whatever you find ;)
Hey! sorry for being late on PRs. Work has been really busy
2020-11-02 30739, 2020
ishaanshah
the above PR should fix the error encountered in the morning
2020-11-02 30743, 2020
ishaanshah
> Hey! sorry for being late on PRs. Work has been really busy
2020-11-02 30744, 2020
ishaanshah
No worries at all, just wanted to notify you in case you missed the notification
2020-11-02 30704, 2020
iliekcomputers
Mhmm, thanks
2020-11-02 30757, 2020
ruaok
Mr_Monkey: you about?
2020-11-02 30706, 2020
Mr_Monkey
Beep boop !
2020-11-02 30724, 2020
ruaok
I'm reading your comments on the recommendation feedback paper.
2020-11-02 30735, 2020
ruaok
and the intent on the back-end is quite clear.
2020-11-02 30743, 2020
ruaok
broadly speaking there are two forms of it: 1. User feedback about tracks in their listening history. These are an expression of how they feel about the track in general. 2. Recommendation feedback about how good or bad a recommended track is in the context of a generated playlist for a user.
2020-11-02 30729, 2020
ruaok
that immediately informs us about some very basic UX things:
2020-11-02 30724, 2020
ruaok
1. the listens page feedback options should only allow the user to give the recording feebdback (#1 above)
2020-11-02 30707, 2020
ruaok
2. A generated playlist could show recording feedback and/or playlist feedback.
2020-11-02 30706, 2020
Mr_Monkey
I'm with you so far, apart from that "and/or" in 2. : I don't think we'll be able to show both modes of feedback at the same time without it being too confusing.
2020-11-02 30719, 2020
ruaok
I suspect that you are right.
2020-11-02 30736, 2020
Mr_Monkey
I haven't tried, so it's a gut feeling more than anything
2020-11-02 30754, 2020
shivam-kapila
I agree with Mr_Monkey
2020-11-02 30755, 2020
ruaok
lets assume for a minute that that is correct.
2020-11-02 30718, 2020
ruaok
which then leads to a simple decision: recording feedback is shown on the listens pages we have now.
2020-11-02 30740, 2020
ruaok
recommendation feedback is shown on the pages where we present users generated playlists.
2020-11-02 30754, 2020
ruaok
and for UX sake we should have distinct icons/colors for each.
2020-11-02 30727, 2020
Mr_Monkey
OK. So we consider that I can visit playlists generated for *you* and give my on feedback, then? Meaning we don't make a distinction of who a playlist is 'for' and just consider any playlist the same?
2020-11-02 30750, 2020
Mr_Monkey
What about user generated playlists? I suppose we would show the recording feedback in that case?
2020-11-02 30717, 2020
Mr_Monkey
(not that we need to decide that right now, considering we don't have playlists yet…)
2020-11-02 30723, 2020
ruaok
about the latter point, yes that makes sense.
2020-11-02 30748, 2020
ruaok
I am not sure about allowing non-target-users to give feedback on the generated playlists. that feels wrong.
2020-11-02 30711, 2020
ruaok
they don't really fully understand the context, since it wasn't generated for them.
2020-11-02 30707, 2020
Mr_Monkey
One could argue they can still make decisions about whether they're good recommendations for them and inform the system. More user feedback = better?
2020-11-02 30727, 2020
ruaok
I don't think more feedback is better.
2020-11-02 30731, 2020
shivam-kapila
+1
2020-11-02 30739, 2020
shivam-kapila
To Mr_Monkey
2020-11-02 30702, 2020
ruaok
I personally think that we may want to start super simple and push this stuff live
2020-11-02 30712, 2020
ruaok
then let people play with it and give us feedback.
2020-11-02 30720, 2020
Mr_Monkey
I guess this was the central question: what's the use we want to make of the recommendation feedback, is it only for playlists generated for *you* or for all generated playlists?
2020-11-02 30739, 2020
ruaok
for you.
2020-11-02 30749, 2020
ruaok
by definition it is personal.
2020-11-02 30736, 2020
ruaok
this would then suggest, IMnsHO: Allow recording feedback on past listens views. Allow recommendation feedback on pages that show recommendations. use two distinct set of icons/colors.
2020-11-02 30749, 2020
ruaok
just that, nothing more until we get concrete feedback.
2020-11-02 30719, 2020
Mr_Monkey
I think that's the best plan too, until we gauge the use of the recommendation feedback.
2020-11-02 30745, 2020
ruaok
good.
2020-11-02 30707, 2020
Mr_Monkey
So concretely on the recommendation page: if currentUser show recommendation feedback, if
2020-11-02 30707, 2020
Mr_Monkey
not curentUser, show nothing.
2020-11-02 30709, 2020
ruaok
I haven't followed the icon discussion closely -- how close is the current code to realizing this simple goal?
2020-11-02 30731, 2020
ruaok
Mr_Monkey: yes, exactly that.
2020-11-02 30749, 2020
Mr_Monkey
Then about one line of code away to be set up for that.
2020-11-02 30714, 2020
Mr_Monkey
(hide/show depending on currentUser)
2020-11-02 30735, 2020
ruaok
vere nice.
2020-11-02 30743, 2020
ruaok
pristine___: what do you think?
2020-11-02 30717, 2020
Mr_Monkey
Summary: if currentUser show recommendation feedback, if != currentUser, show nothing.
2020-11-02 30744, 2020
shivam-kapila
I am a lil caught up in the thought about what makes us treat the feedback for target and non target users as different?
2020-11-02 30736, 2020
ruaok
feedback is subjective per the target user. at least that is my current assertion until we learn otherwise.
2020-11-02 30755, 2020
shivam-kapila
Right. But I meant that why does it make us treat the playlists differently?
2020-11-02 30730, 2020
ruaok
which playlists? we need to plan for user generated and machine generated playlists.
2020-11-02 30741, 2020
ruaok
only the latter should accept recommendation feedback.
2020-11-02 30710, 2020
shivam-kapila
Oh I got it now.
2020-11-02 30723, 2020
shivam-kapila
Thanks
2020-11-02 30740, 2020
pristine___
Mr_Monkey: if we aren't showing anything, then the right wnd of the card will be empty. I initially (before writing the doc) thought of shifting the artist name to the right end. It would require us to make a separate component
2020-11-02 30704, 2020
pristine___
Or do we want to leave it blank.
2020-11-02 30742, 2020
Mr_Monkey
We can just leave it blank
2020-11-02 30706, 2020
pristine___
Umm... I feel it won't look good
2020-11-02 30756, 2020
ruaok
pristine___: for now, lets not consider the visual aspects of this. we can burn those bridges when we get to them.
2020-11-02 30707, 2020
shivam-kapila
pristine___: I think moving the artist name to right is gonna make it look uneven
2020-11-02 30714, 2020
ruaok
let's worry about the general rules about when to show which feedback icons.
ruaok: do we need a design doc for artist recommendations?
2020-11-02 30714, 2020
ruaok
do we have open questions and confusion around our goals? if so, then yes.
2020-11-02 30735, 2020
ruaok
me personally, I have no open questions. I'm hoping for it to be mostly copypasta.
2020-11-02 30720, 2020
pristine___
Lol yeah.
2020-11-02 30728, 2020
BrainzGit
[listenbrainz-server] mayhem merged pull request #1158 (master…rec-recording-path-update): Prepend `recording` to recommendations path to distinguish between recording and artist recommendations https://github.com/metabrainz/listenbrainz-server…
2020-11-02 30750, 2020
pristine___
Thanks for the merge :)
2020-11-02 30743, 2020
BrainzGit
[listenbrainz-server] mayhem merged pull request #1155 (master…werkzeug-profile): Remove unused devserver and werkzeug profiler code from server startup https://github.com/metabrainz/listenbrainz-server…
2020-11-02 30759, 2020
Freso
bitmap (and any other USians/North Americans): note that meeting time has shifted back for you again. :)
2020-11-02 30739, 2020
TOPIC: MetaBrainz Community and Development channel | MusicBrainz non-development: #musicbrainz | Channel is logged; see https://musicbrainz.org/doc/IRC for details | Agenda (USians: note that new/old meeting time if you switched to std. time): Reviews
interesting read on the eve of the 4th annivarsary of moving our services to hetzner.
2020-11-02 30700, 2020
outsidecontext
ruaok: great read
2020-11-02 30711, 2020
ruaok
ya, I find it amazing that people have no clue how expensive AWS is. when we did move and blogged about it one person said: "Just move to AWS and be done with it, why are you messing with Hetzner?" So I opened our spreadsheet that helped us make the decision and I could hear his jaw hit the floor.
2020-11-02 30758, 2020
ruaok
and the lockin problem was one of the greatest reasons for us not go with that. and that is why all services we use except the most basic are ones we provision ourselves.
2020-11-02 30727, 2020
ruaok
I love this guide, if anyone feels confused about postgres joins.
2020-11-02 30736, 2020
ruaok
sadly its not allowed me to fix the issue to hand yet, lol
pristine___: let me see if I can bring together all of my various notes on recommendation reseasrch. I've been collecting a bunch of things over the last few months
2020-11-02 30730, 2020
alastairp
unfortunately it's mostly a list of papers that I still have to read, but it'd be good to get these into a single place so that you can have a look at them too
