[mb-style] Improving the DataQuality implementation

2011-04-18 Thread Dr Andrew John Hughes
As discussed in http://musicbrainz.org/show/edit/?editid=14345490 I
believe the current DataQuality implementation is flawed.

As I see it, it has two aims:

1.  Giving an indication of the perceived quality of a release
2.  Locking down edits on a release.

I have no problem with 1.  2 is an issue.  It creates a feeling of
mistrust, which I don't see reflected in the reality of MB editing, by
assuming that other editors will destroy the existing work.  As stated
in the comments on the edit, I can see this being an issue where the
guidelines are not immediately intuitive (e.g. soundtrack guidelines
where composers are used in place of performers) but generally it
isn't an issue.

I'd like to propose that the increased edit conditions are restricted
only to edits that change or remove existing data, which seems to be
the intent of the restrictions.  I can't see any harm in allowing the
addition of edits, but lots of potential problems with edits being
dropped.

Why is this viable?  Because additions concern:

* New aliases, which may not have been used when the quality was raised.
* Release events which either happen after or are discovered after the
quality was raised.
* New ARs may be added to MB after the quality is raised (e.g.
http://musicbrainz.org/show/edit/?editid=14345418 which is pending
instead of being autoedited in due to the high quality of that
release)
* New URLs may appear.

Add Track is the only one I can see a reason to restrict.  Similarly,
Edit URL is one that could probably be unrestricted, given that broken
links are quite common, but I don't see changing that as a necessity.
The main issue is Add Alias, Add Release Event and Add Relationship.
I can't see how any of those damage the existing data, but they do
allow new material that wasn't present before to be added.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Improving the DataQuality implementation

2011-04-18 Thread Nikki
By the way, the pre-NGS code is not being worked on, so any changes will 
only be done after NGS and some of the things you mentioned won't apply:

 * New aliases, which may not have been used when the quality was raised.

Artists no longer have data quality in NGS.

 * Release events which either happen after or are discovered after the
 quality was raised.

Release events are separate releases in NGS, so this is no longer a problem.

 Add Track is the only one I can see a reason to restrict.

I believe in NGS, there's no add track edit any more, only a single edit 
tracklist edit for the entire disc, so that might be tricky.

Nikki

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style


[mb-style] NGS release date: May 16th

2011-04-18 Thread Robert Kaye
NGS is finally coming:

   http://blog.musicbrainz.org/?p=812

\ø/

--

--ruaokThe answer to whether or not something is a good idea should not 
be taken as an indication of whether I want to do it.

Robert Kaye -- r...@eorbit.net --http://mayhem-chaos.net



___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style