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)
_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
