reosarevok: https://musicbrainz.org/doc/Work/Type would better follow the current structure of the documentation. It could be implemented by replacing on transclusion a placeholder in the wiki page with a React component (listing work types).
2022-01-18 01818, 2022
reosarevok
That would break as soon as we moved the docs to readthedocs or similar, but I guess it's otherwise doable
Wonder if we should have two fields, description and documentation or something
2022-01-18 01851, 2022
reosarevok
(schema change, but trivial otherwise, if useful)
2022-01-18 01817, 2022
lucifer
alastairp: thoughts on where the constants should go. i am thinking one common page of api explaining that we are https only, ratelimiting in future auth too. should constants go here or under individual api pages?
2022-01-18 01802, 2022
lucifer
i think the constants we have currently deal with only single category so individual page should probably be fine.
2022-01-18 01813, 2022
alastairp
yeah, I was going to ask that
2022-01-18 01824, 2022
alastairp
but maybe if we find enough items to put on a "how to use the API" page or section then that'd also be a good idea. rate limiting and auth are good items to put in such a section
2022-01-18 01827, 2022
reosarevok
We could then use that to show the descriptions for the currently selected types in a bubble or something like we do for other types
2022-01-18 01849, 2022
reosarevok
Right now we don't show anything on the release editor nor on "Add RG"
2022-01-18 01805, 2022
yvanzo
Would there be an issue with having large descriptions? (If they are displayed in editing forms for example?)
2022-01-18 01834, 2022
lucifer
👍
2022-01-18 01851, 2022
reosarevok
Well, if they are on the bubble and they close when tabbing away, probably not a huge issue either way
2022-01-18 01819, 2022
reosarevok
But I would still probably prefer just showing a basic one or two lines description, with a "see more" option for further documentation
2022-01-18 01827, 2022
alastairp
I think I may have opened a ticket or made a comment somewhere saying that we should unify all of the bits where we talk about authorization
2022-01-18 01831, 2022
alastairp
but I can't find it
2022-01-18 01831, 2022
reosarevok
It's just that currently requires a schema change, AFAICT :)
2022-01-18 01848, 2022
lucifer
yes i think i assigned it to myself sometime ago
2022-01-18 01831, 2022
yvanzo
A foldable “see more” could be tagged into the description, just like the one in MeB blog posts.
reosarevok: yes “ a comment that we'd parse ” would do
2022-01-18 01858, 2022
reosarevok
So, store RG type descriptions there for now so that they're in the DB. Eventually show them as bubbles. Add a comment to collapse stuff if desired.
2022-01-18 01818, 2022
reosarevok
(maybe easier to do those display things once we have the editors all using React to avoid duplicating work)
2022-01-18 01857, 2022
goldenshimmer
I know Spotify pays a pittance, but if I bought all the music I want I'd probably be broke in a month and end up squished to death by a stack of CDs falling on me...
2022-01-18 01813, 2022
yvanzo
We can also keep the RG type wikidoc page for now, and just retrieve doc from the DB for other new doc pages such as work type.
2022-01-18 01848, 2022
yvanzo
(Whichever way is the simplest to follow.)
2022-01-18 01810, 2022
reosarevok
Sure, I'm also fine with that, but we'll want to add the descriptions to the DB anyway, that way they can also be translated and whatnot :)
2022-01-18 01828, 2022
lucifer
alastairp: another ques, where should pinned recordings go among the api categories in the doc?
2022-01-18 01832, 2022
lucifer
social?
2022-01-18 01830, 2022
alastairp
I wonder if it's kind of related to feedback? they both deal with recordings
2022-01-18 01838, 2022
alastairp
does that make sense? I'm not sure
2022-01-18 01806, 2022
lucifer
yeah, its kinda related. should it be called feeback and pinned recordings then?
2022-01-18 01811, 2022
alastairp
I don't think it's a good idea to just take the name of 2 APIs and call that a section :) what happens if we add another endpoint related to recordings
2022-01-18 01841, 2022
alastairp
for now group them together and call it "Recordings", and then we can look at it and see if it makes sense
i have put the first under recordings, second under recommendations
2022-01-18 01806, 2022
outsidecontext
I can confirm the "temporary holes in Spotifys recently played API" theory
2022-01-18 01810, 2022
lucifer
thanks for looking into that and the detailed ticket!
2022-01-18 01858, 2022
outsidecontext
:)
2022-01-18 01828, 2022
alastairp
lucifer: that sounds like the correct split for these 2 APIs
2022-01-18 01851, 2022
reosarevok
yvanzo: copied those descriptions (with small modifications) to the attribute tables, at least :)
2022-01-18 01841, 2022
rdswift
reosarevok, yvanzo: Actually the Picard docs aren't hosted on readthedocs, but are just served from github gh-pages at this point.
2022-01-18 01822, 2022
rdswift
As for users wanting to make changes to the docs, we're pretty flexible. Easiest is for them to attach the changes to a ticket and one of the maintainers creates the PR.
2022-01-18 01828, 2022
reosarevok
rdswift: so that means you have the rst files on github and then what happens? :)
2022-01-18 01821, 2022
rdswift
Yes, they are on the repo. There is a bunch of github actions to take care of testing and building the actual web site files.
2022-01-18 01817, 2022
rdswift
We maintain a 'master' branch and a 'publish' branch. Changes are merged into 'master' and periodically we merge 'master' into 'publish'.
How do you decide how to organize the docs? What goes where and whatnot
2022-01-18 01849, 2022
reosarevok
I understand this is only user-facing docs, with the dev docs elsewher
2022-01-18 01851, 2022
reosarevok
e
2022-01-18 01840, 2022
reosarevok
I'm thinking for MB there should be two clearly different sets of docs, "how to use the site as a user" and "how to use the data as a data user", but not sure whether that'd mean two read the docs pages, or whether there's a good way to split the page in two like that
2022-01-18 01856, 2022
reosarevok
(since it seems more of a split than just the small headings in the Picard page)
2022-01-18 01853, 2022
rdswift
<reosarevok> How do you decide how to organize the docs? What goes where and whatnot? That's the role of the editor. Pretty much hit & miss right now. The docs just sort of "evolved" and I'm looking at possibly some restructuring.
2022-01-18 01820, 2022
rdswift
It would have been nicer if I had a "master plan" in the beginning. ;-)
2022-01-18 01857, 2022
rdswift
I think that it might make more sense in your case to plan on having two separate docs -- site use and data use.
2022-01-18 01830, 2022
reosarevok
So if we used your system that'd mean two repos?
2022-01-18 01825, 2022
rdswift
That would likely be the easiest, but it might be possible to do it in one. I'll have to give it some thought.
2022-01-18 01801, 2022
reosarevok
I mean, it might be easiest to have it in two repos also for translation, so that MB users can translate the docs for the site while data users can translate the other docs
2022-01-18 01815, 2022
reosarevok
Since I expect they'd not always be the sane people
2022-01-18 01821, 2022
reosarevok
... that too, but I meant same :D
2022-01-18 01855, 2022
rdswift
Possible to do it as two 'master' ('master_site' and 'master_data') branches and do some fancy github actions processing for the actual publishing.
2022-01-18 01822, 2022
reosarevok
bitmap, yvanzo ^ when you have some time it'd be fun to look into this
2022-01-18 01838, 2022
rdswift
I think it might be cleaner as separate repos though.
2022-01-18 01842, 2022
reosarevok
Yeah, me too
2022-01-18 01853, 2022
rdswift
The nice thing about weblate is that it can create a glossary for both and provide suggestions across repos.
2022-01-18 01850, 2022
reosarevok
Oh, neat, so we could have a shared glossary for both MB itself *and* the MB docs?
2022-01-18 01805, 2022
rdswift
Yup. The setup that outsidecontext maintains has a gloossary for Picard and another for Picard-docs and we can access both.
2022-01-18 01834, 2022
rdswift
I would LOVE to have MB in there as well, for consistent use terminology. Right now the Picard Docs are a bit disjointed in that regard.
2022-01-18 01838, 2022
rdswift
*use of terminology*
2022-01-18 01846, 2022
reosarevok
Well, if mayhem's conversation with the weblate people goes well, hopefully we will :)
!m mayhem & zas or increasing bus/tram/whatever factor!
2022-01-18 01849, 2022
BrainzBot
You're doing good work, mayhem & zas or increasing bus/tram/whatever factor!!
2022-01-18 01858, 2022
CatQuest
reducing? whatever
2022-01-18 01805, 2022
mayhem
increasing
2022-01-18 01802, 2022
Lotheric has quit
2022-01-18 01809, 2022
CatQuest
yea, since number s 2 now
2022-01-18 01802, 2022
mayhem
congrats and thank you, CatQuest.
2022-01-18 01824, 2022
mayhem
I got boosted while I was in Cali/.
2022-01-18 01800, 2022
CatQuest
pfifer or modena?
2022-01-18 01804, 2022
CatQuest
I was actually given the option :o
2022-01-18 01804, 2022
mayhem
I was too and got moderna, since the first two were pfizer. wanted some cross training.
2022-01-18 01840, 2022
outsidecontext
rdswift: the MB glossary is also in the weblate and also assigned to Picard and picard-docs. But I just recently realized I'm about the only one seeing it :(
2022-01-18 01810, 2022
outsidecontext
Because the project is not public. But that's something we can than get right once there is the MB weblate
