I want the related events under “rescheduled as” to go away.
Ultimately, they should be deleted, but for starters, I’d settle for having them not show up as related to the parent event. (since I can’t figure out how to fix them in a timely manner)
Any tips/tricks for getting this done as an auto-edit, so that the entries can be clean in time for the event, without having to panhandle here or IRC for votes?
I’m not entirely sure what happened here/what you have been trying to achieve (but I do recognise it’s a bit messy right now ). Did you add those events by mistake, or is it because e.g., Gus’s was originally scheduled for Friday and then got moved to Saturday? Or something else?
Okay, what I see: @bsammon entered a bunch of events, however a few of these were slightly messed up (some missing punctuation and a couple of wrong dates). They originally tried to fix these errors, but since the results didn’t show up right away, they added duplicate events and tried to hide the old ones.
Still one duplicate event left, but I’ve asked about whether that one is actually a genuinely cancelled/rescheduled concert: https://musicbrainz.org/edit/40115887
@bsammon, in the future, it’s better to do the corrections and then ask other editors (here and/or on IRC) to vote/approve your edits. Some edits can be “approved” directly by auto-editors, but some edits (namely “destructive” ones, like removing relationships) have an enforced voting period. If an edit get three yes votes and no no votes it will get applied a few days earlier than the full voting period, but should still get through before the festival starts.
@freso, what you’ve done is only helpful if someone (two someones, after me?) approves your edits. Otherwise the event listing is going to look like crap for the next six days (which is not “before the festival starts” at this point).
To clarify, the goal here was to have this event listing be something that people could use before the event (to figure out which part of the event they wanted to go to), not just at the event.
In the methodology I was using before I started this thread, I could tell people “just ignore the yellow stuff” when looking here.
With this merge way of doing things, I can’t say that.
Why is the merge method better?
It is accurate: someone could swoop in with a “no” vote or people who have already voted “yes” could change to “abstain”. If neither of these two things happen, it will close before the 6 days are up. I’d point to Introduction to Voting - MusicBrainz but it seems that that hasn’t been updated for this. I can’t even find a blog post talking about this, but it was introduced not long after the extension to edits with “last minute” No votes (IIRC).
Edit: @chirlu pointed me in the right direction: the minimum voting period was introduced with MBS-8234 and released as part of the 2015-04-06 server update.
@bsammon, also, please read and reply to edit notes. I’ve left at least one other I’d like a reply to than the one @outsidecontext pointed you to (which I also pointed you to in my 2nd post in this topic).
Okay, this is the argument I’ve seen before, and it’s my impression that it’s relatively low-impact in this case.
That page poses two reasons why deleting entities is worse than merging them:
Other stuff might be linked to / pointing at the deleted entity
As the entities in question are generally only a week or two old, there’s a low probability of links having been made to to them yet
There’s a risk of trampling on other people’s work
There’s very few people interested in editing this event, so what seems low-risk as well. Granted, the number has increased as a result of me starting this thread (before that I’d wager it was only me)
In any case, I’m not really arguing against merging.
My plan was to make that event listing as useful as possible and as minimally-confusing as possible for as much of this week as possible, even if that meant sacrificing some data-clean-ness in the short term.
Then after the event was over, I would clean up the data when a 6-day delay was not a problem. I would not care whether that post-event cleaning involved merges or deletes.
This still seems to me to be the optimal approach, given the current limitations imposed by musicbrainz’s editing system.
A lot of data users (I know the BBC and Setlist.fm at least have this) create links automatically for every artist that is added to the DB as soon as it reaches their replicated copy (so, in an hour, more or less). If the artist is deleted, their entry breaks - and actually right now there’s no way for them to even know whether the links were incorrect, or they linked to a previously existing artist that disappeared.
While I imagine less data users look at things like events, the possibility is there, and there’s no benefit at all to a removal, so marginal benefits would be better than no benefits
The optimal system would be to enter your original edits and do regular edits to fix any mistakes you spot, and then ask the community to vote/approve those edits, as you did in your original post.
All the mess of having duplicate events and waiting for merges to go through, improper use of relationships, “placeholder” events, etc. are a direct result of trying to fix things improperly, thus digging the hole deeper for getting to the result you wanted to achieve. Most of the edits needed to fix your initial omissions (e.g., missing set list info) are approvable and thus only need one auto-editor to look at your edit to get it applied. As soon as you need to do merges and (relationship) removals you need three editors and at least 48 hours before an edit can get applied.
(Note that this is also the approach I hinted at up in my second post:
[quote=“Freso, post:3, topic:108854”] @bsammon, in the future, it’s better to do the corrections and then ask other editors (here and/or on IRC) to vote/approve your edits. Some edits can be “approved” directly by auto-editors, but some edits (namely “destructive” ones, like removing relationships) have an enforced voting period. If an edit get three yes votes and no no votes it will get applied a few days earlier than the full voting period, but should still get through before the festival starts.
[/quote])
Also: MusicBrainz is intended as an accurate music database; generally it’s designed to favor accurate information over quick updates. I really don’t think it’s designed to handle—or good at handling—up to the minute information for people about to attend/attending an event. You can work around it somewhat by pinging auto-editors to approve your edits, but…
). Did you add those events by mistake, or is it because e.g., 
I can’t even find a blog post talking about this, but it was introduced not long after the 