[mb-style] RFC: Change Default Data Quality

[Don Redman]

Note: Yes, I read the entire thread.

On Mon, 02 Jul 2007 06:28:26 +0200, Brian Schweitzer wrote:

> Now that that's said, can we return the focus of the conversation back
> to the main topic here - the RFC - and not the way any one individual
> phrases edit notes?
>
> Just reviewing the emails since my revision on June 27, the only
> suggested point of discussion appears to be the change in terminology
>> from "Verified/Unverified" to "Voted/Unvoted"?  I still think the
> former the better terminology, but I'm willing to go with the latter
> if it gets this through.  :)

Um, no there was a big discussion about how to treat additions to the  
database. Your proposal is implicitly about the Mindset in which such  
additions are welcomed, accepted, treated carefully or even distrusted.  
IMO that is why the conversation drifted this way, and it means there is a  
problem lying around over there.

Note that I am very much in the "People are good" camp. :-)

> So let me put it out there - the revised version is in the email at
> http://lists.musicbrainz.org/pipermail/musicbrainz-style/2007-June/005032.html
>
> Change #2 to read:
>
> 2) Name the 4 settings: "Unvoted" "Low quality" "Voted" and "High  
> Quality".
>
> And add:
>
> 2a) All 4 data quality status levels are to be able to be set via edit
> and vote.
> 2b) "Low", "Voted", and "High" will retain the current voting rules
> for the current "Low", "Normal", and "High".
> 2c) "Unvoted" will require the same numbers of votes to lower to/raise
>> from as "Low".
>
> Given these modifications to the June 27th revision, can everyone live
> with the revised RFC?  If any sticking points, please raise them.
> Unless something comes up that we need to address, I'd like to try and
> go for upgrading this to an RFV on this Saturday upcoming.  I can't
> think of any cat-corners for this type of change, as compared to a
> style guideline or guideline change, but if anyone can, please raise
> them so they can be worked into the proposal post haste.  :)

Are you still suggesting that all add release edits should stay open until  
they recieve three unanimous votes? IIUC this was not part of your initial  
proposal on the wiki page, which I liked a lot. Then it crept in during  
the discussion.

I would certainly veto that part.

Your proposal is not a guideline but an *algorithm* for determining and  
using DataQuality. It sure is good to discuss it in order to better  
understand what this would do, and to get a rough consensus about it. But  
as it is an algorithm you will need to *test* it.

Actually it's even worse: I view MusicBrainz as an information ecology  
with all the edits, votes, that pass, fail, entail other edits, all the  
logic which makes people act this way or the other etc[^1]. So in fact you  
are proposing a change in an ecosystem. It is terribly difficult to  
anticipate what this change will do.
If people *decide* that this is a good idea, this does not necessarily  
mean that MB will not go havoc a month after the change was introduced.  
Therefore, I am not sure that an RFV is the correct way to deal with this  
issue.

  [^1]: E.g.: Some people said, they changed their voting habits since they  
know that unvoted additions pass anyway.

All that said, I believe that the other parts of your proposal (points  
1,2,4,5 in the mail or 1 and 2 in the wiki page) are a good idea and  
relatively safe to try out.

One of the major problems of MB is that it takes to long for edits to get  
applied. This takes away the motivation of contributors. What I like about  
your proposal (without the leave-add-release-edits-open part) is that it  
adresses this by saying "Take the stuff in, but flag it as unverified". It  
would not change too much in the dynamics of open edits, but such changes  
could be made later by carefully tuning the values of the algorithm (from  
which yes:no ratio onward is an edit "verified"? How long do we wait for  
expiration on each quality level? etc.)

Now, careful tuning is exactly the thing you can to to an ecosystem.  
Deciding that it should work differently is not.

   DonRedman

-- 
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/<SomeTerm>
(you might need to transform the term to singular)