Candidate for Deletion/Current

From MusicBrainz Wiki

This page lists current candidates for deletion.

Artist ID

Special:Whatlinkshere/Artist ID

The information on here is covered by MusicBrainz Identifier. Nikki 03:42, 30 March 2009 (UTC)

  • +1 navap 19:28, 30 March 2009 (UTC)
  • -1 Permanent ids are an important aspect of MB, thus I do think it's important to have it explicitly referenced/documented for each MB entity. Anyway not a big priority, there are a lot more junk to clean up before these ones, we can discuss that one we've a clear path for the documentation part of the wiki. Murdos 22:40, 31 March 2009 (UTC)
How about using sections on MusicBrainz Identifier so they can be referred to with anchors (i.e. MusicBrainz Identifier#Artist ID) then? I really don't see the point in having 5 pages to explain what MusicBrainz IDs are when the content of each page is pretty much identical. The pages themselves aren't even very long, one paragraph (which copy/pasted between each page, with Artist changed to Release or whatever), one example and then loads of included template stuff. Nikki 08:26, 1 April 2009 (UTC)
  • -1 For the same reason as above. Good or not, the current system for these pages is well linked by navigation cards, categories and a number of direct links to them. Changing all that for the sole benefit of aesthetic considerations is plain useless work IMHO. dmppanda
I think in general the wiki needs a lot of condensing, we seem to have a sort of one-page-for-every-thought kind of approach; not only is this aesthetically displeasing, but it is confusing and makes it hard to find all the relevant information on a topic one would want to look up. It is my opinion that we don't need to have an entire page dedicated to explaining what a Failed Dependency or Split Release is; I'm not suggesting that all the pages on Category:Terminology be merged, but I think a lot of the smaller ones (eg. CAE, IPI, ISMN, ISWC) can be safely condensed into one terminology/glossary type of page.
Following that train of thought, I think the same applies to "more important"/official WikiDocs pages; for example, it is my opinion that all the ARs in the Discography Relationship Class should be displayed in full on that page itself, instead of having small separate pages that become hard to interlink. In fact that same thing should be done for quite a few of the pages in Category:Relationship Class, Category:Edit Types, and wait for it, Category:Identifier. Putting the various external links, cards, and categories aside for a moment, I don't think there is any reason for Track ID to exist on it's own when virtually all the same information already exists on MusicBrainz Identifier. Additionally, the four examples I gave from the terminology category are also in the identifier category, but if you look at their "backlinks" page it's evident that they just link to each other and the two categories which means they are very well hidden.
I believe instead of throwing each little page into a category (and spreading all the information out over multiple pages) we should instead either flesh the page out or incorporate it as a section into a bigger or "parent" page, thus improving wiki navigation. I apologize if this sounded like a rant, but when I first joined mb I had a terrible time navigating the wiki and finding relevant information about ARs and style guidelines, so this is something I've felt for quite a while and felt it was an important topic to discuss. navap 01:55, 5 April 2009 (UTC)

Release ID

Special:Whatlinkshere/Release ID

The information on here is covered by MusicBrainz Identifier. Nikki 03:42, 30 March 2009 (UTC)

  • +1 navap 19:28, 30 March 2009 (UTC)
  • -1 See Artist ID. Murdos 22:40, 31 March 2009 (UTC)
  • -1 dmppanda

Track ID

Special:Whatlinkshere/Track ID

The information on here is covered by MusicBrainz Identifier. Nikki 03:42, 30 March 2009 (UTC)

  • +1 navap 19:28, 30 March 2009 (UTC)
  • -1 See Artist ID. Murdos 22:40, 31 March 2009 (UTC)
  • -1 dmppanda

Label ID

Special:Whatlinkshere/Label ID

The information on here is covered by MusicBrainz Identifier. Nikki 03:43, 30 March 2009 (UTC)

  • +1 navap 19:28, 30 March 2009 (UTC)
  • -1 See Artist ID. Murdos 22:40, 31 March 2009 (UTC)
  • -1 dmppanda

Needs Intertwingling

Old cruft pronik 19:45, 6 April 2009 (UTC)

The page itself might be useless, but the "backlinks" might come in handy. navap 00:30, 7 April 2009 (UTC)

A category would be better. - Adan Aileron (talk) 18:39, 17 April 2009 (UTC)
  • +1 The page is itself empty, and any backlinks are likely made redundant via the Needs Review category. User:BrianFreud 28 Feb, 2010

Racing The Tide

Move to annotations or whatever ... --pronik 19:51, 6 April 2009 (UTC)

History Of Featuring Artist Style and SG5 Disaster Relief

I don't see any relevance for this in the year 2009, with NGS being implemented... pronik 21:32, 11 May 2009 (UTC)

Veto: Considering the amount of drama which went into this, and the fact that even today we have people who raise debates about Featuring Artist Style, there would still seem good reason to retain this bit of history. (I'm not against removing history, but I do think we ought to retain history that actually is still useful... consider how many times some of us have wished we still had access to the earlier (official) pre-re-proposal version of SoundtrackStyle...) BrianFreud 28 Feb, 2010

History Of Opera Track Style

Mostly non-relevant for anything. CSG2 is upon us. pronik 21:34, 11 May 2009 (UTC)

Veto: Even with CSGv2, the CSGv2 proposal explicitly moves this page, among others, to a historical status in the wiki. It's hard to say that the page is "mostly non-revelant for anything", given that that page itself principally developed the Opera Style proposal, and the concerns raised on it led directly to some of the elements within CSGv2. Esp given the huge debate that's gone in to CSGv2, maintaining some history regarding its development would seem essential, if only to point new users of MB data at when they question why CSGv2 does something the way it does. BrianFreud 28 Feb, 2010

Classical Style Guide Discussion History

Discussion history... That's what mailing list archives are for... pronik 21:35, 11 May 2009 (UTC)

Again, veto, and for the same rationale as Opera Style. Mailing list archives only work for style development which occurs within that mailing list. Much of the earlier CSG, then Opera Style, then CSGv2 development took place outside of the mailing lists; this page, in particular, was essentially the clearinghouse for post-CSG(v1) modifications to the guideline which, for various and sundry reasons (namely the size of the effort that would be required - eg: CSGv2), never actually happened, prior to CSGv2's rewrite of the entire set of guidelines. BrianFreud 28 Feb, 2010

Advanced Moderation

It confuses more than it helps. If it's relevant, those parts should be extracted to an article, otherwise delete it. pronik 21:41, 11 May 2009 (UTC)

Label History

We do have Trac for tracking closed tickets. pronik 21:43, 11 May 2009 (UTC)

  • +1 We do *now* have Trac, plus Trac filters that can give this same list (but current), for this. ;) User:BrianFreud 28 Feb, 2010

Individual cover art pages

I've gathered the various individual permission pages into one page so I think it's safe to delete all the permission pages inside Category:Cover Art and just work from the one page. --navap 15:48, 23 December 2009 (UTC)

Redirected pages without any backlinks

I've fixed all backlinks, so none of these redirect pages are now actually used. BrianSchweitzer 13:26, 15 March 2010 (UTC)

  • -1 These pages are not safe to delete, some of them are referenced at least in edits notes or annotations (e.g. CoverArtSites, AmazonRelationshipType or AdvancedRelationshipStyle). Murdos 13:30, 15 March 2010 (UTC)
  • The same argument could be made about any page; do we really plan to maintain a massive collection of redirecting pages forever, just to avoid breaking links in edit notes, trac, jira, or annotations? BrianSchweitzer 13:33, 15 March 2010 (UTC) ... Just checking, we have 2160 pages which are redirects. We have 4849 total pages. So nearly 50% of the entire wiki is redirects... BrianSchweitzer 13:38, 15 March 2010 (UTC)