Olivier:
Thanks for your reply.
I like your suggestion for making the wording about "Don't use the Cover AR
with Classical" more concise. I'll do that.
I'll make another draft of my proposal which is all written out, instead of
making reference to the existing page. I can see that that is easier to
review.
You made a lot of good points about most contributors probably not wanting
to read lots of text about "style evolutions" and "more than a couple
paragraphs about such a thing as the Cover ar". I agree that concise is
better. Please understand that I'm not proposing to _add_ this rambling
history stuff to the CoverRelationshipType article. It's already there —
read it! I'm proposing to do a minimal change to make it read like history
instead of a currently-open debate.
I think taking it out would be even better, but I don't really want to take
that project on. I'm trying to focus on the CSG revision.
Side comment: Folks, part of why there's a lot of traffic on mb-style about
revising lots of pages is that lots of pages need lots of cleanup before
they become current and concise. I can think of better ways to accomplish
that goal than a blizzard on mb-style, but those aren't the mechanisms in
place in MB.
Thanks, everyone, for your comments.
--Jim
Olivier-10 wrote:
>
> 2008/2/12, Jim DeLaHunt <[EMAIL PROTECTED]>:
>>
>> What we have now is nearly the opposite: a novice contributor needs to
>> read
>> the main style guide, the CSG, a bunch of proposal and discussion pages,
>> and
>> bathe in the mb-style discussion and edit discussions for a few weeks,
>> then
>> cross-index it all in their head, before having enough information to
>> make
>> good contributions.
>
> This is probably kind of a biased opinion about things, but if it's
> your experience ;)
> My point being: not everyone wants to dabble into Classical, involve
> with as much enthusiasm and energy as you into MB, or even want to
> read about style evolutions...
>
>
>>
>> "Efficiency" is relative to an objective. My objective is to empower MB
>> contributors, and I don't mind spending my own time writing down
>> information
>> in multiple places to do it. Reducing the traffic on mb-style is a
>> different objective. Given the neglect of CSG for a long time, and in the
>> absence of a process for empowering a some editors to do a wholesale
>> rewrite, achieving docs which empower contributors will involve an
>> increase
>> of mb-style traffic for a while.
>>
>
> Your involvment in making doc is definitely an excellent thing and
> no-one wants to discourage that.
>
> Now, good documentation is also concise documentation. Quite frankly,
> I don't think most people (eg: by "most" I mean the usually silent
> major part of editors who wants to slack their stuff in - this
> excludes obviously the hardcore longtimers, and the dozen people
> actively involved in discussions) want to read more than a couple
> paragraphs about such a thing as the Cover ar.
>
> If there is also a need for further details, I would really like to
> see these presented in a different section, possibly either a
> different page, or a distinct paragraph on bottom of the page or
> something like that.
>
> Finding the right balance between informative enough content and still
> manageable in quantity for the casual editor is IMHO quite important.
>
> Also note that redundancy has a heavy cost in maintenance terms.
>
> So, specifically, as you asked for a review with suggestions:
>
>
>
>> [1. Change the Description section to read as follows.]
>
>> Description
>
>> This AdvancedRelationshipType links a cover version of a Track to the
>> original Track, or a cover version of a Release to the original Release.
>
> I kind of prefered the old way round formulation, but I don't really care.
>
>> MusicBrainz doesn't have a crisp definition of "cover version", but this
>> phrase from [WikiPedia]Wikipedia sums it up: "In pop music a cover
>> version is a new rendition of a previously recorded song".
>
> Ok.
>
>> (A discussion is open at WhatIsACover to define "a cover" in the context
>> of MusicBrainz, but we proceed despite the fuzzy definition.)
>
> It's just irrelevant for the casual editor.
> Strip that off and put in fine prints at the bottom of the page something
> like:
> "If you're interested in discussing the Cover concept in MusicBrainz,
> you can participate in WhatIsACover"
>
>
>> The MusicBrainz StyleGuideline is to always use the earliest released
>> Track or Release as the target of this relationship. This applies even if
>> the earliest-released one was obscure, and a later one is more famous.
>> This lets us sidestep subjective debates about which release is most
>> important or influential. It also lets us capture the relationship
>> between performances with a smaller number of AdvancedRelationship links.
>
> This should preferably live in a "style" section (see
> http://wiki.musicbrainz.org/RelationshipTypeTemplate)
> Otherwise I kind of think this is a bit long for what it says...
>
> Maybe:
> "You should always use the earliest released Track or Release as the
> target of this relationship, as to avoid subjective debates about
> which release is most important or influential."
>
> The bits about "capturing in less AR" doesn't make much sense IMO and
> somewhat duplicates the don't make relationship cluster thingie.
>
>
>> Do not use this relationship if either the cover or the original is a
>> Track or Release subject to the ClassicalStyleGuide (CSG). This is
>> because the CSG already standardizes TrackTitles and ReleaseTitles to
>> identify the MusicalWork, making "covers" more apparent. ClassicalMusic
>> also has many recordings of the same MusicalWork compared to contemporary
>> music. Do not even use the CoverRelationshipType to indicate a parody. In
>> ClassicalMusic the parody is usually a relationship between one
>> MusicalWork and another, not between performances, so making a
>> relationship between tracks doesn't apply.
>
> This is just way too long. Also, the mentions to MusicalWork IMHO are
> rather inappropriate as we just don't have anything like that in the
> database right now.
> Furthermore, it should be obvious that if CSG doesn't use Covers, it
> doesn't use Parody either (being an attribute...).
>
> So what about:
> "Note that this relationship doesn't apply to classical music, which
> has its own set of StyleGuide (see CSG). Hence you shouldn't link to,
> or from, a classical music track or release using the
> CoverRelationShip."
>
> again probably move this to the "style" section.
>
>
>> [2. Change all occurrences of the word "album" to "release".]
>
> Yes
>
>> [3. Add second-level heading "Details" before "Don't Make Relationship
>> Clusters".]
>
> I would encourage you to stick with the organization
> http://wiki.musicbrainz.org/RelationshipTypeTemplate
> Maybe it's not perfect, but at least it helps in making consistent
> documentation which is definitely wanted.
>
>
>> [4. Move section "Relationship Attributes" to between "Description" and
>> "Details". Add the following. ]
>
> See above.
>
>
>> Begin date, End date: Dates do not apply to this relationship. Leave them
>> empty.
>
> Ok...
>
>
>> [5. Change the following two items in "Don't Make Relationship
>> Clusters".]
>
>> 1. change the 2nd paragraph to read, 'There were three suggestions for
>> StyleGuidelines for this relationship. The first was to only ever link to
>> the very first released version. This is the policy used by the
>> CoversProject, and what MusicBrainz adopted.' [State a policy, switch to
>> past tense.]
>
> Strip the whole thing of altogether (the *three* propositions).
> 1. the current policy is (or should be) stated in the "Style" section
> above mentioned.
> 2. the notes about the other possibilities now belong to
> history/discussion. Should be moved to the "expert/history/whatever"
> paragraph down the page, or even possibly to a new page
> CoverRelationshipTypeHistory or CoverRelationshipTypeDiscussion.
>
>
>> 2. Change present tense "is" to past tense "was" in the next two
>> paragraphs. [Make the topic closed instead of open.]
>
> Same as above.
>
>
>
>
>
>
> Also, editing pages that way is rather painful and awkward to review.
> I would rather suggest one of the two possibilities instead:
> 1. have a transclusion editor fix the transcluded doc to the official
> version, and directly edit the page with your changes (including a
> small "not official yet" mention on top of the page
> 2. create an entirely new page somewhere like Jim/NewCover that will
> eventually replace the existing one.
>
> Either way would make it much either to review and see where we are going.
>
>
>
> In the hope that helps
>
>
> Regards,
>
> - Olivier
>
> _______________________________________________
> Musicbrainz-style mailing list
> Musicbrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>
>
-----
-- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada •
http://wiki.musicbrainz.org/JimDeLaHunt
--
View this message in context:
http://www.nabble.com/RFC%3A-Clarify-CoverRelationshipType-not-for-Classical%2C-takes-1st-release-tp15328891s2885p15463584.html
Sent from the Musicbrainz - Style mailing list archive at Nabble.com.
_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
