#metabrainz

next.. Leo_Verto ?

Quesito, maybe?

ok..

hola!

i thought she ha ben on?

not yet...

alright, well since ok, Quesito next!

ok!

last week I got to talk lots of data visualization with loujine

welcomed a bronze supporter!

woo $$$

:P

and then started the long and winding road of invoicing and accounting with ruaok

people left: yvanzo, Leftmost, who else?

<3 Quesito

o/

I am trying to implement a fixed quarterly billing cycle that follows the fiscal calendar. We’ve begun, and by reaching out to our supporters we’ve gotten some good and interesting feedback.

this should reduce the work that needs to be done on this front.

Thus far I'm at 50% up to speed....so still more work to be done

yes! more work now--but sooooooo much less in the future! which is exciting

Ahh, programmers. Hours optimizing tasks that take five minutes. :)

other notes--need to get back into web verbiage--it's getting close

(But take five minutes eight hundred times.)

[picard] samj1912 opened pull request #699: PICARD-1065: Fix patch_version (master...picard1065) https://git.io/vSinF

Quesito: remind me to take a look at the verbiage too at some point :)

and if anyone want to vote on ORG-10 please voice your opinions!!! thank you CatQuest for yours!

ORG-10: Create banner(s?) for use on social media sites https://tickets.metabrainz.org/browse/ORG-10

(although I trust CallerNo6)

Okay Quesoogle...

will do reosarevok!

:P Leftmost

fin!

Leftmost: GO!

(away!)

Quesito: :D

Fin. ferbncode?

:D

Hi :), I worked on code to create CB database using raw sql so that the ORM models are not used for creating databases.

https://github.com/metabrainz/critiquebrainz/pu....

was busy in organization of some events in the Technical Fest of our college.

thats all for me. fin :)

hi there

Last week, I mostly worked on entity attributes, should be up for code review within this week. I wish we would get it live on test.musicbrainz.org during next week.

Yay, less ORM

That's all for reviews?

I think so.

anyone else?

unless someone of LordSputnik or alastairp wants in, I think so

ruaok: o/

Oh

Or that

hi loujine ! go!

loujine: go :)

hi everyone

\o/

just a quick word

hi!

after discussing with ruaok and Quesito I continued working on data visualizations with MB data

"expeditious"

but didn't do much

Oh, not that sort of quick word. Aww.

played a bit with d3js + python over the weekend

hope to show you something soon

When you have something cool, please put it on the forums too :)

that's all

sure

looking forward to that!

see, like these two

ok, onward, lets see if we can get through the topics this week.

reo: MBS-9248

MBS-9248: Don't show the artist name in the tool-tip if it's the same as the sort name https://tickets.metabrainz.org/browse/MBS-9248

So

I submitted a (half-finished, admittedly) PR for this a whiile ago

But chirlu really doesn't like the idea

So bitmap wanted to make sure whether we should just discard it or not

I second chirlu's opinion on this.

Basically, right now we show the artist sortname on hover if it doesn't match the name, *and* the name if it doesn't match the credit

And if both are the same, we show it twice. Which looks silly IMO

I'm not particularly attached to my PR, which is meh, but I'd really like us not to show the same string twice

(especially since we don't even explain anywhere that one's the name and the other the sortname)

so, we have 1 meh, two against.

anyone for?

showicng twice sounds weird if they''re the same

yea

chirlu: agreed, but I just think showing only one extra "explanatory" string is better than two if the second provides no info

Again, I don't care much *how* we change this, it just feels very off to me as it is

Sorry I am late (again). Real life.

But it makes the code more complicated, to little benefit.

leaning towards rejecting the unmodified PR, then.

something something usability and profesionalistic apparent something

I think my favoured option would actually be to show both, *but* specify clearly one is name and one sortname, instead of making people guess, then

but bitmap didn't want to add more text to the pop-up

appearance*

(like, I'd do "Name: X, Sort name: Y" as hover)

I'd be ok with adding labels, I guess

if sortname = name why show it though?

But I think ruaok really wants to move on, so I'm happy to say "drop the current PR, consider further on Jira"

though I'm not sure how much this is going to help people

reosarevok: +1

there doesn't seem to be a strong set of feelings on this either way.

+1 to "consider further on Jira" then

k

so, refer to this IRC convo and reject PR for now.

Sophist-UK: did you have a general update to get in?

samj1912: onward to picard v2, if Sophist-UK wants to get in he can go after you.

doubly so. :)

A quick summary:

Stopped work on the UI responsiveness PR - and will pick it up again on Py3 when I get the time.

So, I wanted to ask the direction we want to take with picard v2 and wrt to plugins, as I have mentioned earlier, I would like for picard to be more modular and move more things to plugins and introduce more plugin hooks along with having officially maintained plugins

A couple of PRs to provide iTunes Movement tags support - 1 for master 1 for 1.4.x

A couple of tiny bugs fixed.

Not much compared to others.

zas: Mineo bitmap Freso Sophist-UK ^^ thoughts?

better than nothing at all, Sophist-UK. :)

sorry samj1912.

samj1912: have been been requesting more plugin hooks?

and anyone else, if you want to chip in for that matter

ruaok: not yet, but I want to make the core picard core more lean, so we would then need more plugin hooks

this would also solve problems with picard having a cluttered UI, and complicated options page

generally speaking, it is a better policy to add things after people ask for them, otherwise its work that may never be used.

I don't know how I feel about making "core" uses of picard plugin instead.. it might make some features horribly dated after a while..

core* = features

not much thoughts from me, though I'd like to know which features you want moved to plugins

+1 bitmap

samj1912: sounds like it might be good to do more planning on this and maybe toss out a google doc or wiki page with your thoughts?

I think we need to be careful with this approach

yes

I think it comes down to putting the time into doing good design - both for new UI and for plugin hooks. The current plugin hooks have developed organically and it shows.

do some sort of survey on features people use and which peopel don't

as I said yesterday, I fear this will lead to a plugin hook thing and a single plugin for each checkbox in the options, which is a bit meh

A lot meh!!

I agree with Mineo on this

yes: you'll end with it being more features being mesy inteface instead

Well, moving something to be a plugin doesn't mean they won't be there, they can still be active by default (something like ASCII conversion makes 100% sense as a plugin, for example, IMO)

this clearly needs more marination....

ding.

and the plugins (which we don't controll as much) will amek the interface messy and clunky instead

samj1912: think on this and then put your thoughts together somewhere for people to review for a future meeting.

CatQuest: I think the idea would be we still develop those plugins ourselves? But maybe I'm getting it wrong :)