If these huge lists are breaking the site, I say get rid of them. Equally, we see a poor definition of these special entities, as, the huge lists appear to be, in part, a response to a certain interpretation of the ill-defined [worldwide]. I can’t find an explicit/sensible definition in the documentation of what [worldwide] actually means.
Is it purposefully vague, or, is does it explicitly mean every country?
I agree with the stop-gap suggestion to reduce the slow-down/breakage of the site, by the way.
I personally like very much, that all possible information is added to MB. The usability is, like already mentioned before, very bad when using such long lists. If it would be possible to keep the data in the vein “licensed for/in state” vs. released in “worldwide” it would be great.
i am very strongly opposed to a digital release country. the music is being restricted to certain countries, even if it’s just through the internet. i am one of the editors who is interested in this information of where a release is available. musicbrainz has always tried to be the place to store all information for releases. i believe we should introduce an excluded countries field instead, where we can select just the countries in which a release is not available. then, we can enforce that whatever list is shorter is acceptable.
Please refrain from massively replacing long release event country lists with worldwide release event for now because it slowdowns search indexing even more than adding multiple release countries initially did.
Additionally it doesn’t seem that any decision has been made about it. Would it be the case, removal edits should preferably be entered by a bot so that this huge task can be done and at a controlled rate.
In the longer term, there are plans to make indexed search not impaired by removing long country lists thanks to the dbmirror2 replication for which the foundations have been delivered in May 2022.
P.S. This post is solely from the technical perspective of indexed search. I will read the posts of this thread further to reply later on about the other above mentioned issues.
As for the marlonob instance, while cleaning up the annotations I’ve noticed quite a lot of editors were still using it including newbies. Now it’s dead
A while ago I did ask a prolific newbie to not add 200+ release events and forwarded a long-term editor to this thread. It wasn’t fruitful in either case…
No one should be replacing them with Worldwide anyway unless they are truly worldwide. I can see blanking them (which is what I’ve been doing). Is it a problem to blank the country lists as well or just marking them Worldwide?
If there is no animosity with these editors, yes absolutely but only once. It can be helpful to inform them that such long release event lists are triggering technical issues in MB at the moment and to point them to this thread. Many editors seem to enter long release event lists because of the seeder they use. They don’t necessarily mind about these long release event lists but they most often mind to keep MB working.
However if they persist to enter long release event lists (for example because they believe they have a good reason for it), please don’t get into an edit/note/vote dispute about it. There are currently no guidelines about release events and most of these seem to have been added in good faith.
After the formal decision will be made and the documentation/guidelines updated/completed, such edits may become definitively unwanted or even impossible, for example by making the release editor to block entering more than X release events at once.
With @reosarevok’s permission I’ve put this topic on the agenda of MeB weekly meeting to discuss technical limitations and possibilities. It will be introduced tonight and discussed more thoroughly on the 9th of January 2023. I’m preparing a synthesis of the alternative solutions that have been proposed with a rationale so far. So, a poll if needed and, a final decision can be expected in January at the latest.
It’s unfortunate but for their defense neither docs nor guidelines have ever been clear about release events. Hopefully it will be clarified soon or even possibly limited; See my above reply to @yindesu.
I’ve also seen that it can be fruitful too, such as the discussion on edit #88676322.
Also thank you @chaban for having reported some of the technical issues about release events:
No release is “truly worldwide” anyway so “[WorldWide]” certainly has to be used for something.
Yes. The current problem is that the search indexer barely follows the editing of long release event lists. It doesn’t matter whether you blank it or you replace it by “[Worldwide]”. So far it has only kept indexed search outdated for some hours, but it could result in some entities entirely missing from indexed search.
There are 38K releases with more than a hundred of release events, so it will definitely be a job for a bot.
Disagree. The bot shouldn’t mark anything Worldwide. Many instances of a different label having a release in the US and the rest of the world having a different label for example. I’d be okay with either blanked or a new digital/internet option as talked about above. I don’t want to encourage that just because it’s on the internet makes it worldwide.
As pointed out before Pink Floyd uses 2 major labels: Parlophone (Warner) in Europe and a few countries in North Africa & Asia; Sony for the rest of the world. We definitely wouldn’t want to mark all of them as Worldwide as Sony is in about 180 countries and Parlophone in about 54 countries on average. If we could have a bot, that would just blank the country list, but somehow move the countries from the release event and add them to the annotation instead that be cool. Not sure if that’s possible on what you are doing or if someone would have to come up with a third party script.
I’d be cool if it defaulted to a blank country and not worldwide (if it’s not worldwide). Better would be the [digital]. It’s a shame the marlon’s died as it showed Deezer countries that their API shows, but for some reason aren’t on their “official” distribution lists, but that information is available directly from their API if one wants to get it. The main distribution lists now would be the annotation as that seems to be where editors want the info.
But also moreover conceptual issues, if online shop countries are changing with time, as I think I read somewhere in this topic or another (super precise).
Not trying to hijack this, but hopefully those who are using Atisket might see this.
I’m getting real irritated by lazy submitters not setting the correct release date.
You are adding a streaming / digital media entry. It won’t have released in 196x or 197x or 198x… I’m going through and adjusting and posting notes on editors I catch doing this.
These tools are great, and very powerful but a little bit of due-diligence is needed.
It’s a fault with atisket. The tool should stop dates like that from entering the MB data stream. It is well published as to when each of the streaming stores started operation, so a good start will be using that as an initial cut-off. But that then misses those bands who didn’t release on streaming until later…
I also get fed up with seeing these, but it is as much a fault of the tool as the submitter.
True, but if you use a hammer and then hit your thumb, repeatedly - is that a fault of the hammer or the user of the hammer?
These tools we use are great, but as with any tool they need some human interaction. It takes all of about a few moments to go “aww jeez i dont think this digital release is from 1967!” and update the information.
Please refrain from massively replacing long release event country lists with worldwide release event for now because it slowdowns search indexing even more than adding multiple release countries initially did.