#metabrainz

/

      • mayhem
        it is challenging that our needs fit right between advanced and enterprise.
      • 2022-01-18 01848, 2022

      • mayhem
        I think enterprise is just too much.
      • 2022-01-18 01828, 2022

      • mayhem
        $1500/year for enterprise, given our usage, would be fair. what do you think?
      • 2022-01-18 01844, 2022

      • yvanzo
        Yes, it is what they are offering actually.
      • 2022-01-18 01813, 2022

      • reosarevok
        Can I see the email too, out of curiosity?
      • 2022-01-18 01821, 2022

      • yvanzo
        Sure, just forwarded it.
      • 2022-01-18 01824, 2022

      • reosarevok
        If they offer 50% for open source then enterprise would already be 1800
      • 2022-01-18 01830, 2022

      • reosarevok
        Should be possible to talk about 1500
      • 2022-01-18 01852, 2022

      • yvanzo
        Oh right, $ not € :)
      • 2022-01-18 01856, 2022

      • reosarevok
        Oh, wait, I was checking monthly price :D
      • 2022-01-18 01812, 2022

      • reosarevok
        So yeah, only change is USD vs EUR
      • 2022-01-18 01819, 2022

      • reosarevok
        Worth asking about :)
      • 2022-01-18 01827, 2022

      • mayhem
        I will respond to them directly and come to an agreement.
      • 2022-01-18 01840, 2022

      • yvanzo
        I don’t recall exactly if they mentioned €500 or €1500 during the chat, so better clarify it with them. :)
      • 2022-01-18 01842, 2022

      • reosarevok
        Some language translators talked about how our current strings with placeholders don't really work in their languages
      • 2022-01-18 01805, 2022

      • yvanzo
        They are happy to provide a cut for open-source projects, but we are happy to support an open-source project too. :)
      • 2022-01-18 01808, 2022

      • reosarevok
        And asked us to just have translatable strings for each possibility
      • 2022-01-18 01823, 2022

      • reosarevok
        If we ever move into that direction, we'll need more of those 50k strings anyway :)
      • 2022-01-18 01841, 2022

      • yvanzo
        These are source strings, not translated strings.
      • 2022-01-18 01808, 2022

      • reosarevok
        Sure, but I mean that they've wanted source strings like "cover version of", "cover instrumental version of", etc
      • 2022-01-18 01817, 2022

      • reosarevok
        Rather than that be made via placeholders
      • 2022-01-18 01826, 2022

      • reosarevok
        If we did that, that'd need more source strings :)
      • 2022-01-18 01835, 2022

      • yvanzo
        I don’t think that we will reach 20k source strings easily even with these changes to source strings.
      • 2022-01-18 01801, 2022

      • yvanzo
        But if we do, we can adjust the plan with Weblate accordingly. :)
      • 2022-01-18 01804, 2022

      • reosarevok
        Sure :)
      • 2022-01-18 01829, 2022

      • reosarevok
        Remind me, did weblate help also with translating our docs?
      • 2022-01-18 01850, 2022

      • reosarevok
        We really should decide how to move forward with that :) But it's of course tricky
      • 2022-01-18 01819, 2022

      • yvanzo
        We only have picard-docs on an experimental Weblate instance hosted by outsidecontext so far :)
      • 2022-01-18 01835, 2022

      • reosarevok
        So that goes via read the docs?
      • 2022-01-18 01838, 2022

      • reosarevok
        The actual doc display
      • 2022-01-18 01842, 2022

      • yvanzo
        Yes
      • 2022-01-18 01850, 2022

      • reosarevok
        If it works fine, maybe we should consider moving MB docs there too
      • 2022-01-18 01855, 2022

      • yvanzo
        This is a separate issue, but yes it might be a longer-term option. :)
      • 2022-01-18 01800, 2022

      • reosarevok
        I know, I know
      • 2022-01-18 01805, 2022

      • reosarevok
        I just got reminded because of the docsprint week
      • 2022-01-18 01859, 2022

      • yvanzo
        Right, this really related.
      • 2022-01-18 01809, 2022

      • yvanzo
        +is
      • 2022-01-18 01848, 2022

      • reosarevok
        If we have a tested and working system to translate docs using readthedocs + weblate, that gives a very big reason to move to use that with MB too
      • 2022-01-18 01856, 2022

      • reosarevok
        What does that involve? A github repo for docs?
      • 2022-01-18 01835, 2022

      • yvanzo
        reosarevok: As discussed at the last summit, when moving forward with Weblate migration, we will be able to plan for a community event about translation: introduction + sprint. :)
      • 2022-01-18 01851, 2022

      • reosarevok
        Sure, I know, but that was about the actual site :)
      • 2022-01-18 01851, 2022

      • yvanzo
      • 2022-01-18 01805, 2022

      • reosarevok
        Ok, neat, thanks
      • 2022-01-18 01816, 2022

      • reosarevok
        If we go this route, we might want to have two sets of docs, one for site usage, one for development and API
      • 2022-01-18 01817, 2022

      • reosarevok
        But dunno
      • 2022-01-18 01819, 2022

      • yvanzo
        That is an issue for many users: it requires a GitHub account. It is a bit less user-friendly than MediaWiki.
      • 2022-01-18 01834, 2022

      • yvanzo
        (For user docs at least)
      • 2022-01-18 01843, 2022

      • reosarevok
        That's for sure. But it doesn't require it for *reading* the docs, right? :)
      • 2022-01-18 01812, 2022

      • reosarevok
        We could even still have the wiki as a place to amend docs, but when the team sees changes and we agree with them, we transfer them to github
      • 2022-01-18 01825, 2022

      • reosarevok
        If we wanted to make sure we don't take that away from the community
      • 2022-01-18 01846, 2022

      • reosarevok
        So, like we do now with transclusion, kinda
      • 2022-01-18 01854, 2022

      • reosarevok
        Dunno if it would be worth the hassle, but it's doable
      • 2022-01-18 01841, 2022

      • yvanzo
        I’m not sure there is a reliable conversion tool from MediaWiki to Markdown for a continuous transclusion like this.
      • 2022-01-18 01815, 2022

      • Ansh joined the channel
      • 2022-01-18 01818, 2022

      • reosarevok
        Yeah, I suspect that'd just be "dev copies the change by hand and converts as needed"
      • 2022-01-18 01819, 2022

      • reosarevok
        So, more hassle
      • 2022-01-18 01827, 2022

      • yvanzo
        Another option would be to have our own editing UI on top of a git repository, rather than requiring to use GitHub UI/account.
      • 2022-01-18 01833, 2022

      • reosarevok
        But given that changes don't happen that often, maybe still doable
      • 2022-01-18 01845, 2022

      • reosarevok
        And changes would send PRs?
      • 2022-01-18 01815, 2022

      • reosarevok
        I don't feel the few people who actually edit docs would be too annoyed with having a github account - the new, different formatting might be confusing though :/
      • 2022-01-18 01852, 2022

      • yvanzo
        It’s not just the account, it’s also the UI that is more appropriate for coders than for editors.
      • 2022-01-18 01822, 2022

      • yvanzo
        There used to be GitBook for example, but it’s not open source anymore IIUC.
      • 2022-01-18 01830, 2022

      • reosarevok
        True, just not sure how hard it would be to code a new UI on top. If we can reuse something, maybe
      • 2022-01-18 01800, 2022

      • yvanzo
        I didn’t want to suggest coding a new UI at all :D
      • 2022-01-18 01805, 2022

      • reosarevok
        Oh, ok :)
      • 2022-01-18 01819, 2022

      • reosarevok
        I misunderstood the "our own UI" bit I guess
      • 2022-01-18 01847, 2022

      • reosarevok
        I think the translatable docs would be worth some frustration for the doc editors tbh, because hopefully it'll also lead to less frustration with *edits* of people who can't read the docs in their language :D
      • 2022-01-18 01854, 2022

      • reosarevok
        But it's hard to know for sure
      • 2022-01-18 01813, 2022

      • yvanzo
        There is a cool feature in Weblate: source strings review: Allowing editors to review source strings submitted by developers :)
      • 2022-01-18 01843, 2022

      • reosarevok
        Oh
      • 2022-01-18 01844, 2022

      • yvanzo
        So we can have a collaborative review process without requiring editors to inspect the source code.
      • 2022-01-18 01849, 2022

      • reosarevok
        so they could leave a comment like "typo here"?
      • 2022-01-18 01854, 2022

      • yvanzo
        yes
      • 2022-01-18 01857, 2022

      • reosarevok
        Sweeet
      • 2022-01-18 01803, 2022

      • yvanzo
        Of course, it requires developers to make the changes manually in the source code.
      • 2022-01-18 01851, 2022

      • reosarevok
        Sure, but easier to report there than to make a ticket
      • 2022-01-18 01812, 2022

      • reosarevok
        I assume it also means a translator could ask "what does this refer to, X or Y" and we could answer directly there
      • 2022-01-18 01826, 2022

      • reosarevok
        Are the comments to source strings cross-language?
      • 2022-01-18 01837, 2022

      • reosarevok
        Like, if a Polish translator asks and we answer, will the Italians also see the answer?
      • 2022-01-18 01841, 2022

      • yvanzo
        Yes, it will definitely save time for everyone.
      • 2022-01-18 01829, 2022

      • yvanzo
        Yes, editors can also attach screenshots to source strings to bring more context to other translators.
      • 2022-01-18 01842, 2022

      • reosarevok
        ... can we move yesterday?
      • 2022-01-18 01859, 2022

      • yvanzo
        Sure, it also has time-traveling feature ;)
      • 2022-01-18 01821, 2022

      • reosarevok
        :D
      • 2022-01-18 01810, 2022

      • lucifer
        alastairp: around?
      • 2022-01-18 01814, 2022

      • mayhem
        zas: ping
      • 2022-01-18 01858, 2022

      • alastairp
        lucifer: more or less - I'm about to head for lunch though
      • 2022-01-18 01802, 2022

      • alastairp
        what's up?
      • 2022-01-18 01846, 2022

      • lucifer
        wanting to discuss organizing the rtd docs. like which sections to make and what to put under what section.
      • 2022-01-18 01839, 2022

      • alastairp
        can we do that in ~40 mins?
      • 2022-01-18 01840, 2022

      • lucifer
        can do after you return from lunch.
      • 2022-01-18 01842, 2022

      • lucifer
        sure
      • 2022-01-18 01844, 2022

      • alastairp
        great
      • 2022-01-18 01820, 2022

      • reosarevok
        mayhem: I read the document you sent. One thing I did notice is that there's a lot of emphasis on pre-release drafts and whatnot, which is not something we currently store or deal with (except when they get leaked, I guess D: )
      • 2022-01-18 01800, 2022

      • mayhem
        yes, that is quite a lot of their business.
      • 2022-01-18 01828, 2022

      • mayhem
        and byta doesn't want to create a metadata store.. otherwise we could tell them to hold the data until it can be released.
      • 2022-01-18 01844, 2022

      • reosarevok
        Yeah. I mean, *we* could code a way to hold metadata if we need to
      • 2022-01-18 01859, 2022

      • reosarevok
        It's just that makes more sense for "artist sends album to press to preview"
      • 2022-01-18 01813, 2022

      • reosarevok
        But not so much for "artist sends beats to their collaborator to rap on" :)
      • 2022-01-18 01823, 2022

      • mayhem
        the problem there is that if a leak happens, that metadata appears in our DB. then the artist will say that we leaked it!
      • 2022-01-18 01824, 2022

      • reosarevok
        (since those files are probably never expected to be made public as-is)
      • 2022-01-18 01850, 2022

      • BrainzGit
        [listenbrainz-server] 14amCap1712 opened pull request #1823 (03click-docs…reorganize-docs): Reorganize docs on RTD https://github.com/metabrainz/listenbrainz-server…
      • 2022-01-18 01856, 2022

      • alastairp
        lucifer: hi, I'm here
      • 2022-01-18 01800, 2022

      • alastairp
        looks like I'm just in time!
      • 2022-01-18 01804, 2022

      • lucifer
        just in time :D
      • 2022-01-18 01859, 2022

      • alastairp
        so, this is the split between people who want to use our API, and people who want to write LB? just improving the naming of the sections?
      • 2022-01-18 01831, 2022

      • lucifer
        yes so far that the only chnage i made.
      • 2022-01-18 01851, 2022

      • alastairp
        what's the branch it merges into (click-docs)? is that another PR?
      • 2022-01-18 01802, 2022

      • lucifer
        yes
      • 2022-01-18 01810, 2022

      • lucifer
      • 2022-01-18 01819, 2022

      • lucifer
        the one where we first discussed reorganizing
      • 2022-01-18 01844, 2022

      • alastairp
        yes, strange. when I viewed the branch on gh it didn't say it was part of a PR. I thought that was the case
      • 2022-01-18 01858, 2022

      • lucifer
        oh weird.
      • 2022-01-18 01831, 2022

      • lucifer
        so i think we have 4 types of docs: 1) LB users like picard docs 2) LB API users (plus dump users?) 3) LB server users 4) MeB core team
      • 2022-01-18 01839, 2022

      • alastairp
        so the next thing is to decide how/where to make this 3rd section? "information for deploying production LB, but it doesn't need to be private"
      • 2022-01-18 01851, 2022

      • lucifer
        the first should live on lb.org itself i guess. others on rtd.
      • 2022-01-18 01807, 2022

      • alastairp
        for 1), do you mean "this is listenbrainz. we have listens, you can connect spotify. we have stats!"
      • 2022-01-18 01818, 2022

      • lucifer
        right
      • 2022-01-18 01850, 2022

      • alastairp
        sure. my feeling is that this is probably the least important for now (compared to 3 & 4)
      • 2022-01-18 01853, 2022

      • lucifer
        like we'll need to put out docs on how to ask spotify to get sptofy streaming info that can go website etc.
      • 2022-01-18 01807, 2022

      • lucifer
        right currently we should do 2, 3 and 4.
      • 2022-01-18 01825, 2022

      • lucifer
        that category only came up in my mind because there's lfm page on rtd.
      • 2022-01-18 01839, 2022

      • lucifer
      • 2022-01-18 01809, 2022

      • alastairp
        hmm, good point
      • 2022-01-18 01839, 2022

      • lucifer
        the development part of this could go into 3 but the user facing part should on lb.org methinks.
      • 2022-01-18 01857, 2022

      • yvanzo
        There also might be 3.5 or 4-0.5: LB external contributors?
      • 2022-01-18 01813, 2022

      • lucifer
        yvanzo, right thats category 3
      • 2022-01-18 01821, 2022

      • alastairp
        I don't mind if it stays on readthedocs - it's nice to have a single tool to write documentation and have it all in a single place
      • 2022-01-18 01836, 2022

      • lucifer
        oh i made a type 3 is LB server developers
      • 2022-01-18 01807, 2022

      • lucifer
        right but there's duplication too like we have this page on site https://listenbrainz.org/add-data/ and a clients page in rtd.
      • 2022-01-18 01813, 2022

      • alastairp
        can we put up a quick google doc to try and draft some sections/headings?
      • 2022-01-18 01801, 2022

      • lucifer
      • 2022-01-18 01808, 2022

      • lucifer
        shared with editing privileges to MeB.
      • 2022-01-18 01832, 2022

      • yvanzo
        lucifer: FWIW, MB docs for both API users and external developers are mostly under the same entry too: https://musicbrainz.org/doc/Development/ (not necessarily something to follow, just how it is atm)
      • 2022-01-18 01811, 2022

      • yvanzo
        Of course the best docs around for API is for BB: https://api.test.bookbrainz.org/1/api-docs/
      • 2022-01-18 01815, 2022

      • lucifer
        i see, currently we have it that way tii but find it a bit difficult to find whether something is documented.
      • 2022-01-18 01842, 2022

      • lucifer
        oh definitely! +1
      • 2022-01-18 01823, 2022

      • alastairp
        I've seen other people use swagger, but I've never used it myself
      • 2022-01-18 01806, 2022

      • alastairp
        there's now this uncomfortable middleground where we use sphinxcontrib.httpdomain within python, but it's no way near as interactive as swagger docs
      • 2022-01-18 01849, 2022

      • lucifer
        there's an open LB ticket to make openapi spec. it would be nice but i think we can't integrate with rtd.
      • 2022-01-18 01800, 2022

      • yvanzo
        It is not just about writing docs, so it is beyond the scope of this week, but probably worth it. IIRC, it was part of a GSoC project for BB.
      • 2022-01-18 01802, 2022

      • lucifer
        alastairp: what about docs that are common to pythonbrainz, should we move those under LB for now?
      • 2022-01-18 01818, 2022

      • reosarevok
        yvanzo: oh, those api docs look sweet
      • 2022-01-18 01824, 2022

      • reosarevok
        Should try to do something like it...
      • 2022-01-18 01802, 2022

      • alastairp
        I did some updates to pymbngs on the weekend, and had to dive into the WS docs page again. it bought back memories
      • 2022-01-18 01824, 2022

      • alastairp
        lucifer: for deployment, or other things?
      • 2022-01-18 01845, 2022

      • lucifer
        deployment.
      • 2022-01-18 01853, 2022

      • yvanzo
        reosarevok: This has been suggested before. By the way, should we close MBS-5307? API doc has been rewritten since then, there might even be a duplicate ticket about that.
      • 2022-01-18 01853, 2022

      • BrainzBot
        MBS-5307: ws/2 documentation is incomplete and confusing https://tickets.metabrainz.org/browse/MBS-5307
      • 2022-01-18 01842, 2022

      • reosarevok
        yvanzo: maybe? Close it and they can reopen if needed