[mb-users] A cute idea

Brian Schweitzer brian.brianschweitzer at gmail.com
Sat Sep 15 02:30:31 UTC 2007


I think we've all had it happen.

I personally like the idea to cancel the auto-editing period once the edit
receives a vote much more.  Any action that could cancel people's votes just
seems a bad thing from a psychological point of view - we need things that
encourage voting, and anything that I could do that would cancel your vote
seems like it would discourage you to vote, or at least, to make sure you're
not the first to vote (which you could see would easily lead to less voting
overall).

I don't think it needs the 30 minute window - the chances the edit will have
a vote cast that quickly are rather slim - consider for 2000 to 2500 open
add edits, how many receive 3 votes within 14 days, let alone 1 vote within
30 minutes...

Also in terms of the 30 minute window, I don't think the idea of not being
able to tag against a release until a 30 minute window has passed is
detrimental from the editor's point of view - one reason people add releases
is to be able to tag against them right then and there.  (Most people aren't
as crazy as those - myself included - who have various "add an entire
label's catalogue" type projects going on...)

Additionally, I think this would be basically a showstopper for the idea, in
terms of philosophical and coding issues for the site.  Philosophically,
data entered has always been immediately usable.  Making any data - even for
only 30 minutes - inaccessible seems counter to that philosophy.  In terms
of coding, this also seems like it would hold true - you now would have to
code in a way to prevent anyone else seeing a release, as well as preventing
XML/data dumps/replication/taggers from accessing a release, yet at the same
time, allow the adding editor to see (but not use) the release for that 30
minute period.

One other idea, something that I think I recently mentioned in a different
thread, which seems an extention to this one would be that, in some period
(say 30 minutes) after a release is added by an editor, if that same editor
attempts to add a second release with the same artist, title, and track
count, they would be hit with a second "dupe check".  Right now, the dupe
check occurs between pages 1 and 2 of the "add release" process.  We seem to
get a decent amount of duplicates from multiple clicks to the "submit"
button on page 2, be it an impatient user, a screen refresh after an error
500, or whatever - there's a decent number of duplicate releases created
with very close (or even chronological) release rowids.  Adding a secondary
check would help prevent these - I don't think anyone intends to ever create
a duplicate this way...  it just happens.  (FauxFaux's report was rather
informative as to quite how many duplicates there actually are in the
database, and many seem to source from this type of thing.)

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.musicbrainz.org/pipermail/musicbrainz-users/attachments/20070914/3e2afdf6/attachment.htm


More information about the MusicBrainz-users mailing list