Yes! It’s been quite some time since you last heard from me, hasn’t it! But despite the lack of blog posts, I haven’t been faffing around the *entire* corona time! Instead we have been updating quite a lot of instruments with IROM images and also doing a few tickets here and there, as well as updating A LOT of aliases.
But thankfully now we’ve stepped up a gear again and can release a proper (albeit small) release! I present to you Endelig Belg!
Finally we also looked into some other instruments, including checking the aliases and disambiguations for harmonium/reed organ as well as adding and sorting out various other related instruments and their aliases and IROM images. These don’t all have tickets, but see the list of things that have been closed in the meantime for some of it.
Do not despair Fellow Instrument Afficionadoes! The broad strokes of another MiniVersion have already been done as well!
I am pleased to announce that long time contributor and complainer about our UI/UX, Simon Hartman, AKA aerozol has joined our team as a part time designer!
While we are starting with a very modest 3 hours of his time per week, we feel that this marks a rather important step forward for our team. While we now have two team members who have UX/design skills (Monkey and Akshat), they also carry a significant load of engineering tasks working on their respective projects.
Having Simon as part of our team will allow us to carve out concrete design tasks for him to focus on. Simon and Akshat will also revive our long dormant design system, which lets us create UI components that are intuitive and consistent. Our engineering team will be able to re-use these components across our sites, simplifying the future development of new pages. We hope that this shared design system will improve the user interface across all of our sites, with a strong focus on bringing the MusicBrainz UI into the modern age.
Having concrete help on the design front has been needed badly for a long time, which makes me very excited to welcome Simon to our team. Welcome!
This was one of the initial Ensembling-version/family/ensemble instrument-type inspiring tickets.
Initially added on September 2017, it was delayed because it required all the sub-tickets for each instrument being created (and I’m lazy!).
Eventually GCI student mathure, with help from GCI finalist TheFaR8, researched and added a lot of the missing sub-ticket instruments. Many, many thanks to both of them!
There are still however many more gamelan instruments not yet added – if you want a particular one, please add a sub-ticket under INST-556!
Likewise there were a couple instruments that we couldn’t add, since they need to wait for MBS-9642 to be implemented and voice types becoming “instruments”, those being:
There’s also at least one more vocal “instrument” that has no ticket yet, but also can’t be added for the same reason: the kecak (a type of chanting). Additionally, alok and senggakan seem like they might also need adding, but I actually have no idea what these are since they only have Wikipedia page in Javanese ︎😅︎
⌛︎
Remember what I said previously about getting rid of metallophone? :D
hahaha, what a difference in opinion research will bring… ♪;︎
Since the gamelan included so many percussion idiophones (especially metal/tuned ones) it became a natural continuation fix of our previous (clapper tree mini-version).
That meant that we could finally fix up the metallophone/xylophone/lithophone mess under percussion idiophone!
This also included merging tuned percussion into percussion idiophone (“tuned percussion” as an instrument terminology on Wikipedia was deprecated anyway) and sorting out chimes and other related suches.
Stay tuned for कुछ वीणा सम्बन्धित चीजें!
¹ suuper thanks to ’19 GCI student Antara for additional research on this ticket.
I also decided to close the tambouras (strings) version, as after much delay there wasn’t really much progress on it. I had started work on these way back in January, adding the Tamburica instruments (see Instruments part two).
However, by the time ASP came to an end it had became clear to me that I had to move on from dwelling on this, to feel like there was progress and avoid burning out.
Now, after over half the INST tickets have been closed, I had a bit more experience and I could finally finish work on this + some random stragglers left over from the “next” version.
Anyway, after all that, I decided that the thing we needed to do, was to, Get Serious
It’s time for Instruments again!
Now that I was allowed to create fix versions I set about creating such fix versions! (And also, retroactively (re)creating previous batches where these seemed logical.) This also meant creating JIRA Tickets for instruments I had already added without tickets, like the Taonga pūoro instruments.
By now, I was also starting to see the limits of the relationships between instruments we already had, so I was already thinking about what relationships could be added to improve the way we link things. As such, I created a topic to discuss some ideas I had (Reader beware! This is an early and now outdated idea-thread! (More on this in a later post!))
[INST-379] – Add aliases to the Melodica instrument
[INST-398] – add aliases to three hole pipe (was Flauta de 3 agujeros)
[INST-438] – Missing search hint aliases for sax instruments
[INST-441] – Typos in descriptions of pipe and tabor
[INST-443] – Add aliases to three-hole pipe and tabor
Quite a lot of tickets!
Eventually I came to recreating the Taonga pūoro tickets (previously I just added the ones in the Wikipedia page). It became clear to me that this was huge task and deserved it’s own version:
Taonga puortwo: 2017 May 9th to 25th
Updates
[INST-388] – adding "Taonga Puoro" to instrument tree (while technically these were all added in the first batch, pretty much every single one of them were updated and expanded.)
In the past couple years, we’ve steadily reduced the amount of standardisation we do, instead preferring to stick closer to the original release information (except for obvious errors) and let the end users do any standardisation as desired. The main rationale for this is that it’s generally easy to standardise automatically, but impossible to get the original information back: as such, standardisation is best done on demand over the original data. The last big step of this process is to simplify and soften the very restrictive featured artist guideline.
The guideline was originally written when we could only store one artist per track/release, as “add (feat. X, Y & Z) to the track title”. This allowed us to enter the featured artist information on the track title in a standard way in order to deal with it better in the future. And that worked fantastically: in fact, it allowed us to write a series of reports (for release groups, releases and recordings) that make it easier to find entities where the artists need to be moved to their rightful place in the artist field, now that we can!
When we started migrating the info to artist credits, we decided to basically keep the guideline as-is, but start adding the artists to the artist field. So we’d have “Song”, by “Artist feat. X, Y & Z”. This was a huge improvement, since the artists were now properly linked, but such strong standardisation was always a bit heavy handed, and at the same time quite restricted (since it only applied to variations on the word “featuring”, but not to any other linking phrase).
As such, we’ve decided to stop standardising credits using variations of “featuring” as well. The new version of the guideline can be found as part of the artist credit guidelines, and reads:
Featured artists should always be entered in the artist credit, not in the titles. You should generally enter the credit as it appears on the release, omitting any separators (like parentheses) that are intended to separate it from the track title. For example, if the tracklist has “Artist 1 – Song Name (featuring Artist 2)”, enter “Song Name”, by “Artist 1 featuring Artist 2”.
This decision was taken a few weeks ago, but to avoid disruption we waited until we had a Picard plugin available for anyone who still wants to standardise “featuring” in their own tags. That’s now available (thanks to Sambhav Kothari), so we feel it’s the time to make the change official. If you want to keep all variations of “featuring” as “feat.”, go ahead and install that plugin, and things should remain basically as they were!
One last note: I strongly encourage people not to vote against any edit moving featured artist information from the titles to the artist field, even if it doesn’t exactly follow the wording used on the cover. As always, any clear improvements like this one should be accepted, even if they’re not perfect, and the data can be improved further afterwards.
Jeez. This has been overdue! So a lot of things happened, and this Community Recap series kind of got put on the back burner, which obviously means a lot of things have piled up, so if I forgot something you thought should have been mentioned, please share it in the comments below. 🙂 I will be doing a few months at a time until I’ve caught up to the now().
From left→right (top) chirlu, reosarevok, ruaok, Freso, (bottom) Leftmost, alastairp, Gentlecat, bitmap, zas, and LordSputnik. Special guest on the laptop monitor: caller#6.
A couple of weeks ago (Oct. 30th through Nov. 1st), the MusicBrainz Summit 15 took place in Barcelona, at Rob “ruaok”‘s place. We had all of the MetaBrainz employees there, Rob/ruaok (local), Michael/bitmap (US), Nicolás/reosarevok (Spain/Estonia), Roman/Gentlecat (recently local), Laurent/zas (France), and myself, Freso (Denmark) – in addition to a bunch of other people from the community: Sean/Leftmost (US) and Ben/LordSputnik (UK), the two lead developers of BookBrainz; chirlu (Germany), long-time volunteer developer on MusicBrainz; and Alastair/alastairp (local), lead of AcousticBrainz. Between us, we represented 7 countries, 8 nationalities, and 9 languages.
We managed to cover a lot of ground on the serious topics, discussing how to avoid data/MBID loss and how to version data, how to deal with labels (the entities, not the corporations…) and other unresolved style issues, how to integrate all the various *Brainz projects more and better, and a bunch of other things. The official notes for the summit is stored in a public Google Docs document. Feel free to read through and it jot down your own comments!
One of the big things was the we decided again-again-again (for the third or fourth year in a row?) to release the translations of MusicBrainz.org. But this time we actually did it! So MusicBrainz.org is now available in German, Dutch, and French (in addition to English) – go check that out if you have not done so already. 😉 At some point in the not-too-distant future™ we will also enable translating all of our documentation. Sean/Leftmost volunteered to look into options for this. Expect to hear more on that later!
Our Style BDFL: Nicolás a.k.a. reosarevok
We had some talk about how and why MBIDs get lost and what we can do to prevent this. As part of this discussion, we decided to make more edits autoedits for everybody. This was partly due to a wish of having a shorter queue of open edits (and there’s been a significant drop in open edits since Nov. 16!), but also very much to avoid losing MBIDs once they have been generated. More in depth discussion of the reasoning (and some of the community’s response) can be seen in the server release blog post and its comments.
We talked about a few other things like genres, reviewing the work of the style BDFL and the community manager, the future direction of the MetaBrainz Foundation, and a couple of other topics. The summit notes should contain more information on what we talked about and decided on these points.
Obviously it was not all talk and talk and talk. There was also plenty(!!) of chocolate. yeeeargh helped us by getting a lot of Ritter Sport as he apparently lives right next to their factory, and sending it along with chirlu to Barcelona. Thank you, yeeeargh! We also managed to take in a vast amount of gelato (Italian ice cream), as there was an amazing gelato place close by Rob’s apartment. And got to walk a bit around the city of Barcelona. And have various social hanging out that only most of the time was Meta-/MusicBrainz related… but not all of it. 😉 Our system administrator, Laurent/zas, also took a bunch of pictures capturing the summit. A few of them are shown here, but you can peruse them all in the slideshow at the bottom.
Finally, a big thank you to Google and Spotify for helping to fund this meeting. It would have been a lot harder to bring all these people together from around the world without their (continued, no less!) support. Here’s to 2016 and summit 16!
Hi everyone! Here we are with another very, very late style update for the last couple months.
Apart from quite a few smaller changes (full list below), we split the translator relationship so that it’s its own relationship rather than lyricist + attribute (so if any of you were using translator data at all you’ll want to change the way you query for it). Similarly, we got rid of the “transliterated” vs. “translated” difference for alternate tracklists: it often wasn’t clearly one or the other, and the information wasn’t particularly useful in any case without checking the language and script of the release, so now there’s only one relationship type without attributes.
We also demoted the “Do Not Cluster” guideline – while it’s a good thing to keep in mind when creating relationship types, it’s not really something users should be worrying about (and the cases where they might have to are already covered in the specific relationship documentation).
If anyone has any question about these or any other changes, feel free to ask in the comments! And if you want to propose other changes or additions, remember you can always do it from the STYLE section of our bug tracker.
Improvement
[STYLE-315] – Remove the option to add publisher relationships to recordings
[STYLE-474] – Introduce the option to add phono rights relationships to recordings
New Feature
[STYLE-481] – Add artist-release group “has dedication” relationship
[STYLE-505] – Add “written at” relationship between work and place/area
Ok, so the “have a report every two weeks” thing didn’t work out very well lately. But things have been happening anyway, so here’s all that has happened in the last few months!
Guidelines for artists have been updated for what is and is not a different artist (since now relationships can also have credits) and for areas (main artist area is still somewhat fuzzy because it is a fuzzy concept, but at least there’s something now).
Also new (although most parts were just moved into it from existing guidelines where they didn’t really fit) are the guidelines for artist credits.
The English guidelines got cleaned up a bit, but without major changes (only the addition of a section on “O’Clock”).
The alias guidelines got updated to take into consideration the “primary for locale” option, and got a section for sort names (based on the old guidelines for label sort names, which were removed since labels themselves no longer have sort names).
The ability for work-work relationships (like “part of” and “version of”) to have dates was removed. Dates should be on the appropriate artist-work relationships, in most cases (like “arranger” and “translator”), and works which get new parts added / removed should be counted as different parent works to begin with.
The guidelines mandating expanding abbreviations like “Vol.” and “Pt.” have been removed (the special exception of “feat.” has not changed). Titles should, in general, follow the release/track title. The only standardisation left is for series: see the series numbering guidelines.
Some basic work guidelines have been added, both for when to set a type and for when (and when not) to add a disambiguation comment.
Apart from that, a fair amount of relationships and release formats have been added and some sites whitelisted. See the full list below for details.
Bug
[STYLE-427] – Style/Artist hasn’t been updated for areas
[STYLE-524] – "Personal label" has the wrong cardinality
Improvement
[STYLE-149] – Update "Artists with multiple names"
[STYLE-203] – Add a "In homage to" relationship to works
[STYLE-228] – Allow grouping of multiple "identical" bootlegs w/ different titles
We managed to cover a lot of ground on the serious topics, discussing how to avoid data/MBID loss and how to version data, how to deal with labels (the entities, not the corporations…) and other unresolved style issues, how to integrate all the various *Brainz projects more and better, and a bunch of other things. The official notes for the summit is 
We also managed to take in a vast amount of gelato (Italian ice cream), as there was an 
MetaBrainz Blog 
