#metabrainz

/

      • BrainzBot
        MBS-9113: Incorrect age displayed if death and birth dates are not precise enough https://tickets.metabrainz.org/browse/MBS-9113
      • 2017-04-17 10731, 2017

      • reosarevok
        Well, I guess if zas was busy this week and sam is not around, some delays make sense
      • 2017-04-17 10732, 2017

      • ruaok
        see slacker boy from france. :)
      • 2017-04-17 10745, 2017

      • Sophist-UK
        Not so bothered about Picard-Plugins because they tend not to be codependent.
      • 2017-04-17 10750, 2017

      • Freso
        Sophist-UK: Maybe don't make PRs just before Easter then. :)
      • 2017-04-17 10758, 2017

      • Sophist-UK
        True.
      • 2017-04-17 10711, 2017

      • reosarevok
        This just seems like a reasonably simple DR
      • 2017-04-17 10719, 2017

      • Sophist-UK
        However some PRs get reviewed faster than others. So its not quite as simple as being Easter.
      • 2017-04-17 10721, 2017

      • Freso opens and looks
      • 2017-04-17 10739, 2017

      • reosarevok
        We currently guess the age at death when we have years only, which means sometimes we miss
      • 2017-04-17 10750, 2017

      • bitmap
        I like the "circa x years" idea
      • 2017-04-17 10757, 2017

      • Freso
        I think that's fine. Maybe add a "ca.", yeah.
      • 2017-04-17 10700, 2017

      • reosarevok
        The options are on chirlu's last comment
      • 2017-04-17 10702, 2017

      • bitmap
        I think it's still useful to display something
      • 2017-04-17 10712, 2017

      • reosarevok
        I personally prefer "60 or 61 years" than circa
      • 2017-04-17 10719, 2017

      • bitmap
        sure
      • 2017-04-17 10721, 2017

      • reosarevok
        But yeah, definitely something, and ideally something less certain than now
      • 2017-04-17 10753, 2017

      • ruaok
        +1 to circa
      • 2017-04-17 10754, 2017

      • reosarevok
        "aged 60 or 61"?
      • 2017-04-17 10755, 2017

      • CallerNo6
        +1 to "60 or 61"
      • 2017-04-17 10702, 2017

      • Freso
        +1 to either option
      • 2017-04-17 10704, 2017

      • reosarevok
        (says "aged 61" now)
      • 2017-04-17 10731, 2017

      • ruaok
        60 or 61 sounds wishy washy.
      • 2017-04-17 10737, 2017

      • reosarevok
        (I guess circa makes it slightly simpler, I just think it looks meh)
      • 2017-04-17 10745, 2017

      • ruaok
        approximately 60 years old?
      • 2017-04-17 10746, 2017

      • reosarevok
        "circa 61" can be 64
      • 2017-04-17 10750, 2017

      • kepstin
        could also do 60–61 or something like that
      • 2017-04-17 10759, 2017

      • ruaok
        about 60 years
      • 2017-04-17 10700, 2017

      • ruaok
        ?
      • 2017-04-17 10706, 2017

      • Quesito
        ~60
      • 2017-04-17 10719, 2017

      • ruaok
        mauve 60
      • 2017-04-17 10723, 2017

      • reosarevok is happy to leave picking the exact wording to whoever implements it
      • 2017-04-17 10730, 2017

      • Freso
        I wonder how this would work with the "approximate dates" ticket...
      • 2017-04-17 10730, 2017

      • ruaok
        all good databases are mauve, says the pointy haired boss
      • 2017-04-17 10734, 2017

      • reosarevok
        If we agree with option b)
      • 2017-04-17 10754, 2017

      • ruaok
        anyone disagree with option b, regardless of wording?
      • 2017-04-17 10707, 2017

      • Freso
        Doesn't seem like it.
      • 2017-04-17 10736, 2017

      • ruaok
        motion carried then. let the implementer do it and then good luck getting through the PR gauntlet. :)
      • 2017-04-17 10742, 2017

      • Freso
        👍
      • 2017-04-17 10750, 2017

      • Freso
        reosarevok: DR: MBS-66666666
      • 2017-04-17 10752, 2017

      • ruaok likes the next ticket
      • 2017-04-17 10755, 2017

      • Freso
        ( MBS-6666 )
      • 2017-04-17 10755, 2017

      • BrainzBot
        MBS-6666: Artist credits not renamed from artist edit page unless the artist name is changed https://tickets.metabrainz.org/browse/MBS-6666
      • 2017-04-17 10710, 2017

      • ruaok
        meh. doesn't mention satan. boo
      • 2017-04-17 10726, 2017

      • reosarevok
        Right now the UI for this is confusing
      • 2017-04-17 10751, 2017

      • reosarevok
        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
      • 2017-04-17 10703, 2017

      • Freso
        I like "hide/disable these controls when there is no change to the artist name".
      • 2017-04-17 10709, 2017

      • reosarevok
        I'd personally want to show it only when the name changes
      • 2017-04-17 10727, 2017

      • ruaok
        seems sane.
      • 2017-04-17 10728, 2017

      • reosarevok
        (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)
      • 2017-04-17 10737, 2017

      • bitmap
        +1 for hding them if the name isn't changed
      • 2017-04-17 10739, 2017

      • Freso
        Yeah.
      • 2017-04-17 10743, 2017

      • zas
        +1
      • 2017-04-17 10745, 2017

      • reosarevok
        (also much less work, since right now it's attached to modbot)
      • 2017-04-17 10748, 2017

      • reosarevok
        Yay :)
      • 2017-04-17 10754, 2017

      • Freso
        Lots of +1's. Anyone against?
      • 2017-04-17 10755, 2017

      • reosarevok
        Can all DRs be this easy? :D
      • 2017-04-17 10757, 2017

      • ruaok
        that was easy. :)
      • 2017-04-17 10700, 2017

      • Freso
        5...
      • 2017-04-17 10701, 2017

      • Freso
        4...
      • 2017-04-17 10703, 2017

      • Freso
        3...
      • 2017-04-17 10704, 2017

      • Freso
        2...
      • 2017-04-17 10707, 2017

      • Freso
        1...
      • 2017-04-17 10708, 2017

      • CallerNo6
        <crickets>
      • 2017-04-17 10711, 2017

      • Freso
        Motion carried.
      • 2017-04-17 10715, 2017

      • ruaok fails the clicktrack test
      • 2017-04-17 10730, 2017

      • Freso
        Thanks for a nice and speedy meeting, with 10 minutes left!
      • 2017-04-17 10737, 2017

      • Freso
        Night all!
      • 2017-04-17 10740, 2017

      • Freso
        </BANG>
      • 2017-04-17 10702, 2017

      • TOPIC: MetaBrainz Community and Development channel | MusicBrainz non-development: #musicbrainz | GSoC Getting Started: https://goo.gl/JTNkn0 | MeB meeting agenda: reviews
      • 2017-04-17 10739, 2017

      • Freso
        reosarevok: Will you post on the tickets?
      • 2017-04-17 10751, 2017

      • reosarevok
        Reopened and posted already :)
      • 2017-04-17 10756, 2017

      • Freso
        👍
      • 2017-04-17 10759, 2017

      • Freso
        !m reosarevok
      • 2017-04-17 10759, 2017

      • BrainzBot
        You're doing good work, reosarevok!
      • 2017-04-17 10701, 2017

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

      • BrainzBot
        MBS-8393: Extend dynamic attributes to all entities https://tickets.metabrainz.org/browse/MBS-8393
      • 2017-04-17 10721, 2017

      • reosarevok
        Not initially at least
      • 2017-04-17 10731, 2017

      • CallerNo6
        okey dokey, thanks
      • 2017-04-17 10734, 2017

      • reosarevok
        I still like basing them on tags
      • 2017-04-17 10758, 2017

      • CallerNo6 too
      • 2017-04-17 10700, 2017

      • reosarevok
        Because it allows easily adding new "genre tags" to the list and immediately have them working
      • 2017-04-17 10719, 2017

      • reosarevok
        The main benefit of using a closed, not-tags-only list IMO is linkability and mbids and rels
      • 2017-04-17 10722, 2017

      • yvanzo
        reosarevok, bitmap: Most inconvenient shortcoming is the editing system: attributes do not have gids.
      • 2017-04-17 10724, 2017

      • reosarevok
        And attributes don't offer that, so
      • 2017-04-17 10736, 2017

      • reosarevok
        yvanzo: they should :) But that's Q4 I guess?
      • 2017-04-17 10746, 2017

      • yvanzo
        yes
      • 2017-04-17 10756, 2017

      • reosarevok
        Anyway, definitely in favour of adding IDs in more places
      • 2017-04-17 10705, 2017

      • yvanzo
        although it might be possible to create temporary join tables for that
      • 2017-04-17 10733, 2017

      • reosarevok
        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
      • 2017-04-17 10747, 2017

      • reosarevok
        Any in-between solutions sound like a lot of work for little practical gain
      • 2017-04-17 10756, 2017

      • bitmap
        gids for work attributes?
      • 2017-04-17 10721, 2017

      • CatQuest joined the channel
      • 2017-04-17 10721, 2017

      • reosarevok
        Well, some permanent way of calling an attribute sounds reasonable, we have them for reltypes
      • 2017-04-17 10724, 2017

      • bitmap
        I know the types and values already have them
      • 2017-04-17 10729, 2017

      • yvanzo
        yes
      • 2017-04-17 10753, 2017

      • yvanzo
        or at least something comparable to aliases
      • 2017-04-17 10711, 2017

      • bitmap is confused which table you want gids on
      • 2017-04-17 10751, 2017

      • yvanzo
        GIDs are not the only possible solution.
      • 2017-04-17 10754, 2017

      • Freso
        All of them!!
      • 2017-04-17 10706, 2017

      • Freso
        GIDs!! GIDs everywhere!!!
      • 2017-04-17 10709, 2017

      • CallerNo6 doesn't know things. GIDs are internal only? (as opposed to MBIDs)
      • 2017-04-17 10715, 2017

      • yvanzo
        bitmap: The issue is more that concurrent edits of attributes can overwrite each other.
      • 2017-04-17 10749, 2017

      • bitmap
        hmm
      • 2017-04-17 10711, 2017

      • yvanzo
        CallerNo6: MBIDs are GIDs, the reverse is not true.
      • 2017-04-17 10736, 2017

      • bitmap
        can't use locking?
      • 2017-04-17 10738, 2017

      • CatCat approves more entities
      • 2017-04-17 10713, 2017

      • CatCat
        but that DR about changing all credits :/
      • 2017-04-17 10729, 2017

      • CatCat
        i want the feature to be able to edit all credits no matter what :O
      • 2017-04-17 10732, 2017

      • yvanzo
        Actually aliases don't have GIDs either and don't have this issue.
      • 2017-04-17 10756, 2017

      • yvanzo
        bitmap: What is probably lacking is specific edit types for editing attributes.
      • 2017-04-17 10759, 2017

      • CatCat
        aliases aren't like dyn.atrib. though...
      • 2017-04-17 10719, 2017

      • reosarevok
        yvanzo: can't all edits overwrite each other? Or you mean that they should conflict and fail?
      • 2017-04-17 10734, 2017

      • reosarevok
        In which case, shouldn't that be done by just storing the original value and comparing?
      • 2017-04-17 10734, 2017

      • CatCat
        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
      • 2017-04-17 10747, 2017

      • yvanzo
        reosarevok: Sorry, it is just that the last one wins.
      • 2017-04-17 10753, 2017

      • reosarevok
        (I see the attribute types have MBIDs)
      • 2017-04-17 10712, 2017

      • reosarevok
        Oh. I'd say maybe just do like with artist names and whatnot
      • 2017-04-17 10718, 2017

      • reosarevok
        If the data has changed, fail the edit
      • 2017-04-17 10731, 2017

      • bitmap
        I know either iswcs/isrcs or ipis/isnis use some 3-way-merge
      • 2017-04-17 10733, 2017

      • CatCat agrees
      • 2017-04-17 10734, 2017

      • reosarevok
        Which I assume we do by just storing the original value in the edit and comparing on application
      • 2017-04-17 10726, 2017

      • CatCat
        anyway, the ticket was more about letting someone batch alter artist credits in the rel-editor :/
      • 2017-04-17 10742, 2017

      • CatCat
        (which would be a huge boon)
      • 2017-04-17 10754, 2017

      • reosarevok
        Which of the tickets? :)
      • 2017-04-17 10700, 2017

      • CatCat
        the last DR?
      • 2017-04-17 10725, 2017

      • CatCat
        wasnt that about the "change all " instances of artist credit
      • 2017-04-17 10732, 2017

      • reosarevok
        If you mean the 6666 one then I *quite* strongly disagree with that as an option
      • 2017-04-17 10732, 2017

      • CatCat
        in the rel ed
      • 2017-04-17 10735, 2017

      • yvanzo
        Ultimately, ISWC/ISRC/… will be attributes, right?
      • 2017-04-17 10747, 2017

      • bitmap
        probably
      • 2017-04-17 10759, 2017

      • reosarevok
        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
      • 2017-04-17 10719, 2017

      • reosarevok
        No, that was about edit artist credits when editing the artist name :)
      • 2017-04-17 10731, 2017

      • anthony25 has quit
      • 2017-04-17 10735, 2017

      • CatCat
        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??
      • 2017-04-17 10703, 2017

      • reosarevok
        No, batch-changing credits for relationships would be awesome, but it's unrelated to that, that's on edit artist pages
      • 2017-04-17 10711, 2017

      • bitmap
        anyway, it was IPIs and ISNIs that use MusicBrainz::Server::Edit::Role::ValueSet
      • 2017-04-17 10721, 2017

      • CatCat
        reosarevok: edit artist creds when editing artists?
      • 2017-04-17 10723, 2017

      • bitmap
        which merges the values using the current, old, and new values
      • 2017-04-17 10736, 2017

      • CatCat
        uh. i thought that was already unchecked by default because that's a better idea?
      • 2017-04-17 10737, 2017

      • samj1912 joined the channel
      • 2017-04-17 10738, 2017

      • yvanzo
        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.
      • 2017-04-17 10741, 2017

      • bitmap
        but I'm probably misunderstanding the issue, that might not apply
      • 2017-04-17 10706, 2017

      • reosarevok
        CatCat: it's unchecked by default. But it only does anything when you actually change the artist name
      • 2017-04-17 10731, 2017

      • CatCat
        uh.. of course? that's the actual only thing artist credits do :D
      • 2017-04-17 10736, 2017

      • reosarevok
        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 :)
      • 2017-04-17 10738, 2017

      • CatCat
        changing the name :D
      • 2017-04-17 10744, 2017

      • bitmap
        in general I'd like there to be less edit types, though they are useful for searching at present...
      • 2017-04-17 10758, 2017

      • bitmap
        since you can't search for edits that change a certain field
      • 2017-04-17 10703, 2017

      • samj1912
        oh damn