Don Redman wrote:
IMVHO we need to clarify the current process of solving a style issue,
and document it so well that *anybody* can follow the process. If we
develop some tools that help, that's even better.
I invite everybody to mercilessly edit StyleCouncil,
HowToProposeNewGuidelines, Check
Chris Bransden wrote:
ProducerRelationshipType
* New: "artist {additionally} {co-}produced album or track"
ExecutiveProducerRelationshipType
* "artist {co-}executive {co-}produced album or track"
That does not work with AR, it could only produce "artist executive produced album or
track" or "
Peter Adams wrote:
> On Monday 03 April 2006 15:57, Brian Gurtler wrote:
>
>> actually adding (live) to every single track on a live album is "more
>> complicated" not to mention redundant.
>
> Why "more complicated"? Who are you quoting there?
haha i don't know why i quoted it to be honest.. ma
On 26/04/06, Cristov Russell <[EMAIL PROTECTED]> wrote:
> I still say co-producers are not subordinates. Artists are often listed as
> co-producers and at the end the artist doesn't work for the producer; the
> opposite is true.
they can still be subordinates in the production process, whilst st
I still say co-producers are not subordinates. Artists are often listed as
co-producers and at the end the artist doesn't work for the producer; the
opposite is true. Also, as far as I know the idea of an executive producer
being the financer doesn't apply (generally) to the recording industry.
Cristov Russell wrote:
Great. So I would say yes there is a problem with additional executive
producer. I still don't understand what was wrong with the original coproducer
configuration. There is a possibility that multiple executive producers exist
and are labeled co-executive producer. I'll
Simon Reinhardt wrote:
Yes, I support that. And I think "executive co-producer" ==
"co-executive producer". We don't have to include every possible
wording, as mostly the recording studios / labels all do their own
definition of what all that means I guess. And who can tell exactly what
work a
Great. So I would say yes there is a problem with additional executive
producer. I still don't understand what was wrong with the original coproducer
configuration. There is a possibility that multiple executive producers exist
and are labeled co-executive producer. I'll verify tonight if I have
On Wed, 26 Apr 2006 13:04:44 +0200, derGraph wrote:
Simon Reinhardt wrote:
== A Tool ==
Some explanation for the image you attached? I do not understand it. :)
As far as I understand the image it simply shows the number of mails
with a common subject line over a given time. A simple graph
Chris Bransden wrote:
i think the 'safest' option is:
ProducerRelationshipType
* New: "artist {additionally} {co-}produced album or track"
ExecutiveProducerRelationshipType
* "artist {co-}executive produced album or track"
how about that??
Yes, I support that. And I think "executive co-produ
On 26/04/06, Chris Bransden <[EMAIL PROTECTED]> wrote:
> i think the 'safest' option is:
>
> ProducerRelationshipType
> * New: "artist {additionally} {co-}produced album or track"
>
> ExecutiveProducerRelationshipType
> * "artist {co-}executive produced album or track"
maybe even * "artist {co-}ex
haha, gawd, yes :/ typically with rap type releases it seems -
http://www.onestopbeats.com/babypaul.html
ok so another is:
ProducerRelationshipType
* Current: "artist {additionally} produced album or track"
* New: "artist {additionally} {co-}{executive} produced album or track"
BUT you can also h
Orion wrote:
Chris Bransden wrote:
"executive" isn't an attribute of ProducerRelationship as you
apparently can't be a 'co-executive producer' so one has to be a
seperate relationship, and "executive producer" is further from
"producer" than "co"
Err, according to google you can be a "co-execu
Chris Bransden wrote:
"executive" isn't an attribute of ProducerRelationship as you
apparently can't be a 'co-executive producer' so one has to be a
seperate relationship, and "executive producer" is further from
"producer" than "co"
Err, according to google you can be a "co-executive producer.
Cristov Russell wrote:
I'm not sure I'm following this structure. Can you post full examples? Thanks.
Implemented on test and created an example for each possible combination:
http://test.musicbrainz.org/showrel.html?type=album&id=421276
Any problems with the possible combinations with "additi
I'll try!
ProducerRelationshipType
* Current: "artist {additionally} produced album or track"
* New: "artist {additionally} {co-}produced album or track"
ExecutiveProducerRelationshipType (new...currently resides as a
proposed attribute of ProducerRelationshipType, but i will create a
new page if
I'm not sure I'm following this structure. Can you post full examples? Thanks.
Cristov (wolfsong)
--- [EMAIL PROTECTED] wrote:
From: "Chris Bransden" <[EMAIL PROTECTED]>
To: musicbrainz-style@lists.musicbrainz.org
Subject: Re: [mb-style] Co-ProducerRelationshipType
Date: Wed, 26 Apr 2006 19:06:0
request for veto!
On 25/04/06, Chris Bransden <[EMAIL PROTECTED]> wrote:
> hehe, well in that case i'd say:
> {co-} an attribute of producer
> executive producer a seperate sub type
>
> any objections? i'll update the wiki pages to suit once it's on gone thru.
>
> On 25/04/06, Simon Reinhardt <[EM
On Wed, 26 Apr 2006 03:53:58 +0200, Jan van Thiel wrote:
On 4/26/06, Simon Reinhardt <[EMAIL PROTECTED]> wrote:
The only thing we need is that someone *really* cares about a problem
and controls discussions. And well, if noone like that is found for an
issue then the style secretary can ask
On Wed, 26 Apr 2006 02:20:24 +0200, Simon Reinhardt wrote:
Don Redman wrote:
== More Secretaries ==
I don't want to cling to my job. And I know that I have not done my
job in the last weeks. Does someone want to take over the secretaries
job from me? Temporarily or permanently? You'll need
On Wed, Apr 26, 2006 at 09:06:08AM +0200, Lars Aronsson wrote:
> 1. use the same placenames already used for other bootleg
>recordings (I can give you a list, based on the database dump)
Er, this is exactly the point. We're using two names for the same place and
I asked which we should use.
I don't like this rule either. Until there is tagger support to use the release
value, I don't see the harm in having this in the track title.
Cristov (wolfsong)
--- [EMAIL PROTECTED] wrote:
From: Peter Adams <[EMAIL PROTECTED]>
To: MusicBrainz style discussion <[EMAIL PROTECTED]>
Subject: Re:
I agree to a point. The problem that arises is the rogue implementation of
rules. A style guideline would elleviate that but at the same time deligence
from the community can mitigate that. Keep in mind though that a lack of
guidelines creates voting wars. At minimum I think it should be documen
> Bogdan Butnaru wrote:
> > (English seems the best choice), because when we make the database
> > smarter [...] it'll be much easier to make an automatic conversion.
>
> If there ever is such a function, it surely won't be much
> more difficult to convert locations named in other languages.
>
> Cristov Russell wrote:
> > If an Italian artist performs in Spain they obviously have Spanish
> > fans so why should a recording by a Spanish, French or English fan
> > arbitrarly use the language of the performer?
>
> But I think we both agree that we should use the language the
> fans would
Simon Reinhardt wrote:
No, I just think it's way too much work for one person. So I think you
could need some support.
[...]
That way we don't even need fixed secretary positions, only a pool of
trustworthy persons who will really work on the issues.
That's exactly how understood your propos
Don Redman wrote:
We could have a small deamon. The secretary (or anybody?) tells it:
this task/ticket is being discussed/RFCed/RFVed now, and after a
certain period, the deamon asks what has happended. This could be
hacked into Trac
I don't think we should hack anything into trac. This is a
Simon Reinhardt wrote:
== A Tool ==
Some explanation for the image you attached? I do not understand it. :)
As far as I understand the image it simply shows the number of mails
with a common subject line over a given time. A simple graph would be
more intuitive, I think (but this looks nice
Lars Aronsson wrote:
Perhaps MB could just adopt the names used in Wikipedia's article
headings and URLs, e.g. "London" to mean London, England, or
"London, Arkansas" refering to the lesser known place with 925
inhabitants.
This bears a great problem: on Wikipedia, you only have to name an
a
Cristov Russell wrote:
If an Italian artist performs in Spain they obviously have Spanish fans so
why should a recording by a Spanish, French or English fan arbitrarly use
the language of the performer?
But I think we both agree that we should use the language the fans would
expect, or don't w
Bogdan Butnaru wrote:
(English seems the best choice), because when we make the
database smarter [...] it'll be much easier to make an automatic conversion.
If there ever is such a function, it surely won't be much more difficult
to convert locations named in other languages.
But this is not
Lars Aronsson wrote:
What I'm suggesting is simply that we could write in the
guidelines that bootleg locations should
1. use the same placenames already used for other bootleg
recordings (I can give you a list, based on the database dump)
2. for new locations, use placenames from article
I agree actually. I think the tagger should be able to be configured
to add '(live)' to all track titles on a live album.
infact this is something that http://wiki.musicbrainz.org/TaggerScript
proposes. infact i think taggerscript should be fasttracked because it
really sounds like a good idea, an
On Monday 03 April 2006 15:57, Brian Gurtler wrote:
> actually adding (live) to every single track on a live album is "more
> complicated" not to mention redundant.
Why "more complicated"? Who are you quoting there?
It's not redundant as long as there is a supported tagger using the data and
no
Steve Wyles wrote:
> I know you're a big advocate of Wikipedia. But, being
> technically dependant on another data repository for this isn't
> practical. I sorry to say that Wikipedia has had more downtime
> or been inaccessible more often than MusicBrainz.
Back when this was at its worst, in
35 matches
Mail list logo
