[mb-users] "The need for free and open music metadata", but MB not good enough

[Per Øyvind Øygard]

On Tue, 29 Apr 2008 21:17:10 +0200, Jim DeLaHunt <from.nabble at jdlh.com>  
wrote:

>
> I guess I should be more clear.  By "reasonably trusted contributers" I  
> mean
> someone who has registered a user ID and has made a small number of
> contributions which then got voted in.  Thus they have proven that they
> didn't come here just to vandalise. I don't mean contributors with as  
> high a
> status as automod (I consider them "highly trusted contributors").
>
> I think I am in this category of reasonably, but not highly, trusted
> contributor. I would guess you are too.
>
> Personally, I find the two-week delay demotivating. I do a lot of work to
> improve an entry because I'm about to tag music files for that release,  
> and
> I can't easily see the results of my MB contribution in my music files. I
> have to come back two weeks later and refresh.
>

I guess I'm just a patient guy ;), though I do see your point. A  
compromise might be allowing picard to pull data with pending edits if the  
user chooses, though whether this is technically feasible I do not know.  
Either way, it would place the choice in the users hand, and require  
few/no changes apart from the API.

>
> Per Øyvind Øygard wrote:
>>
>> You should also keep in mind that [voting delay is] a major deterrent
>> for vandalism. On wikipedia it's not such a big problem since you can
>> immediately revert, but not so on MB, either you wait for an automod to
>> come by or you risk having your albums tagged with "THIS ALBUM  
>> SUCKS!!11"
>> as title until the vote is inevitably voted down a week later.
>>
>
> We need to preserve a vandalism countermeasure, agreed. But if we were to
> reflect changes immediately we could still have countermeasures. For
> instance, we could say that a change by a reasonably trusted contributer  
> is
> applied at once but still held open for a confirmation vote, and a  
> single No
> vote is enough to reverse the change while the vote completes. Thus any
> contributor could reverse the "THIS ALBUM SUCKS!!11" vandalism  
> immediately,
> it needn't require an automod. This would move our balance point between
> responsiveness and security closer to responsiveness, at a cost  
> proportional
> to how many edits are approved with zero votes.
>

In hindsight this was a somewhat silly example. Anyway, yes an automod  
could of course edit the edit, but that wouldn't change the fact that the  
edit is still there. As you say this can be solved by a single 'no' vote  
cancelling the edit, but is that really something we want? Personally I'd  
rather give an edit more chance than a cursory glance from a novice  
editor. You might say people should think more before voting no, but  
that's simply not always possible; mistakes happen. Of course the editor  
can redo the edit, but that's incredibly annoying, especially if it's a  
large edit. And of course, let's not forget that this would open up for  
malicious revenge-cancelling among editors. I'm not implying anything  
about MB editors, I've seen nothing but exemplary behavior, but blocking  
bad behavior is always a good idea in my eyes.

Anyway, I'm not opposed to doing something about the responsetime, it  
would almost certainly be a good thing, I'm just not sure immediate  
response is a good idea. I guess I could compromise with a  
counter-proposal: give users "ranks" based on their accepted edits, and  
lower the waiting period based on this. It has the added bonus of giving  
an incentive to editors since everyone likes having a higher rank, however  
meaningless it might be. It would also promote making more and smaller  
edits, like ARs for remixes/feat./vocals etc, something discogs thoroughly  
trounces us at in most of the cases I've seen. A con with this might be  
shoddy/irrelevant edits by some editors to boost their rank, but this can  
be alleviated by how you weight stats, make a failed vote cost the inverse  
of 20 passed votes for instance.

--
Per (Wizzcat)