#metabrainz

ss?

for source separation we'd have to do it at an earlier stage - I don't think there's enough data in the acousticbrainz data to do anything with it

but I guess we would need to re-run the low level data.

Screenshot

> Sync already feedbacked recs

alastairp: yerp.

yea it was borked so I used ircloud too

Will be a separate PR shivam-kapila

see KassOtsimine link

it's a pretty active area, especially with new deep learning techniques

both Deezer and Sony presented some pretty amazing systems at ismir last year

pristine___: sorry but that doesnt make sense. Thats an incomplete feature then

I makes senses

I don't know if the tutorial just covered current techniques, or if they were proposing some new systems

Because I have made a separate branch

ok I'm out now

The PR will be hugeeee if I do everything in one PR.

Then branch of the child pr from this and merge it into this

Or make feedback pr totally separate

And only refactor in this

alastairp: I think we should keep an eye on this stuff and choose the most promising tools to include in the next low level scan for AB... when ever that will be.

yeah

shivam-kapila: did you look at the PR. I made a separate less file.

I am not able to render the emojis in line with the text

:(

I did

And I am confused what happened

pristine___: can we do refactor first so we can merge it today

And then move to feedback

Bkz its still some work imo

What refactor

We added a new component

Yeah

But we didnt clean up the redundant code

We have in Recent listens

eh. is the upperline/menu/thing on jira-tickets borked for anyone else?

Listen card

And so on

Lets do the cleanup and move to feedback in separate pr

also seems every page has horizontal scrolling too

I'm fairly sick of these "maintenance" jira updates every 3-4 weeks that changes colours, makes it harder to read and borks things up tbh

Also col-sm-9 etc are bootstrap classes

The component isn't ready in my opinion. I mean I plan to put the non functional emojis properly, merge it, remove redundant code, merge it, syn feedback, merge, to have small PRs.

by all means ypdat security, but could you not f-upp the layout and such, tnx.

Col-xs-9?

Or sm?

Xs

Hmm.

So rec-col-xs-9 is not gonna work properly

I guess that's causing the issue.

Right

pristine___: I am unable to align myself with your planned schedule

Emojis are no good there

shivam-kapila: but for #rexommendations id, I should define col-xs-9 again right?

I mean I cannot use it from #listens id?

You dont need to ideally

Oh

#recommendations, #listens in less

Comma separated selectors share styling

What?

Ah selectors in css is like how we select ids, class, element etc

Did you get chance to look into css mdn docs i linked

> #recommenders, #listens in less

No shivam-kapila I guess I missed the link :(

I have a class now. I will get back to you after that.

Not quite a dress, but :p

I want an updated wikidata shirt. do they sell those?

or do I have to go beg lydia for one?

We asked for them nicely and got them for free :p

Begging Lydia sounds like a plan :p

will do then. :)

I'd offer a summit shirt of ours, but she wouldn't wear it.

There's also socks, although those are more standard

shivam-kapila, pristine___ : For what it's worth, I think alastairp's idea for expanding +1/++1/-1/--1 is not very clear (~= not used anywhere that i'm aware of).

I think sticking to more established feedback methods would be a better idea. Emoticons should work quite well, and can be supplemented with text on hover to clarify meaning.

Also, I do like the idea of showing all the emojis only once the user hovers over a feedback component.

ok, cool

if it's not used then there's no reason to use it

Mr_Monkey: yeah I align with your thoughts

And finally, if the "this is not a good recommendation" feedback is separate (I agree on that), perhaps we could just have some text button, clearly separate from the emojis? I think it would suggest that we're not so much talking about emotions (the emojis are there for that).

So is "I really dislike this" 💩 ?

🤮

Mr_Monkey: I am okay with what community thinks because I am not very clear about using 5 emojis. I personally would have only used thumbs up and thumbs down.

Ah, that's another story :) We do need to figure out how many levels of feedback we want.

one thing that discussed in person is that the meaning of feedback is quite personal

e.g. ruaok has said before that if he says "no" to a song, he never wants to hear it again

whereas sometimes people might want to say "no, not here (or not now), but in other places OK"

Right. I do think emoticons can help with that, compared to the functionally-equivalent stars rating for example.

alastairp: then we can have a hide rec for that

I think for this idea of situational feedback "not here (or not now), but in other places OK" we'll just have to rely on if the user skipped the song.

If a user really doesn't like a song at all, 😠 face is pretty clear for that, compared to thumbs down for example

alastairp: I wonder if we should have a survey of how people may be interesting in giving feedback. and then distilling them into a coherent set of feedback values -- I personally dont see why "never hear this again" and "not, her but maybe ok in a diff context" should not both be available options.

ruaok: yeah, I think that might be useful. at least it'd give us a wider understanding of how people rate stuff

I do worry about one aspect of that -- most people are unfamiliar with giving such feedback, so we would need to educate before ask for feedback

I would flat out ask in a survey 1) do you use a music streaming platform, 2) do you ever use the +1/-1 buttons

and some questions about if they think that the system "listens" to them

let me start a document with some suggestions for questions

perfect

yvanzo: see also https://github.com/metabrainz/musicbrainz-serve... - I answered your comment, but not sure if that's enough or you'd want to change something :)

> Very few studies have investigated which personal and situational characteristics exactly motivate and inhibit users to provide preference feedback to the system (see Pommeranz et al. 2012, for a notable exception). This is an important issue, as many recommender systems rely on explicit feedback (e.g. users' ratings) to give good recommendations.

> Privacy concerns may reduce users' tendency to disclose personal information (TeltzrowandKobsa 2004; Chellappa and Sin 2005; Berendt and Teltzrow 2005; Ackerman et al. 1999). On the other hand, if it positively influences their user experience (i.e. in terms of better recommendations), users may be more willing to provide feedback (Spiekermann et al. 2001; Brodie et al. 2004; Kobsa and Teltzrow 2005)

it will remain critical or us to maintain user trust in everything we do, to uphold the latter sentiment.

[musicbrainz-server] reosarevok merged pull request #1633 (master…MBS-8725): MBS-8725: Allow mediums to have an unknown tracklist https://github.com/metabrainz/musicbrainz-serve...

MBS-8725: Allow mediums to have an unknown tracklist https://tickets.metabrainz.org/browse/MBS-8725

Please let's try to properly test this in beta ^ :)

(I *think* it works fine this time, but I would really like to avoid further messes)

yvanzo: also https://github.com/metabrainz/musicbrainz-serve... was fixed according to your request :) (I think!)

ruaok: yeah, absolutely. I think that we're in a good position to do this because we are explicitly open

open data repository, open code

Project bookbrainz-site build #3494: passed in 4 min 56 sec: https://travis-ci.org/bookbrainz/bookbrainz-sit...

Mr_Monkey: #1133 is ready for review.

I will post a ss here

Great :) I'll look at it today

Mr_Monkey: please ignore the emoji eolors, i will do that in a separate PR, the CSS thing.

iliekcomputers: ah! https://listenbrainz.org/recommended/tracks/Van...

Last_updated is on 8th October

So everything works perfectly.

Thanks!

I guess I will add the window here as well, so users will know the exact dates, for eg your listens were last updates on 8 October. `Listens submitted between 1 October and 7 October have been used to generate recs`

Something like this.

alastairp: did you see the sentry weekly report ? It seems that after friday release events dropped from 4.4k to ~200.

I enabled SSO for Tickets using either MusicBrainz or GitHub.

_lucifer: no, I didn't. that's good news! we must have had a bunch of bugs that we weren't aware of

yeah, right

There is a small display bug that may hide these options on the starting page, I reported it already.

yvanzo: oh, neat

reosarevok: nice tee

pristine___: I looked in detail now and I see a lot of code that we wont need for rec component

Comment on the PR please, I will remove. I wasn't clear when I was writing the first draft :)

But things make a lil sense now.

Yes I can relate

:p