Template talk:Track listing/Archive 10

reference parameter
It might be good to add a parameter to deal with a reference. Some articles are using the all_writing parameter which places the reference before a period and others just dump it after the whole table. Walter Görlitz (talk) 13:24, 10 May 2013 (UTC)


 * Yes, agreed. Or alternatively, make it possible to stop the period being forced at the end of the credits so a reference can be inserted after the period.  Compare these examples:
 * From The Signal (Urthboy album), manually inserted note, how it should appear:
 * "All tracks written by (Tim Levinson and P. Norman) unless otherwise indicated.[1]"
 * From Spitshine, automatically inserted note using template, with the period forced at the end after the ref:
 * "All songs written and composed by Tim Levinson and Phillip Norman unless otherwise indicated[6]."
 * From Smokey's Haunt, no note:
 * "Smokey's Haunt[2][9]"
 * The last example is my temporary fix for providing a general citation for the tracklisting, but not a specific reference for the writing credits. —sroc (talk) 12:51, 14 May 2013 (UTC)
 * It goes beyond that parameter, although that is an annoyance in many instances. Quite often I see articles that use this template and there are minor edit wars over the spelling of track names and their length. It could be the difference between where they were released or comparing the track lengths as recorded on the CD tray insert and the times as displayed in a CD player, or the CD version against the digital download. It would be appropriate to have a uniform location to include and display a reference to avoid the edit wars. A parameter would be the best way to do this. Walter Görlitz (talk) 17:47, 20 May 2013 (UTC)

Personally I think it can be added in the headline parameter. No real need to make a specified area.Lucia Black (talk) 07:55, 2 June 2013 (UTC)
 * This is again an issue of data granularity, as explained to you above. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 17:44, 2 June 2013 (UTC)

Lets not connect different proposals together.Lucia Black (talk) 19:33, 2 June 2013 (UTC)
 * I think I have mentioned the necessity of "reference" parameters at some point over the years. I always point to Template:Episode list as an example of implementation. Thus, I would support the inclusion of a "reference" parameter for those fields which have pre-formatting that otherwise interfere with how the reference is displayed. The "all_writing" parameter for instance, since there's the issue of the reference being before the period. There's also the Title parameter which again, has formatting issues with references. That being the reference being inside of the quote. – Mizery Made  ( talk ·  contribs ) 19:50, 2 June 2013 (UTC)
 * Who is "connecting different proposals together"? This is an issue of data granularity, regardless of any proposals elsewhere. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 21:06, 2 June 2013 (UTC)

Difference being an episode releases separately first while traclist is released unilaterally. To have a ref parameter would be good if it wasnt that apparent on the tracklist. It could simply put the ref or note next to the title/headline.Lucia Black (talk) 20:06, 2 June 2013 (UTC)
 * On this occassion I'm not convinced that separate reference parameter impacts upon data granularity if the reference was included in the headline parameter. It has been done successfully at Glassheart and Talk a Good Game. &mdash;  Lil_ ℧ niquℇ № 1  [talk]  20:49, 2 June 2013 (UTC)
 * @Andy, the issue is subjective and the proposal only improves subjective issues. Im not saying fixing data granularity is subjective, buti am saying artist parameter doesnt fix whats broken, it only adds another slot to be filled in. It makes no impact on the template.


 * @Lil Unique, im not entirely sure you understand the data granularity issue. This is more relavent to the data granularity issue than the superfluous artist parameter. And isnt Andy proposal meant to use the headline less so that multiple pieces of info dont fall in the same parameter? If im wrong then please clarify.


 * A ref parameter would be fine as long as it doesnt change the parameters appearance all that much. Similar to how notes dont have a "notes" column in the tracklist.Lucia Black (talk) 21:31, 2 June 2013 (UTC)

ID3v2 Specification Version 2.4
This may be a dumb question or something that has been hashed out before, but why not just use the data fields used by The ID3v2 Specification Version 2.4? --Guy Macon (talk) 08:34, 26 May 2013 (UTC)


 * (Sound of Crickets...) --Guy Macon (talk) 00:23, 1 June 2013 (UTC)


 * I dont know why. Been watching this template for about a couple years. I don't remember this discussion ever being brought up.Lucia Black (talk) 01:13, 1 June 2013 (UTC)


 * I am not particularly interested in this (my edits are mostly in the science and engineering topics, but if someone wants to run with this, in my opinion we would do well to follow the ID3 naming conventions. Here is some info on it should someone care to pursue this:
 * http://id3.org/Home
 * http://id3.org/Introduction
 * http://id3.org/FAQ
 * http://id3.org/id3v2.4.0-structure
 * http://id3.org/id3v2.4.0-frames
 * ID3 --Guy Macon (talk) 16:44, 1 June 2013 (UTC)


 * Uh, in what context are you proposing this, and why would it be necessary? Why should ID3 be used either, as there are other standardized tagging specifications. – Mizery Made  ( talk ·  contribs ) 16:56, 1 June 2013 (UTC)


 * Standardization is not necessary, but it is desirable. I am leaving it those who are interested in the content of this page to decide whether to do anything with the above information. Apparently this has never been considered.


 * As for why I suggested ID3v2 Specification Version 2.4, it is widely used and is a good match for the kind of information that this template deals with. Of the obvious alternatives, Vorbis comments and APE tags have no structure or format, whereas ID3 is highly structured. As I said, I don't really care what you do. I just put out some info in case someone wants to grab the ball and run with it. --Guy Macon (talk) 06:46, 2 June 2013 (UTC)
 * I fail to ascertain what exactly it is you're proposing. You've just vaguely brought up ID3 with no real indication of what you're expecting to be done. Other than this template and ID3 tags both being used to store and display information pertaining to musical recordings... what relevance do they have to each other? Are you saying we should use "TIT2" as the parameter name for "Title" in the template, or... what? – Mizery Made  ( talk ·  contribs ) 19:57, 2 June 2013 (UTC)

Question
See the producers section here. A few months ago, and for as long as I could remember, if the writers line was longer than producers, the producers would center. And now they have been at the top... What is going on here? — Statυs  ( talk,  contribs ) 00:07, 14 June 2013 (UTC)
 * A change was made back in February due to inconsistency in how the cells were aligned. See here: Edit_request_on_31_January_2013 – Mizery Made  ( talk ·  contribs ) 01:08, 14 June 2013 (UTC)
 * I don't quite understand why this was changed. — Statυs  ( talk,  contribs ) 02:32, 14 June 2013 (UTC)

breaking spacings and flat list
In line with WP:ACCESS and the general movement to simplify things, one recurring issue is that track listing sometimes causes track listings to appear messy as writers overlap with the extra column, for example see here. So at Glassheart we adopted flat list. Is there a way of automatically integrating automatically? At the moment its quite messy and looks complication to include flatlist on every line of the track list template. I was thinking of perhaps trying to create a template where the mark-up would read: and would render as:
 * Standard edition (CD Catalogue #88697963782)

Would this be possible? &mdash;  Lil_ ℧ niquℇ № 1  [talk]  23:23, 19 May 2013 (UTC)

Why would we need catalogue number?Lucia Black (talk) 22:46, 1 June 2013 (UTC)
 * What does that have to do with the question? — Statυs  ( talk,  contribs ) 00:05, 14 June 2013 (UTC)

The editing style this editor chooses explains alot to how much support in a previous example. Cd catalogue isnt necessary in tracklist. Remove it from your example. Also, the spacing issue will just have to stay. To implement such an idea will need more parameters.Lucia Black (talk) 10:20, 18 June 2013 (UTC)
 * The choice to include CD catalogue numbers etc is irrelevant to the issue being discussed. Instead of digressing from the question Lucia you could have just given an opinion on whether there was a way to automatically implement non-breaking line spaces to prevent manual entry. The spacing issue is what this example is trying to address. If you are going to be rude and unhelpful please don't bother giving an opinion... I'd rather the suggestion goes unnoticed because the community thinks its not an issue than have an unhelpful comment from someone who is adverse to any kind of improvement. &mdash;  Lil_ ℧ niquℇ № 1  [talk]  22:10, 18 June 2013 (UTC)
 * Where exactly was she being rude? Walter Görlitz (talk) 22:14, 18 June 2013 (UTC)
 * I consider the entire tone plus the phrase "remove it from your example" as rude. Its not relevant to the discussion. The example above and the question is to whether or not we could create a template or modify the current one to automatically implement non-breaking spaces. If that isn't Lucia's intention then I apologize but on first reading it comes across as blunt, and unhelpful. &mdash;  Lil_ ℧ niquℇ № 1  [talk]  22:18, 18 June 2013 (UTC)
 * Rude is adding spacing when told not to.
 * Rude it telling other people they're rude.
 * Any tone you're reading into another editor's work is clearly just not assuming good faith. Walter Görlitz (talk) 00:05, 19 June 2013 (UTC)
 * With all respect, what are you on about? The spacing i haven't added, my whole proposal is about linespacing and linebreaking spaces hence for demo purposes I've manually mocked up my proposal so that its clear for others to understand. As for calling Lucia rude, that was my opinion because already as expressed at an initial glance I found the comments very blunt and hence rude. This whole proposal is about line spacing, the only part of Lucia's comment which is relevant to the discussion is "the spacing issue will just have to stay. To implement such an idea will need more parameters", as effectively this is what i was asking... "could the automatic non-breaking spaces" be integrated into the template. Lucia's other comments were not necessary. And now I feel like you've jumped on the bandwagon, firstly not understanding what's being discussed and secondly assuming misconstruing the facts. What I found rude was the bluntness and lack of engaging comments from Lucia. Something which if she/he felt I've misunderstand Lucia can bring up with myself because I've already said if that wasn't Lucia's intention I apologize - something which you've failed to acknowledge (bad faith from yourself towards me). &mdash;  Lil_ ℧ niquℇ № 1  [talk]  00:20, 19 June 2013 (UTC)


 * Let's keep this on track; I don't see the overlap in that diff; could this be related to specific browser and screen size issues? Even with a very small 1024 x 768 screen size and manually adjusting zoom and window size, I do not see the problem appear. Could you perhaps provide a Imgur screenshot or something? ChrisGualtieri (talk) 01:57, 19 June 2013 (UTC)

Whether you find it relavant to the subject, doesnt mean its not relevant at all. If you been adding CD catalogue number to any tracklist, that would be overly intricate for a tracklist, and be affecting tracklist negatively. Sometimes a topic sprouts another relevant topic. Being unt isnt being rude. Its just getting straight to the point without sugarcoating it.

Again, I know what your proposal is, but difficult to implement as it would complicate it to add more parameters. Another is that, some are referred together. And sometimes their not. If you can somehow implement this idea without adding parameters, I'm all for it.Lucia Black (talk) 03:33, 19 June 2013 (UTC)
 * For once would you please stick to the topic of discussion. I collapsed it because this was way off-topic; restarting it is not helpful. Also you are not making any sense; please clarify what you are discussing. I do not see the overlap concern and have asked for an example, like a screenshot, for verification. I doubt anything further needs to be done until an example of what exactly is occurring. ChrisGualtieri (talk) 03:47, 19 June 2013 (UTC)

Porting to over wikis
Hello,

Just out of curiosity, but is it possible to port over the data for this template and use it the same way it is used on this wiki? Thanks in advance, RomeEonBmbo (Talk) 20:38, 19 June 2013 (UTC)

Column Width
I'm having troubles to edit the witch of the column of these specified tables, I'be looked at the page for the width of tables but none help me with this specific one. - SilentDan297 20:07, 20 June 2013 (UTC) — Preceding unsigned comment added by SilentDan297 (talk • contribs)

The Composition "Somebody Else" by Mario (f/Nicki Minaj) w/remix by Chris Brown.
Kindly be advised that "Somebody Else" contains a clear sample of my original composition, "Remember The Rain?" recorded by RCA recording artists THE 21ST CENTURY (1975.) I also produced the original recording and I am original copyright owner. Further, the same track has been looped by countless hip-hop artists over the years, including Snoop Dogg ("Sisters and Brothers.) Warner-Chappell Music administers this copyright and has confirmed that clearances and all business surrounding this copyright and track are in order. However, this is not my first hit with the "new school." I've enjoyed success with Charlie Wilson's "There Goes My Baby," Trey Songz "Gotta Go" and several others. I can tell you that unlike some of my contemporaries I am literally delighted these young artists performing on "Somebody Else," their producers and record labels decided to go with the song. And it certainly gives my many grandchildren bragging rights since Chris, Nicki and Mario happen to be among their favorite recording artists. I hope this satisfies your concerns. If not please contact Dave Georgeff, Director of Sample Clearance at Warner-Chappell Music in Los Angeles. I recently received an email from him advising all is well. WARM REGARDS, MARVIN EUGENE SMITH — Preceding unsigned comment added by LASTTYCOON1952 (talk • contribs) 17:25, 25 June 2013 (UTC)
 * per iTunes I've added Marvin E. Smith to the article as a writer. However, as Mario's album has yet to be released there's no liner notes to confirm the exact sample. Unless a reliable source is found, details of the exact sample can't be added. &mdash;  Lil_ ℧ niquℇ № 1  [talk]  17:38, 25 June 2013 (UTC)

Album name + artist
There was an unresolved discussion a couple of years ago in which I said that I'd like to develop this template by including optional album name and artist table headers. It can then be made to emit the hAudio microformat (for which the Extra field is not suitable). For example, in this template's own documentation, "Greatest Hits by Queen" would be part of the template and thus within the resultant HTML table. I'd still like to do that. Any questions, or suggestions as to how best to do it? Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 09:39, 12 September 2012 (UTC)
 * Can you give an example of what you mean more specifically? To a simpleton like me with no programming/web experience its hard to picture what you envision. &mdash;  Lil_ ℧ niquℇ № 1  [talk]  21:53, 12 September 2012 (UTC)

[Restored from archives] Sorry I overlooked your reply. For example, instead of:

We would display

and instead of:

we could display:

We'd need separate parameters for artist, work and side, but they could be displayed in one line as shown; and styled as desired. By wrapping those parameters in HTML classes, we'd make them readable by computer programmes, as microformats. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 20:23, 20 February 2013 (UTC)
 * I don't see a massive need for the use of this field. Could the note field not manually be used? &mdash;  Lil_ ℧ niquℇ № 1  [talk]  17:46, 21 February 2013 (UTC)
 * Does that mean artists could be name per track inside the table? I'd like to see that, It's only natural this template will be able to manage compilations nicely, without an abuse of the extra or notes parameters. trespassers william (talk) 18:44, 26 February 2013 (UTC)
 * Isn't that already possible? It's not what this proposal is about. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 17:58, 29 March 2013 (UTC)
 * No; as explained in the previous discussion, that doesn't allow the necessary data granularity, for machine-readability. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 17:58, 29 March 2013 (UTC)
 * The need for such parameter is virtually non-existent. When would we have to cover the name of the album, artist, and side if the headline and section title dont already cover? Even then in the headline we would put "Album title (Side X)" if necessary. Overall i find this being too precise with parameters. Its like specifying different type of notes within the note parameter.Lucia Black (talk) 18:52, 29 March 2013 (UTC)
 * You say "The need for such parameter is virtually non-existent", despite the need being explained both above and in the earlier, referenced discussion. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 19:08, 29 March 2013 (UTC)

your word against mine is basically what you're saying, but your proposal doesnt solve any key issues. It just adds on to the template when there are other ways.Lucia Black (talk) 20:01, 29 March 2013 (UTC)
 * Which "other ways" would achieve the proposed data granularity and allow metadata to be emitted and gathered? Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 12:45, 1 April 2013 (UTC)
 * what data granularity? Youre making it overly inricate in an unnecessary way. The same with metadata. Youre trying to use ambiguous words to support your idea, which is quite subjective against the layout we have now. Its a tracklist, the header does not need an additional artist, or side parameter. Tracklist would go under the section of an album that mention the artist. if multiple albums in the same article, then we could add paranthesis along side the tracklists. But overall, you havent said how this is a REAL problem. Youre not fooling anyone with big words. Either be straight to the point, or stop.Lucia Black (talk) 18:36, 1 April 2013 (UTC)
 * The date granularity and metadata referred to earlier. Those terms are specific, not ambiguous, and I've been very much "straight to the point". Adding parentheses will not resolve the issue at hand. I'm not trying to "fool anyone" (an accusation that breaches WP:AGF), which Is why I have provided you with links and explanations to answer your questions. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 19:23, 1 April 2013 (UTC)
 * No youre not. You have not been specific at all. Sure the words are specific, but not the explanations. Youre most definitely not straight to the point. Not trying to foool anyone? Than elaborate further. All you saying is "add more parameters to fix meadata" but how does that fix that for HTML format? You provided 1 link, but you havents proven anything.Lucia Black (talk) 19:31, 1 April 2013 (UTC)

"not been specific at all"? I have told you:


 * [the template] can then be made to emit the hAudio microformat
 * I want to add specific fields; that way, we can apply HTML classes to them
 * the Extra field is not suitable
 * [the proposed] columns are not suitable; because they can also be used for other things, so it's impossible to determine that the data entered actually represents an artist or album name
 * I'm suggesting a one-off value in the header [not per-row columns]
 * {the proposed fields] would be part of the template and thus within the resultant HTML table
 * We'd need separate parameters for artist, work and side
 * [This is] for machine-readability
 * By wrapping those parameters in HTML classes, we'd make them readable by computer programmes, as microformats.

and provided two mocked up examples.

"1 link"? Here are the links I've provided, so far:


 * unresolved discussion
 * microformats
 * data granularity

You said "there are other ways", but have been unable to give any other way which will achieve this. You are the only editor who is preventing this improvement to the encyclopedia. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 19:53, 1 April 2013 (UTC)


 * What im saying is that the problem is non-specific. Show me an example of the issue. You only giving links to terms, but your not "illustrating the problem" you're only saying it, and we just go by your word. Theres also the issue of compilation album and soundtracks that have multiple artists, wont be good idea. This is where i see the root of the discussion:


 * [the proposed] columns are not suitable; because they can also be used for other things, so it's impossible to determine that the data entered actually represents an artist or album name


 * Thats not what the colums are for. Just used for tracklist info within the article, i dont understand how thats an issue. Its like putting a name for a table sharing the same name for the article or section in it. Please explain how this is a real issue, show me an article with HTML format that cant be readable for a reader. Also im saying there are other ways, as in lets look for alternative. Am i wrong that alternatives dont exist within the universe? If im the only one preventing this, so be it, why does that matter?Lucia Black (talk) 22:35, 1 April 2013 (UTC)


 * Let me put it this way: if we make this change,we can make every album and EP tracklist on understandable to computers; if we don't, we cannot. And yes, your objection is currently the only thing stopping us. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 00:11, 16 April 2013 (UTC)

I'm sorry but you're not being clear and this continues to sound like a subjective issue. You're not getting a real approval either.Lucia Black (talk) 00:39, 16 April 2013 (UTC)
 * Lack of understanding on your part does not mean lack of clarity on mine. You're the only person objecting; at length - you may have "talked out" other interested parties. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 15:56, 1 May 2013 (UTC)

Correct me if I'm wrong, Andy, but what you're asking for is the addition of two more optional fields: 'Album title' and 'Artist' - is that correct? If present, those fields would display in-line with the current 'Headline' field? The advantage is then that the entire table becomes self-contained (because all the information is inside it) and is able to be re-used more easily? In addition, you could then (invisibly) add classes throughout the template which makes it compatible with automatic readers of the hAudio microformat - which allows third parties to gather information from us in a standardised format (and obviously works best if title and artist are present)?

Sorry if I'm being a bit slow, but if I've understood your request accurately, then it might also help Lucia Black to understand what you're asking for. I can see it's not a big deal for most folks, but it does seem to me to be a step forward, so it's worth drawing out the details to get consensus on an implementation. Cheers --RexxS (talk) 19:04, 1 May 2013 (UTC)


 * i. Don't necessarily believe adding these two parameters will automatically help editors using hAudio microformat. Its like trying to push all ifno into a tracklist table. Especially since this won't cover all albums. And yes, lack of clarity. How does this affect "readers"? And is this "improvement" will hav to rework all the other articles with this template. It just doesn't seem worth it. And yes, you continue to lack clarity.Lucia Black (talk) 19:39, 1 May 2013 (UTC)
 * The hAudio microformat uses title and artist fields to specify the title and artist of the work. Those are rather essential pieces of information, despite what you may believe.
 * We would be doing it for some of the readers, not the editors. We are writing our online encyclopedia for readers, not editors.
 * It is "like trying to push" all of the relevant information into the tracklist table. Were you trying to say that missing out the title and artist is a good thing?
 * You seem to think that supplying title and artist won't "cover all albums". Would you like to suggest some examples so that we can see what the extent of the problem is?
 * The "readers" would be able to re-use our table in its entirety without having to add in other pieces of information just to make sense.
 * The "readers" would be able to make use of automatic tools to extract the information in a standardised format.
 * The "improvement" would allow "readers" to be able to do things that they can't do now. That is what makes it an "improvement".
 * The "improvement" does not rely on you having to rework anything, so don't worry. This is a collaborative project and those who want to add title and artist would be able to do so; at present they can't make the "improvement".
 * I'm sorry that you don't find it worth it. Nevertheless, it is worth it because (1) the "improvement" would allow "readers" to be able to make more use of our content, and (2) you don't have to do it.
 * Is that clear enough for you? --RexxS (talk) 23:38, 1 May 2013 (UTC)

I'm saying that tracklist is complimentary table to the article. Its like making the article about the tracklist rather than the tracklist being part of the article. Also we have compilation albums, and articles that cover multiple albums. Isn't that why each track has a writer/music/lyrics parameter? Asking me if I consider not adding an artist/title parameter a good thing is like asking if I consider not having redundancy in the article a good thing.

Also I don't understand how this would allow others to use this. How does not adding a title/artist parameter affect not using the same template? A simple copy-paste won't work? Or are you referring to somewhere outside of Wikipedia? Or does it just make it "easier"? This is an "editor" issue, not a "reader" issue.Lucia Black (talk) 00:06, 2 May 2013 (UTC)


 * I've been following this discussion for a while, and I find RexxS's explanation to be clear; it makes sense. I'm throwing in my support for making this change. It doesn't seem like it will be a problem for the average editor; at most an editor might choose to include information for a couple more fields. This does not seem like an unreasonable burden on editors, and it's not mandatory; if someone chooses not to enter that information, so be it. Someone else can enter it later. MrMoustacheMM (talk) 05:22, 2 May 2013 (UTC)

I don't think you all do. He initially stated to remove headline/extra parameter because "computers can't understand it". I don't approve for a new artist/title parameter when we already have a headline parameter just for the sake of computers knowing what we're putting. Not only that but no one seems to actually mention any "true" benefits to the reader. You're all elaborating this idea to your own understanding. Each one giving me a different idea. The original poster is merely giving me that "computers will understand" and claims that was as clear as he can be. Now I'm gettting that this also helps re-use the same template (what?) From another editor.

Again, no one has yet to mention the issues of redundancy. Example: Article title "X (album)" and the opening post mentions the artist already. So the template would show "X by Artist" is that really necessary? What's next? A Disc/side parameter?

This "optional" thing still affects the tracklist at a significant way. We will be seeing "redundancy" within the template. HOWEVER the "artist" template would be great if it replaced "All writer" parameter. Same with Lyrics and Music. But other than that, adding two additional parameters somehow fix this "computers understanding the template".

We should only keep the necessity. "Optional" parameters for the sake of somewhat easier for "editors".Lucia Black (talk) 05:49, 2 May 2013 (UTC)


 * We really do need to get away from thinking that we are building an encyclopedia for the editors. We are doing this clearly and unarguably for the benefit of the readers. That includes folks reading our webpages using normal browsers, smart phones or screen-readers. It also includes sites that mirror our content, or data-mine it like Google, or translate it into their own language because they don't have a developed local Wikipedia. Why shouldn't those users just lift the table ("template" is just what creates the table) and use it however it suits them best? Well, at present, the table doesn't tell you either the artist(s) name(s) or the title of the work and I find it very hard to understand why anyone would invest so much energy to prevent them from having quick and immediate access to that information by putting it in the table. Not only that, but if the title and artist were marked up with ... and ... respectively, then a standard microformat can be created allowing our information to be read automatically by the thousands of third-parties who use our site as a source. We could build that inside the template, so editors don't have to worry about html, but it needs separate 'artist' and 'title'. That's why we don't want to just cram 3 different pieces of information into the headline parameter and then have to manually apply the classes around each part. The two extra items of data could still be displayed just before the 'headline' - and I'm pretty sure I've never suggested removing the headline parameter (which would still default to "Track listing", but can also be used for "Side one", etc.)
 * Redundancy isn't the bad thing you make it out to be. When we write the lead of Golden Brown, we summarise the content of the rest of the article by repeating the artist and the major release dates, as well as the label and the album it was taken from - that's redundancy and it's useful. As the article is developed the lead will grow in size, but it will always create redundancy to give readers a chance to read an overview of the topic. When we add an infobox to Golden Brown we repeat that information again in a very condensed format to let readers grab key facts "at-a-glance" - that's also redundancy and it's also useful. We have no shortage of electrons (or storage space on the servers), so there's no imperative to cut everything down to the bare bones. We serve different audiences with different approaches and it involves duplication, but there's very little cost to that compared to the benefit of meeting the diverse needs of a diverse group of users. --RexxS (talk) 00:40, 3 May 2013 (UTC)
 * The assertion that "He initially stated to remove headline/extra parameter because 'computers can't understand it'" is false. If you disagree, please cite a diff. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 10:29, 3 May 2013 (UTC)
 * No such diff has been provided. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 12:31, 13 May 2013 (UTC)

The Lead opening post is suppose to summarize the article. So obviously not a good example. And of course infobox may repeat that exact same info for those who want just the basics. Regardless that doesn't justify a third tier of redundancy. For the record, these templates work fine in a smartphone (a bit cramp, but no irregularities). Also no one has actually took a snapshot of what the problem actually looks like for other webpages for readers.

You see, if we have a headline (meant for title and side/disc #), then we add a title parameter, and an arrtist parameter (again, no one seems to answer the gritty issues of this). We might aswell rename "headline" to "Disc" parameter and maybe disc and side parameter shouldn't go together the same way Headline can't have title, and artist. So eventually maybe both disc and side parameters too.

Then we have compilation albums that don't share the same artist for each track. How will this "artist" parameter work? This isn't "necessary" for readers. This is just to satisfy third party to use the template too. The idea of helping those third parties seems optional but in reality to get to it, things will have to be reworked. Let's not forget the one who started this thread also wants to axe the "extra" column.

But it all goes down to: "why help these mirror wiki sites?".Lucia Black (talk) 01:22, 3 May 2013 (UTC)
 * Yes, I already said the lead summarises the article, please try to read what's written. On the contrary, it is a very good example of what we call redundancy. We do it with information all of the time and you are completely wrong to think there is any inherent problem with it.
 * What you need to see is that there aren't any "gritty issues" with having a template containing an artist and title parameter. You really need to make some attempt to engage in explaining these "issues" that you are imagining. And no, we may as well not start renaming parameters; there is absolutely no need whatsoever to create loads of extra work expecting people to fix all the articles that contain this template by having to rename a parameter for no reason at all. The headline works well now for things like "Track listing" or "Side one" and it will work just as well after we've added artist and title . Why on earth would you even think of changing it to something else? If you want to add disc and side parameters, go ahead and make your suggestion in a separate section, but don't construct strawman arguments so that you can object to something that isn't even proposed.
 * Do you think that nobody has ever considered the problem of compilation albums before? Just look above: Andy even supplied an example of a compilation album, Picnic – A Breath of Fresh Air and it simply doesn't need to have 'artist' filled in, although an editor could just as easily employ the usual convention of using "Various" or "Various artists". When the option exists, people can make use of it. You, personally, need never fill in an artist or title field if you didn't want to. I still can't understand why you want to prevent those who want that choice from having it.
 * I reject entirely your assertion that you get to decide that we should only write for what you call "readers", and not for other users of our content. You don't need to rework anything - and if you take the trouble to look above, you can see how little the appearance changes. Axing an extra column? Strawman again.
 * As for "why help the mirror sites"? (and all the other re-users as well)? Because we can. Because it's our mission to create a world where the whole sum of human knowledge is freely accessible to every person on the planet - and helping spread our knowledge via re-users helps that mission.
 * What it actually all goes down to is this:


 * You need to be lending a hand. --RexxS (talk) 02:24, 3 May 2013 (UTC)

Does anyone other than Lucia Black object to this change? Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 16:12, 10 May 2013 (UTC)


 * Can you provide a good reason for why we need an artist parameter? I can only support 70% of it.Lucia Black (talk) 16:23, 10 May 2013 (UTC)
 * Yes; and I have done, above and in earlier discussions. My question was "Does anyone other than Lucia Black object to this change?". Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 12:31, 13 May 2013 (UTC)
 * I've read through the conversation several times and can't see either a clear need for or against the additional parameter. Can't the artist name etc be manually typed in the current | headline = field? I'm confused as to why we need an additional parameter than ultimately places the new information on the same line as the headline? &mdash;  Lil_ ℧ niquℇ № 1  [talk]  13:44, 13 May 2013 (UTC)
 * As I said above, in reply to your questions: "We'd need separate parameters for artist, work and side... By wrapping those parameters in HTML classes, we'd make them readable by computer programmes, as microformats" and "as explained in the previous discussion, [using the existing fields] doesn't allow the necessary data granularity, for machine-readability". Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 15:09, 13 May 2013 (UTC)
 * Apologies. I wanted to check as I wasn't sure what the issue was and I didnt want to give an ignorant POV. I've re-read the discussion and if data granularity is the issue then I support the addition of the new parameter. It does not cause an issue if you choose not to use the parameter nor does it particularly impact upon the template mark-up much. Not sure upon what grounds its being rejected tbh. &mdash;  Lil_ ℧ niquℇ № 1  [talk]  15:30, 13 May 2013 (UTC)

Because i dont get swept.up by vague comments. The question is "how". The goal is to remove the ambiguois headline parameter by adding additional parameters we would normally add in. Such as title (when multiple albums have different names and are in the same section, and disc and side aswell.) But the artist does not provide that, it does not help computers understand because its not necessary to add in the tracklist. In fact it looks odd having that particular parameter for being overly redundant. And the problem is that why give the option to make a tracklist look ugly and redundant? Andy continues to be vague, and he continues to stay that way so others can find their own interpretation and not see the flaw in his proposal. Thats why RexxS stopped, thats why MoustageMM stopped. Lucia Black (talk) 20:18, 13 May 2013 (UTC)

Oh dear. You may not get swept up by vague comments, but you seem to have been swept up by false assumptions:


 * "The goal is to remove the ambiguois headline parameter" - Nowhere has this been proposed.
 * "the artist does not provide that" - Nor is it claimed or proposed that it would do so.

As to "why RexxS and MoustageMM stopped [sic]", I'll let them speak for themselves. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 21:04, 13 May 2013 (UTC)

Thats it. This is poinless. Im bringing it to dispute resolution. Youve avoided clarification long enough.Lucia Black (talk) 21:32, 13 May 2013 (UTC)


 * "thats why MoustageMM stopped" Please do not presume to speak for me. (Also, please learn how to read/spell, you weren't even close on my name). I have made my support for this addition clear. I have mostly stopped replying because I said everything that needed to be said, and did not feel that arguing with you would be productive. You refuse to read (or perhaps you simply don't understand) the points made by various editors above, and it seems that any attempt to help you understand is rebuffed; you simply don't want this change to be made, and refuse to change your position. Oh, and I've understood what Andy has written, and RexxS's explanation further clarified his position. I haven't seen any "vague"-ness here. MrMoustacheMM (talk) 22:52, 13 May 2013 (UTC)

Compromise
A disc, a side, and a Title parameter, but no "Artist" parameter as we already have the "All writer" parameter. RexxS, read the first two posts of the one who started this thread.Lucia Black (talk) 05:47, 3 May 2013 (UTC)

Also, "title" parameter would be used mainly if multiple tracklist are within the same article/section.Lucia Black (talk) 08:30, 3 May 2013 (UTC)
 * Please explain how your proposed solution will supply an artist-name to the hAudio microformat? Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 10:33, 3 May 2013 (UTC)
 * There's already a "all writers" parameter. We also have individual writer, music, lyrics parameteer for each track. Also the "Artist" parameter won't be useful as there are compilation albums that were not all composed by the same person. Its not necessary for hAudio to cover it because not even the normal tracklist covers it. Its an additional aspect. If people want to read the tracklist and somehow skip it all, maybe, but tracklist is part of the article, not the other way around. Please explain why artist is necessary to cover hAudio format within an article that already mentions the artist (probably twice if infobox is used).Lucia Black (talk) 15:30, 3 May 2013 (UTC)
 * Thank you for your lengthy reply. Unfortunately, though I asked you to "explain how your proposed solution will supply an artist-name to the hAudio microformat", you have not done so. Please do. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 19:24, 3 May 2013 (UTC)
 * We don't, that's part of the compromise.Lucia Black (talk) 20:42, 3 May 2013 (UTC)
 * Thank you for the clarification. Please now explain why you think it would not be useful to pass the artist name with the hAudio microformat, for albums by one artist. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 21:15, 3 May 2013 (UTC)

The same reason we never added them in the first place, overly redundant and that's what "all writers"parameter is for. And it seems you recognize the "artist" parameter isn't a universal parameter for all albums. That's also why title parameter would be necessary when multiple tracks are lumped together "special, extended, limited editions" with varying track lists). If you want this, we should keep the bare necessities.Lucia Black (talk) 22:17, 3 May 2013 (UTC)
 * All_writing doesn't help if the songs were written by a specific member. If John Doe of The Musicians Band wrote all the songs, that doesn't export "The Musicians Band", it exports "John Doe".
 * For albums that don't contain a single artist (ie compilations), the parameter can be left blank. But instead of focusing on corner cases, look at the overall use of the template. Most albums have one single artist, and this would be useful information to extract from the template. MrMoustacheMM (talk) 22:22, 3 May 2013 (UTC)
 * I am, its unnecessary and there's no real benefit to hAudio. Its not necessary and this makes this template resemble an infobox. Example: List of Episodes table template don't have at the top "TV series by "creator". Its redundant. Single artist albums would have the opening post, and the infobox to mention the artist, why repeat it thrice?Lucia Black (talk) 22:35, 3 May 2013 (UTC)
 * What "opening post"? Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 22:59, 4 May 2013 (UTC)
 * Your argument for not passing the artist name with the hAudio microformat for albums by one artist is that it would be redundant? Redundant to what? all_writers is not suitable for passing to the hAudio microformat, as others have explained. Yes, I recognise the "artist" parameter isn't a universal parameter for all albums; I have never claimed otherwise and that negates one of the points I have made. I am unsure why you consider that statement relevant. Since I asked about "albums by one artist", your comments about compilations appear to be red herrings. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 21:57, 4 May 2013 (UTC)
 * The "need" for an "artist" parameter is non existent. Explain (in detail) how the artist parameter is necessary for readability in hAudio. Wasn't the point to avoid parameters that computers can't understand? If I understood you correctly, axing the Headline and replace with Title, disc, side parameters so all three won't be jumbled up into one ambiguous parameter? So then why a single "artist" parameter above the tracklist as part of the headline if artist was never really necessary even now in regular format? It doesn't add up to your previous argument because this is an "additional" parameter compared to the rest.Lucia Black (talk) 22:02, 4 May 2013 (UTC)
 * My question was "Redundant to what?". You appear to have neglected to answer it. Please do. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 22:19, 4 May 2013 (UTC)
 * Yes, I did answer that. It would be redundant to the article info. The opening paragraph mentions the "artist" and even the infobox aswell. If tracklist had neither opening paragraph nor infobox to state the artist, then of course an artist parameter would be ideal. But stop trying to control the discussion. I've answered your questions (even if they weren't directed towards you), you have not answered mine.Lucia Black (talk) 22:37, 4 May 2013 (UTC)
 * My question was not about article content. It was about your allegation of redundancy in the context of the usefulness of "passing the artist name with the hAudio microformat for albums by one artist". You have yet to address that point. Please do; and please refrain from making bogus accusations that I am "trying to control the discussion". Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 22:55, 4 May 2013 (UTC)
 * Rereading, and don't see any of my comments having that exact wording. Maybe you didn't understand the "allegation". The redundancy is related to the article's content as the template falls in the article. Plus not necessary to understand tracklist even for computers.Lucia Black (talk) 23:07, 4 May 2013 (UTC)
 * I asked "Please now explain why you think it would not be useful to pass the artist name with the hAudio microformat, for albums by one artist". You answered "The same reason we never added them in the first place, overly redundant...". If that's not what you meant, please now explain why you think it would not be useful to pass the artist name with the hAudio microformat, for albums by one artist. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 23:16, 4 May 2013 (UTC)

I don't get you, now you quote me accurately, but don't elaborate on the issue. Instead you divert by asking "if that's not what you meant...". I say its overly redundant and the redundancy is related to article content. The template is complimentary to the article, not a stand-alone template. Not that difficult to understand.Lucia Black (talk) 23:24, 4 May 2013 (UTC)
 * I can see the problem now. You think the template should never stand alone. I assure you that when our content is re-used, lots of people will use it on its own, so why not help them out by supplying all the information so that they can use it that way if they want to? What does it cost us? --RexxS (talk) 01:05, 5 May 2013 (UTC)
 * Redundancy and unnecessary is the cost for wikipedia. I assure you, no one is going to add the tracklist template on its own. Why not release date? Catalog #? Type of disc? Vinyl LP, compact disc, Hd CD?
 * No one is going to add a tracklist by itself. And by itself, literally an empty page with only the tracklist. Come on, be practical.Lucia Black (talk) 01:13, 5 May 2013 (UTC)
 * This is a fair compromise. Wikipedia shouldn't cater to those who wish to re-use our content even then, no one is being realistic about it. No one is going to add artist onto their tracklist even outside of wikipedia. Andy Mabbett continues to evade the question of why its necessary at all for hAudio microformat. And I feel you play devil's advocate too much because it didn't seem you understood the so-called "problem" which is parameters can be used by multiple aspects "headline" and "extra". So it was confusing when you supported "title" and "artist" but didn't follow the goal of the proposal by leaving "side" and "disc" into the same parameter "headline".
 * But even then, I support as long as it doesn't affect wikipedia's set up. And the only parameter that does is the superfluous "artist" parameter. The "title" parameter would be used if multiple tracklist are in the same section (by different title or different disc).Lucia Black (talk) 20:10, 5 May 2013 (UTC)
 * Wikipedia has more server space than you could use in a hundred lifetimes of writing, so please don't worry about the cost of redundancy. I assure you lots of re-users will use the track listing on its own. You really need to free yourself from your preconceived notions that re-users are simply copying our format as well as our content. A re-user may be compiling a catalogue of albums and their track listings (rather than collecting complete encyclopedia articles). Wikipedia is an excellent source for that, but a track listing that is missing the album title is pretty useless - and it seems crazy not to give the artists for the majority of albums that are not compilations. That's why those two parameters are necessary. --RexxS (talk) 00:10, 14 May 2013 (UTC)

You provide nothing but empty claims. Stop worrying about other people who want to use wikipedia's template. Why would a tracklist.template be useless without an artist template? The redundancy issue has nothing to do with servers but readability. The artist and title info are basically info expressed in prose. The only reason why title is necessary because multiple tracklist in the same article would have different names. But thats the only reason why. If there is only one tracklist, then a title parameter would be ridiculous to add as it makes it redundant. Pointing out the obvious for no reason. Even more redundant to add artist. And you jut proved my point, this artist parameter wont fit with compilation album or albums with no specific artist/producer. So how can you call it "crazy" not to add them if this only covers single artist albums? again, i say, be practical.Lucia Black (talk) 00:51, 14 May 2013 (UTC)
 * Don't be so rude and don't tell me what I need to be concerned about. What on earth are you talking about a tracklist.template be.useless without an artist template? Nobody's said that the tracklist template is useless without an artist template. On the other hand, a tracklist is clearly useless without the name of the work. Here are the microformats that we should be providing to our re-users (in some order):


 * or


 * In the second example you can see quite clearly how we would handle empty artist fields. At this point, your refusal to listen to explanations is becoming disruptive and I am no longer prepared to assume good faith in your comments here, particularly after you have attempted to spill this debate onto my talk page. This is the place for discussion of this template, not elsewhere. I'm prepared to explain a few times in order to seek consensus, but a single irrational voice cannot be taken to block consensus without providing coherent reasoning. --RexxS (talk) 01:41, 14 May 2013 (UTC)


 * you have yet to explain how an artist parameter is necessary at all. Irrational? Is it irrational to not want a completely unnecessary, and superfluous parameter that provides little to no benefits (both in wikipedia and out) and only offers redundancy.Title is necessary more in wikipedia than out, but artist is unnecessary and no one here has proven how its necessary. You only provide subjective ideas. Html and haudio will work fine without that parameter. The template outside of wikipedia such as mora music store and itune store dont even have universal artist parameter because having a tracklist both outside wikipedia and in are complimentary info to the page. That means title, artist, release date, catalog number, etc will be separate from tracklist. And thats how it should be.Lucia Black (talk) 02:32, 14 May 2013 (UTC)

Consensus
So is there consensus here to make this change yet? Only one editor disagrees, and they have not provided any good reasons for their position, just "I don't want it there, it's redundant" (which as explained above, is not a good reason for opposing a change, as many areas of Wikipedia show redundancy that we nonetheless include, leads and infoboxes being good examples), and "not every single article will use the artist parameter" (which can be answered simply: do not use the parameter on those articles). Consensus doesn't require 100% agreement from all editors, just that the reasons made for the change are reasonable and helpful to the project. Does anyone have any good reasons against this change? Please make sure you cite policy when giving these reasons against the change. MrMoustacheMM (talk) 23:00, 13 May 2013 (UTC)
 * Why offer a completely optional, completely unnecessary parameter, and not been proven to help HTML and hAudio format that offers nothing but redundncy? I provide a.clear reason why we shouldnt. You all spit out the same thing but never elaborate. No one provided a good reason why the artist parameter is necessary. No other tracklist in wikipedia or even outside of wikipedia adds general artist. Not to mention the continuous dodging of not all albums have one universal artist/producer. I can understand title, disc, and even side but artist is pushing a combination of tracklist and info box. No one here provided a good reason at al, Andy continues to dodge questions, RexxS is more worried about things outside of wikipedia, and you go along with it.Lucia Black (talk) 23:18, 13 May 2013 (UTC)
 * Just to be clear, we are writing this encyclopedia for everybody on this planet, and that does indeed include lots of people outside of Wikipedia. So yes, I do worry about them as well. I support adding the two extra fields for artist and title of the work, while retaining the headline field to do precisely the job it does now. I don't think there's any value in restating what I've already said above, and that's the principle reason I've not added anything else to this debate. --RexxS (talk) 00:10, 14 May 2013 (UTC)
 * Because i already countered your points. You literally have nothing left to say that can.actually help your supposed cause. the goal is to make a universal encyclopedia for everyone. not to cater to them so that they can use our templates. Not to mention other sites use other templates.that can be used. Both of.you have this "hear-say" attitude.Lucia Black (talk) 00:17, 14 May 2013 (UTC)
 * Keep your commentary on the issues, not on the editors. Our goal is far wider than writing an encyclopedia - it is to provide every person with the sum of human knowledge, and the more partners we use to spread our content, the closer that goal becomes. --RexxS (talk) 01:48, 14 May 2013 (UTC)
 * Please keep your personal ideas of wikipedia to yourself. Their not worth anything in this discussion. Also part of the issue is having multiple reasons. Lets not forget i support the other parameters.proposed except artist for the reason that its not a necessary one for the opening post's goal for computers understanding what info we put.Lucia Black (talk) 02:44, 14 May 2013 (UTC)
 * This is getting way too personal. I don't think Lucia understands the reason as to why we're proposing the new parameter. Instead of arguing in circles, we should hold a poll to vote on supporting or opposing the changes. Tbh I don't understand Lucia's issue cause if he/she chooses, they can ignore the new parameter. its just an option for editors. &mdash;  Lil_ ℧ niquℇ № 1  [talk]  09:20, 19 May 2013 (UTC)
 * We don't need a poll; with only one person objecting, we have consensus. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 15:51, 19 May 2013 (UTC)
 * Good! Whoever implements it, please let us know when these changes are finished and ready to go. MrMoustacheMM (talk) 17:42, 20 May 2013 (UTC)

How does the artist parameter help with data granulairty? Youve all dodge the key questions at hand. And you will continue to dodge them. For one, no one here denies that this parameter wont be helpfull for all types of tracklist for albums that arent all by a single artist or by no artist at all. Also its a nuesance in wikipedia and unhelpful period. If its an option, then i willl look for all tracklists and REMOVE it if its that optional for reasons of unnecessary redundancy in an article. Every1 here has their own personal view on this. Instead of making it perfectly clear, you.all dodge the question. Andy claims to have answered. my question but i reread it dozens of times and has not. RexxS is more concerned for people using our template outside of Wikipedia. And even then hes being unrealistic about it because he makes it seem like others outside of wikipedia need a single artist paraeter integrated into the tracklist. But if wikipedia doesnt need it, what makes it necessady outside? Can we also keep our reasons to benefitting wikipedia more than mirror sites?

No one here has explained how adding an artist parameter will help with data granularity. So heres my final question, if not answered, i will bring this to admin. I dont want to oppose something i dont understand, but rereading it all and the other articles, no one here made it clear enough why this particular parameter is important for data granularity. This shouldnt be a poll, my issues are for readabiloty and holding only key info within a track list, a tracklist that is complimentary info to the article, similar to a list of episodes and a list of chapters. The title parameter may be helpful for data granularity, as for disc and side parameters, all with it serving as a replacement for headline. Those parameters would be helpful in wikipedia becauae they are ones we will be using judging by what we add in headline parameter. However, artist provides no benefit whatsoever, its one we never added in tracklist and we shouldnt. Adding an artist parameter provides no real benefit even for Andy's cause. Youve all dodge this issue.Lucia Black (talk) 16:39, 19 May 2013 (UTC)


 * Excuse me, I hate to interrupt here, but if you don't know what you are opposing or why, why oppose at all? You are threatening to get an 'admin' involved when you do not understand the underlying concept. No one is required to educate you to your satisfaction on a topic you do not or refuse to understand, and your ignorance of what you are opposing is self-declared. It is disruptive to strong arm editors into 'compromise' to get your way. A fact that is made all the worse when you do not understand why you are opposing. ChrisGualtieri (talk) 13:46, 20 May 2013 (UTC)
 * That is a responce to them claiming i dont know what im opposing. But what i dont know is something they are hiding. i know about data granularity, and i support it, however this artist parameter does not add data granularity in the sense that it fixes the template, it only adds data granularity as if it were an extra parameter. But this parameter isnt suited for track list because tracklists are all complimentary info of the related media such as list of episodes of a Tv series or list of chapters in a manga. if their hiding a real reason why they desperately want a superfluous parameter with no benefit at all, they better say it. they avoided to answer why. RexxS is more about having this template be usable to people outside of wikipedia and believes those will need that parameter, but if wikipedia does not need it, why would other sites need them? Hes not even thinking of data granularity because he still argues side and disc info can still be in the same headline parameter. lil unique also fights for data granularity as for andy mabbett but none of them made a good compelling reason (or any reason at all) as for why artist parameter would be needed for data granularity. it only adds redundancy where.prose and infobox would already cover artist, the template is suppose to cover what cant be covered in prose. title, side, and disc are available for easy navigation if multiple tracklist are in the same section. lets say album X came with mini album Y, it would be relevant to add the title to distinguish tracklist. side and disc help distinguish between sides and disc. But artist doesnt help with distinguish between tracklist.Lucia Black (talk) 20:16, 20 May 2013 (UTC)
 * in all honesty I think its time you seriously considered dropping the stick, and letting go &mdash;  Lil_ ℧ niquℇ № 1  [talk]  21:44, 20 May 2013 (UTC)

Nope. not until you give a reason why we need an artist parameter. the more i fight this, the more its obviois you avoid answering key issues.Lucia Black (talk) 22:01, 20 May 2013 (UTC)
 * As the only person in opposition it looks like this change will go ahead per WP:CONSENSUS. There's a detailed explanation above. If you cannot understand the explanation that's a shame but so far you've not provided viable opposition for a reason as to why it shouldn't go ahead. &mdash;  Lil_ ℧ niquℇ № 1  [talk]  22:12, 20 May 2013 (UTC)

Explanation doesnt answer my question. this question is being made after the compromise i proposed and im asking this to you and andy specifically. its completely fair compromise. if its not, .tleast say why. the one who proposed this, still gets 80% of what he proposed. title, disc, side are relevant to data granularity because those are the ones being used within headline parameter. Artist parameter provides no real benefit. this isnt a democracy. i provided clear reasons why im opposed to the artist parameter specifically.

Come on, is it so hard to answer a simple question? its like removing information and the answer you get is because of NPOV. and when you ask a specific question like "how does NPOV apply here?" instead of actually answering it, you already claimed they did. This is whats happening here, the explanation isnt answering my question. My previous question was why should we care about data granularity, but at this point the compromise is to allow it but not affect template anymore than it needs to.

When will we ever "need" to use the artist parameter? What benefit does it even offer if it doesnt fix data granularity issues?. Why avoid these questions? Its common courtesy to answer relevant questions. if your avoiding to answer simple yet relevant questions, then this isnt really for wikipedia's benefit but your own personal gain. and if im wrong about that, then answer the relevant questions. Is it so hard?Lucia Black (talk) 22:33, 20 May 2013 (UTC)

Support Add me into the consensus here, even reading the arguments the intended use is logical and makes sense. If you don't want to use it, don't use it. We are building an encyclopedia, the 'redundancy' argument is off base. Lucia doesn't seem to understand "data granularity" anymore then "in a nutshell" or other Wikipedia policies. I'm sure the template will be useful like so many other infoboxes have been. I may not need or use half the suggestions for the company infobox, but having them present for inclusion or even present on the master helps keep it standard and clean. Knowing your options is never a bad thing. ChrisGualtieri (talk) 23:43, 20 May 2013 (UTC)
 * Chris youre wikistalking me, and barely read the discussion. claiming it is logical, but then claim redundancy is off base without even clarifying. youre all bark, with no reason to leave a bite mark. This has more to about options, it has to do if we wil ever need them in the tracklist at all? Do list of chapters add title of the entire manga series and author? Do list of episodes add a universal creator onto their templates? No they do not because its redundant, most articles cover that info in the prose the reasons for the parameters are for data granularity so that computers can understand it (an incredibly subjective issue). The "optional" is to use these parameters to fix data granularity. but the artist parameter does not fix anything, its only additional. Also you said infobox, this isnt an infobox, its a tracklist. are youu sure you read this? I know what granularity is. theres an article on it.Lucia Black (talk) 00:00, 21 May 2013 (UTC)
 * WP:CIVIL/WP:NPA (I also indented you for clarity) ChrisGualtieri (talk) 02:19, 21 May 2013 (UTC)
 * WP:BOOMERANG. Wow. you all really dont want to answer such a simple yet relevant question.Lucia Black (talk) 02:38, 21 May 2013 (UTC)

my reasons for opposing are based out unnecessary, and not being beneficial at all to wikipedia, in fact only adds redundancy. The prose will cover the artist and so will the infobox, and recording/development info (if any) will constantly mention who the artist is. So why add an option that only serves for unnecessary redundancy? What true benefit what will we gain? Is options for the sake of options???? I'm asking a consensus-changing question. Why would we ever need an artist parameter? All parameters included are because we will need them. The option to use title, side and disc parameters instead of Headline parameter is beneficial for data granularity without actually changing the template, but the artist parmeter doesnt help distinguish between album/side/disc. its completely ADDITIONAL and the only thing it offers is redundancy. So why would i support an optional parameter that doesnt even help the very thing you support which is data granularity, and only provides redundancy if used. You still dont answer how we can use this parameter for compilation albums, instead you all switch to saying this parameter be used only for single artist albums. The level of nessecity is way low to even fight for such a thing.

Whats wrong with the compromise? You still get title, you still get disc, you still get side parameters. all that are necessary to make a readable and distinguoshable template if multiple albums, side, and disc are in the same section/article. Artist parameter provides no real benefit. How is this not even being addressed? Youve dodge literally everything. Andy then asks me how artist parameter be implemented which i said they wont and refuses to answer mine. Why push for something so utterly useless?Lucia Black (talk) 07:02, 21 May 2013 (UTC)


 * I think the issue is how easy the code is to parse by machine, not how easy it is to look at by a human. Walter Görlitz (talk) 13:37, 21 May 2013 (UTC)
 * But what does that have to do with the ADDITIONAL artist parameter compared to the title/side/disc parameter? if data granularity is just to organize/subdivide information into their respected parameters, why would we need to "add" this parameter that we dont need because we never added that info? i know this is about machine related issue, but no one has.proven how this particular parameter is needed for their cause.
 * Hypothetically, lets say there's a template about ...idk....uhm....pizza. And instead it has a headline parameter where name of the pizza, number of toppings, and type of pizza are all rolled in it. And lets say Andy Mabbet wants to make a number of toppings, type, and title parameter for granularity. However he then adds a original creator parameter. The rest were needed because those were used in athe headline parameter, but the original creator isnt because we dont use that info to even have a parameter for it. you get me?


 * Same here, the artist parameter doesnt help their cause one bit. However im on board for the rest of the other parameters.Lucia Black (talk) 17:43, 21 May 2013 (UTC)


 * Again, I don't know, but I'll venture that with compilation discs, there are not sufficient parameters to represent, in machine-readable form, all of the key information such as original recording artist, original label, original producer(s), original catalogue number, original year of release, original recording medium. At this point, I'm executing a reductio ad absurdum argument since I don't necessarily agree with adding this parameter, I am simply stating what is understood by one party and possibly missing by another. I would sooner see a new template for compilation discs that allows additional parameters rather than run into problems with this general template.
 * So in your pizza example, which in and of itself is bad, it's not necessary. However, if each of the 12 slices in the box were created by a different pizzeria, and each slice's title would have to indicate the variety, then the number of toppings, then the pizzeria. If we use the extra heading here, you can't indicate the variety of crust (thin, thick, whole wheat, gluten-free, deep dish, cheese in the crust, etc.). We do get the "original creator" or pizzeria parameter on normal pizzas since the template is usually used on an article about the pizzeria (original creator) so it's already present at that level. Walter Görlitz (talk) 19:32, 21 May 2013 (UTC)
 * Thats one issue im not targeting. im merely targeting between unnecessary parameter that provides no data granularity. The tracklist is merely meant to have specific info of track. The key is to list specific info of each track. but the artist parameter is unnecessary because we will never use it in a situation where it wouldnt be redundant. the artist parameter is about having an artist of the album in the same place where the headline would be. So its like you said, that info is already present in prose so unnecessary to add the same parameters.


 * Im only against the artist parameter.Lucia Black (talk) 20:31, 21 May 2013 (UTC)

Granularity
I've tried not to get dragged onto this farce any further; but for the sake of newcomers: it is not claimed that we should include the artist name "for data granularity", but to enhance the usefulness of the emitted metadata. Granularity only arose in response to a question of whether the existing note could be used to emit the artist name. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 21:04, 21 May 2013 (UTC)
 * But you havent exactly establish how much this woud benefit? The key issue is "if its not broken, dont change it." You only says it enhances metadata. but by how much? This parameter is more of a nuisance. It seems like any little enhamcement is enough but you forget the fact that its a nuisance in regular format. This is still incredibly subjective. I'm stikl 80% onboard.Lucia Black (talk) 21:29, 21 May 2013 (UTC)

Implementation
Noting that the consensus here has also been recognised by uninvolved editors, I have added the three new parameters to the sandbox. Examples of them with and without the current headline parameter may be seen at Template:Track listing/testcases.

Please note that I haven't yet added microformat markup; I'm just trying first to get the visual presentation right. Are folk happy with them as they are, or should we use commas, or suchlike, as separators? Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 07:10, 26 May 2013 (UTC)
 * There was a consensus? I didn't see that happen. Please explain. The changes don't appear to be an improvement. Walter Görlitz (talk) 07:53, 26 May 2013 (UTC)
 * Your supposition (in edit summary) that I made that decision is false. The explanation is above. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 08:14, 26 May 2013 (UTC)
 * I am totally uninvolved as far as this content dispute goes (I really don't care one way or the other about track listings) but I am concerned about statements like "the consensus here has also been recognised by uninvolved editors" with links to WP:ANI. That's completely bogus; ANI never, ever, addresses content disputes. ANI is concerned with user behavior, not with article content, and indeed the linked-to section is about a particular user's behavior, not about content. It should be noted that sometimes it is the person who is right on content who is wrong on behavior, and sometimes it is the person who is wrong on content who is wrong on behavior. The two have every little to do with each other.
 * Pigsonthewing|Talk to Andy needs to follow our WP:CONSENSUS guidelines in general, and WP:TALKDONTREVERT in particular. WP:BRD has some good advice on how to do this. --Guy Macon (talk) 08:21, 26 May 2013 (UTC)
 * I haven't claimed that ANI has addressed the content dispute. HTH. You're welcome to follow your own patronising advice on BRD. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 08:24, 26 May 2013 (UTC)
 * I made no assumption in my edit summary that I didn't state in my edit. There was no consensus. This entire section is premature. Walter Görlitz (talk) 16:17, 26 May 2013 (UTC)
 * Perhaps it's premature now that other editors apparently disagree with its implementation. But up until now consensus was gained (no substantial disagreements with implementing this, just one editor who disagreed without giving any good reasons why). But if other editors disagree with it, what are your arguments against implementing this change? Please provide links to policy/guideline supporting your disagreement.
 * That being said, so far the new parameters look good overall. I think however that if only the "part" parameter is used, it should be with an uppercase first letter (ie "Side one", not "side one"). Having an apparent headline with all-lowercase looks strange. I don't know if this is something that the software can force, or if it will just have to be something mentioned in the parameter description on the main template page. MrMoustacheMM (talk) 19:15, 26 May 2013 (UTC)
 * Thank you. We would nee to use the latter. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 21:57, 28 May 2013 (UTC)
 * Your edit summary was "When did you decide that there was a consensus?". Since you were replying to me, I took that as being addressed to me also. If that's not what you meant, and since you did not refer to the maker of a decision in your comment, please clarify your meaning. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 15:48, 28 May 2013 (UTC)
 * "There was a consensus? I didn't see that happen. Please explain. The changes don't appear to be an improvement."

- me


 * The italics don't directly relate to the edit summary. Walter Görlitz (talk) 20:46, 28 May 2013 (UTC)
 * As such, there is currently no consensus on this matter. Walter Görlitz (talk) 22:50, 28 May 2013 (UTC)
 * For the record, I am neither for or against this content change and neither support or oppose the theory that there is a consensus. What I am against is the claim that ANI recognizes a consensus. ANI is specifically forbidden from doing that or in any other way ruling on article content instead of user conduct. --Guy Macon (talk) 23:05, 28 May 2013 (UTC)
 * Please either provide evidence that anyone has claimed that ANI has recognised a consensus, or stop disrupting this discussion with irrelevant nonsense. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 23:25, 28 May 2013 (UTC)
 * It appears that someone may have compromised your account and made this edit without your knowledge. Either that or you are once again being a bit *cough* "creative" with your incivility. You do realize that insulting other editors does not strengthen your case, right? Quite the opposite, actually... --Guy Macon (talk) 00:25, 29 May 2013 (UTC)
 * I see your point Guy Macon. Pigsonthewing seems to forget the edits that Pigsonthewing has made earlier. Now either it's a compromised account (WP:AGF), a strange medical condition, or something else. Pigsonthewing wrote this:" Noting that the consensus here has also been recognised by uninvolved editors, I have added the three new parameters to the sandbox. Examples of them with and without the current headline parameter may be seen at Template:Track listing/testcases.: Pigsonthewing even edited a short while ago. Walter Görlitz (talk) 00:38, 29 May 2013 (UTC)
 * It isn't quite up there with editing a policy and then reverting one of your edits while quoting the part of the policy he himself added, but it is getting there. The lesson here is that we need to double check any claims made by this particular editor, all the while ignoring the steady stream of insults and abuse and not stooping to his level. --Guy Macon (talk) 01:00, 29 May 2013 (UTC)
 * Technically, per WP:NUMERO, that would be either No. 1 or number one. #1 is right out. I'm not sure if that would be hubris or something else. What's the word I'm looking for? Walter Görlitz (talk) 01:08, 29 May 2013 (UTC)
 * I forgot that the octothorpe is contraindicated. Perhaps I was distracted by trying to parse the wikibarratrous difference between "recognized by ANI" and "recognized by the uninvolved editors who comprise ANI". I think the word you are looking for is probably somewhere on this webpage. :) --Guy Macon (talk) 13:06, 29 May 2013 (UTC)

--Guy Macon (talk) 01:36, 29 May 2013 (U

I note that, in among the personal attacks and falsehoods posted above, it is implied that I asserted that "ANI has recognised a consensus". I of course did no such thing. Any literate person reading the linked page will see that my actual statement, that consensus had been "recognised by uninvolved editors", is correct. May we now set aside this inane side-show and discuss the question I asked, above? Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 09:16, 29 May 2013 (UTC)
 * Intelligent readers will also note that I didn't refer to "the uninvolved editors who comprise ANI". Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 14:00, 29 May 2013 (UTC)
 * No the statement claims that the "uninvolved editor" recognized the consensus. The editor never recognized the consensus. Also, intelligent editors will see that there is currently no consensus on the subject. Walter Görlitz (talk) 14:38, 29 May 2013 (UTC)

Let's ask User:Drmies whether the comment (my emphasis):

"Andy's proposal there is supported by all but one editor... a pretty clear consensus. Someone with a decent amount of technical knowledge should go by there and close that discussion as if it were an RfC, to move forward with Andy's proposal..."

was a recognition of consensus, shall we? Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 14:58, 29 May 2013 (UTC)
 * . --Guy Macon (talk) 15:07, 29 May 2013 (UTC)
 * "Also, intelligent editors will see that there is currently no consensus on the subject." So then please get back to the subject. What is your objection to this? Up until you disputed consensus above, there indeed was consensus to implement this change. Please state your objection(s), cite policy/guidelines, so that we can move forward with this or stop it if there are good reasons opposing it. MrMoustacheMM (talk) 19:15, 29 May 2013 (UTC)
 * There was no consensus. There were questions about how it was to be implemented and I still don't see a reason for its addition. I tried to suggest why it miught be helpful, but I still don't see a need for this. Maybe I need to re-read the earlier discussion but right now, I can't see 1) where it's needed and 2) how it won't be abused. Walter Görlitz (talk) 21:19, 29 May 2013 (UTC)
 * The consensus here has been recognised by uninvolved editors. The question of why this is needed is addressed, at length, above, and in the earlier, linked, discussion. The fact that you have not grasped that does not mean that consensus does not exist; you do not have a veto. The question of whether it might be abused is not addressed, because it's hypothetical, and anything might be abused. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 22:39, 29 May 2013 (UTC)
 * No consensus. The fact that you have not grasped that doesn't mean there is one. Walter Görlitz (talk) 22:43, 29 May 2013 (UTC)
 * Why do you insist there was no consensus? Everyone either agreed with the proposal or didn't specifically disagree with it, with one exception, who admitted her own lack of understanding and ended up devolving into WP:IDHT territory. So yes, there was consensus. There still appears to be, unless you have specific reasons against this. You say you can't see where it's needed? Then read the above discussions. The explanations are given there. You're worried about how it could be abused? Give specific examples of how it could be abused and we can address those in template documentation. MrMoustacheMM (talk) 23:48, 29 May 2013 (UTC)
 * I note that Walter has failed to answer this simple question. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 10:42, 1 June 2013 (UTC)

My opposition is completely valid. This entire discussion was A)refusal to answer clear consensus changing questions, and then near the end claiming they have answered them B) No one here actually seems to be onboard for the exact same thing. Everyone is focused on a different aspect. And it doeant help that Andy Mabbett doesnt clarify not just for my sake, but any editor who might support for the wrong reasons. I honestly dont see much improvement even in metadata, because it looks like making this proposition is forgetting what its actually for, which is to benefit wikipedia articles. I mean in order for an artist parameter to be necessary in a template the article would have to have some other microformat that somehow adds in an artist parameter to the title. But thats already covered by manual disambiguation.

Also hypothetically you "did" answer my question, it wouldnt hurt to be clearer and say "I already answered that, (repeat the answer here)" just so I can know exactly what youre referring to.

Its about time we treated this discussion with respect, and civility and actually treat the opposing editors as equals. Although theres no clear opposition, there is a clear sign of "no consensus" and although one editor claims to not be part of this, he did mention how this parameter provides no real improvement. I think its about time you all addressed the issues I brought to the discussion. Lets not forget this is a completely "subjective" improvement.Lucia Black (talk) 23:27, 31 May 2013 (UTC)
 * See. Thanks for your response. I will try to re-read the previous material to see if there was a consensus or just a conspiracy to invent one. Of course, objection from one or two doesn't negate a consensus from many others. Walter Görlitz (talk) 00:12, 1 June 2013 (UTC)
 * The consensus here has been recognised by uninvolved editors. I have already given you a quote from that discussion, above. Your allegation of "conspiracy" is a grievous violation of WP:AGF, and unless you have evidence of such, I invite you to do the honourable thing, apologise, and strike it.  Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 10:39, 1 June 2013 (UTC)

He not accusing you yet, he will review the situation. And a moment ago you mentioned how data granularity is not the relevant aspect to this proposal, but I see it at the veryy beginning of your post and you mention it again at a different post. Whats going on here? Are the people who support this actually know what their supporting? Because their so sure of it, but never really provide a clear reason. The exception is RexxS and Lil unique, but their points have been countered.Lucia Black (talk) 19:46, 2 June 2013 (UTC)

Redux
[Apologies; I've been offline for over two weeks for medical reasons]

As I said above: "I'm just trying first to get the visual presentation right. Are folk happy with them as they are, or should we use commas, or suchlike, as separators?" Anyone have a view? Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 17:50, 25 June 2013 (UTC)
 * i'd prefer the · used in flat list. &mdash;  Lil_ ℧ niquℇ № 1  [talk]  17:56, 25 June 2013 (UTC)
 * its insane how much you all dodge the gritty questions. Im starting to think this is an issue more of personal data-granularity rather than granularity for the sake of computer readability. Can someone explain adding a slot that never needs to be used in template? It was reverted for a reason.Lucia Black (talk) 03:49, 26 June 2013 (UTC)
 * This is explained, and your increasingly vexatious questions answered, at length, above. The consensus here, and your disruption here in the face of it, has already been commented on at ANI. You would do well to desist. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 16:22, 26 June 2013 (UTC)
 * ANI was about how I handle myself, not if I opposed or prolong a discussion. But its not about me, at this point. You keep saying you answered my question above, but you never actually clarified which is the answer. And for the longest time youve ignored me and tried to make it seem like there was consensus. (Incredibly uncivil of you) And when another editor actually notices this, you still use you 1 month wait, and return only to act like you conquered that issue when you only avoided it.
 * And you get offended easily if one editor starts to suspect a conspiracy to make consensus rather than actually defending a possible point. Forbthe longest time you didnt claim to have answered my question, you only ignored me. So even hypothetically if you did, you never clarified what the answer was. Which I still doubt you ever did.Lucia Black (talk) 20:05, 26 June 2013 (UTC)

* sigh* Let's ask User:Drmies to clarify their comments at ANI shall we? Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 20:18, 26 June 2013 (UTC)
 * Andy, I saw a consensus at the previous discussion. What I see here is the same kind of badgering and refusing to get the point that I saw before. I think you should let this RfC run as a relatively straightforward yes/no option, and count heads and balance arguments afterward. Sorry, and *sigh* right back atcha. Drmies (talk) 01:10, 27 June 2013 (UTC)

Hiw about this, ill ask the question again, if you answer, I will drop ir (depending if I find it beneficial in general rather subjective benefit).

Why must we add parameters for artist for the sake of microformats? You realize this isnt a parameter that is actually benefit wikipedia to be used, as it could get redundant by overly repeating something that doesnt need to be repeated. But no, this seems more like 1 flaw for the greater benefit, but to who and how great is that benefit? Tell me how this template cant be converted to microformat without artist parameter. You also mentioned issues of the extra parameter aswell.

Why not clarify. Why is every1 here so adamant about answering a gritty question? Youve all dodge these questions. Thats why im bringing this to RfC, because no one here is defending the reason, your all just assuming consensus and disrespectfully ignoring the opposer for valid reasons and not even try to help them outnin your view point. This isnt refusal to get the point, this is begging to understand the point.Lucia Black (talk) 20:33, 26 June 2013 (UTC)
 * He's clarified it for you with a list of reasons. Including re-pointing them out for you. Please address it. You have yet to provide a single reason other than your emotionally charged objections. Do not go off on a tangent as you did at "breaking spacings and flat list". The proposed change has good reason behind it that is not being discussed or even acknowledged by you. It will be an option for use that will be present to assist those who want it and bring conformity and unity to an aspect of the template that is currently lacking. Just three simple questions need to be asked. Does it do something currently unable to be done? Yes. Is this change positive and improve the function and unity of articles which will use this template? Yes. Does it result in errors or template problems? No. Then by all means it should be made. Its good outweighs any "data granularity" issue. for which you seem to lack understanding of. It seems to be a case of WP:IDHT because you do not address Andy's arguments on why it is good and fail to provide an alternative or solution of your own. ChrisGualtieri (talk) 01:40, 27 June 2013 (UTC)

Ok chris, this is how I can tell that you havent fully read this entire thread, or you did but read mine quickly. I know whar he said, but what ive said still stands. The initial explanation doesnt explain the superfluous artist parameter, because as explained, this would be meant to add 1-value parameter rather a parameter that has multiple so that the computer can understand that what the info in that parameter stand for. Example computer will read info in "headline" as 1 value despite that it would normally have album title, side #, and disc #, alternate version. So in a sense, doesnt understand what the parameter represents. HOWEVER, this proposal to fix the issue for haudio and micro format doesnt click. Why would we need an artist parameter for the sake of granularity if it doesnt actually fix granularity 100%, it only adds another slot to be filled in. He did not answer this question. Which is why compromised a title, side, and disc parameter to replace header but NOT artist because artist has never been used in the header in order to disambiguate between multiple tracklists. Plus it only adds redundancy as prose would constantly be mentioning the artist, so having it seems like an option to add redundancy in the title. Theres a difference between fixing granularity and adding unnecessary slots just for subjective complete set for granularity.Lucia Black (talk) 05:38, 27 June 2013 (UTC)


 * Basically the issue is not the goal, but the method and how it affects other aspects not related to the goal. The proposal is to fix granularity, but how does adding a parameter we dont need to use actually help fix that issue? It only offers the option to be redundant. Which is why I ask how come we need an artist parameter for the sake of the goal.Lucia Black (talk) 10:36, 27 June 2013 (UTC)


 * This is a total farce; you seem to advocate "granularity" as something with a specific form and designated by having maximum usefulness without any additional fields? Wasn't the compromise made to have that option for data granularity? Your argument is self conflicting and doesn't even make sense. What does this even mean, "Theres a difference between fixing granularity and adding unnecessary slots just for subjective complete set for granularity."? If its unnecessary we wouldn't need the field, but it was shown to have a use for the emitted data. Look... you need to be clear about your issue and explain it, I like having better parsing, but even if they are not used, we don't flip out and axe other templates because of it. There is far more "waste" in geographical and settlement infoboxes, but the templates are useful and they bring conformity and function to Wikipedia and are great for exporting that data. You say "fix granularity" like we have some scalability problem by adding the field in; that is incorrect and no one will back that claim up. Explain your position better; because it doesn't make any sense to me or the majority of editors in this lengthy discussion! ChrisGualtieri (talk) 04:19, 28 June 2013 (UTC)
 * Artist parameter doesn't provide the benefits Andy claims because its not a parameter that would be needed in any situation to disambiguate between tracklist. My compromise was to have parameters we "need" not parameters being "optional" with "no benefit". So title would be necessary to disambiguate between albums, disc and side to help disambiguate between multiple tracks within the same album and recently added, is the version/edition parameter (because there are multiple versions of the same album with the same name).
 * Of course headline still exist, but the option should be to fix granularity in general by adding parameters that can replace the headline parameter. What the option shouldnt be is use a parameter that doesnt help the tracklist or the article. Artist parameter is only additional and thats why i provided a compromise in which seemingly no one except RexxS (despite increasingly subjective opposition toward the compromise) brought up a reason against the compromise other than it wouldnt have artist, but that was the point as I repeat, "artist parameter solves nothing and only adds redundancy". Why redundancy you might ask? Because in all albums, the article will cover the artist in the prose of the article, so repeating that would be redundant. This is also the reason why not every tracklist has a "title". Because theres no need to disambiguate between multiple tracklists in one article. Adding it in a title when theres no need for it, would be redundant. But in this case, artist doesnt help disambiguate or clarify between tracklist.
 * so let me summarize just incase. Artist parameter = unnecessary, never going to be beneficial, and tries too hard to make the tracklist into an album database, not a list of tracks.
 * title, side, disc, and version/edition parameter = useful to disambiguate between tracklists, necessary when an article would actually need to disambiguate, helps granularity aswell.
 * I noticed you are talking about axing a template (?). I assure you this isnt about axing a template more than it is about against a superfluous parameter that only provides redundancy and no other benefit. Unless of course theres multiple tracklists in the same article that share the same title with only having different album artist, but even then those will probably be separated into their own articles. As ive attempted to look for such an article for devils advocacy, and found none.Lucia Black (talk) 06:37, 28 June 2013 (UTC)
 * So you are for those changes. Good. Let's do that and forget the artist parameter for now and implement it. I need not provide the rare example for the artist parameter now. ChrisGualtieri (talk) 14:18, 28 June 2013 (UTC)
 * If by "forget" you mean "ditch", then yes, lets forget the artist parameter. I provided a much better compromise and im not letting it go   after a huge mess of neglect and prejudice of minority only to 2 editors actually understanding the issue.parameter would never be necessary, and it only offers editors redundancy in the article, and slowly changing the tracklist into an album database (which, no thats not what the tracklist is for, its a list of track and the info of each individual track. Thats why we have an infobox).Lucia Black (talk) 23:22, 30 June 2013 (UTC)

Post RfC
So, that's the time-wasting RfC over with. As requested above, please view the examples at Template:Track listing/testcases and comment on the visual appearance (remember that the non-visual microformat markup hasn't yet been added). Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 22:44, 25 July 2013 (UTC)
 * Last call... Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 13:31, 13 August 2013 (UTC)
 * I don't see why we can't fix this issue with a compromise that benefits both side (at least the idea of it). It gives the data granularity you need, and it doesn't impose editors on using unnecessary parameters that don't benefit the article This shouldn't be an issue of WP:IDHT if other editors give out their own personal individual reasons that don't tie in with yours (and of course staying silent).Lucia Black (talk) 23:20, 24 August 2013 (UTC)
 * Data Granularity is an improvement for all. Your comment seems to suggest that granularity creates unnecessary parameters when its been established above that the changes create fields which improve granularity and frankly accessibility changes IMO are more important than increasing the documentation and number of fields in a template.  → Lil- ℧niquԐ 1 - {  Talk  } -  23:32, 24 August 2013 (UTC)
 * not all methods of granulairty. data granularity for this template should focus on "disambiguation" purposes between tracklists. Data granularity "can" be subjective and there is such a thing as too much granularity. Granted, you still believe the "catalog #" is still beneficial in the headline of a tracklist, in which doesn't help disambiguate between tracklists but just informs its existence to the reader (if they ever want to buy the track? rather encyclopedic, in my opinion). So selling the idea of "artist" parameter is useless in a tracklist template is harder to sell to you.


 * Basically the compromise, is to add disc #, Side #/letter, title, and (edition/version) to replace the headline for granularity (that is needed in this template for granularity) but we don't need the "artist" to appear in the headline as there's never a need to disambiguate between "artists". I'm not saying data granularity is bad in general, but "how" we go about it. the headline is there for disambiguation purposes, and the only ones that ever go on "headline" is to differentiate between sides, discs, versions, and title. A good example is Voices of the Lifestream in which each disc has its own title too.


 * doesn't that sound like a fair compromise? we get "more" parameters that are actually useful and gain granularity.Lucia Black (talk) 23:49, 24 August 2013 (UTC)
 * I haven't actually advocated that catalogue numbers should be used in headlines across the board. I had a specific case where the album was released in a limited number of territories and there was only the same two versions of the album available for sale. that digresses from the above discussion anyway which was specifically about an artist parameter of which there appears to be general support for.  → Lil- ℧niquԐ 1 - {  Talk  } -  23:54, 24 August 2013 (UTC)

I'm simply saying, you use the headline for alternate purposes on occasion, in which its difficult to convince you to keep the parameters as simple "need-only" basis. A lot of what I'm saying gets ignored while i constantly address the issues you all bring out. many of the supporters gave out their own personal reasons for it, rather than beneficial to wikipedia itself. Example: RexxS was more worried about usage of this template outside of wikipedia in which other sites (most likely himself) can add "artist" in the tracklist despite other sites already using a similar tracklist (such as iTunes) where they keep overall artist alongside release date and title. What's wrong with the compromise given out? It's within the needs of wikipedia and provides more coverage than the simple "title" and "artist" parameter. If we want granularity, we need "disc" parameter, "side" parameter, "title" parameter and "version" parameter.Lucia Black (talk) 00:20, 25 August 2013 (UTC)


 * regarding the pattern of the cycle of this discussion, i predict the ignoring of my key questions begin until an appropriate time to assume consensus by Andy Mabett.Lucia Black (talk) 01:02, 25 August 2013 (UTC)

New compromise
Slightly different but mostly the same as before which to offer the compromised alternate headline parameters and I'll give you reasons:
 * Disc parameter due to multiple releases (mostly compilations) release multiple tracks. Use only numerals (unless proven that discs use another form of numbering)
 * Side parameter mostly would affect vinyl LP and early CD releases. This parameter would contain both numerals and letters as multiple releases mark their tracks with 1,2 or A,B,C,D.
 * Version/edition parameter. Their are often alternate releases such as digital and physical disc, that vary with different tracks. Also limited/alternate editions, this parameter would have anything written under it inside parathesis "". I'm skeptical of having editions and versions separate..but then again there's never an alternate version of a limited edition.
 * Title of course this is absolutely necessary if multiple versions, sides, and discs would appear. This parameter would be in Italics.
 * Also multiple discs may have multiple names between discs. So it may be needed to keep "Disc" parameter line up before "Title" to keep consistent. OR we add "Disc Title" parameter to simplify.

All these meet the goal of "Data granularity" and "necessary parameters"

Reasons NOT to have an artist parameter.
 * Despite belief of granularity, we never needed to add a single artist in the headline of a tracklist. So data granularity shouldn't be a reason to add this parameter if its a parameter that we won't need to use. So artist parameter =/= data granularity.
 * as stated dozens of time, if an editor would want to make use of it, it would only serve to be more harm. It would bring unnecessary "redundancy" as both lead paragraphs, infobox, and following sections before tracklist would ultimately mention the artist constantly. Making it obvious this parameter is of "just for show".

What makes this different? Well there's no reason why we can't implement these suggested parameters now (unless you have a problem with it). If data granularity is trully the goal, we can add these in alternate form of headline now and further discuss the need of the "artist" parameter here and/or when it becomes necessary to add one. There's no reason to implement the compromise if both sides get about 80% of what they want while the 20% still being discussed.

This is a completely fair, and rational compromise.Lucia Black (talk) 02:33, 25 August 2013 (UTC)