Wikipedia

Wikipedia:Templates for discussion/Log/2010 May 28

< Wikipedia:Templates for discussion | Log
< May 27 May 29 >

May 28

edit

Template:Fb event

edit
The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was subst and delete. delldot ∇. 15:40, 8 June 2010 (UTC)[reply]

Template:Fb event (talk · history · transclusions · logs · subpages)

This template is trying to apply a standard format to what is effectively proseline. Encouraging or trying to standardise proseline is not useful or desirable, as such information should be converted to well-defined lists, tables or prose. I suggest substituting all existing transclusions of this template and then deleting it. Jameboy (talk) 20:55, 28 May 2010 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review). No further edits should be made to this section.

Template:Tracklist custom

edit
The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was Moved to Template:Track listing/sandbox6, without redirect. The editor who created it aside, there is consensus that this template is an undesirable fork of {{Track listing}}. However, there is also a consensus that features found in the fork may be useful. To ensure that this material is available for further use, I've moved the template to a sandbox page. RL0919 (talk) 14:25, 4 June 2010 (UTC)[reply]

Template:Tracklist custom (talk · history · transclusions · logs · subpages)

Speedy T3 contested, elevating for discussion. UtherSRG (talk) 14:07, 28 May 2010 (UTC)[reply]

  • Strong Keep for WP:Featured articles & WP:ACCESS. The track-table formatter Template:Tracklist_custom was specially designed and developed to provide customized track-tables, such as for sound recordings listed in WP:Featured articles or formatting to support guideline WP:Accessibility, for sight-impaired users with special needs. Some users read pages with larger text-size settings, such as MS Internet Explorer textsize "Larger" or Firefox zoom-in text. Because the template allows specifying the exact width of table columns, internally it has been completely redesigned, and it is NOT a mere fork of Template:Tracklist, but rather an entirely different implementation intended to look similar for visual compatibility. Running a diff between the 2 templates reveals the extensive differences, on more than 230 lines. It also allows for automatic adding of track-length times, to calculate the total length (in minutes & seconds) of an album or song list. In terms of performance, the internal coding of the template has been optimized to speed the display (or reformatting) of frequently-read articles. Beyond those customization features, the template also checks the validity of the track-table format, to help young readers when writing about record albums (by reporting any misspelled parameters). It would be unfair not to support sight-impaired readers and younger viewers. To simplify maintenance, the template contains extensive internal documentation to explain the coding, which acts as a tutorial in understanding the formatting of track-tables, in general. Because the main purpose of the template is to allow special customization, it also provides an easy avenue for introducing new features, needed only in a few select articles, without risking changes to track-tables used in over 11,000 other articles. After months of long-term testing, such features could later be added into all articles, but "Template:Tracklist custom" frees volunteers from the risk of updating a major template when only a custom fix is needed, while allowing them the freedom to add that feature into all track-tables at a later time. Consider the template as a "lifeboat" to support WP:Featured articles, sight-impaired viewers, young readers, and allow quick customization or new features to be added by volunteers who have limited time. -Wikid77 (talk) 14:51, 28 May 2010 (UTC)[reply]
  • Incubate. It looks like a lot of discussion is ongoing at Template talk:Track listing. I don't understand the FA argument— if it is good for FA articles, then it is good for all. I also don't understand why a separate template is needed for accessibility— if {{Track listing}} has accessibility issues, then it needs to be fixed. I recommend that this be moved to a subpage of {{Track listing}} and the features worked into the original template with consensus. ---— Gadget850 (Ed) talk 15:07, 28 May 2010 (UTC)[reply]
The original template is stuck in complex discussions which have paralyzed attempts to improve that template, and which have not produced any consensus in a long time. See explanation in subtopic below: "#Analysis paralysis prevented updates to related template". -Wikid77 (talk) 09:29, 29 May 2010 (UTC)[reply]
  • Delete and return to implementing these features into Template:Track listing. The first appearance of changes to the template by Wikid77 appeared on May 1, but that was a small change with none of the features mentioned above. At that time I noted on the talk page, "The (new) parameter has not been added to the documentation, nor was it discussed or even announced here. ... I'm not certain of the purpose of this change. Should we revert?" [1] Others agreed to revert, and Wikid77 made further improvements in testing areas, which were discussed at length, mostly to do with auto-sizing the width of columns. Work was also done on improving the "total time" row and footnotes. Over the next week, many requests were made for further changes and explanations of what was being changed, and Wikid77 did a lot of work in handling these requests. Although we were generally enthusiastic about these changes, it wasn't approaching consensus to implement, because Wikid77 was continually adding more features to his proposed version, and the examples on the talk page were continually changing. Also, a lot of the change was quite technical, and usage needed to be explained at a user's level. I (and others) tried to encourage him to create an updated version of the existing documentation in a test area, to move the process along. [2] [3] [4] [5] Wikid77's response was, "The changes are quite extensive, so it will take some weeks to fully document" [6], and I believe he is alluding to this in his reponse earlier in this section when he mentions "volunteers who have limited time".
So the result is that Wikid77 has created a forked template an announced it as basically a "free-for-all" where anyone can make changes without gaining approval or making documentation. I do realize he hasn't actually said this, but when I stated that we don't want a 3rd and 4th version of Track Listing to appear, Wikid77 agreed, suggesting his version could be the one "2nd, customized, template" for "people who do not have time" to get consensus and document what they are changing. [7] (I'm piecing several quotes together and interpreting their meaning, sorry if I'm taking anything out of context, but I believe this is what he is saying.) I disagree that it would take weeks for Wikid77 to provide user documentation for the changes he has made, although I admit nearly all of the new features he talks about in this section are new to me, so clearly he has been doing a lot more work since the discussion dried up on the talk page. But even so, documentation is always essential, and should be written as you go, to prevent it from becoming a big chore later. (I used to work as a programming project leader, and can attest that programmers who don't do this on big projects run a risk of giving themselves too much work. But I really don't think it's reached this point yet, on this template.)
The big problem is that if the custom template is indeed a "free-for-all", then it's quite probable other editors will come in and make changes for their own needs, and mess up its existing usage in articles. I have pointed out that we don't really need to have a template to make a customized table. An editor can just make a Wiki-table. Track lists can be in one of 3 forms: a text list, a custom table, or Template:Track listing (per WP:WikiProject Albums#Track listing). The template exists to establish a reliable, stable, documented table with helpful features. The same could be said for most templates. This is why custom, forked, and undocumented templates are discouraged and deleted (via this page) when they appear. --A Knight Who Says Ni (talk) 22:23, 28 May 2010 (UTC)[reply]
It is NEITHER a fork nor undocumented: it has its own documentation subpage. Keep reading below. -Wikid77 (talk) 09:29, 29 May 2010 (UTC)[reply]
First, {{Tracklist custom}} is NOT a fork, but rather a total redesign that produces a track-table which appears similar. Hence, {{Track listing}} cannot be "updated" to have similar capability, but rather, would need to be re-designed to allow those new features. Again, because it is not a fork, the other template cannot be "modified" to produce the same new features: it would have to be similarly re-designed. Second, the discussion at Wikiproject WP:ALBUM was very limited, perhaps by 3 other people, and the result seemed to suggest ignoring guideline WP:ACCESS. I firmly believe that any template designed for use in album articles should not ignore a Wikipedia guideline, even if some members of a Wikiproject think WP polices or guidelines don't apply to them. Currently, {{Tracklist custom}} can be used in articles to support WP:ACCESS, until the other template is discussed to reach consensus for updating it to also support WP:ACCESS. Because the template is NOT a fork, and provides several new features (with documentation), to be used in WP:Featured articles as well as to support WP:ACCESS, there are no grounds for deleting it. -Wikid77 (talk) 09:29, 29 May 2010 (UTC)[reply]
{{Tracklist custom}} serves exactly the same purpose as {{Track listing}} and started out in it's sandbox as {{Track listing/sandbox2}} so IMO that makes it a fork. So does other people seem to think. I hope you remember that (although it took me several days to figure out what you were talking about) I did agree that {{Track listing}} do have some display issues on narrow screens, and that both myself and A Knight Who Says Nee gave our "weak support" to /sandbox2 provided you could sort out some issues were it degrades the display on a normal sized screen and provide some documentation for all those new parameters you added [8]. Your problems started when you—behind everyones back—moved /sandbox2 to the template namespace and deployed it on Dark Side of the Moon. At this point, WP:ALBUM decided against it and no, we were not 3 but 5 people (excl. you) involved in that discussion [9]. So regarding your endless allusions to WP:ACCESS, it's an upright lie to state that we "think WP polices or guidelines don't apply to [us]". We simply believe that the template in it's current form is not mature. Personally I think that the multitude of width parameters you added is the perfect example of feature creep; we can't expect editors to think about defining column widths in numbers of pixels when they set up a track list. Neither in FA-articles nor in all other. – IbLeo(talk) 17:02, 30 May 2010 (UTC)[reply]
  • Delete, as multiple templates serving essentially the same purpose would result in an unnecessarily increased workload for everyone involved. People would have to learn about the differences, evaluate what variant to use for what article (obligatory squabbles included), then there would be maintainance and housekeeping for each individual template, the issue of where to hold discussions that might pertain to either one of them and so on and so forth.
    Now, I'm sure Wikid77 will readily offer rebuttals for each of these points and also promise to become the second template's keeper until kingdom come (even though it is supposedly intended to be a free-for-all effort), but lets just return to Template talk:Track listing and continue working on the consensus behind one template for one purpose. After all, it's not rocket science, just tracklists. – Cyrus XIII (talk) 12:11, 29 May 2010 (UTC)[reply]
Yes, there are numerous misconceptions:
  • First, it's not essentially the same purpose, but rather custom formatting in WP:Featured articles (& other new features, not the same).
  • 2nd, to have new features (such as summing the total length of an album), some effort is needed.
  • 3rd, this "unnecessarily increased workload" has been a lot easier than the "necessarily debated consensus" still ongoing for months.
  • 4th, for "everyone involved" is overstating the customization of a few articles, while not involving most of 11,000 other track-table articles.
  • 5th, only a few people would need to learn about new features, and the vast majority would use the original template. Not everyone works on featured articles.
  • 6th, the current "table analysis paralysis" (linked below) has paralyzed the "working on the consensus behind one template".
  • 7th, perhaps it's "not rocket science" but I think it could be called "wikitable calculus": the typesetting and auto-widening of table columns is much more complex than many people imagine, and that is why the 2nd template is a total redesign (the original template could not precisely set the width of columns: it's the wikitable issue of 2% versus 20px).
  • 8th, the resistance to a "2nd template" is unfounded; it's like saying this family can continue taking turns on the motorcycle, we don't need to have both a motorcycle & car, because then there's "increased workload" for car maintenance, and everyone in the town will have to learn how to drive the car, and riding a motorcycle is not rocket science: we can find a way to fit all 5 family members on the motorcycle at the same time, we just need "consensus" to do it, etc.
Please note that a car is "not a fork" of a motorcycle, and consensus does not solve putting 5 people on a motorcycle. The customized template is like a car for WP:Featured articles, while most articles use the motorcycle template, but some users have trouble riding the motorcycle, due to special needs. For them, there is the customized car template, to support WP:FA and special needs. -Wikid77 (talk) 18:56, 29 May 2010 (UTC)[reply]
Because the Template:Tracklist custom is a total redesign (not a fork), it can specify the width of each column as pixels ("220px") plus set a gap-width between the columns. The prior template was not designed to allow spacer-gaps between columns. An analogy is that a car is "not a fork" of a motorcycle, but the car provides new features (4 passengers, A/C, trunk, reclining seats, etc.), while a motorcycle can drive in more places (on narrow sidewalks, through a yard gate, into an apartment for storage at night), so both car & motorcycle are useful. There is a table showing some of the new features; see talk-page: "Template_talk:Tracklist custom#New features provided by redesigned template not fork". -Wikid77 (talk) 23:28, 31 May 2010 (UTC)[reply]
  • Comment: Several editors clearly indicated the importance of gaining consensus before adding any new features to the related Template:Track listing. However, after more than a year of little progress, on 1 May 2010, I began directly addressing some new features to add. Often, when discussing one feature, someone would request another feature be added, then when discussing that feature, yet another user would object to that feature being added into the other features. In short, no new feature gained consensus, and people began complaining about too many features being considered. A feature requested by one person would be considered "useless" to other editors. The result became a typical "paralysis of analysis". Hence, creating the customized template provided several new features (something for everyone), all at the same time, but none of them would be mandated to require consensus of all concerned users for the 11,000 track-table articles. The custom template allowed some people to use new features, as documented on a new doc subpage, but only applied to a few articles, where results could be specifically tested. At that point, the overall discussion was reduced to considering only 1 new feature for the prior template: changing the width of the table to appear wider for WP:ACCESS, when users have narrow windows (800x600 pixels) or enlarged font (textsize "Larger"). The single focus quickly became mired in wanting the wider table to be the same width for multiple albums, if needed, or only auto-widen to fit the names of the songs (or writers) as actually listed. Again, even when focusing on a single new feature (setting table width), the detailed analysis of table-width with images (or infoboxes), plus auto-widening only to fit actual data, seemed to be returning to over-analyzing the situation and paralyzing any chance of near-term consensus. After another month had passed, the customized template was the only new capability to have been created, combining the ideas of several people to provide something new for each; while with the prior template, the discussion to add 1 new feature (table width) had reached a deadlock, in wanting too much automated-capability for that one feature, in preparation to ask for consensus to update. The result: after extensive discussions, the customized template is the only new capability to allow formatting album track-tables in WP:Featured articles and support for sight-impaired readers (for the articles they are most-likely to find unreadable). It also provides other new features, and helps young readers when first writing track-tables. The related template has not been able to offer those features, so that is why the customized template exists, not as a mere fork, but as an advanced redesign (with separate doc subpage), which allows new features while appearing similar to the other 11,000 track-tables. -Wikid77 (talk) 09:29, 29 May 2010 (UTC)[reply]
    I understand that, although I think "paralysis" and "deadlock" are unfair terms. Changes were not approved because details of how these features were to be used were not clear, and at the time it appeared you were not prepared to update user documentation, stating that in-code comments were all that would be provided. As for the many features you have added, most of them as described at the top of this section were never presented at all on the Track listing talk page. As for changes requested, there weren't all that many in comparison to the new features you kept adding; a new feature proposed by you was appearing almost daily! All of us have been saying repeatedly that we would like to see these features implemented in the existing Track listing talk page, so I disagree about resistance to change. The problem is, changes were being presented in a way that made it impossible to assess the whole package, including the problem that previous examples on the talk page kept changing, rather than adding new examples. I don't think a rewrite of the coding is a problem either, if it includes all previous features. You have just given up too easily, and have not presented your plan in an acceptable way. When you created a new template, against our advice, I think some of us were kind of shocked, so we objected to this end-run solution, and I still object. But I'm not opposed to the whole idea of overhauling the template. What I'd really like to see, is the changes going back to a user-page proposed version (not used in articles), with some stability, and an explanation of all features and changes in proposed user documentation. Give us a chance to see it, which has not been presented before. And hold off on trying to add more new features for the time being. You will undoubtably get more criticism, reported bugs, and requests for change, but I really don't think it's impossible to have it approved, and you won't know until you try it. Have you done programming as a career, and worked with program change presentations before? I presume the answer is no, but since you are really into programming, this is your chance to learn how it works. Actually, 75% of programming work is in the finalization phase, with presentation and minor fixes. It may be frustrating, but it's a waste of time commit to the first part if you're not willing to do the rest, and I've known many fellow programmers who have to learn that. Please don't take any of this personally! We're on your side, whether you appreciate it or not. --A Knight Who Says Ni (talk) 20:40, 29 May 2010 (UTC)[reply]
    I have to concur with A Knight Who Says Ni, both your concerns and suggestions would benefit greatly from a more step-by-step approach. It is apparent that few editors are actually convinced of the current template's inadequacies in terms of featured article deployment and WP:ACCESS. Then there are the transparency issues; wouldn't a changelog and a list of known bugs be better suited for a template (or template talk) subpage, than comments within the actual code? General code rewrites might also fare better if presented separately from new features. In order to test and preview new code, I could indeed imagine deployment of a staging version in a predefined pool of out-in-the-wild articles, though, out of due diligence, not those of the featured kind.
    Everything A Knight Who Says Ni said about the programmer's plight has held true in my experience and within the context of the collaborative effort that is Wikipedia, that potential for frustration can go up exponentially. Some of the initial discussions surrounding the original template were no walk in the park either. Maintaining good faith and aiming low helps though. – Cyrus XIII (talk) 08:41, 30 May 2010 (UTC)[reply]
    The internal HISTORY changelog is a software technique used for decades, and it lists only major changes (not every time Bots shift a space/comma or revert a hack). On busy talk-pages, the updates get buried or archived. The 2nd template was tested on several non-FA articles, but someone removed it from all articles, giving the devious impression it had no use.
    Of course, I've done programming (and systems engineering) as a career: that is how I knew to avoid paralysis of analysis with a 2nd template. Also, I expected many people to keep suggesting new features, which is what they did. It was User:Mizery_Made who suggested adding track lengths as "mm:ss". It was User:Bread_Ninja who requested 2 templates, saying, "It would be great if we had to[2] templates, because those related to game OST, one would slightly be larger than the other. we've seen multi templates for stuff like this, why not for tracklist? i was thinking it would have two extra sections, extra and extrab." Hence, now there are 2 templates, with {{Tracklist custom}} providing new features. The further request was for 2 extra columns, such as extra1/extra2 & more1/more2 to put two additional data columns on tracks 1 & 2. So, you see, it was not me, but the other users who wanted more and more new features. I was providing something for everyone, not creating a so-called "end-run" to bypass what people wanted. Even Bread_Ninja specifically wanted this 2nd template, who had seen "multi templates for stuff like this". Indeed, forcing album track-tables to use only 1 template is severe, compared to other templates on Wikipedia. We have both {{Convert|1.85|m|ft}} & {{Height|m=1.85}} for m-to-feet conversions: 1.85 m (6 ft 1 in). So that proves my point: some people want to over-analyze and debate even the obvious: other people requested these features ("No they didn't, you invented it all" ) or other articles have Convert-&-Height ("No, they shouldn't: those are fork templates & extra maintenance"). This TfD entry is just more "paralysis of analysis" in trying to paralyze the solution to the first paralysis. It is a waste of everyone's time. Stop debating, and just work on something else. Leave this template alone, so it can make some progress. -Wikid77 08:49, 30 May 2010 (UTC)[reply]
    FYI, we are working with the very same editors you are citing on the template talk page right now. – Cyrus XIII (talk) 08:41, 30 May 2010 (UTC)[reply]
    You said, "I've done programming ... that is how I knew to (address this) with a 2nd template". So if, for example, you were on a project involving a database and/or its access applications, and you or a small group had special needs that weren't being addressed by the existing system, and you didn't have time to get improvements added through normal channels, you would consider creating an unauthorized duplicate database or access system for the use of the small group? NO, DON'T ANSWER THAT... I'VE SEEN IT DONE! (The foregoing was stated for a little levity, but it makes a point: I have seen it done, an when it was found out, it wasn't allowed to stay. History repeats.) --A Knight Who Says Ni (talk) 16:22, 30 May 2010 (UTC)[reply]
    On software projects, there is typically a waiver process]] to quickly authorize changes (when no time for approval "through normal channels"), and Wikipedia does not require prior approval to create articles or templates.
    Consider essay: "WP:Redundancy is good redundancy" and the many NASA policies about when to use redundancy, versus variation. There have been several Space Shuttles, but each has been a little different from the others: the next Shuttle to fly might have a new type of computer not used earlier, or some other new features. The exact meaning of Shuttle Atlantis changed, from year to year, depending on the upgrades to the technology in the spacecraft. Multiple templates, or multiple Shuttles, offer benefits in the variation, as well as in the redundancy, and the first computer used on Shuttle Endeavour was radically different (not a fork) compared to the computer on Shuttle Columbia. Multiple templates for similar purposes can produce many benefits over a single template. -Wikid77 (talk) 04:37, 31 May 2010 (UTC)[reply]
    Isn't this comparison a little off? If we'd apply the same logic to what we are discussing, it would mean that with every new revision of the template, every article using it would either be stuck on the the previous version or have to be manually refitted. If anything, you could losely compare the template to space shuttle blueprints, but with the added benefit, that NASA could refit their entire fleet at zero cost or effort, once the theoretical design has been improved. I'm sure they'd have loved that. And by the way, the original template already has several options to handle different situations in different ways, that's not a novel design paradigm here. – Cyrus XIII (talk) 13:24, 31 May 2010 (UTC)[reply]
    The comparison is how multiple Space Shuttles, like multiple templates, allowed new features (not minor fork improvements). One Shuttle could have a radically different computer to run the avionics flight software, so it would be improper to call the new computer as a "fork" of the older computer. The major new features were possible because the various Space Shuttles could be quite different: some had a large robotic arm, in the cargo bay, while others did not. -Wikid77 (talk) 23:28, 31 May 2010 (UTC)[reply]
    For the record, "It was User:Mizery_Made who suggested adding track lengths as "mm:ss"." was not a feature request, but actually a request for your proposed feature to accord to the Manual of Style. – Mizery Made (talk · contribs) 04:34, 3 June 2010 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review). No further edits should be made to this section.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Templates_for_discussion/Log/2010_May_28&oldid=1088097897"