Tag: robustness

Growing pains: An update on the ListenBrainz service status

TL;DR: The growth of ListenBrainz has caught up with us, and our limited team is working on replacing central parts of our infrastructure. In the meantime, many features are unstable.

We are victims of our success. While in the long term this is a good problem to have, the sharp increase in users over the past year and a half has left our infrastructure cracking at the seams.

The good news: Your listens are being stored and imported without issue, even if there are delays. The core service is not compromised and we ask that you please keep submitting your listens. Your stats and playlists will be back!

However, we know that every other week your statistics, weekly playlists, and other features fail to generate for everyone, and cause crashes. We know it is frustrating, and we share that feeling.

While we are aware of the issues, fixing them is far from simple and requires us to completely rework all the crucial parts of our infrastructure.

In the interest of transparency, here are our main issues and what we are doing to fix them:

Continue reading “Growing pains: An update on the ListenBrainz service status”

Robustness principle applied to communities

The great internet pioneer Jon Postel once wrote the following in an early draft of the TCP specification:

Be conservative in what you do, be liberal in what you accept from others

He wrote this in the context of computer networking and this philosophy arguably helped the Internet become robust to faults. Personally, I think this is great wisdom even in a larger scope — it can be applied to many other contexts in life. Today, I would like to apply this wisdom to our community:

If members of the MusicBrainz community could work hard to craft their edits so that they adhere to the guidelines as much as possible and to add supporting links to their edits, that would fit the bill of “being conservative in what you do”. Then, when you consider other edits, be liberal in accepting other people’s edits. If an edit makes the database better, vote yes, even if you don’t fully agree with it. If you see a small mistake and you’re an auto-editor, accept the edit and fix the small mistake. See if you can find a way to accept the edit, rather than shooting it down.

Our attitudes shouldn’t be “How can I shut this person down?”, but “How can I help this person make better edits?”. If an editor gets shut down for small mistakes, the editor is going to be discouraged from doing more edits. This harms the project overall! But, if an experienced editor politely helps a less experienced editor to improve their edits, the less experienced editor will feel more welcomed and is much more likely to continue learning and to continue making more edits.

After all, happy teams are vastly more productive than unhappy teams.

Happy editing!