Re: [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/
(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

Re: [mb-style] ARs about cover-art roles

[Don Redman]

On Fri, 04 May 2007 01:05:45 +0200, Bogdan Butnaru wrote:


The only technical issue is splitting the art design/illustration AR
with minimal loss of data. Is it possible to make a tiny temporary
hack that keeps an already-existing AR "present" but disallows
creating new ARs of that type? We only need to activate this once,
leave it there for a month or two, then remove it together with the
"deprecated" AR.


You can rename and relocate an AR type in the tree.
Don't know if that helps.

  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFC: Bad Terminology: bootleg

[Don Redman]

Hmm, I am still unsure. Here are the important definitions that were  
proposed during this thread (did I miss one?)


On Sun, 29 Apr 2007 16:21:54 +0200, Lauri Watts wrote:


Any release that was not legally sanctioned by the rights holder,
which is normally, but not always, the artist and/or their record
label.  This includes unofficial live recordings, pirated releases,
and custom burnt compilation and 'leaked' releases including demos.
It does not include demos released by artists themselves, issues
released by record labels without the artists input, or (..any of the
other examples people seem confused about, I can't think of any
more...)



On Wed, 09 May 2007 14:27:15 +0200, Olivier wrote:


2007/5/9, mud crow <[EMAIL PROTECTED]>:
It's the publisher who owns the rights to the songs, the publisher may  
be

the record label, or the artist or a totally separate company.
[...]
they have total control over releases and licensing.

[...] A bootleg is
an unlicensed release.


I like that, and second it.

Either a release is properly licensed by the right owner (publisher)
(hence it is "official" as we word it right now) or not (hence it's a
"bootleg" as we word it right now).

There's no notion about legal/illegal in that, no nitpicking about
artist/label opinion whatsover, no endless discussion about recording
vs release etc.

Something simple, clear and to the point.



On Tue, 08 May 2007 23:45:18 +0200, Bogdan Butnaru wrote:


I'm sorry, I didn't follow the entire thread from the beginning, so I
apologize if this was mentioned before.

Unless I'm mistaken, the original meaning of the word bootleg when
applied to music is "unofficial recording" of a show. That is, the
show was recorded without the cooperation of the band (other than
singing...), by someone in the public or even someone among the
concert staff. The illegality is not a direct factor in this (the band
may allow or encourage a recording, just not help it). This definition
includes very well the case where the band simply takes a bootleg
recording and publishes it officially. (There are many cases of this,
I think Metallica does it, too.)

The term is unfortunately applied to unofficial album releases (again,
some of these may even be legal, for example if the band releases a
concert in the public domain).


IIUC we are talking about different things.

Lauri: a not legally sanctioned release.
Mudcrow: a release that was not sanctioned by the publisher.
Bogdan: a recording that was made without the cooperation of the artist.

Question: What is the difference between the "Lauri definition" and the  
"Mudcrow definition"? I don't get it, but to Olivier it seems to be  
important whether we talk about legality or not.


Both the "Lauri definition" and the "Mudcrow definition" could describe a  
release status. That status could be called "unofficial".


The "Bogdan definition" (which is better than the one I used but similar  
to it) does not talk about the status of a *release*, but of a recording.  
It is unusable for a release status.
However, I believe that it describes the original meaning of the word  
"bootleg". I have *re*read the Wikipedia article, and I think that is what  
it says if you weed out the copyright-is-bad ideology.


My conclusion would be to actually do as Olivier said and rename the  
status to "unofficial". IMO "bootleg" is not a release status. It does not  
belong there. With the current system it belongs next to "live" or  
something like that.


(sorry for contradicting myself so often :-) )

  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFC: "changed name to" AR

[Don Redman]

On Mon, 07 May 2007 13:08:41 +0200, Bogdan Butnaru wrote:


Hi!

There was a discussion a while ago about bands changing their names. I
can't find it now, and I'd like to revive the discussion.

In short, I propose we add a new artist-to-artist AR to reflect bands
changing their names.

The relationship phrases would be "X changed its name [on date] to
Y"/"Y was called X [until date]".



There is a single unpleasant issue I see with this proposal (though
I'm sure others will point out more): The AR is semantically "clean"
by marking the relation between exactly two names; this is good from
the database point of view. However, users tend to expect to see _all_
previous/future band names listed for each 'view' of the band.

An extreme example is Nirvana (the grunge band), which switched
through half a dozen names in quick succession before settling on
Nirvana. In such cases a Nirvana fan would expect to see all the names
on the "main page".
  1) we could allow clusters, ie, link all names to all names, and use
"X was named Y between [year] and [year]". But of course that's going
to cause lots of problems and confusion, especially for bands with
many name-changes.
  2) we could allow clusters selectively, for instance in the example
of Nirvana above. This is easier to do, but probably even more nasty
and confusing.
  3) we could add special-case code to the site, that follows the
links recursively and shows the entire history. This is the best
logical solution, but it may be hard to implement. (However, it's not
_necessary_ to do this from the beginning, so the AR can be
implemented as proposed, with improvements to come later.)


What you describe here means: This new AR would introduce a serious change  
in semantics into the MB database. I believe it is crucial to collect  
these bands and possible issues and to do some serious testing on  
test.mb.org.


How will the artist pages look like? will they still make sense?
Can people still usefully tag their files from the new semantics?
How will this splitting of bands affect other ARs?

I am not saying you need clear responses to all these questions. Just be  
aware that this is *not* just a simple addition of a new AR. You'll need  
to do a lot of testing and find a dev to work on the additional changes  
that this might require.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFC: New AR Type: Edited By

[Don Redman]

On Wed, 02 May 2007 01:03:49 +0200, Chris B wrote:


On 01/05/07, Don Redman <[EMAIL PROTECTED]> wrote:



now i'm convinced they are different things :)


yes they are


it could be handled
under my relationship though because the use should be obvious from
the context.


I suggested two types (and then my next comment makes sense)


> anyway, thoughts? i'm not sure how good my definition is. i do know
> that it's specified on releases reasonably often, and alongside
> 'remix', 'mixed by' and 'engineer' credits, so isn't the same thing.

I think it's a good idea to add both types as subtypes to the engineer
class.


what 2 types? sorry not sure what you mean :)


Luks' (movie editor)
and yours (editor)

  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFC: Bad Terminology: bootleg

[Don Redman]

On Thu, 03 May 2007 11:09:03 +0200, Sami Sundell wrote:


On Thu, May 03, 2007 at 07:59:55AM +0200, Lauri Watts wrote:


I honestly don't understand the wikipedia article's point of view.


For once, I do, at least in some respects :P


Ok, I'll give it a try (this is DonRedman's definition, not Wikipedias):

"Bootleg" is a term that describes the status of a *recording*. It  
describes a recording which was made without the rightsholder's  
permission. The rightsholder is usually either the artist or the record  
company, that the artist has an exclusive contract with.


The term says *nothing* about the legality of the distributed medium.

For example IIRC there are some reocdings of Jimi Hendrix' concerts which  
are now legally available. These are legally buyable (aka official)  
bootleg recordings.


The "fan recordings" could also be called bootlegs if you want, because  
they are made in the tradition of bootleg recordings, but in a strict  
sense they are not bootlegs.



Please comment on this attempt of a definition.

If you agree with this, it follows that indeed Olivier's proposal is the  
correct thing to do, because the Release Status describes the legal status  
of the distributed release, and says nothing about the legality of the  
recording (of course usually you are not allowed to distribute copies of a  
recording which you were not allowed to make in the first place, but  
that's not the point here).


(BTW: Don't mind that I contradicted my previous post. I am used to that  
:-) )


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFC: New Release Status: "Upcoming"

[Don Redman]

On Sat, 14 Apr 2007 19:56:44 +0200, Aaron Cooper wrote:


Thanks to the internet, information about soon-to-be released albums
is available well before the official release date.  I think we should
have a "Upcoming" or similar ReleaseStatus for albums which are added
to the database before the official retail release date.

This would allow us to add information which people find useful (with
proof, of course) before the release is available for public
consumption.  We could maintain a query of the "Upcoming" releases
(possibly sorted by expected release dates) which would make it easy
for us to review and confirm details on or after the official release
date.  The release status could then be changed appropriately.


The discussion about this proposal seems to have died out. IIUC consensus  
seems to be that really calling it "upcoming", reserving it for upcoming  
releases and using low data quality seems to be the best thing to do.


The next step to realization would be to write up a wiki page that  
describes the new release status. Then maybe discuss this some more.


Just remember: You are the developer of the new status. You can make  
'dictatorial' decisoins. Of course, if they go against common oppinions,  
you will likely get a veto. But on the other hand, making decisions can  
make this little project proceed faster and give you _more_ support for  
the final RFV.


When the feature and the way it should be used are sufficiently well  
described, issue an RFV.


Remember: You may decide to give your feature a "beta period". The period  
starts when the feature has been implemented and runs for two to four  
weeks. It means that

 * the threshold for the RFV should not bee too strict
 * some aspects of the feature can be clarified during this period
 * editors MUST NOT make mass edits in this period. Instead edits should  
be made one by one and people should ask for oppinions and discuss their  
edits.


Finally, in order to make the new feature official, you MUST make a  
blogpost or find someone to make it for you and describe the new feature  
to the MB community.




As to creating a wiki page (my suggested next step). I would suggest to  
"freeze" ReleaseStatus, so that you (and maybe Olivier, who raised the  
issue about bootlegs) can work on the wiki page, while the official  
version of the guideilne resides at /doc/ReleaseStatus. I will ask Olivier  
to do this.


I also suggest to create a page for each release status, like  
BootlegReleaseStatus, UpcomingReleaseStatus, etc.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFC: "has a blog at" AR

[Don Redman]

This proposal from Luks has not gotten any response. Maybe because it is  
so trivial and clear?


Please clarify: Do you want to add this as a subtype to "community page"  
or as a sibling to it.


Then I suggest you issue an RFV.

  DonRedman

On Sun, 08 Apr 2007 14:10:17 +0200, Lukáš Lalinský wrote:


Now, I'd like to add one more AR type from Beth's e-mail, which I think
it's quite important and it missing in our list - artist blogs:

 * " has a blog at "

Comments?

-Lukas

On So, 2007-03-10 at 21:40 +0100, Lukáš Lalinský wrote:

> You are using the same argument to add the PureVolume AR that was used
> to add the MySpace AR - but now you're removing the MySpace AR.  I
> think you need a better argument for adding a PureVolume AR since "is
> large enough" didn't work for MySpace.

No, I want to move the AR type, not individual ARs. I'd like to have
structure like this:

 * "has a community page"
   * "has a MySpace page"
   * "has a Purevolume page"

So, nothing would change for the MySpace AR type, except that it would
be one level deeper in the AR tree.




--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFC: Bad Terminology: bootleg

[Don Redman]

On Sun, 29 Apr 2007 16:21:54 +0200, Lauri Watts wrote:


As was pointed out last time this argument came up, the thing missing
in our definition is legality.  It's not a matter of sanctioned or
not, it's a matter of legal licensing.  A bootleg is illegal. Always.
Every time.  Anything that's legally licensed, is by definition not a
bootleg, however unofficial it is, including these releases.

The only thing that really needs to be added to our definition of
bootleg to bring it into the real world is adding the word 'legally'
before the word sanctioned, however, I would rewrite it as follows:

Any release that was not legally sanctioned by the rights holder,
which is normally, but not always, the artist and/or their record
label.  This includes unofficial live recordings, pirated releases,
and custom burnt compilation and 'leaked' releases including demos.
It does not include demos released by artists themselves, issues
released by record labels without the artists input, or (..any of the
other examples people seem confused about, I can't think of any
more...)


Olivier, would this solve the original problem to you? Or does this make  
things worth according to your point of view?


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFC: New AR Type: Edited By

[Don Redman]

On Tue, 01 May 2007 01:21:36 +0200, Chris B wrote:


See http://wiki.musicbrainz.org/EngineerRelationshipType

# artist edited release or track
# release or track was edited by artist

"The editor is responsible for either connecting disparate elements of
the audio recording, or otherwise redistributing material recorded in
the sessions. This is usually secondary, or additional to the work
done by the mix engineer. In many ways it is the audio-only equivalent
of  film editing ( http://en.wikipedia.org/wiki/Film_editing )."

this kinda follows on from Lukz's RFC for a 'music editor' AR but that
seems to have petered out, and although the original proposed wiki
page has since been deleted or something, from the wording of the
original thread i'm not sure he was talking about the same role as me
anyway :)


Lukas has deleted the page without any comment. So I suppose he was just  
annoyed by the fact that nothing happened. :-) I have restored it and it  
is here: 



anyway, thoughts? i'm not sure how good my definition is. i do know
that it's specified on releases reasonably often, and alongside
'remix', 'mixed by' and 'engineer' credits, so isn't the same thing.


I think it's a good ide to add both types as subtypes to the engineer  
class.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] Artistic role ARs

[Don Redman]

On Tue, 01 May 2007 11:33:03 +0200, Bogdan Butnaru wrote:


Hello!

I've tried recently to add some ARs to some new CDs, and I almost
never managed to find very good matches for the cover artists. Some
examples:

"Artwork by", "Layout by", "Typography and executive design by", "Cover  
art by".


The only similar things we have are "design/illustration by" and
"graphic design by", which don't fit very well at all. Not to mention
they're a bit redundant, as both mention design.

But neither means "artwork" (it could be more than "illustration") or
"layout", exactly, though they're similar somewhat. Shouldn't we add a
few more versions?


This field has not been touched since the first release of AR. so go ahead  
if you want to improve this.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFC: Bad Terminology: bootleg

[Don Redman]

On Fri, 27 Apr 2007 09:11:00 +0200, Frederic Da Vitoria wrote:


2007/4/27, Don Redman <[EMAIL PROTECTED]>:


I think you are not getting his point.

Bootleg *means* someting and MB has been using the term for a lot of  
stuff

that means nothing. Thus our formal and very broad definition.

I am not sure whether removing a meaningful entry of the status' list  
is a

good idea. Maybe rather add "other unofficial" and make clear that
bootlegs are only unofficial *recordings*?



Don, now it's you I don't understand :-) Who spoke about removing an  
entry?




Heh, MisunderstandingDonRedman :-) Not technically remmoving, but  
replacing "bootleg" (meaningful) with "unofficial" (formal).


I just don't think that >>The meaning of the word does not fit our formal  
definition, lets remove the meaningful word and replace it with something  
purely formal<< does make MusicBrainz a friendlier place to our users.  
Rather the opposite. To me this smells of bureaucracy...


Also I am not sure this makes things clearer. official|unofficial is  
intuitively a binary distinction. Demos could be official|unofficial as  
well. Even a bootleg recording could be officially released if the  
(initially unofficially recorded) tracks are remastered and rereleased by  
the artist or record company.


So instead I would favor something along the lines of: >>Ok, bootleg seems  
to *mean* "unofficial recording". So how should we deal with all the other  
unofficial stuff?<<.
For example you could add an entry "other unofficial" for compilations. Or  
you cold pick up the work on ReleaseTypeRestructuringProposal. I could  
even imagine that a binray distinction could be part of this. I'd just  
hate to loose a meanigful entry, that's all.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFC: Bad Terminology: bootleg

[Don Redman]

On Thu, 26 Apr 2007 10:33:28 +0200, Olivier wrote:


2007/4/26, Brian Schweitzer <[EMAIL PROTECTED]>:
Well, as I mention in my note on the LiveBootlegStyle proposal wiki  
page, we

have several classes of bootlegs that are left undefined under current
bootleg definitions.


No. Our current "bootleg" definition is exactly equivalent to
"unofficial". It matches all releases not sanctioned by the right
owners.



On http://musicbrainz.org/doc/ReleaseStatus :
  Definition of a bootleg: "This includes unofficial live recordings,
pirated releases, and custom burnt compilations."


This is what I linked to in the first mail. You're not emphasizing the
definition, which is:
 "An unofficial/underground release that was not sanctioned by the
artist and/or the record company." (which *includes* "this" and "that"
and left room for everything else matching the definition).



On wikipedia
(http://en.wikipedia.org/wiki/Bootleg_recording):
  Definition of a bootleg: "...recording of a performance that was not
officially released by the artist, or under other legal authority..."
  Same page, continued definition: "...Bootlegs can consist of  
recordings of
live performances, or material created in private or professional  
recording

sessions..."

Currently, the definition used on MusicBrainz, linked above, specifies  
only

"unofficial live recordings" as being bootlegs.


Not at all. Our current definition matches "unofficial". The is the
object of this RFC: replace "bootleg" by "unofficial" in our release
status definitions.



This then leaves undefined
1) recordings of rehearsal recordings
2) studio demos
3) recordings of soundcheck recordings
except for when those classes of recordings appear on official releases.


No, our current definition matches everything unofficial...


I think you are not getting his point.

Bootleg *means* someting and MB has been using the term for a lot of stuff  
that means nothing. Thus our formal and very broad definition.


I am not sure whether removing a meaningful entry of the status' list is a  
good idea. Maybe rather add "other unofficial" and make clear that  
bootlegs are only unofficial *recordings*?


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] forthcoming albums and their tracks.

[Don Redman]

On Wed, 04 Apr 2007 23:12:39 +0200, kuno wrote:


(ps. I'm reasonably new to this mailinglist, and am unsure if 'just',
 a wiki page is appropriate.  If the more experienced members think
 it would be better to have this discussed as a formal RFC with the
 accompanying RFV, etc...  please let me know, and I'll look into
 whatever is required for all that ;)  hm... it's not even really
 style issue is it?... still this place seemed more appropriate than
 mb-user.


'Just' a wiki page is perfectly fine. Just clearly state that this is not  
an official style guideline but some kind of good practice. It might even  
become a guideline eventually. So you could even call it  
ForthcomingReleaseStyle if you wanted. Or -- if you want to stay clear off  
the whole style bureaucracy -- just call it HowToEnterForthcomingReleases.  
;-) Seriously: I believe *Style is the better choice.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] Disc catalogue numbers

[Don Redman]

On Thu, 05 Apr 2007 16:44:32 +0200, Frederic Da Vitoria wrote:


> under the current system it would be:

CD1 =
NTCD354 + release date A
NTCD1952 + release data B

CD2 =
NTCD38l + release date C
NTCD1952 + release data B


Ok. Although I still feel we are losing information and that attaching
the release number to the individual disc is less than "reliable" (to
use your own words), I will probably seldom use the numbers, so I
might as well enter them in a way that is meaningful for those who
will actually use them.



OK, so what's  needed now is someone writing up CatalogNumberStyle or  
something like this. Or should this be an addition to BoxSetNameStyle? Or  
should we make a new BoxSetStyle that combines both?


If you want to work on BoxSetNameStyle, please ask Olivier to wikidocsel  
revision 6 of that page. Then you can edit the wiki page at will if you  
leave a big warning that the official version resides at  
mb.org/doc/BoxSetNameStyle. If you want to create a new page proceed as  
usual.


'Beta' editing seems already to be going on, so this one could take less  
than a month, if we're lucky ;-).


Happy Easter eggs (or resurged Messiah, depending on your religious  
preferences)!


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

[mb-style] RFV: Opera Track Style

[Don Redman]

On Tue, 27 Mar 2007 16:39:21 +0200, Aaron Cooper wrote:


It looks wonderful!  Great work everyone!  :)

We could use a few more example releases - I'll try and get my Der
Ring box set updated and linked.

Cheers!


Very cool and thanks to everybody who took part. I do not think a veto is  
really necessary, but for formal correctness:


Does anybody believe that MusicBrainz will become a worse place if this  
guideline becomes official? If so, please issue your veto within the next  
48 hours.


If noone issues a veto until Thursday 21:00 European Summertime. The bare  
"sceleton" of the guideline is acceptet. In order to get some flesh, the  
following should happen (forgive me the metaphor):


Someone (Fréderic or me) will make a blogpost and announce the new  
styleguide. This announcement will include (save this list for the next  
RFC/RFV :-) ):

 * A short summary of the guideline
 * A link to the Wiki page
 * The request not to do any mass edits that follow this guideline fot the  
next two or three weeks.
 * A link to a new forum thread about this guideline and the request to  
post any questions, issues and problems there.


That way the guideilne will slowly become official over the course of two  
or three weeks.


Is that ok with everyone?
Fréderic can I put the burden of the blogpost on you?

  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFC: Opera Track Style: Vote on Two Options

[Don Redman]

On Mon, 19 Mar 2007 23:36:18 +0100, Frederic Da Vitoria wrote:


I have introduced a third possibility (which there almost since the
beginning but got lost somehow in the discussion). If somebody feels
it is too late to do it and I must choose between the first
possibilities, my vote will be... the second. I changed my mind once
again because I believe the first doesn't work if the PartType or the
Characters are omitted;


Which third possibility? Where is it? Is it on the wiki page? Did you  
apply it in an edit but not document it on the wiki? Who was for it? Why  
did it get lost? Why do you introduce it again? Aaargh! #-O


Um, ok, back to normal. I suppose you refer to the Idea leivhe mentioned  
on . That discussion had  
slipped past me. [1]

IIUC that would be:
 3. OperaName, OpusNumber: ActNumber[, SceneNumber].
PerformanceType (Characters) "Name of the song"

If you think it is worth it, then please update the wiki and start this  
vote again. I am not sure whether #3 would override #1, or the vote should  
have three options. Frederic, please decide as you seem fit. You can also  
wati a day or two (but not more please) :-)


(BTW one link to your edits seems to be broken on the wiki page)

  DonRedman


[1] Mental note: Beta editing works and makes sense, but it is difficult  
to keep track of.


--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

[mb-style] RFC: Opera Track Style: Vote on Two Options

[Don Redman]

OK, seems we need a clear decision now. The wiki page lists the two  
options that remain:


 1. OperaName, OpusNumber: ActNumber[, SceneNumber]. (PerformanceType:  
Characters) "Name of the song"
 2. OperaName, OpusNumber: ActNumber[, SceneNumber]. PerformanceType "Name  
of the song" (Characters)




I'll ask everybody who took part or read in the past discussions, to  
please make a *BRIEF* statement which option they prefer. Yes this is a  
vote. After that I'll help Frederic to edit the wiki page so that it  
reflects that one oppinion. Then we'll make a brief RFV, and then the  
guideline can slowly start to be applied.


Here is my statement:

I am for option #2 because this is most similar to all other MB  
guidelines. >>Duettino "La ci darem la mano"<< is more like the title of  
the song, and >>(Don Giovanni, Zerlina)<< is more like the featuring  
information.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFC: Classical Part Numbering

[Don Redman]

On Sun, 11 Mar 2007 17:33:59 +0100, Robert Kiessling wrote:


Are track titles required to be unique within one release?


No

  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] Fwd: Purevolume URL Relationship Missing

[Don Redman]

On Sat, 10 Mar 2007 08:53:57 +0100, Lukáš Lalinský wrote:


We already have an AR type for MySpace and the main argument for it was
that it's big enough. I think Purevolume is big enough as well *and*
it's specialized to music. So, I'm proposing these changes:

 * Add new AR type "has a community page at".
 * Move the MySpace AR type under this new one.
 * Add new AR type "has a Purevolume page at".

Comments?


I am very much for the first steps and have no oppinion about the third  
one.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFV: New AR Type: Music Editor

[Don Redman]

On Sat, 10 Mar 2007 08:56:26 +0100, Lukáš Lalinský wrote:


On Pi, 2007-03-02 at 10:27 -0800, Kerensky97 wrote:
I still think "editor" is ambiguous enough to cause alot of confusion  
like I mentioned in the RFC, even labels use it in different ways; but  
I guess it could be solved if there's a really good definition of what  
specifically an editor is in this AR.


I take this as a veto, right?


I dont' think so. You really need to use the word "veto" if you want to  
cast one.

And Frederic Da Vitoria wrote:


Couldn't we put something in the combo itself; like "(film) editor" or
"editor (film)" ?


That would pretty much solve the issue, wouldn't it?

  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mailing] [mb-style] RFC: Opera Track Style

[Don Redman]

On Wed, 07 Mar 2007 13:29:39 +0100, Frederic Da Vitoria wrote:


Alternatively you can say: Hey, I'ts a wiki. Just delete stuff as you
like, and link to the old revision of the page for historical purpose  
like

this: 


Yes, but this is for experts who know how a wiki works or for those
who are thorough enough to do so. Keeping visible (and searchable)
pages seems a better option to me. Maybe these pages could be
synthesised a little: I don't think we need to keep track of each
specific answer, what is most useful IMO is:
- what has been tried,
- why it was not kept and
- when.


Right, as you prefer. Just go for it.

BTW What you describe is called TentativeSummary over at The Wiki:


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] Albums compiled by artists

[Don Redman]

On Thu, 08 Mar 2007 11:07:00 +0100,  wrote:


The compiling artist is credited on the cover, I would expect these kind
of albums to appear on the artist page (in the appropriate section, not
along their regular albums)._I_ fail to see why it would be better to
keep them linked to 'various artists' as an artist, [...]


You gave the reason yourself: "not along their regular albums". And that  
is exactly why I an so opposed to this.
I do not care whether the compiling artist is in the artist field or not.  
But I do not want this release to appear *along their regular  
compilations*. However this is exactly what will happen if you put the  
compiling artist is in the artist field.


[...] keep them linked to 'various artists' as an artist, wherethey will  
be harder to find for those looking for them.


Why? They are listed in the AR list for that artist. If you are looking  
for an album compiled by X, where would be a better place to search than  
the "X complied ..." section of the ARs?


OK, I agree that the current display is *very* rudimentary. (No wonder, I  
helped design it ;-) ). Keschte has started to redesign this stuff, and  
the bits I have seen are very nice and usable. However it is not finished  
and he is no longer part of the project. But that would be the way to  
solve your problem.


I mean, we *have* a data structure to represent this: the "compiled by"  
AR, so why not use it. And IMO the *primary* artist of such a compilation  
are the performing artists, and those are various.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] Albums compiled by artists

[Don Redman]

On Tue, 06 Mar 2007 11:37:33 +0100, Erik Dalén wrote:


Chris Bransden wrote:

On 06/03/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:


I agree :)

> So in your opinion this release should be Ladytron not Various  
Artists?

>
>
http://musicbrainz.org/release/b6cbb7a5-a0c2-47f8-93a2-7157874249eb.html

Yes. (imo).

-- kuno (warp).


thirded :) this release is part of the ladytron canon, regardless of
it having VA content. it needs to appear on their artist page (other
than just an AR), IMO.



ok:

http://musicbrainz.org/show/edit/?editid=6534607



I do not know Ladytron or this special release, but I disagree that these  
should be generally set to the compiling artist.

I suppose this greatly depends on the genre of music.

For a rock artist, the difference between an album of their own and a  
compilation of tracks that influenced them is huge.
For an electronic artist, the difference between the usual remixes-album  
and such a compilation is not that big.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mailing] [mb-style] RFC: Opera Track Style

[Don Redman]

On Mon, 05 Mar 2007 23:08:07 +0100, Frederic Da Vitoria wrote:


2007/3/5, Aaron Cooper <[EMAIL PROTECTED]>:

I would like to clean up the OTS wiki page, but I dislike the idea of
"deleting" all documentation of our discussions (and all of Frederic's
work!).  What do we think about moving the current OTS contents to
OperaTrackStyleProposal and then using OperaTrackStyle to document the
guidelines?


Yes. Or OperaTrackStyleDiscussion, since it may need a page to discuss
evolutions. I agree keeping track of the history is important. Thus
newcomers may see that some ideas were already suggested and why they
were not kept.


That makes perfect sense. We also have HistoryOf... pages. You could just  
copy all old stuff to HistoryOfOperaTrackStyle instead of deleting it.


Alternatively you can say: Hey, I'ts a wiki. Just delete stuff as you  
like, and link to the old revision of the page for historical purpose like  
this: 


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mailing] [mb-style] RFC: Opera Track Style

[Don Redman]

On Fri, 02 Mar 2007 13:26:33 +0100, Frederic Da Vitoria wrote:


2007/3/2, Aaron Cooper <[EMAIL PROTECTED]>:

On 3/2/07, Frederic Da Vitoria <[EMAIL PROTECTED]> wrote:
> Do you want to try Don's suggestion yourself? It would mean editing an
> actual release this way and telling other users you have done so that
> we can see if it works.

I would like to try Don's procedure, but I am unclear as to when the
style becomes "official".  Would editing a 14-disc 'The Ring' set be
enough of a testing ground?  I know that many of those complex
examples exist on a release I own.

I think I will edit that release this afternoon and post the edit #'s
here for everyone to review and we can move forward from there, one
step at a time :)


I suppose we can't really define the number of tests before triggering
the RFV. It depends on the complexity of the rule being tested. For
this one, I suppose the relevant releases are potentially quite
different so we have probably missed problems, but OTOH the rule
itself is pretty simple... and it is really needed! So you can send
the RFV as soon as you think we have enough actual edits to support
it.



My intention was not to place even more burdens on you by having you make  
test edits.
I have explained a bit what I *did* mean, and I have done it as a podcast  
to save my fingers some typing. It's 5 minutes long (and no, it does not  
have a MBID yet ;-) )




listen, then read on:

I would suggest, you delete all the clutter form the wiki page ('cooked'  
discussions, the alternative orderings etc) and then present this as a RFV  
pretty soon and without too much fuss. Then we have a 'beta period' for a  
while (as explained in voice), and then we make the guideline 'stable'.


What do you think?

  DonRedman
--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mailing] [mb-style] RFC: Standardizing Classical Release Titles

[Don Redman]

On Wed, 31 Jan 2007 00:22:38 +0100, Aaron Cooper wrote:


Well, this discussion died off 4 days ago and I did manage to scrounge
up some time over last weekend to throw together the beginnings of a
Wiki page @ http://wiki.musicbrainz.org/ClassicalReleaseTitleStyle -
Please check it out and post comments.


I have reworded and reordered stuff on the wiki page. I hope I have not  
changed the meaning. Please check and improve or revert. :-)


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mailing] [mb-style] RFC: Standardizing Classical Release Titles

[Don Redman]

On Sat, 27 Jan 2007 13:38:54 +0100, David Gibson wrote:


Erm.. except I believe the thread was discussion classical Release
Titles, not Track Titles.


How embarrasing. :-) Funny that I did not realise this while reading  
through the 50+ mails. I really have been reading too fast. Sorry.


Still the propsal is valid. Just create ClassicalReleaseTitleStyle and go  
ahead.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mailing] [mb-style] RFC: Standardizing Classical Release Titles

[Don Redman]

On Fri, 26 Jan 2007 00:29:45 +0100, Aaron Cooper wrote:


I started this thread to get rid of this:

Symphon[y|ies] No[s|]. 5[, | / | & ] [No[s|].|] 7
// square brackets imply a choice between the items separated by bars
// so, for example we currently have:
// Symphony No. 5 / No. 7
// Symphonies No. 5, No. 7
// Symphony Nos. 5, 7
// Symphonies Nos. 5 & 7, etc.

And make this:

Symphonies Nos. 5, 7



Aaron, As I wrote to Frederic in the other mail: To avoid that this thread  
ends with no descisions made, you could try to summarize what you believe  
most people could agree with on the wiki page. I have renamed it to  
ClassicalTrackTitleStyle for standard naming.


If you want to bring this forwad, then I encourage you to be bold. Delete  
discussions, make sensible decisions and do not wait for perfect  
consensus, clean up the page. And when you grow tired of the discussion,  
propose it for RFV for a kind of beta stage.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

[mb-style] How to Proceed (Was: RFC: Opera Track Style)

[Don Redman]

On Thu, 25 Jan 2007 10:14:16 +0100, Frederic Da Vitoria wrote:


Back on track

We still have three issues here
- information order
- "punctuation"
- numbering system

Should we start three different threads?


Holy Moose, no!

I very strongly suggest that you create OperaTrackStyle, summarise the  
'most consensual' guideline there, and maybe add some variants that are  
discussed.
You should tag it as a ProposedGuideline and link to it from CSG CSGD, and  
ideally move all the relevant discussion over to the new page (better even  
summarize the talk and delete it), so that people know where to add their  
two cents.


Also, I would encourage you to integrate as much of the discussion here,  
*as you seem fit*, but not more. Be a bit like a developer who writes up a  
new module. In fact the guidelines *are* a kind of code. Just not  
computer-code but human-interpretable code.


I hope that such a wiki page and your assuming the role of a 'developer'  
of the guideline helps to genearte a *result*. something which the process  
hiere is often lacking.



Ok, that's for now. Additionally we could lower the barrier for the RFV  
and give the new guideilne a beta-period. That means we would just do a  
quick vote: Is this good enough to be slowly tested? if there is no veto,  
Frederic would announce the new guideline on the blog (you'll get an  
account from Robert) and on mb-users, and maybe the forums (I don't know  
them). I could help to descibe what beta-period means (though I cannot  
type a lot, I am still suffering from RSI). and editors would slowly start  
to apply the new guideline and discuss all its ramifications, maybe even  
adapt the guideline a bit.


Then when the guideline has become an accepted practice, we can declare it  
"stable". I could ask MLL to make the appropriate changes to WikiDocs.


Ar you willing to try this out?

  DonRedman, the secreatary. who presents his most regretting excuses for  
not being that active anymore



--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFC: Standardizing Classical Release Titles

[Don Redman]

On Mon, 22 Jan 2007 06:54:06 +0100, Aaron Cooper wrote:


Good evening,

I want to propose a standard way of titling classical releases.  This
wouldn't apply to compilations with several parts of different works,
but rather for releases which have an (or multiple) entire works.
Here's the gist:

Separate multiple works of the same "type" with commas (,).
Separate multiple works of different "types" with slashes (/).
Hyphens (-) are used when there are three or more consecutively
numbered works of the same type.


You mean space, slash, space ( / ), right? And the comma is comma and  
space (, ), but this should be obvious.


In fact this seems to make for a really good *general* ennumeration rule.  
What would you think of appending this to MultipleTitleStyle? Maybe not on  
that page but on an additional ComplexMultipleTitleStyle. Because, if you  
look at it from the outside, then what you classic folks have to deal with  
is nothing but very complex multiple tracks/works in one title field.


I would also like to add that such complex rules should not be in the way  
of adding releases to MB, IMO. They should be good for cleaning up, but  
not for voting stuff down. (But I am talking theory here. I do not know  
the voting practices of the classical people here at all)


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

[mb-style] FW: [mb-users] Remasters of Jean Michel Jarre

[Don Redman]

On Sat, 13 Jan 2007 12:20:29 +0100, Chris Bransden wrote on mb-users:


On 12/01/07, Erik Dalén <[EMAIL PROTECTED]> wrote:


As I understand it remastered releases should be added as a new release
with a remaster AR to the original even if the track list hasn't  
changed,

right?



i seem to recall there being something in the wiki that says as much,  
but i
can't find it, and there never seemed to be a rational reason for it  
anyway

when we merge vinyl versions (all different formats are mastered
separately), different label releases, boxset versions, etc, etc.

none of my subscribed artists have their mastered versions separated out  
-

the users have voted with their edits :)


I believe this is about  
http://wiki.musicbrainz.org/RemasterRelationshipType
Is there any other page that mentions explicitly that remasters should be  
entered as separate releases? Should the guidelines be changed? Or should  
we wait until Lukas' labels come out, since they might affect the whole  
issue?

  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] Re: Should we keep the spaces before punctuation in french?

[Don Redman]

On Mon, 08 Jan 2007 22:04:55 +0100, Frederic Da Vitoria wrote:


2007/1/8, Don Redman <[EMAIL PROTECTED]>:


<http://musicbrainz.org/style.html>.


Wow, I didn't know this page even existed!


Should this not be
changed to <http://musicbrainz.org/doc/StyleGuideline>?

But maybe the StyleGuideline and OfficialStyleGuideline page should be
cleand up a bit, and discussions should be moved out to *Discussion  
pages,

etc. but that should be worth the effort. Should we do that?


I think we should first decide what we want to do about the
documentation (apart from enhancing the rules, of course). Do we want
to create a reference system? Or a quick procedure guide? Or both?
Personally, I'd prefer the last option, reference because it is the
best way to get close to completeness, procedure because if we don't
offer this newbies will flee away from MB.


I really like your idea of HowToAdd... pages.

Question is, if people start to mass edit style pages (without changing  
the wording of the guidelines), should we "freeze" the status quo of the  
wiki as WikiDocs pages beforehand?


I could ask MLL to do this, but it's quite some work, and I guess he might  
not want to do this all on his own.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] Re: Should we keep the spaces before punctuation in french?

[Don Redman]

On Mon, 08 Jan 2007 21:30:03 +0100, Frederic Da Vitoria wrote:


2007/1/8, Olivier <[EMAIL PROTECTED]>:

Sure this is something that needs to be addressed... definitely
MusicBrainz is a complicated beast.


I guess many style rules will become useless once Loch Ness, sorry NGS  
is here.


I am afraid they won't. There might be even more of them (though they  
might get somewhat simpler).


On a related matter, the official link to "Editing Style" on the main page  
still points to . Should this not be  
changed to ?


But maybe the StyleGuideline and OfficialStyleGuideline page should be  
cleand up a bit, and discussions should be moved out to *Discussion pages,  
etc. but that should be worth the effort. Should we do that?


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] CSG reflecting MBz style [Was: Re: Should we keep the spaces before punctuation in french?]

[Don Redman]

On Mon, 08 Jan 2007 20:43:50 +0100, Olivier wrote:


Well... I can't help but being disturbed by that way to proceed (which
possibly you are/were not alone to have experienced?), which at least
in its process places the CSG "before" other documents...



Ok... wouldn't this still make a consequent quantity of additional
information to add to the CSG?
Sorry to be picky, but I feel this still (in the process) make people
consider the CSG *is* the codex, concentrating all info (classical
exclusively and non-classical altogether, which would possibly prove
confusing?).




Isn't after all the CSG just one styleguide among others?

*blink* :p




No it's not and that's part of the problem. All other guidelines tell you  
how to enter a specific bit of information (e.g. a subtitle) into a field  
(e.g. into the track/releasetitle after a colon following the main title).


The CSG tells you how to fit all possible bits of information into all  
fields. IMHO it is both a terribly long page, that you cannot require the  
casual user to read, and a TooLargePage for a wiki (it contains too much  
different stuff in one place that should be spilt over someting like ten  
pages).


I believe we need one page, not longer that two screens that sums up this  
"how to fit any information into all fields" usnig *one* (maybe fictional)  
example and that links to detailed pages with explanations, more examples,  
details etc.


Sometimes this might be an existing page ("... as in MultipleTitleStyle"),  
sometimes not. Then you may create new pages (ClassicalOpusNoStyle?) or  
maybe add new sections/sister pages to existing pages (ReleaseArtistStyle,  
ClassicalReleaseArtistSytle. The latter would start with: "This is a  
special case of ReleaseArtistStyle that applies to classical music only").


The current CSG is saved and fixed at  
. That means that everyone  
can edit the wiki pages at will. When everything is done, you can put the  
whole thing to RFC/RFV.



All in all CSG needs more intertwingling not less.


Actually I think that the metaphor of  that you enter  
into  could be used to massively clarify all the guidelines. Look  
at pages like DiscNumber ReleaseTitle and MainTitle. Some of them talk  
about  some about . If we added a page for each  
field: TrackTitleField, TrackNumberField, and used the existing pages to  
describe the , you could write very precise sentences  
like "The SubTitle of a track is stored in the TrackTitleField after the  
MainTitle and ': ' (colon space) according to the SubTitleStyle." This way  
people could access the guidelines by three ways:


 1) I have this bit of information, where do I put it, and how do I format  
it?

 2) How do I format stuff that comes into this field?
 3) What are the rules around here?

That would be even more intertwingling, but I believe these three  
approaches would be extremely useful for classical data.


  DonRedman


--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] Is a common CSG possible and/or desirable?

[Don Redman]

On Mon, 11 Dec 2006 23:18:21 +0100, Frederic Da Vitoria wrote:


2006/12/11, Frederic Da Vitoria <[EMAIL PROTECTED]>:

Ok. Thanks for the explanations. We still miss the name of the
discussion page. The name is not too important, after all, this should
be a temporary page!


I have browsed this thread and I found the following suggestions:
-ClassicalTrackTitleStyleCondensed
-BringingBackClassicalStyleToMainstream
-CondensedClassicalStyleGuide
-GrandClassicalUnificationTheory
-ClassicalTracksTitlesStyleGuide

So far, IMO, the first suggestion is the one that best suggests the
scope of the changes Leiv called for.

What about ClassicalTrackTitleStyleRevision?


No, the point is that you do not *need* a new page. Just go and edit  
 *directly*. The old  
revision is preserved at .


Just keep the note at the top intact.

  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] Is a common CSG possible and/or desirable?

[Don Redman]

On Mon, 11 Dec 2006 22:31:20 +0100, Frederic Da Vitoria wrote:


2006/12/11, mll <[EMAIL PROTECTED]>:

OK, DonRedman lent me his magical wand so that (I shorten) now
http://wiki.musicbrainz.org/ClassicalStyleGuide will be pasted to
http://musicbrainz.org/doc/ClassicalStyleGuide only when we decide it  
(and

not instantly until now).

So now we can start the rehaul Leiv suggested, on the to be created page
(ClassicalTracksTitlesStyleGuide ?), and even on ClassicalStyleGuide.  
This
is why Don & I added at the top of wiki.CSG "This is work in progress  
and

not official. The Classical Style Guide is currently being reworded. The
currently official version of the Classical Style Guide is located at
http://musicbrainz.org/doc/ClassicalStyleGuide.";


When we think the result is ok to be released to the world at
http://musicbrainz.org/doc/ClassicalStyleGuide, then we'll change the
version in the transclusion table (more info on this at
http://wiki.musicbrainz.org/WikiDocs).

MLL


Ok. Where is this discussion going to happen? I should say: "where are
those discussions"! Here, the forums, the new wiki page, all three of
them?



Decisions happen _here_ using the good old RFC/RFV mechanism. There will  
be a big Official Notice from me if this should change.


The only difference is that *anybody* can edit the CSG wiki page(s) at  
will. Once someone believes the wiki version should be made official, they  
can issue a RFC (if there was a previous RFC, during which the wiki was  
edited). If the RFV passes, MLL will update the transclusion table, which  
will update http://musicbrainz.org/doc/ClassicalStyleGuide to reflect the  
changes in the wiki.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] Cantata and movement names names: where ?

[Don Redman]

On Sun, 03 Dec 2006 23:36:42 +0100, Andrew Conkling wrote:


Have we reached any consensus on this? I'm getting a bit confused
rereading this thread, but I'm on a Bach rampage and am looking to
clean up a few cantata releases.


Heh, someone should try to summarise the result. That's what RFC/RFV is  
for, too. :-)


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFC: SeriesStyleGuideline

[Don Redman]

On Mon, 13 Nov 2006 22:39:38 +0100, Lauri Watts wrote:


I'd love to see the CdM and MoS 'current practise' written up too, and
there are probably plenty more around, concensus built over time, and
known only to a handful of people, or buried in edit notes.


I love this term "Current Practice".

That's what these 'things' should really be: A documentation of current  
practice. With no more (nor less) legitimacy than "that's what we've benn  
doing all the time". Maybe add a littel "because " :-)


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

[mb-style] RFC: SeriesStyleGuideline

[Don Redman]

On Thu, 09 Nov 2006 23:54:08 +0100, azertus wrote:


2006/11/9, Lauri Watts <[EMAIL PROTECTED]>:

I've made some small formatting edits to the Promo Only guideline
page, which I think clarifies which of it comprise the actual
guideline, and which parts are just extra information.

I hope this helps allay your fears, I'd like to hear what you think  
about it.


http://wiki.musicbrainz.org/PromoOnlySeriesStyle


I agree that this makes them more readable. Per my other reply I'm
still not convinced about the need for these guidelines though.


OK here comes the content-oriente part of my reply:

I can really understand Azertus' concerns. When we had the Promo Only  
style, I had suggested, not to call these pages style guidelines. What  
about these two steps:


#1 We reduce the "guideline" to two lines as proposed:

  '''Promo Only: ''!SeriesName'', ''Month !FullYear' [[BR]]
  Example: "Promo Only: Modern Rock Radio, October 2006"

#2 We put all of this into SeriesStyleGuideline: One concise list of all  
series styles.


#3 We put all details into additional wiki pages, which are not called  
*Style. Just PromoOnlySeries. These contain additional info etc, but no  
guidelines


#4 These pages can be created by anyone without the RFC/RFV process, but  
you need a (short) RFC/RFV to make changes to SeriesStyleGuideline.  
Non-approved series will be listed in a separate "informal" section.


#5 We add a paragraph to SeriesStyleGuideline explaining that this  
guideline is "weak".


Can everybody live with that?

Erm,  I realised this is a new RFC and changed the topic accordingliy  
:-)


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

[mb-style] What a veto means (Was: RFV: DMCSeriesStyle)

[Don Redman]

On Thu, 09 Nov 2006 23:38:01 +0100, Jason Bouwmeester wrote:


Hardly; only if other people feel the same way, I guess.


Oh I was just under the impression that one veto was all it took.


That is only half of it. All of it goes like this:

If you really believe that MusicBrainz will become a worse place if it  
accepted the proposed StyleChange, then any active participant in the  
Style Council can veto after a RFV.


This means that the Style Council cannot reach consensus. The council has  
therefore not made any decision. Neither was the change accepted, nor was  
it rejected. The council is simply incapable of making a consensual  
decision.


Therfore the power to make a decision is handed over to our Evil Overlord  
Robert Kaye. I (the Secretary) will contact him, explain the situation to  
him from a neutral point of view (if possible), and then he will make a  
decision.


That's the current formal RFV process.


The fact that this situation is pretty rare shows that the Style Coucil  
_can_ make consensual decisions most of the time.


Actually I believe that this is still possible, but I'll make a proposal  
in a different post.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] WikiDocs for StyleGuidelines?

[Don Redman]

On Tue, 07 Nov 2006 11:00:04 +0100, Age Bosma wrote:


I mean templates: http://en.wikipedia.org/wiki/Help:Template

Where we can just put a bit of HTML in a separate template page: style="border: 1px solid #3F3F3F; background-color: #FF;  
font-weight: bold; text-align: center; padding: 0px 10px 0px 10px;  
margin: 10px 0px 10px 0px;">Deprecated


And call the template where needed: {{deprecated}}


As far as I can tell, MoinMoin does not support the same kind of  
templates, nor does it allow me to include HTML :-(


There is this macro:  that  
does most of what you want. Moin does allow to include HTML _if_ the  
parser is enabled, which it is not for security reasons.


There is a version for Moin 1.3 and if Robert could install it, we could  
take care of the rest.
There are also Macros called Color and Color2 but they either work for 1.0  
or 1.5, AFAICT.


We will have to find out, if the CardMacro works well with WikiDocs, or if  
something breaks (IIRC Robert patched the Include Macro in our wiki).


You mean that as soon as a status on one of the wiki pages changes to  
official the one who is monitoring it should automatically change it to  
a wikidoc (update the transclusion table)?
I think this might be a bit too error-prone. It happens quite often that  
people change something and realize afterwards that they e.g. forgot a  
tiny bit so they start editing again. One of the moderators might have  
already updated the transclusion table in the meanwhile. Because of this  
I thought it would be better to submit a ticket with 'please update this  
page, it's really ready now'.


Yes, that's what I mean, and yes, your criticism might be valid. Although  
we will have to find out which of these two ways is easier to do.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] WikiDocs for StyleGuidelines?

[Don Redman]

On Mon, 06 Nov 2006 22:21:11 +0100, Age Bosma wrote:


 Would this be worth the work?



I think it will. We have the system in place so why not us it to the  
fullest. It would sure fit nicely in the current discussion on the forum  
about changing and improving the RFC/RFV process [1].


I do, however, have a few concerns:

The status of a specific page should be made _very_ clear. The current  
icon and line of text is far to easy to overlook. I suggest to put a  
nice box around the status line with a black (#3F3F3F) border and  
different background colours for each status. I don't know how many  
possible statuses we are dealing with throughout the wiki but simple  
colours like green (#99FF99) for 'official', blue (#FF) for 'working  
draft' and red (#FF) for 'deprecated' come to mind.
Can we use templates in our wiki at the moment? If yes than it shouldn't  
be hard to add or change the status of a page.


What exactly do you mean?
There are some icons that we can use  



I do no know of any existing Macro that would display a box. I guess with  
some python knowledge it should be easy to create one, though.



Wiki's tend to become a maze quite fast. Especially when they are used  
for documentation purposes, like in our case, it's necessary to have a  
solid structure. I already feel lost in the current wiki pages every now  
and again ;-)
To prevent the wiki from becoming a real maze, imo a set of guidelines  
(...more guidelines...) should be created providing steps to go through  
for each type of page. The same basically goes for the content structure  
which should be used for a specific page.


With the CategoryProducts pages, Keschte and me introduced breadcrumbs. We  
could use that for the OSG too.
that would mean to reorganize some pages. E.g. there is a mess between  
StyleGuideline and OfficialStyleGuideline, and I have no idea how to clean  
that up.


People should not have to knock on too many doors to get something done.  
When there's a specific group of people who are allowed to add or change  
something in the wikidocs, you don't want to have to ask them directly  
by sending them an e-mail or wait for them to come online in the IRC  
channel. Probably the best way to handle this is to add a ticket to the  
tracker in a dedicated category when a work is finished. This way the  
wiki people don't have to be active in every discussion all the time and  
they can just go through each ticket every now and again.


If you mean us when reorganizing the wiki, then we do not need tickets. We  
just watch each other's steps closely. I have just started to reorganize  
ReleaseAttribute, and would appreciate if someone followed my tracks.


If you mean how changes get wikidocselt (i.e. the revision in WikiDocs is  
raised), then this should be easy. If the person who moderates this  
section of the wiki is subscribed to the page, they get the change emailed  
and can update the transclusion table. Since official *Style pages do not  
change too often, that should be feasible.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFV: Translation Transliteration Relationship Type

[Don Redman]

On Sun, 05 Nov 2006 16:15:33 +0100, Alexander Dupuy wrote:

Anyhow - no need for a new RFV on this - as I was the only one objecting  
strongly to the attribute, we can add it provisionally, and remove it  
once the server support on updated album page makes it obsolete.


Done: 

Does this need an announcement or just a comment to the blogpost? If so,  
Dustin, would you please do that? Thanks,


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

[mb-style] WikiDocs for StyleGuidelines?

[Don Redman]

OK, here is a simple idea:

I have observed that people who propose _new_ guidelines or AR types  
create a wiki page and work the changes in. This makes it easy to make an  
RFV at the end. It's nothing more than: Should we make that page official?


People who want to change a guideline have a hard time doing this, since  
the page is already there and must represent the currently official view.


Now, MusicBrainz has a system in place that could solve this very  
efficiently: WikiDocs.


WikiDocs [1] means that we can 'freeze' a wiki page at a certain version.  
This version will be shown at musicbrainz.org/doc/SomePageName. People can  
still change the page on wiki.musicbrainz.org/SomePageName, but this will  
not affect the /doc/ page (we call this the "transcluded" page).
This way it is possible to have an official version under mb.org/doc/ and  
a refined draft at wiki.mb.org.


Should we do this for the OfficialStyleGuidelines? Maybe even for the AR  
documentation?



This would require:

 (1) Two or three people volunteering to observe the wiki and the style  
council so that they update the pages when needed. This is not much more  
work than staying up to date. I would explain the details of the system to  
these WikiDocsModerators.


 (2) A community effort to make the wiki pages ready for WikiDocs. This is  
a matter of a few days if a couple of active wiki editors join in. We'd  
have to

  * Move the Discussion out to /Discussion sub-pages
  * Put a standard notice on every page that makes clear where to find the  
official version, and where the draft


The offical version would look like this:  
 (note the status  
message)
The working draft would look like this:  
 (with  
different status message). Maybe these messages could be autogenerated.


 (3) Actually we would probably find a lot of stuff that can be clarified  
on the wiki pages. So there would be some reformulating, restructuring,  
and reformating to do without _changing_ the guidelies. This would mean  
some work, but we could finally replace that dreaded  
 page.


Would this be worth the work?

  DonRedman



[1] http://wiki.musicbrainz.org/WikiDocs

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

[mb-style] RFC: How to handle band/artist name changes (Was a RFV)

[Don Redman]

On Mon, 06 Nov 2006 12:07:03 +0100, Age Bosma wrote:


Kerensky97 wrote:
Add me as another person who really likes this idea but not the wording  
of

"legal".  If we can just think of a different way to word it I think it
would be great.



Who are the other people who don't like the wording of 'legal'? ;-)


I do not think we need a rewording, but I believe that we should state  
very clearly that the common world definition of the term differs from the  
MB definition.


Could it be that we just have to *define* that in MB a person has *one and  
exactly one* LegalName?



Offtopic:  RFV already?


Yeah, there was no response on the other thread any more and this RFV  
was the consensus of that discussion. It's a bit strange that people  
start to object to the 'apply attribute automatically' bit now instead  
of earlier.


I have to agree with the arguments given and we shouldn't apply the  
'legal' attribute to the existing ARs automatically for the reasons they  
pointed out. I do, however, see no reason to leave the 'legal name'  
attribute out or change it. I can't think of any other way of naming it  
and I think we all agree that we should be able to make the distinction.


We could change the AR even more to allow it to be used for all these  
relations:

- 'legal name <-> legal name'
- 'performance name <-> performance name'
- 'legal name <-> performance name'

It will get complicated but at least it will allow us to specify  
multiple legal names where it's needed.


A way to implement it could be:
- Provide a dropdown or radio button selection to choose a) 'performance  
name' or b) 'legal name'

- Change the phrases to:
1. '*artist* is/was a name used by *artist*'
1a. '*artist* is/was a performance name used by *artist*'
1b. '*artist* is/was a legal name used by *artist*'
2. '*artist* is/was using the name *artist*'
2a. '*artist* is/was using the performance name *artist*'
2b. '*artist* is/was using the legal name *artist*'

I guess we are starting the process all over again but how does this  
sound?


Starting over again sounds right to me. At least drop back to RFC (I  
changed the subject).


As I said before, this could change the semantics of MB in a substantial  
way. I think you need to have clear responses to these questions before  
doing a RFV:


 * How will this affect the question which release
   is stored under which artist?
   If this will change, then you _must_ do beta editing.

 * Will this create relationship clusters?
   If so why is this desirable (we try to avoid them as
   much as possible).

  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFV: Translation Transliteration Relationship Type

[Don Redman]

On Sat, 04 Nov 2006 00:14:56 +0100, Kerensky97 wrote:



Maybe I won't add it to Trac, it keeps saying "Akismet rejected spam"


Uh?

Whatever, here it is: 

And I have added a comment to Rob'S recent blogpost. Howver, I am not  
sure, this attribute can be added in the next mini-release. Customers  
might need to be warned that there is a new attribute.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] ARs for labels

[Don Redman]

On Fri, 03 Nov 2006 17:54:55 +0100, Lukáš Lalinský wrote:


Hi,

I'm working on adding support for labels/catalog numbers. Now that I have
implemented adding ARs for labels, I started thinking about possible AR  
types we will need. I can think only of these two:.


Just to be sure: Labels will be linked to Releases by a core relationship,  
that is why you are not listing label--release ARs, right?


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFV: Translation Transliteration Relationship Type

[Don Redman]

On Sat, 04 Nov 2006 01:30:12 +0100, Kerensky97 wrote:


I tried to fix one of the mistagged ones but it doesn't let you have
two of the ARs at the same time so to correct something people would
have to remove the error "translation" AR then re-enter the AR with
the "transliteration" checkbox.


Uh? did not get that

  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFV: Translation Transliteration Relationship Type

[Don Redman]

OK, we seem to have consensus about this. Should I make a RFV for this or  
is this part of the first one? If everybody is ok with it, I can change  
the AR definition now to the way it is on test.


I have already added the new attribute, but not enabled it in the AR.

I have lost track of this RFV a bit, so I am not sure what to do. Please  
tell me: Should I make the change _now_?


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFV: Translation Transliteration Relationship Type

[Don Redman]

On Fri, 03 Nov 2006 22:09:34 +0100, Kerensky97 wrote:



So who is the person to talk to to get this done?  The AR is live but  
doesn't distinguish between Transliteration ar Translation yet.


Do you need that to be changed like it is on the test server? Or the  
alternate proposal with just one attribute? If you give me exact  
instructions I can make the change.



Also I'd say the voting for the naming of the Release Status is over,
Pseudo-release won it leading the pack by 3 votes (not my favorite choice
but the people have spoken).  Who can enter that into the options for
Release Status?


Add a ticket to Trac, assign it to Rob and maybe put the priority up a  
bit. I put him on CC for this post, so he should notice :-)


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] New Tools for the Council (Was: RFV: Translation Transliteration Relationship Type)

[Don Redman]

I have tagged all style council related pages in the wiki with  
CategoryStyleCouncil. While doing so, I have found two pages, that I  
believed are not used anymore. These are


 * RecentStyleChanges and
 * the category on Trac 
   as mentioned on StyleIssue.

I have marked these pages as outdated and Shepard has objected. Now I am  
asking: Are these pages or tools used? If so by whom and for what purpose.


My impression was that they were not used as a reference on this mailing  
list. i.e. We do not seem to be using Trac to track which issues are  
important -- but then maybe individual persons are?
We do not seem to use RecentStyleChanges as a means of communicating with  
the wider community. The discussion here was always about using the blog.  
What should we do?


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

[mb-style] New Tools for the Council (Was: RFV: Translation Transliteration Relationship Type)

[Don Redman]

On Thu, 26 Oct 2006 23:53:48 +0200, Kerensky97 wrote:



Sorry I was a bit short on that last post, I'm frusterated for all the
exact reasons you keep mentioning.  We need to make the whole RFC/RFV 
process more accessable to everybody so that anybody who spends morethan  
a 30 second click though on the site can find, read, and commenton any  
proposed change we make.  After this recent issue in Augustabout better  
communication we have all the tools we need to do it nowwe just need to  
figure how best to put them to use without having toduplicate out  
discussion in 4 different places.  I emailed Don Redmanabout as much in  
response to another post he made on the mailing listsabout the same  
thing.


Yes, yes, and yes!

How can we make the process more transparent to the community? How can we  
make the process less tiresome for the people who want to get something  
done? Most importantly: How can we achieve this without inventing the  
wheel again? What I am interested in are (a) small tweaks to the current  
process, and (b) using other _existing_ tools to make it better.


My raw thougts on this:

The current process goes more or less like this: Style issues evolve from  
a problem during editing to a question or discussion somewhere (edit  
notes, mb-users, forum), to the notion that this is a _general_ problem.  
Around that time it becomes a topic for the style council. Then some  
people start to work on it, and propose solutions. That's the RFC phase.  
They refine it until it becomes so clear-cut, that it could be released to  
the public (which does not mean 100% perfect), and then they issue a RFV.  
When this has passed, the change needs to be announced to the public.


#1 This "moving along" is not supported very well. We could use forums to  
move an issue from one state to the other. Should this be different  
forums? How many of them? General, RFC, RFV? More, less? Or should we use  
the blog for RFVs?


#2 The wiki is good to develop a solution, while discussing it on the  
list/forum. We are not using this as much as we could. With WikiDocs the  
currently official version of a guideline could be 'frozen' and presented  
on the website, while it is being debated and changed in the wiki.


#3 The RFC process is tiresome. I would love it if the people who are  
working on the issue would have more of a "developer status". Something  
more like "I am developing a new guideline. I will pick up criticism and  
enhancements as I seem fit, and then present the final result to the  
community" and less like "I have to defend my proposal against a zillion  
of tangential remarks". However, I have no idea how to achieve this.
If we need it, I could probably convince Rob to free a virtual test server  
just for the StyleCouncil. This way people could experiment with changes  
without fearing that they get lost.


#4 Both the information that there is a specific RFC and the RFVs need to  
be more public. Our experience has shown that an issue tracker is not the  
appropriate tool for this. A blog could be. Should we set up a new blog or  
create a new category in the brainzblog (and transclude it to a newspage  
of its own) and give every acitve participant of this list an account?
Then an RFV would be a blogpost that a change as spelled out on _this_  
wiki page and _those_ releases on the test server will be made. An RFC  
could also be announced there.


#5 I do not have enough time to play a very active role in the council  
anymore. On the other hand I realised, that the style secretary's job is  
not something very active anymore, either. IIUC there is not a single  
thing left, that only I could do, and that is a good thing. Now I need to  
enable other people to actually _do_ these things. (blog accounts, admin  
rights on forums, WikiDocsModerator status, ...)


What else? Any other ideas or comments on this one?

  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] Re: RFV: Translation Transliteration Relationship Type

[Don Redman]

On Thu, 26 Oct 2006 05:33:24 +0200, Alexander Dupuy wrote:

Okay, Rob fixed the bug with the test server, and I created a  
{transtype} attribute for the new transl-tracklisting on the test  
server.  Tried it out with the attribute optional, then made it  
required.  Created some ARs for mini-moni.  
(http://test.musicbrainz.org/show/artist/?artistid=174327) albums, and  
also Twelve Girls Band  
(http://test.musicbrainz.org/show/artist/?artistid=175461) Beautiful  
Energy.


All in all, I'm still not convinced that having an attribute to  
explicitly mark translation vs. transliteration is really worth the  
extra hoop-jumping, and although I tried to fit the parameter into the  
link phrase, it's still rather awkward, especially for the "original"  
(forward) phrase.  (Changing {transtype} to {transl-ated} might help a  
bit when selecting the new AR type in the UI).


I have made a terrible hack to give a better display. The downside is that  
the names of the values are now tructed to "tranliterat" and "translat".  
As I said. Terrible :-)


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

[mb-style] Style Council Procedures (Was: ClassicalReleaseArtistStyle...)

[Don Redman]

First, I would really appreciate if you (both of you) could keep this tone  
out of this mailinglist. Thank you.



Second, mb-style is *the* place for decisions about changes to the style  
guidelines. This is adevertised on the wiki and repeatedly on mb-users.


If anyone fears to be left out in decisions, then subscibe to mb-style and  
delete every message that does not start with "[mb-style] RFV:". That is  
*very* low volume and every RFV will pass through you.
I will not buy any argument that decisions which have followed the  
official procedures here were passed in the dark of the night.



Third: Yes the process by which offical changes are propagated into the  
community must be enhanced. I think blogging about offical changes would  
be a good thing.


PLEASE anybody who wants to have access to the blog, send me a private  
mail.


I would not want RFVs to be decided on the blog. The people I want to take  
part in the RFV process are experienced users, novices who put a lot of  
energy into this one topic, and also respected editors who just 'heard'  
about this change. I am ont interested in every single MB user who is  
either not willing to work their way through the past discussions or not  
accustomed with the practice of MB.



Fourth: If you want to move the style council over to the forums, I am  
willing to do that. I can imagine a forum for any discussion, a forum for  
RFCs (the former discussions can be moved over to the latter), and a froum  
for RFVs and vetoes *only*.


However, I am not accustomed to forums, and I would need one or two people  
who have experience with moderating forums, and who are willing to start  
to take over part of the Style Secretary job. If you are interested send  
me a mail.



Lastly: Whatever changes we discuss. A running RFC or RFV will be decided  
by the rules which were in place the moment it was issued. Changes to the  
process will only affect later RFCs/RFVs.


  DonRedman hath spoken :-)

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] ClassicalReleaseArtistStyle - seems to have passed!

[Don Redman]

On Sat, 21 Oct 2006 02:00:13 +0200, Ryan McCabe wrote:


I think this flew under the radar of a lot of people. Given the comments
in the edit notes, and given the comments on IRC regarding the
moderation, maybe there isn't a consensus after all, and it should be
withdrawn for the time being, or at the very least, made to withstand
another RFV.


Erm, has ClassicalReleaseArtistStyle not been announced to mb-users? Dave,  
that would be your job, since you have been "championing" this change.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] ClassicalReleaseArtistStyle - seems to have passed!

[Don Redman]

On Thu, 19 Oct 2006 19:10:29 +0200, Frederic Da Vitoria wrote:


CSGDiscussion being probably one of the biggest pages in the wiki, and
discussions about classical being so long to resolve, I'd like to
reorder "Covers" section in it (it helps me stay optimistic ;-) )

So examples 1, 2, 3, 8 and 9 are to be put under their performers, 5,
and 7 under their composers, 6 would stay under VA, 4 remains
borderline. If nobody objects, I will move this section under
"Approved...". Furthermore, I plan to split CSGDiscussion in two,
creating a CSGDiscussionArchive to store what is currently under
"Approved..."


Or rather just split the page into many new pages which each state what  
they are *about* like for the exiting offical style guidelines. e.g.  
ClassicalTrackTitleStyle,  ClassicalExtraInformationStyle,  
ClassicalReleaseTitleStyle, ...

Then mark some as "approved" on the page.

This way you follow the structure that has proven its value over the years.

  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] ClassicalReleaseArtistStyle - seems to have passed!

[Don Redman]

On Thu, 19 Oct 2006 04:29:06 +0200, Dave Smey wrote:


Well, it looks like ClassicalReleaseArtistStyle has passed its RFV.  I
edited out the part in the draft where it said that it was only
provisional, and I edited in references to the new exceptions into the
ClassicalStyleGuide.

If for some reason this is not correct, the CSG edits can always be
reverted, and of course the draft and the CSG edits are still open to
tweaking.

One bit of unfinished business is editing all of the releases we cited
as examples so that they are 100% consistent with the new guidelines.  I
actually linked to some releases on the test server, lest I be
accused of making edits that were not official policy.  I'll edit them
for real and relink them soon.

Thanks to everyone for all your input - I'm glad we got something done!


Thank you for pushing this through. I have started to intertwingle the  
page and marked it as official (you could have done this yourself after  
the RFV has passed).


Can anyone with blogging rights please post a short note and/or send a  
mail to mb-users?


And is there anyone who would like to blog about Style related stuff, but  
does not have an account on the BrainzBlog? If so, please send me mail!


Thanks

  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] Request for Clarification: positioning of disc numbers

[Don Redman]

On Wed, 18 Oct 2006 13:10:24 +0200, David Gibson wrote:


As far as I can tell, the current style guideline information doesn't
have any examples covering the intersection of DiscNumberStyle and
ClassicalStyleGuide.  Which order should the information mandated by
each go, that is should it be:

Big Works (Timbuktu Philharmomic feat. conductor Fred Nertz) (disc 1)
or
Big Works (disc 1) (Timbuktu Philharmomic feat. conductor Fred Nertz)


I know for sure that there is a guideline on which we have already  
discussed this problem. The result was that this stuff should be ordered  
by generality. The information that applies to most elements comes first.  
Therefore


if the Timbuktu Philharmomics appear on all discs, it is
Big Works (Timbuktu Philharmomic feat. conductor Fred Nertz) (disc 1)

whereas if they appear on disc 1 only (and another orchestra on disc 2),  
then it is

Big Works (disc 1) (Timbuktu Philharmomic feat. conductor Fred Nertz)

Unfortunately I cannot find this on the wiki anymore. I have searched all  
guidelines that could be relevant, but have not found it. I would expect  
it in ExtraTitleInformationStyle.


Does anyone of the elders remember the page and discussion I am talking  
about?


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] Re: RFV: Promo Only Series Style

[Don Redman]

On Tue, 17 Oct 2006 22:02:15 +0200, Jason Bouwmeester wrote:


Don, do you think it's ok if I rename this page to
"PromoOnlySeriesStyle", or leave it as is?

And assuming it passes this RFV, shall we make an "Official Series
Style Guideline" category and put this and the OC Remix Style in it?

And assuming all the above is yes, shall I use the wording "This is an
Official Series Style Guideline" on it :)

I think that's all.  Maybe. I'm even getting halfway useful with the
wiki and can probably do most of that myself, as long as you promise
to pick up the pieces if I go wrong.


I'm not Don but I think that Series Style should be a separate RFC/RFV
and once it is implemented then renaming the PromoOnly and OCRemix
pages accordingly and setting up the Official Series Style Guideline
at that time. Just my thoughts on what I've seen in the other
discussion :)


I'm Don and I disagree :-D

No seriously, just renaming a bunch of wiki pages without changing their  
content does not need a RFC/RFV process IMO.


My idea was to create a "grouping page" like SeriesStyleGuideline and to  
link to pages like OCRemixSeriesStyle and PromoOnlySeriesStyle for the  
details.


I had even thought of dropping the "Style", thus naming them OCRemixSeries  
and PromoOnlySeries. I am not sure of this, however.


Just keep in mind that if you rename a page, you have to fix all the links  
to it.


Anyway, it's a Wiki. Edit mercilessly. If soneone disagrees they will  
revert your change and *then* you need to dicuss/vote/veto/whatever. :-)


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFC: Proposal for "Promo Only Style"

[Don Redman]

On Mon, 16 Oct 2006 21:47:31 +0200, Jason Bouwmeester wrote:


Meanwhile, do you think I should take this promo only thing to an RFV?

I'm still a bit confused about the exact procedure (or if this even
needs to go through the whole formal process, if we're gonna have
"style guidelines lite" for series styles)


Confused as well but from what I gather this is the procedure... it's
been discussed for some time now, haven't seen anything negative about
it - as for RFV, how many votes does it need?


None at all.

Just ask for a veto. If none comes within the next 48 hours the thing is  
official. If the guideline was heavily debated, then you should wait a  
while after the discussion has died down before issuing a RFV (a day or  
two), but this is not the case here.


Currently anybody can veto, but only informed people should. As long as  
there are no problems with this, I will not set up stricter rules.



I really have to apologise for not documenting this process enough. But I  
have now a job at the uni and much less time at hand than when I was a  
student. I am hapy to keep up with mb-style and have basically stopped  
reading mb-users already.


There are two things to do about this:

#1 If you want to earn my eternal gratitude, then document the process in  
the wiki from your point of view (mine is known to be a bit akward ;-) ).  
Start off wiht StyleCouncil and edit all outdated pages mercilessly.


#2 I should slowly retreat from my job. I will think of this a bit more,  
try to write down what I used to do and then ask for people who would take  
over the StyleSecretary job. I think that moving over to forums could be  
part of that change. I will post about this in week or two, it is on the  
top of my MBTODO list.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFC: Proposal for "Promo Only Style"

[Don Redman]

On Sat, 14 Oct 2006 07:33:06 +0200, Michelle . wrote:

This looks good. The only "problem" I have with the proposal is that I  
think it shouldn't be a StyleGuideline as such. It seems to me that  
style guidelines apply more generally, while this only applies to a  
small subset of releases.


Perhaps PromoOnlyStyle and HelloProjectStyle should be in a new  
category, like "Style Guidelines for Specific Series". A lot of other  
series, which have a style reached through informal consensus in edit  
notes, could also fit into this.


One that comes to mind is the CMJ series  
(http://musicbrainz.org/search/textsearch.html?query=CMJ&type=release&an=1&as=1&limit=100&handlearguments=1).  
The New Music Monthly section is quite clean, but the Certain Damage  
section is messy.


So, anyone else up for a new category? :)


"Series" is a name that comes to my mind.

That would mean to change OCRREmixStyle to ORCRemixSeries and to create a  
SpecialSeriesStyle page that lists all series on which a decision has been  
made here.


OK, it's a bit of work, but it makes sense. It would separate specific  
guidelines from geneal ones, it would increase the status of the general  
guidelines, and also reflect that the process to come to a conclusion for  
series is much looser that for guidelines.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFC: Transl(iteration-ation) AR (Resurrection).

[Don Redman]

On Mon, 16 Oct 2006 12:26:41 +0200, Chris Bransden wrote:
(I corrected Status)


A: Original Release (eg, http://www.discogs.com/release/656463)
ReleaseStatus: Official

B: Released in another language (eg,  
http://www.discogs.com/release/683846)

ReleaseStatus: Official

AR between the A and B: A is the original language track listing of  
release B


C: Fan-translated to german
ReleaseStatus: Alternate

AR between A and C: A is the original language track listing of release B



what i'm saying is that even if Boris put up a tracklisting
translation to german on their official website, it would still be an
'alternate' release as it doesn't physically exist. the JP and US
versions were pressed and sold.


Ok, after reading this I think we *really* need to settle for a name for  
this ReleaseStatus. there seems to be consensus about everything else. I  
see thre sensible names:


Either we want to be as specific as possible about the *reality* status  
and state that this is not a 'real' release, that can be bought, illegally  
traded, put in your CD player, or whatever. In this case we should name it  
"virtual release" or "pseudo-release".


Alternatively we define the thing by its *function*. In this case it  
should be called "alternate language/script titles", or just "alternate  
titles". I would not want to call it "alternate release", because this can  
mean something like alternative pressing or differently distributed  
version (which are real releases), but this has been proposed as well.


Since we have dicussed this to death, I call for a vote:


I hope that the result is clear enough to end the debate, if not it should  
at least reduce the options.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFC: Transl(iteration-ation) AR (Resurrection).

[Don Redman]

On Fri, 06 Oct 2006 19:59:17 +0200, Kerensky97 wrote:



BTW, I still like using "Alternate" as the release status.  Then it  
might be
possible to add a setting where people can choose to show alternate  
discs or

not.  Plus it's ambiguous enough you can stick a few other "virtual
releases" in there or if we think of something in the future that isn't
official or bootleg and just needs to be shuffled to the back till NGS.


IIUC this one is really not fleshed out. There are some docs on the AR on  
ReleaseTransliterationAndTranslation. I suggest to rename that to  
Transl(iter)ationRelationshipType, to intertwingle it into the AR pages,  
and to document the finer details when the AR is in use.


But I believe there should be a wiki page with *some* hints about the new  
release status. For that you have to decide on a name. You have proposed  
"Alternate" and "Virtual". What about "Transl(iter)ation"?


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFV: Artist type: Project

[Don Redman]

On Wed, 11 Oct 2006 00:22:58 +0200, Robert Kaye wrote:

Given that there seem to be no real objections to this, I'd like to put  
out an official call for veto on this topic. Please speak up in the next  
48 hours if you have objections to this issue. Otherwise I will bring  
the code back for the next server release.


VETO for formal reasons

Please issue an RFV when the (kind of) RFC discussion has either died out  
or trailed off into tangents. Not when it is in mid course.



And on topic:

I strongly disagree with the second option. Where is the boundary to a  
group? Just because a band dissolved after their first albun they are a  
project? Note that according to Wikipedia "Argyle Park" is a band, just a  
very shortlived one.


The problem is that you want to replace a purely objective criterion  
(singluar/plural) with one that has *meaning*. But that meaning is  
different to different people. Isuggest to either leave the objective  
criterion alone, or replace it with a full set of meningful artist types,  
but not mix the two.


either: person, group. Period

or: band, project, person, character, collaboration, orchestra, composer,  
...


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] How to handle band/artist name changes

[Don Redman]

On Sat, 07 Oct 2006 15:49:23 +0200, Age Bosma wrote:


Hi,

Based on the responses I think we can draw the following conclusions:
1. Releases have to be filed under the artist name it was releases under.


Um, no?

http://musicbrainz.org/artist/6514cffa-fbe0-4965-ad88-e998ead8a82a.html

Most of the Fela Kuti releases were released under either "Fela Anikulapo  
Kuti" or "Fela Ransome Kuti". But this is not important *in the context  
of* his music/his discography. So MB has settled for "Fela Kuti".


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] How to handle band/artist name changes

[Don Redman]

On Wed, 04 Oct 2006 21:30:50 +0200, Kerensky97 wrote:


For now i
think we need to consider an AR that artist X changed name to artist Y (a
complete changeover, not performas as or anything like that).  And the
Picard tweak would be cool too (it'll cause issues with last.fm  
submissions

though :o ).


Which shows that changing the current habits (we cant really call that  
guidelines) would substantially change the semantics of the database. This  
means that anyone who wants to push for a change in this domain must be  
prepared to do quite alot of work (like test cases on test.mb.org, tagging  
against them, etc).


I personally suggest not to change anything, but to state that this is a  
complicated matter which has to be decided on a case by case basis. If you  
look at all the split/unified artists in MB you will find that the  
decision made for each of them makes perfectly sense *for that arstist*.


Heh, what about that simple suggestion: We could make a wiki page and  
collect all these artist there and the decisions that led to the state  
they are in. This would not be a guideline yet, but maybe a step towards  
one.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] Should we change Classical Rules?

[Don Redman]

On Wed, 04 Oct 2006 03:03:27 +0200, Dave Smey wrote:


Pointing out the fact that he
really doesn't seem to have much experience with Classical music was a
justified criticism, IMO.  (Perhaps he will learn from the experience and
not be so arrogant - though I admit that's pretty unlikely.)

I don't think I did the best job on my last post to him, but I don't
really regret it, either.  But next time, somebody else can talk to the
idiot.


I would really appreciate if you (and anybody else) would refrain from  
writing personally insulting mails. This is plainly against the  
CodeOfConduct that has been established for communication within the  
MusicBrainz community.


This is not intended as a critique to you in person. Indeed you have done  
some very good and constructive work on the wiki page.


I would just ask everybody to make an effort to keep the tone on this  
mailinglist friendly. If you feel annoyed by someone, then write an angry  
mail, go have a walk/smoke/cup of tea, and then don't send it. :-)


Thank you very much.

  DonRedman

PS: While I am at it: There is no explicit MB wiki etiquette. I guess good  
stlye is something along the lines of:

 - Edit mercilessly
 - Log in
 - Comment your changes (so that other people can retrace your steps)

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

[mb-style] RFC: ClassicalReleaseArtistStyle

[Don Redman]

On Tue, 03 Oct 2006 00:59:25 +0200, Alexander Dupuy wrote:

Without speaking to the correctness or accuracy of your arguments, I'd  
just point out that you're not likely to advance your cause very far  
with attacks like these,


or worded differently:

I am right of course,
stop arguing already will you,
it's you who is wrong.

(There seem to be many reasons to post this lately :-( )

To return to substantive discussion on the details and merits of the  
proposal, I would take Dave's wording:

(...)
and modify it to also include recitals that have only works by a single  
composer but avoid some of the ambiguity in Frederic's original  
proposals:


I have entered your wording to  
 (as rev 1) and  
then reformulated it a bit (rev 2).


I now ask for

 a) constructive cricisim and wiki-editing that helps to mke this as clear  
and precise as possible and generally to make this happen.


 b) *focussed* criticism from people who believe that MusicBrainz might  
become a worse place than it is if ths guideline would become official.


 c) Since this guideline would change the semantics of the database, it  
would help very much if both partise (who are for and against this change)  
would tentatively apply it to some releases on  
 (aka BetaEditing).


consider this a formal  (I seem to be the only one  
using this tag :-) )


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] Re: [mb-users] Featuring artist revisited...

[Don Redman]

On Mon, 25 Sep 2006 02:49:32 +0200, Edward Kaye wrote:

Hi, I admit it, I am the one that kicked off this arguments :) My BLS  
seems
to have caused more than a little controversy. I meant to raise this  
issue,

but it has been a hell of a week, with job interviews etc.

For my two cents, I am a firm supporter of the "What it says on the  
cover"

approach. I understand  what some people have been saying about the cover
being up to the whim of the graphic designer, but this is really the only
information there is about a track. the designer has to get this  
information
from the band/composer. There is only one better source for this data,  
and

that is to ask the composer themselves, which is not a very practical
approach.

I also understand that there are times when a studio album may say
cheesecake (feat. Bobby zakton) and a live album might say just say
Cheesecake. In my opinion the musicbrainz titles of these should be  
EXACTLY

as written, and if people are interested in who features on the track
without the feat. data, they can look at the AR. I also propose that if a
song says Bluebottle (with John Compton drum attack) we should write  
that,

not change it to Bluebottle (feat. John Compton)

In my opinion using (feat.) where the album cover does not include it is  
as ugly as appending (live 06-12-04) to tracks.


There is also the issue as whether or not the composer want to  
acknowledge
the fact that someone performed vocals on there track, if they want it  
out
there for everyone to see, to increase sales, they will put it on the  
cover,
if not they will just acknowledge it in the liner notes, which is where  
we get the data for the advanced relationships.


That is all from me for now, feel free to flame me with your scathing
opinions :D


Do you realise that your POV differs considerably from the official style  
guidelines? I am not sure what to think of it. The way you present it, I  
can only conclude that you should


 a) seriously challenge the existing guidelines. Quite a lot of them do  
not follow the "as it's on the cover" principle.

 b) just accept that your personal oppinion does not matter that much.

I hope you do not take this as an aggression towards you. But do you see  
my problem?


It has taken MB a long time to grow the guidelines into the state they are  
in now. They form a pretty balanced set. Switching to purely "as it's on  
the cover" guidelines would make *many* people very unhappy. Look at  
NadelnderBambus: you will find *both* worlds there, and for a reason!


All I want to say is that the FeaturingArtistStyle is guideline with a  
long and winded history. You can start to change it, but please do not do  
so by just setting up a conflicting editing practice. Do so using the  
paths established in the MB community. And be prepared that path a) means  
a *lot* of work.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] Re: [mb-users] Featuring artist revisited...

[Don Redman]

On Sun, 24 Sep 2006 23:17:40 +0200, Steve Wyles wrote:


On Sun, 24 Sep 2006, Don Redman wrote:

This issue needs to be raised on the style mailing list. We can discuss  
this to death here but it will not matter. The only instance in  
MusicBrainz that could come to a binding decision on this matter is the  
StyleCouncil.


So, please move this thread over to mb-style.

I will not reply to the content of your mail here.



I will bounce it across to mb-style. But, in my opinion, this should  
have been done by the parties proposing the change. As far as I can see  
there had been no previous wide area discussion on this matter.


Ah, right I understand that.

All I wanted is to lead this debate in a relatively informed circle. That  
does not mean that interested parties should not jump in, but while I find  
it hard to come to a conclusion on mb-style, I believe it to be impossible  
on mb-users.


So, for everybody's information:

IIRC this issue was last raised around the time of the SG5 disaster.  
SG5DisasterRelief has shown us that "feat" is not just a matter of how to  
write titles, it is about the semantics of the database, i.e. where to  
store what. Small changes to these semantics can have huge consequences as  
the disaster has shown.


IIRC the last consensus was mor or less like this:
We all hate FeaturingArtistStyle, and all want to get rid of it. However,  
in order to do so we need to replace the fuction "feat" fulfills with  
better semantics. We do not really know how these would look like, but we  
can tell that they would need the follwing features:

 * Store the information in ARs (this is already possible)
 * Display the ARs on a track level (Keschte did that in the last big  
server release)
 * Tag files based on the info from ARs (Picard is still lacking this  
ability)


Once all these are in place, it should be relatively easy to move all the  
information that "feat" carries over to ARs *without loosing functionality  
in any of the components, that MB consists of*. We might need some  
additional AR attributes (like "featuring" to distinguish those that  
should be shown from those that are only informative), or repurpose  
existing ones (maybe we can finally give "additional" a real purpose), or  
whatnot. All these details will need beta editing and huge discussions :-)


My point is: The technical requirements to change the semantics are not  
met yet -- at least according to the latest consensus I remember. Now  
Anybody who wants can challenge that, but please challenge _that_.


  DonRedman

PS: Steve, should this go to mb-users, too? If so, please bounce it over.

--
Words that are written in CamelCase refer to WikiPages:
Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation  
around! :-)


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

Re: [mb-style] Rejigging release attributes (was Re: RFC: BonusDisc ammendment...)

[Don Redman]

On Wed, 20 Sep 2006 22:07:28 +0200, Jan van Thiel wrote:


On 9/20/06, Lauri Watts <[EMAIL PROTECTED]> wrote:

Imagine the possibilities.  You could totally have a live spoken word
ep, performance poetry perhaps.  Or an audiobook compilation album
(say, excerpts from a series, or a collection of HG Wells short
stories for instance, that have been previously released separately).
 Or a remix compilation ep, collecting remixes that were released as
b-sides. Or a perfectly ordinary album.


See http://wiki.musicbrainz.org/ReleaseTypeRestructuringProposal and
http://wiki.musicbrainz.org/ReleaseTypeRestructuringDiscussion ;)


Yes, but what this needs is

 a) a dev willing to work on this.
 b) someone determined to put a considerable amount of work and  
persistence into this to collaborate with the dev. That person would be a  
kind of 'secretary' who shields the dev from noisy (maybe even aggressive)  
debates and keeps them cool and forwards the constructive bits to the dev.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RE: Jazz and World Music Style Guide?

[Don Redman]

I suggest you create a page along the lines of  
 and collect all these  
ideas.


And please discuss new feature suggestions on mb-users, first. If you get  
some agreement and a more concrete idea, and if you need a decision or  
statement by the style council, then post to mb-users.


  DonRedman

On Wed, 20 Sep 2006 15:59:26 +0200, P. HarryE. Coenen wrote:


Hi

Is anyone working on a Jazz or world Music style guide?
Below just a few samples of issues I encountered.


For Jazz I think in terms of:
A. Relating the recording session to tracks This would require a  
Session_ID,

session_DateTime and Session_Description and a Session_Source See for
eample: http://www.jazzdisco.org/miles/dis/
Session_source would include the more or less authorative source from  
which

the session information is derived.
If you look at http://www.crisscrossjazz.com/album/1089.html you see that
this could be the record label database or official public domain
discographies.

B. relating personnel to track
For example soemthing like
Miles Davis (tp) David Sanborn (as) David Paich, Steve Porcaro (key)  
Steve

Lukather (el-g) Michael Porcaro (el-b) Jeff Porcaro (d, per) Joe Porcaro
(per) For TOTO - Fahrenheit (Columbia FC 40273)

For ease of use this could be at release level inherited by the tracks  
with
the possibility of EXCEPT(n1,n2...) and ADDIOTIONAL to enable a server  
side

script to cascade it down to tracks properly.

The style issue here is defining the abbreviations of the instruments,
defining the delimiters in the text frame used,etc.
In short something that would enable bulk upload from session data by a  
user

(or record label like CrissCross) who already has the data available in a
proper format.

C. Relating to the Lable and label_Id
Just as an example, I own five official releases of a series of Miles  
Davis'

concerts in Europe and have copies of some other as bootlegs.
The names of the tracks are the same in most cases, though being long
medley-suites they are different. MB (both TRM and PUID) wanted to map  
them
all to the same Release. I would want to see them all as different  
releases

(which they are) with a likelyhood value attached to each release. The
likelyhood is important to avoid confusing the average user with only a  
few

Miles Davis records with several options, reducing it to the most likely
Columbia Legacy. But the Miles freaks still can catalog and tag their
obscure Jazz Door (semi-bootleg, though offical) and even bootlegs.
This may explain why several Jazz releases have multiple Disc_IDs (though
another cause may be the flawed tagging of re-releases with bonus tracks)

D. Different releases that are actually the same (Disc_ID) but with
different packaging.
Example1:
Affinty is a release by Toots Thielemans and Bill Evans.
In real life this could be packaged as one of three A. Toots Thielemans
(featuring Bill Evans) as on MB B. Bill featuring Toots C. both (I  
haven't

seen this one yet) This is not really a user issue (initially), but
eventually three different users submit the same disc_ID with different
Titles and Main artist.
So the system has to build in build in some sort of ISIDENTICAL_EXCEPT
relation.
Example2:
Over time the issue is even worse: Miles Davis play trumpet on one track  
of

a certain Charlie Parker release in the 1940s; now it is re-released as
Miles Davis featuring Charlie Parker. Just clever marketing bollocks, no
problem with that, except that it is the same release (be it remastered),
with a different Disc_ID.

E. for the live performances the coding of dates, venues, sets etc.

F. for compaitbilty with other sources a reference to the native Table Of
Content of a CD.
You would probably end up with three levels of title/track name data 1.
native TOC 2. cover 3. corrected for spelling mistakes And the search  
engine

should enable querying all three
Example: I have about 30 versions of the Miles Davis Track [Woody 'N'  
You],

in a few cases misquoted even in the TOC as [Wouldn't You]


For World Music I would think about:
The country and region of the music the artist performs In case of  
vocals:
The language and regional dialect they sing in There are differences  
between

Celtic-Scots, Celtic-Irish, Celtic-Brittany(France) Celtic-Welsh and
Celtic-Welsh of the Welsh speaking peoplein Patagonia (Agentina)

Related to internationalisation I would also want a proper transcription  
of

the name in Latin characters (from my Western Europe perspective).
I CANNOT do anything with names in Russian, Arabic, Chinese, Japanese,  
etc.

characters. Just like I read Bejing, Moscow, Seoul, etc. in the paper
instead of the name in the local script, I want at least international
English characters.

The gold standard here is probably the way the offical gouvernment of the
country transcribes the name Latin characters though this may be a bit
controversial for artists from communities who feel themselves  
discrimin

Re: RFC: BonusDisc ammendment (was: Re: [mb-style] x (disc 1) & x(disc 2), vs x & x (bonus disc) / version info for special releases)

[Don Redman]

On Wed, 20 Sep 2006 20:02:44 +0200, Lauri Watts wrote:


On 9/20/06, Don Redman <[EMAIL PROTECTED]> wrote:

I am right of course,
stop arguing already will you,
it's you who is wrong.


There's my haiku!


Well, IMVHO it applies to you as well. Neither of you have really been  
trying to understand the other's POV.


One thing I thought was established after the "Great Dispute" was that, if  
you feel offended, then


 * Stop! Breathe, slow down.
 * Take a walk, leave the Computer, have a cup of tea.
  * Think about what happened last time you were involved in a dispute.
  * Think about what the other one might try to tell you all the time.
 * Come back. Now you might want to:
  * Raise the issue that you feel offended/aggressed.
  * Try to mirror the other's point of view and ask them to do the same.
 * Read your mail over carefully before posting.
   Think about how the other one might read it.

I *really* believe that the MB community has to grow up WRT their  
communicative culture.




OK, I have been in the garden and had a glass of whine. Now back to the  
topic, trying to mirror what people have been arguing about:


To me it looks like there is a difference in what people understand under  
"album". In the past, MusicBrainz has had a very formal definition of an  
album. It is my impression that Chris and Aaron are bringing in a  
definition which is much more meaningful. Restructuring of release  
attributes has been in the making since quite some time but nothing has  
come out of it, yet. There is an issue and it is overdue. So it does not  
really help if Lauri or me say: Well that's how albums are defined, period.


I also believe that a very simple reason for the past practice (assigning  
the same type to the bonus disc) was that then it shows up just next to  
the main album. With the ammendement this relationship would get lost. I  
do not have the impression that Chris or Aaron have opened up to concerns  
of this kind. I am very uneasy with redefining what an album is, and my  
impression is that this is a consequence of your arguments.


Anyone replying within less than five minutes has left out the walk! :-)

  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: RFC: BonusDisc ammendment (was: Re: [mb-style] x (disc 1) & x(disc 2), vs x & x (bonus disc) / version info for special releases)

[Don Redman]

On Wed, 20 Sep 2006 12:37:58 +0200, Matt Howe wrote:


On Wednesday 20 September 2006 3:37 pm, Lauri Watts wrote:

> off-topic.  But I just didn't think that "almost all bonus discs are
> Albums" was a fair statement.  In fact, I would (and am) argue that

I never said that almost all bonus discs are albums.  All I wanted to
say was "bonus discs are never albums" is not a fair statement either.
 Nobody said they aren't (more) often live or compilations.


This is how stupid arguments occur on this mailing list. Chris'  
ammendment

never said "bonus discs are never albums", see for yourself:
http://wiki.musicbrainz.org/BonusDisc?action=diff&rev2=6&rev1=5

"Also note that the ReleaseAttribute for a Bonus Disc will normally not
be 'album', unlike the primary release."

I personally have seen dozens of bonus disc's and there is only 1 that I  
would

consider even close to being an album:
http://musicbrainz.org/release/e299757e-d320-471c-88f6-b8b946a13e04.html  
All

tracks are previously unreleased.

That said, I don't believe that it is impossible for a bonus disc to be  
an

album and I haven't heard anyone else here say that. I don't know why you
dislike Chris and I couldn't care less, the point is that your personal
like/dislike of people should have no bearing on how you judge their
suggestions/proposals.


I am right of course,
stop arguing already will you,
it's you who is wrong.

  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: RFC: BonusDisc ammendment (was: Re: [mb-style] x (disc 1) & x (disc 2), vs x & x (bonus disc) / version info for special releases)

[Don Redman]

On Tue, 19 Sep 2006 21:09:08 +0200, Chris Bransden wrote:


On 19/09/06, Don Redman <[EMAIL PROTECTED]> wrote:

On Mon, 18 Sep 2006 10:56:06 +0200, Chris Bransden wrote:

>> so, i tried to create some kind of rule for bonus discs -
>> http://wiki.musicbrainz.org/BonusDisc (the ammendment section)
>>
>> thoughts?
>
> i still think this is a worthy ammendment, and noticed another case
> for it today. any thoughts?

Why should the ReleaseAttribute for a Bonus Disc normally not be  
'album'?


because they are not normally albums :) (exceptions? i can't think of  
any)



And what should it be then?


depends what the bonus disc's contents are :) often they are
compilations of b-sides (COMPILATION), live cuts (LIVE), combinations
of them (OTHER, if neither has the majority), or just random tracks
that didn't make it onto the album and weren't otherwise released
(OTHER, unless the band decide to call it a bonus 'EP' or whatever)


Random tracks that were not otherwise released *are* an album by  
MusicBrainz definition.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: RFC: BonusDisc ammendment (was: Re: [mb-style] x (disc 1) & x (disc 2), vs x & x (bonus disc) / version info for special releases)

[Don Redman]

On Mon, 18 Sep 2006 10:56:06 +0200, Chris Bransden wrote:


so, i tried to create some kind of rule for bonus discs -
http://wiki.musicbrainz.org/BonusDisc (the ammendment section)

thoughts?


i still think this is a worthy ammendment, and noticed another case
for it today. any thoughts?


Why should the ReleaseAttribute for a Bonus Disc normally not be 'album'?

And what should it be then?

  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFV: Playlists do not belong in MusicBrainz

[Don Redman]

OK, the follwing RFV has passed:

Bootleg torrents that are compilations based on playlists of charts  
authorities (like Billboard's) should not be sotered in MusicBrainz as  
releases. These playlists are copyrighted by their issuers.


I have written a blogpost[1] and entered a delte edit for the initial  
release in question [2]. Please vote and edit accordingly.


Is there a traditional subject line for notes about such changes on  
mb-users?


  DonRedman


[1] 
[2] 
--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFV: Playlists do not belong in MusicBrainz

[Don Redman]

On Sat, 05 Aug 2006 15:21:35 +0200, Rod Begbie wrote:


Any opinion on how this would affect the John Peel Festive 50[1]
"releases" already in MB[2]?

As far as I know, the Beeb don't give two hoots about the lists being
distributed, so I'm not sure that copyright is a concern, but these
"releases" are just the playlists of the fifty tracks.


Yes, those are just playlists and therefore, if this RFV should pass, it  
would mean that those, too, should be removed.


  DonRedman



[1] http://www.bbc.co.uk/radio1/johnpeel/festive50s/
[2]  



--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

[mb-style] General feelings about the tone of mails these days (Was: AutoEditor Elections)

[Don Redman]

Initially, I wrote this as a personal reply to Lauri. When I read it over,  
I thought, what the hell. This is of interest to everybody. I changed the  
subject, too.


On Fri, 04 Aug 2006 21:53:09 +0200, Lauri Watts wrote:


To me it is just about dialogue versus judging, about respect versus
evaluation. And I much prefer the former.


Whyever would you think I don't.


I didn't. I am sorry if it sounded like I wanted to accuse you of  
preferring judging over dialogue. That was not my intention.


I feel pretty uncomfortable on the mailing lists these days. It feels to  
me as if since the flames about the latest server release the discussion  
moves into personal accusations too easily. And I am not sure how much it  
is me writing something that already contains an aggressive tone, or the  
other (in this case you) who just listens on that personal level and gets  
a message I did not intend to send.
It is also my impression that 'camps' form very easily, so that some  
people always support a POV and others always oppose it.


I *hate* this, and the worst is that I feel completely helpless about it.  
I know what to do about these kind of conflicts in a face-to-face group  
setting. But it just does not seem to work via mail.


I know that Keschte had his share in causing the latest flame, but this  
rough tone has already come up on mb-style a month or so before that  
flame. In any way it is too easy to put all the blame on him, and unfair  
too. It always takes two to tango.


Robert said that he had tried to sort things out in private and this was a  
mistake. So, maybe we too should talk about this more in the open. This is  
*not* another "Stefan is the evil guy who cannot take critique"-mail. This  
is about everybody else, including me.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

[mb-style] RFV: Playlists do not belong in MusicBrainz

[Don Redman]

OK, the discussion about Billboard's has faded out.

Re-reading all the mails, I come to the conclusion, that what would  
legitimate Billboard's Top whatever bootleg torrents is the autority of  
Billboard's who have composed a *Playlist*. The torrent is just a way to  
distribute the songs which are on the playlist.


(a) The value of this pseudo release in MB would mainly consist in the  
information that the *playlist* holds.

(b) the playlist is copyrighted.

I therefore have to conclude, that whatever this is, it should not be a  
MusicBrainz release. If you want to make this available to the public,  
then you can:


 - Compile the list with links to the appropriate MBIDs on your own server  
(which means that you will have to deal with takedown requests).
 - Add PUIDs to the respecitve tracks on the origial releases in MB so  
that people can easily tag their files agains the originals. They can  
still keep the filenames and folderstructure unchanged if they want.


I therefore issue the following
 (don't quote this line):

Bootleg torrents that are compilations based on playlists of charts  
authorities (like Billboard's) should not be sotered in MusicBrainz as  
releases. These playlists are copyrighted by their issuers.




if noone veotes withing 48 hours, I will enter a delete edit for the  
respective release [1] and add the bit above to an appropriate wiki page.
BTW what is the status of LiveBootlegStyle vs. UntitledBootlegStyle? I  
could merge all the official stuff into one BootlegStyle.


  DonRedman

[1]  



--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFC: Torrents as Releases (Was: Billboard's "topwhatever")

[Don Redman]

On Tue, 01 Aug 2006 15:55:21 +0200, Aaron Cooper wrote:


The topic is "Torrents as Releases", but I don't know if that was the
direction I would have taken this.  Sure, there is a torrent for the
top 100 Billboard songs for 195x, but isn't that just a side effect of
the actual Billboard list being so popular?  What is important is that
the Billboard lists would exist without torrents and there is a
possibility that someone would want to tag against this information.
I think throwing in "torrents" unfairly risks the chance of the
Billboard lists being approved.

I do think that discussing torrents is a good idea, and will likely
become a hot topic, but perhaps we should discuss the Billboard lists
separately?


Oh, I think I might have misunderstood what we are debating.

Does this mean that in fact Billboard's Top whatever is nothing but a  
*playlist*.
Because this playist is so popular, people created torrents with the music  
on the playlist.


IIUC this playlist is double-pirated.
 a) the music is illegally distributed.
 b) the playlist is copyrighted.

Well, b might be a stop-gap argument. I think Robert should ask his lawyer  
when he'S back from OSCON. I guess Billboard could send MusicBrainz a DMCA  
cease and desist request anytime, and MB would have to take all the  
copyrighted Billboard 'releases' down. However, IANAL.


a) was never of any concern to MB and should not be now, but what concerns  
me, is that it seems these 'things' are primarily *plalists* and only  
secondarly *releases* which compile all the songs of the playlist. If this  
is the case, then maybe MB is the wrong place to store this information.  
This is more something for a global playlist project.


Or am I again misunderstanding something?

  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFC: Torrents as Releases (Was: Billboard's "top whatever")

[Don Redman]

On Tue, 01 Aug 2006 10:29:04 +0200, Chris Bransden wrote:


define "popular" :) to quote myself: "how do you really measure
that on the internet anyway? torrents are the only method of
distribution [here], and aren't centralised anyway?" i just don't know
how i would begin to decide which torrents were worthy and which were
not.


That is why my proposal says: This will be decided on a case by case  
basis. I completely agree that we are not able to make a clear cut  
distinction between "popular" and "unpopular" now. However, I disagree  
that this is a good reason to ignore this phenomenon alltogether.  
Therefore I proposed the most pragmatic approach.


In practice anything of which
 * some people say: "yea, I know this one, I think it is popular"
 * noone says "sorry but this is really a minority thingie"
 * someone is willing to take care of the data in MB
can be considered "popular" in a first go.

Maybe some figures will help (how old is the torrent? Are there statistics  
on the user counts?). If we make some decisions they can serve as landmark  
cases for the rest and will eventually form a guideline.


Actually these criteria *are* derived from the concrete case of  
Billboard's Top n, which meets all of them.



and also, why torrents? why not archives? playlists? lists found on
sites? it goes on :/


Because my RFC is limited to torrents. Period. I try to stay focussed on  
the issue at hand. You are welcome to raise the issue for archives when  
someone wants to enter one.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

[mb-style] RFC: Torrents as Releases (Was: Billboard's "top whatever")

[Don Redman]

Hmm, there has not been a lot of response to my request. Strange thing,  
since a lot of people voted.


in orter to push the process I'll make a concrete proposal as a


MusicBrainz will start to keep track of series of *popular* torrents and  
have them in the database as compilation, bootleg. We know that they need  
a release attribute of their own, but there is none for now.


Since we need to figure out which gidelines we need for such torrents, we  
will allow such series in *one by one*. The most important thing which we  
need to figure out is how to determine whether a torrent is 'popular'  
enough.


That means, if you are an editor and want to start to enter a series into  
MB, send a mail to the StyleMailingList and ask if it is considered  
popular enough. This should be a realively quick process.


Currently accepted torrents are:

 * Billboard's Top... (i.e. torrents that are compilations of a year's  
Billboards Top something listing)




All of this will be documented in TorrentStyle. Please raise criticism  
now. If this topic stays as silent as it has till now, I will issue an RFV  
in a couple of days.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] Billboard's "top whatever"

[Don Redman]

On Wed, 26 Jul 2006 21:37:40 +0200, Jason Bouwmeester wrote:


Finally I have kept my personal POV out of this mail. Maybe I'll send a
separate mail later.

   DonRedman


How come? Pardon my ignorance, I am fairly new to the MB Community
(even though I've been using MB for some time now)... I'm assuming you
are one of or the head honcho around these parts? Even so, everyone is
entitled to a POV and I'm interested in hearing what everyone and
anyone has to say about this... or are you concerned your POV will
sway some other people?


I am the appointed Scretary of the StyleCouncil[*]. As such my job is to  
moderate the decision process. This is easier if I keep my personal POV  
out of the debate. Otherwise it is easy to inadvertedly direct the process  
into a direction of my liking.


I believe that if I am conscious about my POV, I usually manage to keep  
these things separate quite well. It gets problematic if ideas about the  
matter, feelings about individuals and thoughts about the process get  
mangled.


Since I have not been active in the last weeks and since the style of  
debate was, um, rather shitty these days. I prefer to keep a strict  
division here.


  DonRedman

--
[*] Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] Billboard's "top whatever"

[Don Redman]

On Wed, 26 Jul 2006 01:43:05 +0200, Bogdan Butnaru wrote:


I start this thread because of (1) and to a related thread on the
user's list. I started it here because I think this is a guideline
issue and we need to discuss as such. I encountered  similar
situations before.

(1) http://musicbrainz.org/show/edit/?editid=5258089


Thanks for raising this issue. This is a pretty general issue for  
MusicBrainz. There is a type of bootlegs out there that we have  
traditionally not let into the database: collections of files that are  
distributed (usually illegally) using torrents.


It seems that there are now some such collections which are so popular and  
have gained such a status in subculture of music listeners, that some  
people expect these to be entered into MusicBrainz.


I think the questions that we need to adress are

#1 What is this?
Is this a new cultural practice? How important is it? Is it growing and  
gaining more importance? How small is the group of people using this  
practice?


#2 How should MusicBrainz deal with it?
Should we embrace it and find a way to represent it in the database,  
because we consider it a valid practice of listening to music? Should we  
keep it out of the database, because we consider it something which is  
outside the scope of MB? Or is there a middle ground in which we let some  
few distinct cases in, for which there are contributors who care about  
them and see what happens?


#3 How would this affect the database?
Is there a risk of flooding the database with irrelevant stuff should we  
let all of this in? How could this be prevented?
Is there a risk of missing an important new movement of how music is  
distributed should we keep all of this out?


I would like to hear as many oppinions as possible. Have I missed some  
important points? Please try to stay on focus so that we can reach a  
decision and not let this trickle off into nothingness.


I will wait for your statements and maybe try to make a concrete proposal  
in a few days. I declare this to be the current Number one Style Issue on  
my radar and will monitor this closely. I will encourage and help anybody  
who wants to work towards a concrete sollution on this issue.


Finally I have kept my personal POV out of this mail. Maybe I'll send a  
separate mail later.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFC: New URL relation types: Has blog at , Has LiveJournal at

[Don Redman]

On Sun, 16 Jul 2006 20:01:44 +0200, Alexander Dupuy wrote:

As nobody has raised any objections, in the spirit of beta testing, I  
have made these changes (renamed myspace AR, added blog AR) on the  
test.musicbrainz.org server, so that people can experiment with them.   
Interestingly, the auto-recognition for MySpace pages works even after  
changing the link phrases, description, and even the AR name itself --  
I'm not sure how that works, or if it is dependent on cached information  
in the JavaScript code, or dependent on the position in the list.   
Perhaps Keschte or someone familiar with the code could comment on that.


Can you please post some links? I have no idea how I would find artists  
with that AR on test.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFC: New URL relation types: Has blog at , Has LiveJournal at

[Don Redman]

On Fri, 14 Jul 2006 17:22:12 +0200, Ilya Kasnacheev wrote:

Proposal: New URL relation types: Has blog at , Has LiveJournal at  



Why needed?: As of today, musicbrainz have the relation "Have the
MySpace page at".  MySpace is not only blog service in universe,
neither it does have monopoly on music people/bands pages. A lot of
musicians and bands have blogs/communities on other blog services or
individual sites. LiveJournal is worth because it almost implies
specific activity in livejournal environment, and because there are a
real lot of Russian musicians/bands there.

Coding needed?: Guess, NO.

Effect on the current system?: Guess, NO but more complete URL
relations for a lot of artists.

I brought this up in Users
http://lists.musicbrainz.org/pipermail/musicbrainz-users/2006-July/012640.html
and it seemed readily acceptable.

URL Relations Inclusion:
 have a LiveJournal at 
and
 have a weblog at 


I like it. Essentially it means to generalize the current MySpace  
relationship type. IIRC someone oon mb-users suggested to put the most  
important blogging sites as sub-types of the general blog type.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFC: New Artist Type: Project

[Don Redman]

On Fri, 14 Jul 2006 21:46:00 +0200, Steve Wyles wrote:

I've just checked and there are now 66 artists that have been set to  
project and it appears to break the lucene search.


http://musicbrainz.org/search/textsearch.html?query=limelight&type=artist&an=1&as=1&limit=25&handlearguments=1

limelight is one of the artists that has been set to project

http://musicbrainz.org/show/artist/?artistid=31378

I think until the full impact has been assessed, it should be reversed.


I have entede a ticket:

http://bugs.musicbrainz.org/ticket/1817

  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFC: New Artist Type: Project

[Don Redman]

On Thu, 13 Jul 2006 22:50:09 +0200, Steve Wyles wrote:


On Thu, 13 Jul 2006, Robert Kaye wrote:


I did not mean to circumvent the process here -- I do apologize.

Please advise if I should:

1. reset the four artists to unknown and remove the project type from  
the live server or

2. don't sweat it and call it a done deal or
3. Have the RFV now and if a veto appears, I will do #1.



Was the impact on the libraries, applications and datafeed customers  
assessed?


The impact of a sematical change was definetely not assesed. The  
boundaries between the new type and other types are not defined. I opt for  
1.


2. is out of the question. That's not how we have agreed to work here.

If you want you can issue an RFV and explain why the feature is mature  
enough to be on the main server. I _personally_ do not think it is and  
would probably veto.


  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFC: New Artist Type: Project

[Don Redman]

I do not like the drift this debate is taking.

Why are people spending twelve (12!) mails on debating the way someone  
presents an argument instead of debating the argument? ~:-(


This goes directly to Beth and Christov.

Bath: I have presented a similar argument (person and group are well  
defined and cover all cases, introducing a thing makes things complicated)  
and you have responded constructively. I was (temporarily) convinced and  
said: Let's see what testing this new type shows. Christov seems to have a  
problem whcih is similar to mine.
Instead of saying something like "Don had a similar argument, please check  
for his post and the discussion about it." You are going off on a  
Meta-Debate.


IMVHO this is as tangential as some of the previous debates, just on  
another level.
I cannot help but get the impression that you are defending your proposal  
with a discussion about how to present arguments instead of a discussion  
of the arguments.

Now, maybe this is not what you intended, but that is how this feels to me.


Christov: Beth and Shepard have done some work on test and the wiki. The  
way you presented your criticism indeed feels to me like wiping their work  
off the table with a simple statement of "I don't like this". Again, I do  
not believe this was your intention, but it came to me a bit like that. I  
can imagine that it felt even worse to Beth, who has started the whole  
thing, put efforts into it and wants to get things done.



Maybe some focus does help:

Beth: Please, do not fear that your proposal can be easily dismantled by  
some oldtimer coming in and saying "I do not like this". Christov has not  
issued a veto and indeed has no right to do that at this stage. At this  
stage he can do _nothing_ to stop you and Shepard from working out your  
proposal.
If the problem he has with it is substantial, then your proposal should  
have _a_ solution for it. It does not need to be one he likes. If the  
problem he has with it is not substantial, then this should be no problem  
for your proposal. But please debate this with arguments, not arguments  
about arguments.


Also, please be patient. Your proposal will need a guideline about when to  
use projects and when to use groups. This takes time.



Christov: It may very well be that your feeling has a substantial reason.  
Please, can you try not to debate this on an abstract level. Maybe you can  
find an artist on test, make them a project and show how this is  
problematic? At the point where the proposal is now, Beth has put some  
work into it. If you want to argue about it now, you have to put some work  
into it, too. If that means "I will take a week to read the mails, do some  
editing on test and then come up with a counter proposal" so be it. If you  
bring up concrete cases which challenge the documentation and make Shepard  
and Beth refine them, it would be even better.


Of course you can just shut up now and issue a veto later, but if this is  
not based on substantial arguments, it is not likely to make Robert stop  
this project (although I cannot tell, and found that it is harmful to have  
comments by the Evil Overlord before the protocol sais he should make a  
ruling). And it would not help anybody.



To everybody: Can everyone who has edited projects on test please add  
links to these artists to the wiki page? This should help to focus the  
debate on the concrete feature. As I said before this feature _may_ change  
the semantics of the database in an unforseen manner. The only way to find  
this out is to test it.



I am off to Hamburg now, so unfortunately I will be unable to read your  
replies. I apologise if someone feels personally offended by the tone of  
this mail. This is not my intention.
My intention is to get a debate back on a constructive level. This seems  
to be the current challenge of the Style Council and I feel a bit  
responsible for that.


You are all grown up people, and I think you can sort this out.

  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] Re: split artist release title

[Don Redman]

On Mon, 03 Jul 2006 20:07:41 +0200, Jan van Thiel wrote:


I've created http://wiki.musicbrainz.org/SplitReleaseTitleStyle and
like to have comments. Thanks!


I think that page should state very clearly that the artist should be  
Various Artists. This is kind of implied but not very clear.


Otherwise I like it.

  DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/
(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

Re: [mb-style] RFC: New Artist Type: Project

[Don Redman]

I just realized that you (Beth) are not alone on this project (just  
finished reading mb-users).


So, I want to bring Simon's excelent summary to everybody's attention:


That mail could serve as a good starting point for a wiki page.

And it would surely help to work on this issue in a team.

  DonRedman

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

Re: [mb-style] RFC: New Artist Type: Project

[Don Redman]

OK, I think I got your point: There are artists in the DB that cannot be  
clearly classified as either "person" or "group", it is time to give them  
a proper type of their own.


So, you got positive feedback on this. The only thing that remains is that  
it is difficult to forsee how big a semantic change this is. I would  
therefore suggest the following (this should remedy the problem of  
semantic changes _and_ help you complete the project _and_ keep  
discussions focussed):


Get a dev to make the few changes which are required for this new type on  
a test server (I have completely lost track of the test servers. Ask  
Robert for one).


Then you can start to use it (you will probably find some aspects that you  
have not thought about), create a wiki page about it and document it.
Once there is some rudimentary documentation you can present the new type  
on mb-users and ask for concrete feedback there and here on mb-style. This  
should help you to flesh out the docs, so that they are in an acceptable  
state (I said acceptable. Good should come much later).


That is about the time when you will want to request a veto.

While this looks like a lot of work, the advantage of this approach is  
that after the RFV period, making the feature reality is a matter of a  
snap (it will just go into the next minor server release).


Is this approach acceptable to you?
I do not want to raise excessive barriers to your project. We had that in  
the past of the Style Council and I do not want these times back. However,  
the discussions about fruitless tangents have shown that we have a lack of  
focus on concrete solutions. That is why I thought that it would be better  
to work on a concrete solution instead of requesting a veto for something  
wich is -- in its current state -- still a relatively abstact concept.


What do you think?

  DonRedman

On Sat, 01 Jul 2006 09:25:04 +0200, Beth wrote:


Artist: Autumn's Descent
Type: Person
Born: 1996
Project Owner: Ash
Project shifted to group: 2005
Project died: 2005?
I don't know.. this is a hairy case, but there are others.

The problem is, person has a "born on date" projects aren't born. Also,
people have differing opinions; is NIN (which was Trent Reznor's  
project) a

person or a group? They have members when touring, therefore they're a
group? I personally disagree, but I think most people would agree it's a
project.

Celldweller, which is a project, performance name, and a studio therefore
has productions listed to it as well as recorded by and when left  
unstated
(artist or group) someone came along and listed it as a group, same  
argument
rises and you can't lock something so it's neither, which if we don't  
have

anything but Person or Groups is the only way to keep it from being
confusing. When celldweller (the project) tours, there are stand in
musicians. It so happens those musicians may remain over the next touring
season, or they may not. The true fact is, they have no artistic
merit/license over the songs whatsoever. Once more, project works,
group/person does not. It looks rather funny that a whole "group"  
recorded

an album and then it makes recorded by confusing, as Steve a while back
pointed out. Or, a whole "group" produced a song. I know, tired of  
hearing

about this project I'm sure.

I personally don't see how your AR idea fixes this in the slightest. It  
will

still come down to "is it a group, or a person" argument and I don't feel
anyone that follows these (becoming) expansive projects is happy with the
disambiguation that is being forced on the database because one simple  
(if

indeed Robert's statement is true) artist type isn't added. As far as why
the previous mention of Joan's will change the database, I'm not  
familiar so

can't give light into that instance.

Nyght aka Beth

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Don
Redman
Sent: Friday, June 30, 2006 7:39 AM
To: MusicBrainz style discussion
Subject: Re: [mb-style] RFC: New Artist Type: Project

On Thu, 29 Jun 2006 01:07:39 +0200, joan WHITTAKER wrote:


I also write to support Beth.  A classic case in point is
http://musicbrainz.org/showalbum.html?albumid=504290

Roger Glover would in this context be the owner of the project and
participants would be Glenn Hughes, David Coverdale, Ronnie James Dio,
Jimmy Helms, John Gustafson, etc.

This is in the database at the moment as a simple Roger Glover album,
without even the other artists featuring.  To be able to mark this as a
project and to show that Roger Glover adapted the concept from a book by
Alan Aldridge would clearly show it as a stand alone project and not a
simple collaboration or even a VA.


What would change with this album?

IIUC the album would not be filed under "Roger Glover" anymore but un

Re: [mb-style] RFC: New Artist Type: Project

[Don Redman]

On Thu, 29 Jun 2006 01:07:39 +0200, joan WHITTAKER wrote:


I also write to support Beth.  A classic case in point is
http://musicbrainz.org/showalbum.html?albumid=504290

Roger Glover would in this context be the owner of the project and  
participants would be Glenn Hughes, David Coverdale, Ronnie James Dio,  
Jimmy Helms, John Gustafson, etc.


This is in the database at the moment as a simple Roger Glover album,  
without even the other artists featuring.  To be able to mark this as a  
project and to show that Roger Glover adapted the concept from a book by  
Alan Aldridge would clearly show it as a stand alone project and not a  
simple collaboration or even a VA.


What would change with this album?

IIUC the album would not be filed under "Roger Glover" anymore but under  
"Roger Glover and Guests". This new artist would be of type "project" and  
ARs would relate the members to the project.


1) Is this correct?

If this is correct, then Robert's statement is not true:

On Thu, 29 Jun 2006 23:26:51 +0200, Robert Kaye wrote:


Effect on the current system?: Unsure
 Same, very minimal impact.


In fact this is a relatively major change in the semantics of the  
database. Releases that were previously grouped under one artist would now  
be distributed between multiple artists.


I am *not* saying this is a bad idea. I just want to correct Robert's  
statement. And I want to prevent another desaster of not-understood  
semantic changes. I suppose that some beta-editing on a test server would  
be appropriate.



Now to the content of the proposal:
I am not sure that a new Artist type is needed at all to solve the issue.  
We currently distinguish between person and group, where everything that  
is more than a single person is a gourp.


Alternative Solution:
Would an AR " is a solo project by " not do the trick?  
This would cater for both the wumpscut case which has only one member and  
would therefore be considered a 'person'; and for the "Roger Glover and  
Guests" case, which is a kind of collaboration.


Or to put it very simply: "Collaborations" are distinguished form "Bands"  
by the connecting AR not by an artist attribute. Why should this be  
different for solo projects?
Actually such an AR would really make sense as a sub-type to the  
collaboration AR.


  DonRedman


--
Words that are written in CamelCase refer to WikiPages:
Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation  
around! :-)


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

Re: [mb-style] Meritocracy and the Style Council

[Don Redman]

Finally found the time to reply to your mail.

On Tue, 20 Jun 2006 01:39:26 +0200, Beth wrote:

Okay, there's little way I can reply to this without my normal ugly  
"[beth]" comments.


Yes, they really are ugly. Especially since my mail client does not  
support them.


[beth] I'll jump in here... one of the biggest frustrations I have is  
those
that aren't currently doing edits/voting/actively working with the  
database
veto things, and do so without being clear on what they are vetoing.  
(Don, yes this is directed at you partially, but it's also in general)


Robert and Don neither actively edit/vote/work with the data as much as
other active moderators. This has been admitted by Don. Though, they are  
the two making final decisions. I think this is a somewhat concerning  
practice.


I am not making style decisons. I am moderating the decision process.  
Everytime I come near to making a decision there is an uproar, which I am  
very thankful about.
As for Robert, he is the maintainer of MusicBrainz. If you are unhappy  
with him, you can take the data and the code and do your on project. I  
know that is a harsh reply, but it is the truth.



Potential solution? Find someone that is actively deeply involved, and
trusted to start overseeing final decisions. As well those that are more
actively reading the discussions. (no, I am not suggesting myself)[/beth]


I think you are forgetting something very important here: _Continuity_.  
People who are not active editors any more but know the history of the  
project are important.
What would the SC be if noone was there who could step in and say "We had  
a two weeks debate about this just half a year ago. Please do not dig this  
out again unless there is a really good reason to"?

It would change direction following the group of newbs that shoult loudest.

One thing that might have gone unnoticed is that many of these oldtimers  
have left the council in the last half-year. This is as much of a  
challenge to the project as the growth in new users.


I do not agree with your solution, becuase I think your description of the  
problem is wrong.
In terms of kybernetics the SC needs three things: vaiation, selection,  
and stabilisation.

 - Variation is how new ieas and new issues come in.
 - Selection is how those that are not helpful get sorted out.
 - Stabilisation is how the decisions are kept so that they become history.

Our problems are mostly in the realm or selection and partially with  
stabilisation.
We do not have the most basic means of filtering an uninformed newbies  
comment out of a style disucssion. And by "We" I include the newbie  
himself. How should they know that going off on tangents is a bad idea?  
Nobody ever told them.
This last point is very important, because most people who go on tangents  
are _not_ cluesless newbs. They are intermediary users, but still they do  
not know what kind of behavior is expected from them (that is what I  
gathered).


Stabilisatin is an issue, too. People are joining and leaving the project  
at a pace that many informal decisions are likely to get lost. I realised  
that this is part of the secretary's job, too.
Now a solution might be to make more explicit decisions and to have a form  
of automaically archiving them. I am not talking about more formalization!  
This is where we just came from half a year ago, and I do not want to go  
back.


I will dig into the way the real RFCs are done over at the internet  
engineering task force. I surely can learn something from them.


  DonRedman

--
Words that are written in CamelCase refer to WikiPages:
Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation  
around! :-)


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

Re: [mb-style] RFV: RenamedRelationshipType

[Don Redman]

On Wed, 21 Jun 2006 00:52:01 +0200, Aaron Cooper wrote:


I've been reading the other posts about staying on topic and such, and
I know that you're requesting a veto here derGraph... I don't think
we're off topic, but it appears that we have some discussing to do on
the topic of how we store artists in the database who released
material under different names and how we will relate those artists.


Well, we both stated that we do not want to change this aspect at all:

derGraph:
This relationship type should not replace the decision when to createa  
new artist or when to use an alias


DonRedman:
This AR type will not change the current handling (splitting/merging)of  
groups. If they had one artist entry before, they should keep it.If they  
had separate artist entries before, these should be linked bythis AR  
type.


So, yes in a way this discussion is off topic _from the orignal request_.

  DonRedman


--
Words that are written in CamelCase refer to WikiPages:
Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation  
around! :-)


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

Re: [mb-style] Meritocracy and the Style Council

[Don Redman]

On Tue, 20 Jun 2006 02:53:32 +0200, joan WHITTAKER wrote:

No sooner do we seem to have agreed than someone goes off at a tangent,  
and at least a third, usually those against the original proposal,  
following suit and trying to turn the debate.


Yes this is a serious problem. It would be possible to ignore some newbie  
who starts a tangent, but it is difficult to ignore a person with whom you  
have been debating once they too get on that tangent.


We seem to be lacking the most basic method of filtering out noise. I do  
not know of tools that would do that, but a few _techniques_ come to my  
mind:


 - Ignoring it. Actually this is a lot of work. You have to decide that  
the debate has left the path of wisdom and stop to take part. You still  
have to watch if it returns to another path of wisdom. And when it has  
finally ebbed out, you have to read all the confuse stuff again, post a  
summary and issue a RFV.
Even then people might start new tangents. This is _really_ annoying, but  
in fact easier to ignore. You just have to watch for one word: "veto" and  
can ignore all the rest.


I have done this in the past, but I need a weeks break before I can  
'ignore' another debate this way again. This really is a lot of hard work.  
Unfortunately starting tangents is not :-(


 - Bullying. I do not mean this in a negative sense, so bullying is the  
wrong term, I just don't know a better one. What I mean is that people who  
start a tangent lightheartedly would get a clear reply: DON'T DO THAT!  
This is a matter of culture. I know that there are other projects in which  
the mailinglist are pretty rude, the barrier to entry is relatively high  
and newbies are requested to listen a lot, to ask whether they are well  
informed and all that jazz.
I do not know whether this is a sollution. There is some really good input  
from some more-or-less-newbies here and we would loose that too.


Maybe these two techniques can help if they are applied the right way. For  
example it might help to send a mail that says "IMO this has lost the  
focus of my original request. I will ignore the remainder of this thread.  
If you think something sensible came out of it, feel free to send me the  
results in a private message."


Or instead of saying DON'T DO THAT we could say DON'T DO THAT HERE and ask  
people to start a new thread with a different subject. Again you could  
say: come back to 'my' thread if you have serious results.


This notion of 'my' thread might help too, although it is dangerous when  
the debate is heated. And if I would push a valid argument out of 'my'  
thread, then I would surely reap a veto later.



Anyway these are just a sociologist's thoughts about the situation.  
Perhaps the hackers have some more straightforward ideas


  DonRedman


--
Words that are written in CamelCase refer to WikiPages:
Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation  
around! :-)


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

Re: [mb-style] "(album version)"

[Don Redman]

On Tue, 20 Jun 2006 12:50:11 +0200, Lukáš Lalinský"" wrote:


On 6/20/06, Don Redman wrote:

(this argument does not hold if Lukas says Picard 0.8 takes longer)


No, Picard 0.8 will not come within a month.


OK, I withdraw my argument (which was not a veto anyway).

Since this issue has been more than discussed to death now (and I was part  
of it[1]) I hereby issue a



for the following:

Remove the paragraph
We generally do not retain information such as "(album version)" as  
this is considered incidental. If the release is a single, of course  
one of the tracks is going to be the "album version"; "album version"  
is not part of the title, and is extraneous ExtraTitleInformation.<<


from ExtraTitleInformationStyle and add

In June 2006 we changed the rules slightly. They now explicitly state:  
If a track on a single has the additional info "(album version)", we  
''retain it''. This extra information of TrackTitle``s is considered  
contextually relevant and should be kept.<<


If you want to specify that the album version is identical to a  
specific track on an album use the OtherVersionRelationshipType.<<



Jan has written an excellent summary fo the arguments in the debate which  
I repost here (plus Nikki's and my additions):


Against
---
- people like having the same track name for the same tracks on
different releases. This, however, is already the case for e.g. live
tracks on album releases and the same tracks on live releases.
- mostly used for tagging purposes, and people contribute to MB
primarily for tagging purposes, so these contributors should have more
to say on this issue.
(- DonRedman wanted to bundle this change with probable changes to the  
same guidelines with the release of Picard 0.8, but since that will take  
some time, this does not make sense.)


For
---
- we loose version information when it's removed
- in line with 'state what is on the cover'
- when it's removed, a release can have two tracks with the same name,
making the track listing ambiguous.
- SameTrackRelationshipType is the AR that can state that two tracks
have the same content; no need to rename them all to the same name.
- The album version isn't necessarily the main version, and the album
  version may not be called an album version, but instead LP version, 12"
  version, etc. and in both cases the version info is kept.
- There's currently an inconsistency in assumptions we make, i.e. an
  unlabelled track on a live release is a live version, but an unlabelled
  track on a single release is an album version.



[1] There is one thing I have to clarify here:

Lukas wrote:

Anyway, using Picard as an argument against removing any info from the
database is, in my opinion, silly.


I never wanted to say that. I only wanted to avoid changing the same set  
of guidelines twice in a short period of time. Sorry if it came through  
differently.


  DonRedman

--
Words that are written in CamelCase refer to WikiPages:
Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation  
around! :-)


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

Re: [mb-style] "(album version)"

[Don Redman]

On Tue, 20 Jun 2006 00:53:28 +0200, Nikki wrote:


If  Picard 0.8 comes out within a month, then would be two consecutive
changes. (this argument does not hold if Lukas says Picard 0.8 takes
longer)


Well, 0.7 is not a stable release yet (according to the wiki page...),  
so I

can't imagine 0.8 being here in under a month. Of course, maybe Lukáš has
stuff hidden up his sleeve.


Well, as I said, if this takes longer than a month, then I withdraw my  
argument. I am for this change anyway.


I CCed the post of this thread in which I asked how long picard 0.8 would  
take to Lukas, but have not gotten any reply yet.


Anyway this was an argument against that was part of the debate, and it  
was missing in Zout's summary. Therefore I added it. I do not feel that  
this is strong enough to justify a veto (well I would not veto because of  
this). So you can feel free and ignore it.


  DonRedman

--
Words that are written in CamelCase refer to WikiPages:
Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation  
around! :-)


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