#metabrainz

MBS-9113: Incorrect age displayed if death and birth dates are not precise enough https://tickets.metabrainz.org/browse/MBS-9113

Well, I guess if zas was busy this week and sam is not around, some delays make sense

see slacker boy from france. :)

Not so bothered about Picard-Plugins because they tend not to be codependent.

Sophist-UK: Maybe don't make PRs just before Easter then. :)

True.

This just seems like a reasonably simple DR

However some PRs get reviewed faster than others. So its not quite as simple as being Easter.

We currently guess the age at death when we have years only, which means sometimes we miss

I like the "circa x years" idea

I think that's fine. Maybe add a "ca.", yeah.

The options are on chirlu's last comment

I think it's still useful to display something

I personally prefer "60 or 61 years" than circa

sure

But yeah, definitely something, and ideally something less certain than now

+1 to circa

"aged 60 or 61"?

+1 to "60 or 61"

+1 to either option

(says "aged 61" now)

60 or 61 sounds wishy washy.

(I guess circa makes it slightly simpler, I just think it looks meh)

approximately 60 years old?

"circa 61" can be 64

could also do 60–61 or something like that

about 60 years

?

~60

mauve 60

I wonder how this would work with the "approximate dates" ticket...

all good databases are mauve, says the pointy haired boss

If we agree with option b)

anyone disagree with option b, regardless of wording?

Doesn't seem like it.

motion carried then. let the implementer do it and then good luck getting through the PR gauntlet. :)

👍

( MBS-6666 )

MBS-6666: Artist credits not renamed from artist edit page unless the artist name is changed https://tickets.metabrainz.org/browse/MBS-6666

meh. doesn't mention satan. boo

Right now the UI for this is confusing

It only does something when you change the name, but it is always there even if you haven't, so people get confused nothing happened

I like "hide/disable these controls when there is no change to the artist name".

I'd personally want to show it only when the name changes

seems sane.

(because I think it's safer than the other option, of allowing using this as a way to batch-change credits even if the name didn't change)

+1 for hding them if the name isn't changed

Yeah.

+1

(also much less work, since right now it's attached to modbot)

Yay :)

Lots of +1's. Anyone against?

Can all DRs be this easy? :D

that was easy. :)

5...

4...

3...

2...

1...

<crickets>

Motion carried.

Thanks for a nice and speedy meeting, with 10 minutes left!

Night all!

</BANG>

reosarevok: Will you post on the tickets?

Reopened and posted already :)

👍

!m reosarevok

You're doing good work, reosarevok!

post-</bang> question for reosarevok: if MBS-8393 happens, does that change how you want to approach the genre/tag thing?

MBS-8393: Extend dynamic attributes to all entities https://tickets.metabrainz.org/browse/MBS-8393

Not initially at least

okey dokey, thanks

I still like basing them on tags

Because it allows easily adding new "genre tags" to the list and immediately have them working

The main benefit of using a closed, not-tags-only list IMO is linkability and mbids and rels

reosarevok, bitmap: Most inconvenient shortcoming is the editing system: attributes do not have gids.

And attributes don't offer that, so

yvanzo: they should :) But that's Q4 I guess?

yes

Anyway, definitely in favour of adding IDs in more places

although it might be possible to create temporary join tables for that

CallerNo6: in general, I'd say either make them full entities that can be linked to, say, their Wikipedia page, or leave them as tags

Any in-between solutions sound like a lot of work for little practical gain

gids for work attributes?

Well, some permanent way of calling an attribute sounds reasonable, we have them for reltypes

I know the types and values already have them

yes

or at least something comparable to aliases

GIDs are not the only possible solution.

All of them!!

GIDs!! GIDs everywhere!!!

bitmap: The issue is more that concurrent edits of attributes can overwrite each other.

hmm

CallerNo6: MBIDs are GIDs, the reverse is not true.

can't use locking?

but that DR about changing all credits :/

i want the feature to be able to edit all credits no matter what :O

Actually aliases don't have GIDs either and don't have this issue.

bitmap: What is probably lacking is specific edit types for editing attributes.

aliases aren't like dyn.atrib. though...

yvanzo: can't all edits overwrite each other? Or you mean that they should conflict and fail?

In which case, shouldn't that be done by just storing the original value and comparing?

they are user entered date.. not unlike tags in away, the ones what are "official anmes" could and maybe should) have gids..., but search hints.. not as much

reosarevok: Sorry, it is just that the last one wins.

(I see the attribute types have MBIDs)

Oh. I'd say maybe just do like with artist names and whatnot

If the data has changed, fail the edit

I know either iswcs/isrcs or ipis/isnis use some 3-way-merge

Which I assume we do by just storing the original value in the edit and comparing on application

anyway, the ticket was more about letting someone batch alter artist credits in the rel-editor :/

(which would be a huge boon)

Which of the tickets? :)

the last DR?

wasnt that about the "change all " instances of artist credit

If you mean the 6666 one then I *quite* strongly disagree with that as an option

in the rel ed

Ultimately, ISWC/ISRC/… will be attributes, right?

probably

That'd just lead to even more people changing stuff wrongly because for some reason people like checking checkboxes even when it makes no sense if they're there :D

No, that was about edit artist credits when editing the artist name :)

that you can vbatch alter crreditas? heavens why? if for example I want to changella instances of This guy making trumpet whne i know for a fact that is hould be trombone (or subultimate credits, hoi) then Y noT??

No, batch-changing credits for relationships would be awesome, but it's unrelated to that, that's on edit artist pages

anyway, it was IPIs and ISNIs that use MusicBrainz::Server::Edit::Role::ValueSet

reosarevok: edit artist creds when editing artists?

which merges the values using the current, old, and new values

uh. i thought that was already unchecked by default because that's a better idea?

There are specific edit types for adding/removing ISWC/ISRC too, so it won't be a nuisance to replace it with edit types for attributes.

but I'm probably misunderstanding the issue, that might not apply

CatCat: it's unchecked by default. But it only does anything when you actually change the artist name

uh.. of course? that's the actual only thing artist credits do :D

CatCat: so, if you just check a box without changing the artist name, you might think it'll do something, but it doesn't. That's why we want to hide it instead :)

changing the name :D

in general I'd like there to be less edit types, though they are useful for searching at present...

since you can't search for edits that change a certain field

oh damn