Discussion:
[mb-style] Changes to our style process (Important)
Nicolás Tamargo de Eguren
2014-10-19 17:42:37 UTC
Permalink
Hi! So, this has already been posted to the blog, but for those here who
don't read the blog, I'll repost:

At the MusicBrainz Summit last month in Copenhagen, one of the topics to
be discussed was the state of the style guidelines and style process.
One thing those present agreed on was that the process was in need of
reform, for several reasons: the complexity of the process,
inconsistency with other processes in the project, the high level of
individual commitment required to make changes, long-running discussions
without conclusion or followthrough, and ultimately the state of the
final product, the style guidelines themselves. The inaccessibility of
our existing process meant that many users, both new and old, avoided
the style process, and this hurts the project: style is part of what
makes MusicBrainz what it is, and low participation means our guidelines
have grown both internally inconsistent and out of sync with community
practice. Nor is the style process a new problem for MusicBrainz:
historically, it’s changed several times and some past style leaders
have vanished into thin air. After all, it is a hard job, for a
volunteer, to convince many voices to come to a consensus.

To improve upon these issues, we’ve decided to make two major changes.

First: to designate our JIRA issue tracker at tickets.musicbrainz.org as
the central coordination point for style issues. This way, any issue, be
it style-related or code-related, is reported and discussed in the same
place (and should an issue be misfiled, it’s easily corrected). The
issue tracker can also collect links to other discussions, in edit
notes, the forums, IRC, etc., and store links to related issues such as
features in need of implementation.

Second: to promote our current Style Leader to Style Benevolent Dictator
For Life (Style BDFL). Nicolás Tamargo (reosarevok) will then be in
charge of considering tickets and implementing changes in the style
guidelines. This change shifts the burden of evaluating style issues
from the community to our newly appointed BDFL. For simple changes and
for simple improvements to consistency and writing style, the BDFL can
change things directly, without need for lengthy discussion. Of course,
his work won’t happen in a vacuum: for changes that are complex or
contentious, the role of the BDFL will be to gather feedback and
determine the next steps before making changes. To this end, he may
occasionally call for a non-binding vote on a particular topic, to
collect a snapshot of community opinion to augment existing discussion,
all in order to make a better informed decision.

We hope that this new process will make contribution to the creation of
style guidelines easier and less onerous a commitment for everyone, and
that the resulting style guidelines will be more up-to-date, more
consistent, and more clearly written and organized. To test it out,
we’re going to try this process for 6 months, and then review how things
have progressed and if the process needs further tweaking or even
complete replacement.

tl;dr: Style system has changed, new info at
http://musicbrainz.org/doc/Proposals
lixobix
2014-10-20 12:02:02 UTC
Permalink
Post by Nicolás Tamargo de Eguren
Hi! So, this has already been posted to the blog, but for those here who
At the MusicBrainz Summit last month in Copenhagen, one of the topics to
be discussed was the state of the style guidelines and style process.
One thing those present agreed on was that the process was in need of
reform, for several reasons: the complexity of the process,
inconsistency with other processes in the project, the high level of
individual commitment required to make changes, long-running discussions
without conclusion or followthrough, and ultimately the state of the
final product, the style guidelines themselves. The inaccessibility of
our existing process meant that many users, both new and old, avoided
the style process, and this hurts the project: style is part of what
makes MusicBrainz what it is, and low participation means our guidelines
have grown both internally inconsistent and out of sync with community
historically, it’s changed several times and some past style leaders
have vanished into thin air. After all, it is a hard job, for a
volunteer, to convince many voices to come to a consensus.
To improve upon these issues, we’ve decided to make two major changes.
First: to designate our JIRA issue tracker at tickets.musicbrainz.org as
the central coordination point for style issues. This way, any issue, be
it style-related or code-related, is reported and discussed in the same
place (and should an issue be misfiled, it’s easily corrected). The
issue tracker can also collect links to other discussions, in edit
notes, the forums, IRC, etc., and store links to related issues such as
features in need of implementation.
Second: to promote our current Style Leader to Style Benevolent Dictator
For Life (Style BDFL). Nicolás Tamargo (reosarevok) will then be in
charge of considering tickets and implementing changes in the style
guidelines. This change shifts the burden of evaluating style issues
from the community to our newly appointed BDFL. For simple changes and
for simple improvements to consistency and writing style, the BDFL can
change things directly, without need for lengthy discussion. Of course,
his work won’t happen in a vacuum: for changes that are complex or
contentious, the role of the BDFL will be to gather feedback and
determine the next steps before making changes. To this end, he may
occasionally call for a non-binding vote on a particular topic, to
collect a snapshot of community opinion to augment existing discussion,
all in order to make a better informed decision.
We hope that this new process will make contribution to the creation of
style guidelines easier and less onerous a commitment for everyone, and
that the resulting style guidelines will be more up-to-date, more
consistent, and more clearly written and organized. To test it out,
we’re going to try this process for 6 months, and then review how things
have progressed and if the process needs further tweaking or even
complete replacement.
tl;dr: Style system has changed, new info at
http://musicbrainz.org/doc/Proposals
_______________________________________________
MusicBrainz-style mailing list
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Seem like some good changes. Lets see how it goes.



--
View this message in context: http://musicbrainz.1054305.n4.nabble.com/Changes-to-our-style-process-Important-tp4668864p4668873.html
Sent from the MusicBrainz - Style mailing list archive at Nabble.com.
David Gasaway
2014-10-22 22:25:40 UTC
Permalink
On Sun, Oct 19, 2014 at 10:42 AM, Nicolás Tamargo de Eguren
Post by Nicolás Tamargo de Eguren
tl;dr: Style system has changed, new info at
http://musicbrainz.org/doc/Proposals
Hi. How should an editor keep abreast of style changes under the new system?
--
-:-:- David K. Gasaway
-:-:- Email: ***@gasaway.org
Nicolás Tamargo de Eguren
2014-10-22 22:30:29 UTC
Permalink
On Sun, Oct 19, 2014 at 10:42 AM, Nicolás Tamargo de Eguren
Post by Nicolás Tamargo de Eguren
tl;dr: Style system has changed, new info at
http://musicbrainz.org/doc/Proposals
Hi. How should an editor keep abreast of style changes under the new system?
For checking what changes have happened, we'll be posting on the blog
(category "Style") a list of implemented changes every two weeks (more or
less). For discussion and feedback before things are implemented, for now I
plan to post both here and on the Style section of the forum, so being here
should be enough :)
lixobix
2014-10-23 14:34:57 UTC
Permalink
On Thu, Oct 23, 2014 at 1:25 AM, David Gasaway <
Post by David Gasaway
On Sun, Oct 19, 2014 at 10:42 AM, Nicolás Tamargo de Eguren
<
Post by Nicolás Tamargo de Eguren
tl;dr: Style system has changed, new info at
http://musicbrainz.org/doc/Proposals
Hi. How should an editor keep abreast of style changes under the new system?
For checking what changes have happened, we'll be posting on the blog
(category "Style") a list of implemented changes every two weeks (more or
less). For discussion and feedback before things are implemented, for now I
plan to post both here and on the Style section of the forum, so being here
should be enough :)
_______________________________________________
MusicBrainz-style mailing list
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Is there a way to get email updates when the blog is updated?



--
View this message in context: http://musicbrainz.1054305.n4.nabble.com/Changes-to-our-style-process-Important-tp4668864p4668956.html
Sent from the MusicBrainz - Style mailing list archive at Nabble.com.
Robert Bihlmeyer
2014-10-23 19:42:22 UTC
Permalink
Post by lixobix
Is there a way to get email updates when the blog is updated?
I don't think so. But http://blog.musicbrainz.org/feed/ is an RSS feed,
that most popular mail user agents know how to handle. There are also
phone apps for twitchers.

See https://en.wikipedia.org/wiki/Comparison_of_feed_aggregators for an
overview.
--
Robbe
Robert Bihlmeyer
2014-10-23 20:08:18 UTC
Permalink
Post by Nicolás Tamargo de Eguren
For checking what changes have happened, we'll be posting on the blog
(category "Style") a list of implemented changes every two weeks (more or
less).
Can we get versioned (or time stamped) style documents?

That would make it possible to look up
style-as-was-fashionable-when-this-edit-was-made. It is sometimes useful
to determine why an edit was done the way it was.

--
Robbe
Rachel Dwight
2014-10-23 20:13:19 UTC
Permalink
Post by Robert Bihlmeyer
Post by Nicolás Tamargo de Eguren
For checking what changes have happened, we'll be posting on the blog
(category "Style") a list of implemented changes every two weeks (more or
less).
Can we get versioned (or time stamped) style documents?
That would make it possible to look up
style-as-was-fashionable-when-this-edit-was-made. It is sometimes useful
to determine why an edit was done the way it was.
I second this. A lot of our guidelines haven’t been updated in years (many predate NGS).
Post by Robert Bihlmeyer
--
Robbe
_______________________________________________
MusicBrainz-style mailing list
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Frederic Da Vitoria
2014-10-23 20:27:14 UTC
Permalink
Post by Robert Bihlmeyer
Post by Nicolás Tamargo de Eguren
For checking what changes have happened, we'll be posting on the blog
(category "Style") a list of implemented changes every two weeks (more or
less).
Can we get versioned (or time stamped) style documents?
That would make it possible to look up
style-as-was-fashionable-when-this-edit-was-made. It is sometimes useful
to determine why an edit was done the way it was.
Am I missing something or wouldn't the wiki history answer this need?
--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
Robert Bihlmeyer
2014-10-26 22:00:09 UTC
Permalink
Post by Frederic Da Vitoria
Post by Robert Bihlmeyer
Can we get versioned (or time stamped) style documents?
Am I missing something or wouldn't the wiki history answer this need?
Style is currently split into more than 30 wiki pages. That's fine if
you're reading the current version. But AFAIK MediaWiki does not offer
the possibility to look at multiple pages in their
January-1st-2012-version -- only for one page at a time.

So while possible in principle, it's very cumbersome to get at the whole
style guide in its January-1st-2012-incarnation.
--
Robbe
Calvin Walton
2014-10-29 16:14:39 UTC
Permalink
Post by Robert Bihlmeyer
Post by Frederic Da Vitoria
Post by Robert Bihlmeyer
Can we get versioned (or time stamped) style documents?
Am I missing something or wouldn't the wiki history answer this need?
Style is currently split into more than 30 wiki pages. That's fine if
you're reading the current version. But AFAIK MediaWiki does not offer
the possibility to look at multiple pages in their
January-1st-2012-version -- only for one page at a time.
So while possible in principle, it's very cumbersome to get at the whole
style guide in its January-1st-2012-incarnation.
With the changes in how we're doing the style process, I wonder if it
might make more sense to change the process for editing the style
guide to make it more like code or documentation than a wiki.

There are various ways of having documents done in a git repository,
all versioned together, and then generating static html pages from a
specific version to be published: e.g. what you see with
https://readthedocs.org/

Just a thought, but it would enable easier tracking of changes, and
allow generating docs from a specific date or version of the style
guide if desired.
--
Calvin Walton <***@kepstin.ca>
Ben Ockmore
2014-10-29 17:32:15 UTC
Permalink
I very much agree with this. While having only one person editing docs may
be a good idea for ensuring consistency and quality, it also rules out the
main advantage of storing docs in a wiki.

It'd probably simplify things if all the docs were written in Markdown or
RST, then displayed as static pages on the site, as Calvin suggested.
Ian McEwen
2014-10-29 21:00:26 UTC
Permalink
Post by Calvin Walton
Post by Robert Bihlmeyer
Post by Frederic Da Vitoria
Post by Robert Bihlmeyer
Can we get versioned (or time stamped) style documents?
Am I missing something or wouldn't the wiki history answer this need?
Style is currently split into more than 30 wiki pages. That's fine if
you're reading the current version. But AFAIK MediaWiki does not offer
the possibility to look at multiple pages in their
January-1st-2012-version -- only for one page at a time.
So while possible in principle, it's very cumbersome to get at the whole
style guide in its January-1st-2012-incarnation.
With the changes in how we're doing the style process, I wonder if it
might make more sense to change the process for editing the style
guide to make it more like code or documentation than a wiki.
There are various ways of having documents done in a git repository,
all versioned together, and then generating static html pages from a
specific version to be published: e.g. what you see with
https://readthedocs.org/
Just a thought, but it would enable easier tracking of changes, and
allow generating docs from a specific date or version of the style
guide if desired.
This was, in fact, part of the hidden goal here :) As those of you who
were at the summit know, my original proposal didn't centralize things
quite as far as what ended up being decided, but even without that it
moved writing it to people who are certainly able to use
developer-oriented tools like git.

I think that at present between the upcoming schema change,
acousticbrainz, the holidays, and the various other work I and the other
devs have been doing, right now the style changes will focus on
clarifying writing style and dealing with neglected things. But
hopefully soon.

P.S. the usual tool for this in perl is POD:
http://perldoc.perl.org/perlpod.html /
http://perldoc.perl.org/pod2html.html -- example output at e.g.
https://metacpan.org/pod/Catalyst (and the rest of metacpan)
Post by Calvin Walton
--
_______________________________________________
MusicBrainz-style mailing list
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Tom Crocker
2014-10-29 22:55:53 UTC
Permalink
Out of interest, does this mean we're getting rid of the distinction
between official style guidelines and docs? Or are docs still open to
community editing?
Ian McEwen
2014-10-29 23:24:48 UTC
Permalink
Post by Tom Crocker
Out of interest, does this mean we're getting rid of the distinction
between official style guidelines and docs? Or are docs still open to
community editing?
Any moving things into the codebase doesn't change the 'community
editing' aspect, just the technical process and prerequisites for
implementing changes and the particular gatekeepers involved in changes
appearing on the site -- instead of editing a wiki and transclusion
editors, template files or other code and those with merge power plus
the schedule of the beta/production merge process.

It's similar to the style change: instead of a proposal system with wiki
pages and a gatekeeper embedded in the patience to negotiate the old
style process, community participation goes through interaction with
reosarevok, who serves as the gatekeeper himself.

Or, in short, anyone can open pull requests:
https://bitbucket.org/metabrainz/musicbrainz-server

P.S. for the curious what template files look like (which would probably
be where documentation of this sort ends up):
https://github.com/metabrainz/musicbrainz-server/tree/master/root has
them all. (github for this link because it has better display for this
sort of file; it and bitbucket are kept in sync)
Paul Taylor
2014-10-30 13:11:08 UTC
Permalink
Post by Ian McEwen
Post by Tom Crocker
Out of interest, does this mean we're getting rid of the distinction
between official style guidelines and docs? Or are docs still open to
community editing?
Any moving things into the codebase doesn't change the 'community
editing' aspect, just the technical process and prerequisites for
implementing changes and the particular gatekeepers involved in changes
appearing on the site -- instead of editing a wiki and transclusion
editors, template files or other code and those with merge power plus
the schedule of the beta/production merge process.
It's similar to the style change: instead of a proposal system with wiki
pages and a gatekeeper embedded in the patience to negotiate the old
style process, community participation goes through interaction with
reosarevok, who serves as the gatekeeper himself.
https://bitbucket.org/metabrainz/musicbrainz-server
P.S. for the curious what template files look like (which would probably
https://github.com/metabrainz/musicbrainz-server/tree/master/root has
them all. (github for this link because it has better display for this
sort of file; it and bitbucket are kept in sync)
I disagree, although one person is currently has now been put in charge
of the style process this is a new change that may need tweaking, and
future tweaking may involve delegating some of the style modifications
so we should not assume that only one person will always be making all
the edits. Nor we should assume that future editors will be git literate
or similar, this puts unneccessary restrictions on possible contributors
, surely one of the main point of the style guidelines has been they can
be contributed to my non-coders/tech.

Also wouldnt this mean that unlike a wiki if we did move to the process
your are advocating you wouldnt be able to see how changes made looked
on the site before comitting without having a musicbrainz server setup.
Actually to me this points to a fundamental problem in Musicbrainz,
again and again assumptions are made all Musicbrainz contributors are
coders whose preferred OS is Linux , this isnt true, but assuming it is
true discourages contributions from the those not fitting into this niche

ijabz
Nicolás Tamargo de Eguren
2014-10-30 13:54:00 UTC
Permalink
Post by Paul Taylor
I disagree, although one person is currently has now been put in charge
of the style process this is a new change that may need tweaking, and
future tweaking may involve delegating some of the style modifications
so we should not assume that only one person will always be making all
the edits. Nor we should assume that future editors will be git literate
Both bitbucket and github allow on-site editing of files that does most of
the branching and pull-requesting in the background. So it's not exactly
much more complicated than editing a wiki, and it doesn't require basically
any amount of actual git-literacy. Yes, it lacks being able to preview, but
that shouldn't matter much - after all, right now you can preview how stuff
looks in the wiki but not in /doc/, anyway.
Post by Paul Taylor
this puts unneccessary restrictions on possible contributors
, surely one of the main point of the style guidelines has been they can
be contributed to my non-coders/tech.
That changes how? To be able to write a wiki page you need a starting
template and/or knowledge of wiki syntax. To be able to write a static TT
template you need a starting template and/or knowledge of basic html
syntax. Both are similarly simple. In fact, with our old wiki templates for
relationships, for example, using them was probably *quite a bit harder*
than using TT would be (mostly because they were a badly written mess of a
template, but people managed anyway). Plus, people can always put together
a plain text draft on the ticket, to be made into a doc template by the
person implementing it.
Post by Paul Taylor
Also wouldnt this mean that unlike a wiki if we did move to the process
your are advocating you wouldnt be able to see how changes made looked
on the site before comitting without having a musicbrainz server setup.
Yes, this is the only drawback, but as mentioned previously, it seems minor
enough. The people writing the final docs should have the (fairly basic)
knowledge to know what to expect, and also probably their own server setup
anyway.
Post by Paul Taylor
Actually to me this points to a fundamental problem in Musicbrainz,
again and again assumptions are made all Musicbrainz contributors are
coders whose preferred OS is Linux , this isnt true, but assuming it is
true discourages contributions from the those not fitting into this niche
How is this assumption made here? The whole point of this is allowing
*everyone* to contribute, regardless of their coding expertise, by having
someone who can take care of the more code-y stuff (instead of having
non-coders fight confusing mediawiki templates). Actually, I don't see
where that assumption is made *anywhere* in the project, to be honest, as a
part-time coder (and non-coder when I started) whose usual OS is Win 8. But
even if it was true elsewhere, I really don't see it here.
Paul Taylor
2014-10-30 20:23:57 UTC
Permalink
Post by Paul Taylor
I disagree, although one person is currently has now been put in charge
of the style process this is a new change that may need tweaking, and
future tweaking may involve delegating some of the style modifications
so we should not assume that only one person will always be making all
the edits. Nor we should assume that future editors will be git literate
Both bitbucket and github allow on-site editing of files that does
most of the branching and pull-requesting in the background. So it's
not exactly much more complicated than editing a wiki, and it doesn't
require basically any amount of actual git-literacy. Yes, it lacks
being able to preview, but that shouldn't matter much - after all,
right now you can preview how stuff looks in the wiki but not in
/doc/, anyway.
But /wiki and /doc are VERY similar whereas i assume without the
templates there will be quite a difference in what they look like. To my
mind introducing Git and Templates and lumping more files into the
already Monolithic codebase is not a good idea and is certainly this is
not making things simpler, I don't think this is the direction that
other sites are going and I'm now wondering if there are any other
'hidden goals' with this idea
Post by Paul Taylor
this puts unneccessary restrictions on possible contributors
, surely one of the main point of the style guidelines has been they can
be contributed to my non-coders/tech.
That changes how? To be able to write a wiki page you need a starting
template and/or knowledge of wiki syntax. To be able to write a static
TT template you need a starting template and/or knowledge of basic
html syntax.
The difference is the kind of users that are used to writing wikis are a
bit different to those who write pure html and wikis protect users from
making invalid modifications. Consider Wikipedia do you think that site
would work better if users had to create valid html pages rather than
edit in the wiki style.
Post by Paul Taylor
Also wouldnt this mean that unlike a wiki if we did move to the process
your are advocating you wouldnt be able to see how changes made looked
on the site before comitting without having a musicbrainz server setup.
Yes, this is the only drawback, but as mentioned previously, it seems
minor enough. The people writing the final docs should have the
(fairly basic) knowledge to know what to expect, and also probably
their own server setup anyway.
Its one drawback, but what are the actual advantages I don't see them,
we shoudn't be adding any drawbacks.
Post by Paul Taylor
Actually to me this points to a fundamental problem in Musicbrainz,
again and again assumptions are made all Musicbrainz contributors are
coders whose preferred OS is Linux , this isnt true, but assuming it is
true discourages contributions from the those not fitting into this niche
How is this assumption made here? The whole point of this is allowing
*everyone* to contribute, regardless of their coding expertise, by
having someone who can take care of the more code-y stuff (instead of
having non-coders fight confusing mediawiki templates). Actually, I
don't see where that assumption is made *anywhere* in the project, to
be honest, as a part-time coder (and non-coder when I started) whose
usual OS is Win 8. But even if it was true elsewhere, I really don't
see it here.
Well look at what you just wrote above 'and also probably their own
server setup anyway' you have made the assumption yourself.

To be clear I'm not against you being the final decision maker and only
editor for the time being, but we need to try test out the new process
before making changes like these, and what I'm against is making
changes to the way things works so that in the future it will be harder
for others to edit if decide want to spread the role. And putting a
dependency that the final editor has to have their own server running
just for modifying and viewing the changes is not a good thing, and what
happens if you get hit by a bus and we need a new style editor, Ian put
himself and nikki forward in the original proposal but I really don't
think having the main Musicbrainz developer involved (whoever they are)
is a good idea at all.

1. Developers have there plate full already
2. There is a conflict of interest between making the style proposals
and being the implementor
3. Concentrates control to fewer people, leaving musicbrainz exposed
4. Developers notorious for being bad at documentation

Maybe Im the only one thinking like this, and its not the most pressing
issue for me so I wont go on about it any further, but the absense of
discussion at the musicbrainz summit makes me feel I have a duty to put
alternative povs over.

ijabz
Ben Ockmore
2014-10-31 00:58:16 UTC
Permalink
Yeah, I have to agree with Paul, making documentation editors edit HTML
templates is an unnecessary complication, when there are plenty of existing
plain text to HTML conversion systems which would work just as well.

AFAIK our current system doesn't require any data from the rest of the
server, so what advantage does using TT provide? I'm also against any
further integration of the documentation system into the MBS codebase.

I do still think that putting it all on Git is a good idea though
(especially given the online editing capabilities of GH and BB). Just not
TT templates, and separate from the server code.
caller#6
2014-10-31 18:43:15 UTC
Permalink
Post by Ben Ockmore
I do still think that putting it all on Git is a good idea though
(especially given the online editing capabilities of GH and BB). Just
not TT templates, and separate from the server code.
For anybody interested, keep an eye on
https://github.com/PharkMillups/beautiful-docs , an ever-growing roundup
of doc-related resources.
Daniel Sobey
2014-11-02 04:49:53 UTC
Permalink
Using git as a wiki replacement can be a good idea and can be easy to do if
you know how.
Github encourages you to use a text document using markdown.
Markdown is a wiki like language and can be easily converted into html.

Editing a markdown in github is just as easy as editing a wiki page.
First create an account and login to github.
Go to the project page and find the file you want to edit.
click the edit button
make your change, there is a preview tab to see what the result will be.
enter a comment on what you have changed.

The change will be made to your local branch and a "pull request" will be
made to the owner notifying them of the change.
The owner will then be able to review and merge the changes into the
officia document.

For a good example of this working well see the following project:
https://github.com/vhf/free-programming-books
This is just a list of programming resources but has had 2630 changes by
478 people.
Post by caller#6
Post by Ben Ockmore
I do still think that putting it all on Git is a good idea though
(especially given the online editing capabilities of GH and BB). Just
not TT templates, and separate from the server code.
For anybody interested, keep an eye on
https://github.com/PharkMillups/beautiful-docs , an ever-growing roundup
of doc-related resources.
_______________________________________________
MusicBrainz-style mailing list
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
jesus2099
2014-11-10 09:22:46 UTC
Permalink
+1 docs in git with Markdown



-----
 PATATE12 
 jesus2099 
 GOLD MASTER KING 
 FAKE E-MAIL ADDRESS 
--
View this message in context: http://musicbrainz.1054305.n4.nabble.com/Changes-to-our-style-process-Important-tp4668864p4669298.html
Sent from the MusicBrainz - Style mailing list archive at Nabble.com.
Loading...