#metabrainz

Inside this css class you can define `&.timeline-event-sub` (meaning elements with both .timeline-event and .timeline-event-sub classes) and defined your style.

The horiwontal bar before the icon was based on https://github.com/metabrainz/listenbrainz-serv... but changes width, height and positioning (top/left)

[listenbrainz-server] 14MonkeyDo merged pull request #3161 (03master…friends-feed): "My Network" feed — new follows and similar users listens feed page https://github.com/metabrainz/listenbrainz-serv...

lucifer: for the notifications back-end that I speccing for GSoC right now, it stipulates that the notification endpoints be private AND with oauth scope for sending/receiving notifcations.

come to think of it, that is probably not necessary to make it private. If your account doesn't have the scope, you can't auth to the endpoint. thoughts?

reosarevok: ping

Was on a bike, let me read

dumb question: why *don't* we call the people we follow "friends" ?

(on listenbrainz)

I haven't said anything yet, reosarevok :)

are you near a computer now, reosarevok ?

Because an Estonian could only follow two people then, Jigen (IRC):

I will be in 5 to 10 min, parking the bike

what is our goal with "followrrs" though? I mean I only follow like, peopel i actually consider well that I know. maybe "folks I know"? :P

(Thought you were pinging about the notifications bit, sorry)

"buds"

my buds. my people, my guys, pals, chums

idk.

Jigen (IRC): Ready to chat :)

reosarevok: I am, but now something entirely new

maybe that's why i follow liek 35 peopel and only have like 5 followers back (laughing on the inside)

monkey[m]: ! ok

But if you just call it follow then each person can decide what it means to them :)

monkey[m]: wanna do it in pm?

Yus

mayhem: pong

k, the topic is now how to deal with the mail templates. so far we've got jade's work which is available as an API, but requires rust templates to be compiled into an API for each template IIRC.

and each template change. which is quite annoying -- but it supports i18n, which is a big bonus.

my main question is this: should we force the MB style templates on all projects or do we let python based projects to user jinja2? so, the notification creator can choose which sending engine to use?

I mean, ideally it probably makes sense for all emails to share a look and feel if possible, and localization would be a good thing too.

I understand https://github.com/metabrainz/mb-mail-service/b... looks a bit scary, but how often do you change the email content once the message is ready?

but getting from point A to full implementation will take a while, methinks.

(and I understand if you just change a string content the template file stays the same)

Yeah, not saying it won't, we are still migrating some of the MBS emails while others already use it

Seems fine to use what you have for now, with the goal to slowly move towards this - bitmap and Jade (try @jade:ellis.link) could probably help set it up as needed

what I have now being Jinja2 and mb-mail-service, with the creator deciding which to use?

Well, I am not sure if for example in LB you have any basic functions to actually use the mail-service, stuff like this in MB https://github.com/metabrainz/musicbrainz-serve...

we do in Brainzutils which is used by all python projects

Ah, ok

In that case it seems that yes, you could say that for now people can keep using jinja2 but anyone who wants to try can already test the new service

And have a longer term goal to migrate the existing ones to the new service and improve them a bit

the jinja2 and mb-mail have two different workflows that I need to reconcile.

(and once you're doing that I guess you'd say "that's it, now all new stuff must use the new one")

mb mail keeps the templates in that project, (which feels really weird to me) whereas jinja will require the template and arguments to be passed to the notification API call.

I mean, yes, you'd need to either call the "mail via jinja" or the "mail via mail-service" method - we have both and they look fairly different

See https://github.com/metabrainz/musicbrainz-serve... which changes one specific mail from one to the other

But I don't see a reason why both methods cannot live side by side at least for now

aside from the workflow issue I mentioned.

I mean, the same template should of course always be sent only in one way

So for a specific email you should always know what workflow to follow

The parameters you're still passing to the email service either way, the difference is on the way you do it

Am I missing something? :)

I just realized another thing about this really weird mb-mail flow -- we now have content that needs to be translate in two separate repos. that seems like a really bad decision to me.