Category: Style Guidelines

Style update, 2014-12-03

After skipping a fortnight because of concentrating on the schema change release, here’s the next edition of the style update, with all the changes from the last month. Most of the changes involve adding new medium formats and new place/area relationships, plus making changes and additions related to the new schema change features (events and data tracks).

The biggest change this month is the addition of a classical music titles guideline. This deprecates the old Opera Tracks guideline, and basically just provides a certain amount of standardisation while keeping mostly true to the on-cover titles.

Improvement

  • [STYLE-221] – Add Data CD format(s)
  • [STYLE-354] – Add a new medium format "dts Audio CD" for CD’s that are encodes as DTS streams
  • [STYLE-367] – Add an attribute for performing time to event artists

New Feature

  • [STYLE-344] – Style for classical track titles
  • [STYLE-356] – Add a "part of" event-event relationship
  • [STYLE-371] – "Subseries" relationship (needs MBS-8055 to actually work)

Task

  • [STYLE-349] – Update special purpose track title for data tracks
  • [STYLE-350] – "Engineered at" Place relationship
  • [STYLE-351] – Release group official website wording causes it to be misused
  • [STYLE-352] – Add relationship types for setlist.fm
  • [STYLE-357] – Add event type "clinic"
  • [STYLE-359] – Merge "Videotape" into "Other"
  • [STYLE-360] – Add Playbutton as a medium format
  • [STYLE-361] – Add music card as a medium format
  • [STYLE-363] – Add VinylDisc as a medium format
  • [STYLE-364] – Add DVDplus as a medium format
  • [STYLE-365] – Add 3.5" floppy disk as a medium format
  • [STYLE-366] – Add Edison Diamond Disc as a medium format
  • [STYLE-368] – "Edited at" Place relationship type
  • [STYLE-369] – Disable dates for event relationships
  • [STYLE-370] – Place(/Area)-Recording rel: produced at
  • [STYLE-379] – "remixed at" place-recording/release relationship type

Style update, 2014-11-03

As mentioned when the new style process was announced, at a similar time to every server release post we’ll be publishing a list of what’s changed in style during that period.

The first period of two weeks (or three, in this case) under the process has passed, and these are all the style-related issues that have been accepted and implemented during it. Most of them are very small (mostly adding sites to the whitelist for the Other Databases relationship) although a couple are new relationships or relationships being extended to more entities.

No changes to the guidelines themselves have happened during this period.

  • [STYLE-211] – Allow new allmusic.com release links
  • [STYLE-250] – Add finnmusic.net to the other databases whitelist
  • [STYLE-251] – Add pomus.net to whitelist
  • [STYLE-256] – Add fono.fi to the other databases whitelist
  • [STYLE-269] – Add mixing and mastering to area relationships
  • [STYLE-307] – グラスレ（grass thread／yunisan） as Artist and Label “Other DB” relationship
  • [STYLE-308] – ジャパメタ（japameta） as Artist “Other DB” relationship
  • [STYLE-312] – Add “Deutsche Nationalbibliothek” to whitelist for other databases
  • [STYLE-328] – Add leader/concertmaster artist-release/recording relationships
  • [STYLE-337] – Add IMSLP relationship to artists
  • [STYLE-338] – Add Stage48 Wiki to the other databases whitelist
  • [STYLE-339] – Add CiNii to the other databases whitelist
  • [STYLE-340] – Add NDL to the other databases whitelist

Changes to our style process

At the MusicBrainz Summit last month in Copenhagen, one of the topics to
be discussed was the state of the style guidelines and style process.
One thing those present agreed on was that the process was in need of
reform, for several reasons: the complexity of the process,
inconsistency with other processes in the project, the high level of
individual commitment required to make changes, long-running discussions
without conclusion or followthrough, and ultimately the state of the
final product, the style guidelines themselves. The inaccessibility of
our existing process meant that many users, both new and old, avoided
the style process, and this hurts the project: style is part of what
makes MusicBrainz what it is, and low participation means our guidelines
have grown both internally inconsistent and out of sync with community
practice. Nor is the style process a new problem for MusicBrainz:
historically, it’s changed several times and some past style leaders
have vanished into thin air.  After all, it is a hard job, for a
volunteer, to convince many voices to come to a consensus.

To improve upon these issues, we’ve decided to make two major changes.

First: to designate our JIRA issue tracker at tickets.musicbrainz.org as
the central coordination point for style issues. This way, any issue, be
it style-related or code-related, is reported and discussed in the same
place (and should an issue be misfiled, it’s easily corrected). The
issue tracker can also collect links to other discussions, in edit
notes, the forums, IRC, etc., and store links to related issues such as
features in need of implementation.

Second: to promote our current Style Leader to Style Benevolent Dictator
For Life (Style BDFL). Nicolás Tamargo (reosarevok) will then be in
charge of considering tickets and implementing changes in the style
guidelines. This change shifts the burden of evaluating style issues
from the community to our newly appointed BDFL. For simple changes and
for simple improvements to consistency and writing style, the BDFL can
change things directly, without need for lengthy discussion. Of course,
his work won’t happen in a vacuum: for changes that are complex or
contentious, the role of the BDFL will be to gather feedback and
determine the next steps before making changes. To this end, he may
occasionally call for a non-binding vote on a particular topic, to
collect a snapshot of community opinion to augment existing discussion,
all in order to make a better informed decision.

We hope that this new process will make contribution to the creation of
style guidelines easier and less onerous a commitment for everyone, and
that the resulting style guidelines will be more up-to-date, more
consistent, and more clearly written and organized. To test it out,
we’re going to try this process for 6 months, and then review how things
have progressed and if the process needs further tweaking or even
complete replacement.

New Guidelines for Recordings

We got this from Ben, who has been in charge of taking this discussion forward:

Since the beginning of the year there has been a lot of discussion about recordings and what exactly they should be used for. After several meetings on IRC and a couple of huge topics on the style mailing list, we’re finally ready to bring in a new definition for recordings, and new style guidelines to go with it!

The new recording definition can be viewed at http://musicbrainz.org/doc/Recording

And the accompanying style guidelines are at http://musicbrainz.org/doc/Style/Recording

The new guideline brings significant changes to the way recordings should be used, so all editors dealing with recordings should take the time to read it.

As a short summary, recordings are now never produced solely through copying or mastering. This means that recordings shouldn’t distinguish between different masters of some audio – in general, a recording will correspond a particular mix or edit. In addition:

– AcoustIDs and ISRCs have been removed from the guideline – they are mostly irrelevant for managing recordings under the new definition.
– Guidelines for audio channels have been introduced.
– Existing guidelines have been expanded.
– Several in-depth examples have been added to explain how recording should be used.

Also, as a result of these changes, the recording-recording remaster relationship type and the artist-recording master relationship type have been deprecated.

Thanks to everyone who was involved on mb-style and in the IRC meetings for your excellent ideas and contributions!

New Style Leader and Updated Proposal Process

Nicolás Tamargo (reosarevok) is replacing Kuno Woudt (warp) as style leader. This will allow Kuno to fully concentrate on development, and also allow our other style leader Nikki to dedicate more of her time to testing changes and make it less likely for us to have botched releases.

We are also updating the proposal process, and tying it to the Jira tracker, to avoid the manual updating of the proposal table and problems with two people using the same proposal number by mistake. The updated system is at Proposals – the huge table there has been moved to Proposals/History

Please welcome our new Style Leader: Nikki

The MusicBrainz Style Leader has a really hard job — this position requires people to to have a thick skin, a deep understanding of MusicBrainz and the patience of a saint. Its a really challenging job! And because of this, people burn out fast and generally abandon their jobs after a while. This has been the pattern for many years for us and its been very frustrating. And now its has happened again: Brian, the Style Leader up til today, has not been responding to me. I’ve not heard anything from him in weeks.

In an effort to try and break out of this cycle, I am going start a new experiment: Make the Style Leader a paid position.

While we have some money in the bank, its not massive amounts of money and the pay for this position reflects just that. Its not a whole lot of money, but I am hoping its enough money to offset the pain of being the Style Leader and will keep the Style Leader engaged over a longer period. With that in mind, I am proud to announce that Nikki will be our next Style Leader and our first paid Style Leader.

Nikki has been tasked to ensure that the style process moves along and is properly documented. Her goal is to drive consensus among the brainerz who participate in the important Style process and to keep proposals on track. Once a proposal’s RFC/RFV periods are up, its Nikki’s job to ensure that the proposal is acted upon by the appropriate people. She should also help to keep the style process evolving as the MusicBrainz style needs evolve.

Thank you for all your hard work Brian! I look forward to working with you more closely Nikki!

BTW: Warp will still be involved in helping Nikki lead the style process, but his focus is on NGS for the time being. We’re very much dedicated to staying focused on delivering NGS as soon as we can.

Release groups & ISRCs: Please help us test this release!

We’ve hammered out many of the rough edges from the upcoming release and now we need your help to test the release to spot any problems that may have slipped past our new code review process.

New in this release:
– Release groups: This allows us to group same titled releases from one artist that have slightly different track lists into release groups. For instance, here is a Weezer release group that has many separate releases in it. We have converted as many batches of releases to release groups as we automatically could, but there are tons left to do. We’ll need your help!
– ISRC support: We can now track ISRC codes. While this is less useful to end users, our commercial customers have been asking for this for eons.
– WikiDocs: Our WikiDocs system now uses our new Mediawiki to pull documentation from.
– Bug fixes from our last release.

Aside from a good chunk of the bug fixes, all of these things are now live on our test server. Please report bugs to our bug tracker and make sure to select the “Server: ReleaseGroups, ISRCs, Bug Fixes” milestone so we can spot your bugs fast. Also take a look at the bugs we’ve already closed for this release and which ones are still outstanding.

We have one major known issue, where some release groups may be found in the search engine, but will give a “release group not found error” (example). This is a known bug.

Finally, do the release groups as we have them now make sense to you? There are a few things that may not be entirely clear, so we’re looking for feedback how to make things more clear before we release this on May 24th.