A positive outlook going forward

My next installment of MusicBrainz management changes focuses on how we should frame our discussions going forward. Currently there is a lot of animosity in our community and a lot of finger pointing — neither of these are constructive for moving forward, so I will aim to cut these short and focus on fixing rather than blaming.

I’d like to offer an analogy to start this discussion: When two people are in a personal relationship and when that relationship starts falling apart, a lot of negative feelings come up. The two people will often blame each other and be convinced that the other person is the reason for all of their troubles. If you’ve ever had an opportunity to talk to two people in a failing relationship, you’ll probably have seen that failing relationships are usually the fault of both people. I’ve yet to find a relationship that failed, solely on the actions of one person alone. Both people are involved, both people had a hand in it.

That said, I’ll step forward and say it: I am guilty. I am partially to blame for what is going on. Go ahead, feel free to blame me for the troubles we’re facing.

But, that is it. Basta! We’re not going to engage in finding every little thing that was done wrong, by whom and work hard to lay blame. That is pointless and it brings up unnecessary emotions. Instead of finding blame we’re going to find problems to our solutions and we’re going to move forward.

As part of me restructuring MusicBrainz, I’m going to be asking everyone what problems they perceive with the project right now. I will listen to the problems, catalog them and attempt to build a plan for tackling these problems in the future. However, I will insist that problems are stated without aggressive communication (e.g. passive aggressive communication) and without value judgements. If you cannot state your issue without being aggressive or disrespectful, you can count on me calling you on your behaviour. I will not address problems that are stated in an aggressive or disrespectful manner.

For instance, it is not acceptable to say: “I don’t think that anyone is going to listen to me anyway, but I think that because of Joe’s idiotic decision to not allow white space in code, all of our code is a freaking mess — this was the worst idea ever!” This statement has passive aggressive communication, it lays blame and contains a value judgement. One way to express the same concern in a constructive manner could be: “The decision to exclude whitespace from our code has created a number of difficulties for people to follow our code. We should re-consider this decision.”

This means of expressing problems, ideas and solutions allows us to focus our energy on moving forward and improving the project. It avoids painful discussions that won’t gives us much insight on moving forward. As we work to mend our community, I will be relying on these communication tools heavily. If you run afoul of these new communication guidelines, expect me to remind of you of this blog post. 🙂

Restructuring MusicBrainz’ management

In the recent past, the MusicBrainz community has become more fractured with evident tension rising between members of the community, the dev team and myself. I’ve been struggling with trying to find a good way to fix these problems and I’ve attempted making a number of changes over the past few months. Mostly with mixed or bad results, which further increased the frustrations for everyone involved.

While I was on vacation the past two weeks, I had some distance from work and at random points during this vacation a few key issues/solutions became clear to me. Over the next few weeks I will be announcing changes to how I manage this project and possibly some changes to some of our core policies to support these changes. Stay tuned on this blog for more announcements regarding this restructuring.

In the first round of changes, which I will detail in a subsequent blog posts, I would like to:

  1. Re-emphasize that we are an open source project and that we must do all of our work in public. Point 3 of our social contract states: “We won’t hide problems and policies: We will keep all MusicBrainz related discussions open for public view at all times, regardless of their content. All problems and policies related to MusicBrainz will be visible to all.” As problems in our community grew, factions hid from the public view. A lot of development work and development discussion went underground in private communication channels that had no transparency at all. Fixing this will be my most important goal moving forward.
  2. Take control of tasking the development team. Starting this monday, during our weekly development chat, I will take the lead on discussing what tasks the development team should be focusing on. I will need to catch up on a lot of happenings that I haven’t paid attention to recently. I also suspect that we will need to talk quite a bit about which tools we would like to use to manage our short, medium and long term plans. Don’t expect us to magically revamp this process on Monday — Monday will simply be the first step in what could be a long journey to improve how the MusicBrainz dev team is currently managed.

More posts are coming in the next few days!

Team change

Ian (ianmcorvidae), our senior developer on the MusicBrainz project, has decided to leave the project due to personal reasons. I’m sad to see a very skilled engineer leave our team — Ian has done a tremendous amount of great work for MusicBrainz and the MetaBrainz hosting infrastructure. Thank you for all of your hard for in the past few years, Ian!

Ian will remain on our team while he seeks a new professional position, so the change won’t be immediate. That said, now is the time to ask Ian to document whatever pieces of his work that still need documentation.

If anyone knows an experienced perl developer with experience using web technologies, Postgres and the myriad of technologies that MusicBrainz uses, please let us know! I’ll be posting an official job posting next week.

Server update, 2015-07-13

This update contains bug fixes and improvements the new tag voting interface, thanks to feedback from people during the last couple weeks. The plus/minus buttons simply add or subtract 1 from the current score (and are disabled where you’ve already done that). There’s still room for improvement, but hopefully it should be more intuitive now.

We’ve also made duplicate entity detection more immediate—the interface will show you possible duplicate artists, labels, etc. before you submit anything.

Thanks to Nikki and the MetaBrainz team for their work on today’s release. The git tag is v-2015-07-13 and the changelog is below.

Bug

  • [MBS-8322] – Editing entity (now) removes its URL relationship dates
  • [MBS-8434] – Work editor can’t seed both relationship type and target
  • [MBS-8463] – Adding a tag with upper-case letters on the tag page has funny behaviour
  • [MBS-8470] – Bulk tag submission doesn’t work if the same tag appears in different recordings

Improvement

  • [MBS-2873] – In add relationship edits, always display the URL second
  • [MBS-8331] – Move some of the duplicate entity check code to the client
  • [MBS-8464] – tag voting interface doesn’t make sense if you don’t use reddit

Server update, 2015-06-29

Today’s release progresses in finishing up the UI for last schema change. One of the changes introduced was tag voting, and as of this release you can finally upvote/downvote tags on the website. This should make it easier for people to re-use tags and to hide tags they consider wrong.

In other news, artist and place collections can be created now, too.

The rest of the release contains various bug fixes and refactorings (some without tickets, but visible in the git log).

Thanks to JesseW, legoktm, nikki, and the MetaBrainz team for their work. The git tag is v-2015-06-29 and the changelog is below.

Bug

  • [MBS-8430] – SQL exception when undoing creation of a record label: “Controller::Edit->cancel “Failed query: …” “
  • [MBS-8443] – Not possible to remove dates in the relationship editor
  • [MBS-8448] – ISE on Donation Check page

Improvement

  • [MBS-4145] – Up/down vote for tags
  • [MBS-7987] – Event series should be (auto-)ordered by date

Server update, 2015-06-15 (a day late)

This release includes a variety of bugfixes, listed below, plus a few more entities are now available for collections.

The git tag for this release is v-2015-06-15.

Bug

  • [MBS-6065] – Internal server error when double submitting an add artist edit
  • [MBS-8408] – Existing external links can be edited to have deprecated types
  • [MBS-8409] – Track parser won’t parse times for data tracks if there’s a disc ID
  • [MBS-8410] – Track parser can change the data track boundary
  • [MBS-8421] – Recording list on a work’s page has misaligned data
  • [MBS-8425] – Wikipedia extract not shown for artist with Commons link in Wikidata
  • [MBS-8431] – Statistics page sorting is broken

Improvement

  • [MBS-6737] – Improve the warning banner
  • [MBS-8031] – make mirror server’s “return to musicbrainz.org” link go to the right place

Style update, 2015-06-02

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).

Some indications on barcodes were added to the release guidelines.

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.

“Different bootleg recordings of the same concert” was added to the list of things that should be in the same release group.

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
  • [STYLE-431] – Add "marketed by" release-label relationship
  • [STYLE-436] – Add castalbums.org to the Other Databases whitelist
  • [STYLE-447] – Add treble/boy soprano as a vocal type
  • [STYLE-453] – Add "Pathé disc" format
  • [STYLE-472] – Add operadis-opera-discography.org.uk to the Other Databases whitelist
  • [STYLE-487] – Remove honorary titles from artist names
  • [STYLE-492] – Add "printed in" release-area relationship
  • [STYLE-508] – Clarify the barcode field guideline when the scanned value differs from the numerical value
  • [STYLE-511] – Add SMDB to "Other Databases" whitelist
  • [STYLE-515] – Reorganise and clean up Style/English
  • [STYLE-522] – Create a basic Artist Credits style page
  • [STYLE-523] – Update Style/Aliases for "primary for locale"
  • [STYLE-527] – Work-work relationships shouldn’t allow dates

New Feature

  • [STYLE-437] – Add VHD as a media format
  • [STYLE-439] – Add Capacitance Electronic Disc (CED) as a media format
  • [STYLE-442] – Add classicalarchives.com to Other DBs whitelist
  • [STYLE-446] – Work-Event rel: Premiered at
  • [STYLE-450] – Add Copy Control CD (CCCD) as a media format
  • [STYLE-451] – Add Videogam.in to the Other Database whitelist
  • [STYLE-475] – Add artist-place "organist" relationship
  • [STYLE-479] – Add artist-artist teacher relationship
  • [STYLE-483] – Add "incidental music" work type
  • [STYLE-498] – URL whitelist request : mvdbase
  • [STYLE-512] – Add an artist-artist "composer in residence" relationship

Task

  • [STYLE-393] – Drop "EP" attribute from the "single from" relationship type
  • [STYLE-404] – Update series (volume number, etc) guidelines now that we have series
  • [STYLE-414] – Add Spirit of Rock to the Other Databases whitelist
  • [STYLE-441] – Add guideline which covers artists in work disambiguation comments
  • [STYLE-444] – Add a relationship type for linking recordings to their corresponding music videos
  • [STYLE-445] – Add a relationship type for artists featuring in videos
  • [STYLE-491] – Add guideline about where to set a work type
  • [STYLE-496] – Other DB: Traditional Tune Archive (tunearch.org)
  • [STYLE-497] – Other DB: FolkWiki; folkwiki.se
  • [STYLE-500] – Ability to link to bandsintown.com
  • [STYLE-501] – Add "has BookBrainz entry" relationship
  • [STYLE-513] – Add SHM-SACD as a medium format
  • [STYLE-514] – Clarify how "o’clock" should be capitalised in English
  • [STYLE-516] – Add a relationship for linking artists to their tours
  • [STYLE-517] – Update Theatre guidelines to remove link to deprecated Opera guidelines
  • [STYLE-518] – Approve MusixMatch as a lyrics source
  • [STYLE-521] – Label sortname guideline needs updating

Server update, 2015-06-01

We’re back with another fortnightly release of musicbrainz-server. A small set of bugs this release, as we’re still primarily working on the bits of UI that were not finished for last fortnight’s schema change release. MBS-7489, relationship artist credits, is now finished, and (not listed below), work collections are done and ready to be used. Still remaining are collections for a variety of additional entities (eventually, everything but URLs, which would just be silly) and tag upvoting/downvoting. Thanks to all contributors and we hope you enjoy these improvements!

The git tag for this release is v-2015-06-01.

Full list of bugs:

Bug

  • [MBS-8187] – URL with open edits not removed when no relationships are left
  • [MBS-8341] – Can’t seed work attributes to /work/create: HFH: param clash for edit-work.attributes value
  • [MBS-8384] – Series-series relationships aren’t displayed
  • [MBS-8401] – “send email” broken for me (only?)

Improvement

  • [MBS-7972] – Make edit relationship edits auto-edits when the endpoints don’t change

New Feature

  • [MBS-7489] – Artist Credits for Relationships

Task

  • [MBS-8375] – Add a bunch of new sites to otherdbs
  • [MBS-8378] – Fix redirect on /tags link to docs

Schema change release, 2015-05-18 (including upgrade instructions)

Our previously mentioned schema change release is finished! Below will be upgrade instructions, including configuration updates for replication access tokens.

This release does not include UI for several of the schema change patches, which will (hopefully) happen for next release on June 1. The incomplete patches are MBS-7489 (credits for artists in relationships), MBS-4145 (tag upvote/downvote), and MBS-8004 (collections for additional entity types). These patches have had their schema change components finished, but the UI was incomplete or needed more work.

Schema Change Upgrade Instructions

These are largely as previous upgrade instructions, using the tag v-2015-05-18-schema-change. The primary difference is the inclusion of configuring an access token for replication.

  1. Make sure your REPLICATION_TYPE setting is RT_SLAVE and your DB_SCHEMA_SEQUENCE is set to 21 in lib/DBDefs.pm. If you’re running a standalone server, you can run the upgrade, but it may be easier to just import a new data dump!
  2. Ensure you’ve replicated up to the most recent replication packet available with the old schema. (if you’re not sure, run ./admin/replication/LoadReplicationChanges and see what it tells you; if you’re ready to update, it should say “Mismatched schema sequence, 21 (database) vs 22 (replication packet)”).
  3. Take down the web server running MusicBrainz, if you’re running a web server.
  4. Turn off cron jobs if you are automatically updating the database via cron jobs.
  5. Switch to the new code with git fetch origin followed by git checkout v-2015-05-18-schema-change
  6. Run ./upgrade.sh (or carton exec -Ilib -- ./upgrade.sh if you’re using carton, with very old setups).
  7. Run cpanm --installdeps --notest . to ensure your perl-based dependencies are up to date. This release adds a dependency on LWP::Protocol::https, for fetching replication packets from the new server; many systems may already have this installed, but it should be verified.
  8. Set DB_SCHEMA_SEQUENCE to 22 in lib/DBDefs.pm as instructed by the output of ./upgrade.sh
  9. Assuming you have been updating your server with replication, it will now be necessary to configure an access token:
    1. Go to https://metabrainz.org/supporters/account-type and choose your account type as applicable. If you’re an individual, non-commercial user of the data, choose “non-commercial”; if not, choose an applicable tier in the “commercial” section. If you’re not sure of the appropriate tier, make your best guess; it can be adjusted if necessary.
    2. Then, from https://metabrainz.org/profile, create an access token, which should be a 40-character random alphanumeric string provided by the site.
    3. Finally, add this token to lib/DBDefs.pm under the REPLICATION_ACCESS_TOKEN configuration option. The final configuration section should look something like sub REPLICATION_ACCESS_TOKEN { "ck3UpgwgOXhWC6SpFcd99rZOTjzfrei3gQlgZZ9z" }.
    4. Don’t reveal your access token! If you do, inadvertently, you can use the MetaBrainz site to generate a new token, invalidating the old one. (The one in the example above is one I created for myself and then invalidated — don’t get any ideas, it won’t work!)
  10. Turn cron jobs back on, if applicable.
  11. Restart the MusicBrainz web server, if applicable. It’s also recommended you restart memcached.

Finally, the list of bugs closed this release:

Bug

  • [MBS-4436] – Medium titles cannot be longer than 255 charaters

Improvement

  • [MBS-1347] – Implement aliases for release groups, releases and recordings
  • [MBS-7906] – maybe don’t show “”≠null diff. in edit pages
  • [MBS-8279] – Remove empty_artists etc. database functions

New Feature

  • [MBS-8302] – Add Live Data Feed access token support

Task

  • [MBS-8266] – Make medium titles VARCHAR NOT NULL
  • [MBS-8278] – Update DB_SCHEMA_SEQUENCE in DbDefs.pm.sample
  • [MBS-8283] – Remove DB constraint that disallows empty event names

Not included in this list but also relevant is MBS-8349, which while fixed for a previous release, in this release is also applied to old slave servers, which may help performance for some queries.

New MetaBrainz site, new look and Live Data Feed access tokens

If you’ve been following this blog, you’ll be aware that we’ve been working on a complete overhaul of our branding and the look and feel of our web sites. While we still have a few minor adjustments to make here and there, we are happy to present you with our newly re-designed MetaBrainz Foundation web site.

MetaBrainz

New features of this site include our new site design, new logos, showcasing our projects and our customers, and HTTPS support. But the most important feature of this new site include online sign-up for commercial use of our data and access token generation for our Live Data Feed.

Two months ago we announced that as of today our Live Data Feed would require an access token in order to download the replication packets. These access tokens are available for free for private use and available on a sliding support scale for commercial use. Starting right now, you may go to the new Sign Up page and associate a new MetaBrainz account with your existing (or new) MusicBrainz account. Once you complete the sign-up process, you will be able to generate an access token to use with our Live Data Feed. We will post details on what to do with this access token after the schema change release takes place later today.

We’ve needed this new site for years and years, but have always been too busy focusing on our flagship project MusicBrainz. But, with help from Roman Tsukanov (aka Gentlecat) and MonkeyDo, we have finally released a web site that both brings us into modern times and streamlines the process for commercial users to start using our data.

If you are curious about what logos we chose for our other projects, see the animation on the MetaBrainz home page. Soon we will roll out the new site design onto CritiqueBrainz, BookBrainz, Cover Art Archive and our Picard site. However, since MusicBrainz is not built on the Bootstrap toolkit it will take us a while to roll the design out onto that site.

Thank you to Gentlecat, Nicolas at MonkeyDo, and everyone who gave feedback on the many logo and site designs that have been floated here for the past few weeks.