User talk:Eyes

Regarding your bot

First I'd like to say Welcome to WikiSWTOR!

It's very likely it will not work, as AWB does not play nice on the Curse network. While I have not specifically tried it here on WikiSWTOR, it's been true on every Curse wiki I have tried it on. The only botscripts that seem to function properly are python based ones. I just wanted you to know that you should probably test it, before making any extensive plans to use it. --Wynthyst 08:34, 10 November 2011 (UTC)

Interesting. I've been using it successfully on STOWiki with no problems. I'll try to set up some kind of harmless test today or tomorrow and verify it works here, though. (Could it be something to do with the anti-abuse extensions? We're not quite fully set up on STOWiki yet.) — Eyes 12:03, 10 November 2011 (UTC)

I was able to connect with AWB, get page lists from categories, and successfully made an edit. The basics seems to be working alright for me. — Eyes 13:51, 10 November 2011 (UTC)

LOL! well, then you are a better bot man that I! I'm happy to hear you got it functioning, as having a working bot is always a good thing for those tedious types of things. I just wanted to give you a heads up that AWB has proven problematic on just about every Curse wiki I work on, so you weren't pulling your hair out if it didn't work. --Wynthyst 21:35, 10 November 2011 (UTC)

Would you like a bot flag? -- Wynthyst talk 21:51, 20 November 2011 (UTC)

It would be appreciated. I can always run the bot under my main account when it's something that shouldn't be hidden from RC. Thank you. — Eyes 04:54, 21 November 2011 (UTC)

Licensing template format

I'm guessing you missed it, but I implemented a Fairuse licensing template some time ago, and after getting it approved have begun using it on the project. You can see an example of it being used on File:SS 20091127 Alderaan01 full.jpg. -- Heaven's Agent 07:04, 15 November 2011 (UTC)

Indeed, I did, because I only checked to see what was set up in MediaWiki:Licenses. The problem is, what I've just set up for this wiki is a unified licensing system relying on a single core template. If we decide to use this setup, setting up that template as a redirect is probably the easiest way to make the existing licenses consistent. I will, however, change these templates to use the existing category before asking Wyn to set up the license dropdown on the upload form appropriately. — Eyes 07:17, 15 November 2011 (UTC)

Yes, but your templates seem too restrictive in many instances. For example, a user uploading his or her own work does not currently have the option to specify which license the work is released under. I'm guessing the goal is to define a license template for every instance, but this an impractical goal. They need to be flexible enough to be applied in various circumstances, especially those that the designer does not necessarily perceive when the template is written. A core template make sense, but the system built upon it needs to be custom to this project and flexible in its application. -- Heaven's Agent 07:42, 15 November 2011 (UTC)

Do you mind if I make some alterations to the basic template design, to bring it more in line with what was already approved, as well as bring my Fairuse template into the structure? -- Heaven's Agent 07:47, 15 November 2011 (UTC)

If you're going to do that, I'll wait on giving Wyn the code for MediaWiki:Licenses then, since I'll have to see what changes you have in mind. Keep in mind, though, for any one-off cases, there is no reason Template:Image license can't be used directly on image pages. There's where the flexibility comes in, though adding a license parameter to Template:User created image would also be trivial. — Eyes 07:55, 15 November 2011 (UTC)

Is it going to be that much trouble to alter the template's appearance once the MediaWiki:Licenses code has been implemented? I ask because we are expecting a major change in project appearance in the near future, and such redesign will be necessary at that time. There is also plans to support user-defined skins, so it would need to be changeable in those situations as well. -- Heaven's Agent 08:04, 15 November 2011 (UTC)

What happens behind the scenes is this: a user selects one of the options for the dropdown (say the user chooses "I don't know the license" which we've attached to Template:Unattributed image through MediaWiki:Licenses), and the wiki puts this on the bottom of the page below the summary:

==License==
{{Unattributed image}}

So, no, any appearance changes made are irrelevant, and that's part of the advantage of the core template design. But I'm not clear on how you're bringing the preexisting fairuse template into this, so I have to wait and see if I'm going to have to add another template/user-friendly description pairing to the code, since as an non-admin, I can't edit the MediaWiki namespace. I can only make it easier for Wyn by writing up what goes there so she can check it over and just copy-paste if she finds it acceptable.

And yes, the simple user-friendly selection scheme built into the software has its drawbacks. Since selecting a template is all it can do, it's really only good for common cases. For one-offs, going back and editing the file page by using Template:Image license directly is an inconvenient way to do things, but it does let users specify whatever they want. That's the aim of this: ridiculously easy for the most common cases, harder but still possible for all others (since that's really the best that can be done with the existing mechanism). — Eyes 08:21, 15 November 2011 (UTC)

That's what I was thinking, but something you said made me believe otherwise. That said, I couldn't tell what that was exactly. A new day, and many things appear clearer, and all that.

I won't worry about adding the existing template to the structure; the most important thing is that the templates are in place so they can be used, and probably incorporated into a Image and Media Policy. It may take me a while for me to read and understand your core template and make the existing work function within it. With the game launching in a month, we need to get such things squared away soon.

Since the code does automate what appears, I would like to see a few more standard parameters get added to the structure before being presented for implementation. In addition to Author (which we might consider changing to "Artist"), a "Copyright" parameter is appropriate to list both the date the media was copyrighted and the copyright holder(s), should they be different from the artist. A "use" parameter would indicate the primary articles an image is intended to be used on, and a "description" parameter would serve to elaborate on what an image depicts. The "License" parameter should also not be hard coded into so many of the template; it can be added as an optional parameter that can be defined by the uploader or left to its default output.

We might also want to remove the statement "This image may be used freely on user pages" from the core template. A user uploading his or her own work, for example, should be able to specify where on the project that work can and cannot be used. Finally, the default license of several of these template designs should not be the GFDL 1.3; this project generally operates under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0), which should probably be used instead. -- Heaven's Agent 14:41, 15 November 2011 (UTC)

The wiki's copyright page indicates GFDL 1.3, so if that's wrong, that should be corrected first. Ideally, the templates would default to the correct license, which is what I thought I was doing.

I don't think description should be part of the license template. That's more what the summary part and rest of the file page is for. I'd rather keep these templates dealing with things directly related to the license, not the content. Otherwise, these essentially become file page templates, and while there's nothing really wrong with that approach (some advocate a template-based approach to all pages on a wiki; it's a key part of the Semantic Forms-based approach to wikis, in fact), it's a new way of thinking for most wiki users presently, and Wyn's stance on Semantic MediaWiki would suggest she prefers the tried-and-true approaches (and the benefits and drawbacks thereof). I honestly haven't seen too many wikis include the copyright year, but there would little harm in adding support for a copyright parameter--I just have my doubts about your average editor going back and using it.

Keep in mind these are really just mildly modified license templates used by other wikis (on Curse's network, no less), so you can hopefully understand my surprise at the reaction here. As for switching from hardcoded values to defaults, it makes more sense to me for the core template to handle the special cases rather than try to make each template capable of handling them (which would seem to be the point here). That's just a reflection of how I've seen license templates actually getting used. It's not a whole lot of work to do what you ask when you look at it by itself, but it is a lot of work when you compare it to the tiny benefit the community is likely to derive from it. Other than correcting a blatantly incorrect license choice, I've never seen anyone go back and refine the details of a license on a specific image--we might be talking about adding features that no one will use. This is why I sometimes prefer to wait and see if a need arises rather than adding layers that need not be there; even if it's not a lot of lost time, it's still lost time if they never get used. — Eyes 15:54, 15 November 2011 (UTC)

(Resetting Indent)
Most of the additional parameters can be optional, and utilize if-then syntax to allow them to be incorporated only when the parameter is defined. A good candidate for this would be the "copyright" parameter I mentioned. You're correct that many users won't care to include this information, and it isn't always a concern anyway, but it is something we should probably include for those instances when it is known and/or necessary to include.

I would have to agree with your hesitation to create page templates. I've always preferred to leave wiki article layout more organic. This can result in layouts that may not be perfectly identical across the project, but it also allows users to make improvements in the design of what was present before. That said, I still recommend a "description" parameter; in my experience, an image uploader usually neglects to include such a description. Making it a parameter, even if it is only an optional parameter, should prompt more uploaders to add such comments to files. File pages are unique articles anyway, and I don't believe a unique treatment would be a detriment to their purpose.

I apologize if my reaction is surprising to you. Keep in mind that most of the currently active contributors here were/are Admins on different projects elsewhere. We've had similar, but in many ways different, experiences with these basic foundation elements. We may be adding features that, in the long run, will not be used, but it's easier to account for them at the start. Additionally, simply by including the options within the template, we may be prompting their use more often. Because a template is used over a wide range of articles, reasonable flexibility should be a primary concern in their design. As you said, it is a simple matter to include optional parameters as I've mentioned, so why not do the extra legwork now? I think this is especially important due to the number of rival SWTOR wiki projects that currently exist. Including these extra features will allow us to appeal to a wider range of users, even if they are never used, simply because the options are available; people enjoy having freedom in anything they do, even if they end up taking that freedom for granted. -- Heaven's Agent 16:17, 15 November 2011 (UTC)

Funny, I probably would have ended up using a similar argument against Wyn's point against SMW eventually. (Using it more heavily and visibily would help solve the chicken-and-egg problem that makes her argument valid in the first place.) I admit I'm less convinced by the argument on something as peripheral as license templates, but I will do as requested. It just may take me a few days to find a good time due to the middle of the week tending to be busiest for me, but I should have plenty of free time on Friday. — Eyes 16:31, 15 November 2011 (UTC)

Hehe, I must admit I'm unfamiliar with SMW; it's not been used on any of the projects I've worked on. When you brought it up to Wyn I did some looking into it, but I'm afraid I ended up being more confused. I'm guessing the reason is that I lack any formal coding training. I'm entirely self-taught.

If nothing else, I'd use those parameters, as can the other regulars to the project. Take your time; as much as I hate to admit it regarding something I'm passionate about, wiki work has to take a secondary role in my life as well. I've got several things I really want to get done before launch (one of which is getting all instances of the content license switched to Creative Commons), but with work and school my time is fairly limited. Of course, I imagine that's the case for most wiki contributors. that said, we've got a great community coming together here. A lot of folks with past experience in multiple types of wikis, each bringing individual perspectives and experiences; I think it'll end up being a great boon to the project. I even recognize a few names from past wikis. It's going to be a blast. -- Heaven's Agent 17:19, 15 November 2011 (UTC)

Since my response is to the conversational tangent, I'm making a separate section.

Semantic MediaWiki

I don't blame you. I personally believe SMW's introductory documentation is horrible, which is probably part of the reason for the chicken-and-egg problem.

To put it in simple terms, think of conceptually as creating a kind of hidden infobox for a given page, but instead of using that information on that page, you use its queries to pull that information onto other pages. The simplest example of the usefulness of this is that instead of manually maintaining something like a quest list page, you automatically pull the info off the page and format it with a template. This usage doesn't require the page-as-template approach I described, but you do need templates to format your lists in the example I mentioned. It's a tradeoff of more work initially to save work in the long run since many small edits no longer have to be done. There's also a slight loss of flexibility since adapting to changes requires some additional adjustment work, since you have the hidden data to consider as well.

For most gaming data I've seen, it's nice but not having isn't a big deal. The extra work of maintaining certain pieces of information across separate pages is annoying and somehwat prone to errors, but it is a manageable problem by an active community. I would not have wanted to try documenting Star Trek Online's duty officer system without it. It's a highly structured system with a huge amount of very regular data (we've been told there are 6,000 duty officers, but the only relevant information about each is a handful of small data items), meaning there were many logical way to present listings of the data and it would have been completely impractical to do it by ordinary organic methods. In that case, the page-as-template approach with Semantic MediaWiki + Semantic Forms has proven to be extremely helpful.

But for most of the things we need to document in games are more mixed, having a combination of highly structured data like you would use in infoboxes and less structured data like descriptions and walkthroughs, and there, I believe a mixed approach is best. (And most wikis do this by making infobox templates for the less organic content; they just don't usually go the extra mile of having templates set up the semantic data too). Unfortunately, Wyn's not exactly wrong about there not being enough people who understand it. That's why your argument about expanding the image license templates applies to this too; a wiki that is able to set it up early and use it throughout for the "non-organic" information could likely teach users its advantages and how to use it because they'd be able to see how it works.

I think another reason for the chicken-and-egg is that we technical users are taught to black-box things because we're usually dealing with situations with end users that properly don't care how something works as long as it works. For SMW to be truly successful on a wiki, I think it'd have to be done in an open-box way (for example, turning on the factboxes so the "hidden infobox" isn't actually hidden at all would reveal it's not nearly as complicated as it first seems). — Eyes 18:03, 15 November 2011 (UTC)

It essentially functions as an automated database, then? It would draw defined information from specific sources and tabulate that information in an orderly method as needed? That would have definite benefits, but Wyn does have a valid point about general usability.

Your last paragraph sums things up pretty well; if the application could be presented in a manner that allows an average user ro not only understand what it is and what it does, but how it functions as well, then its implementation would likely not be an issue. I hate the term, but if it could be "dumbed down" for those of us with less expertise in the specific field, it sounds as if it could become a true asset. Doing so, however, is often a lot easier said than done. -- Heaven's Agent 18:26, 15 November 2011 (UTC)

Jumping in here since you've piqued my interest. Do you have any links that can help break someone into SMW that's never dealt with it before? -- Alianin T • C 20:17, 15 November 2011 (UTC)

Not off the top of my head. The user manual for it isn't too good unless you already have a fair understanding; it's a good reference, but a poor educational tool. You can get a glimpse on guildwiki.org, though, since they have the factboxes enabled to always show. Go to a page like Copper Shilling and you can see the properties that are set. If you want to dig deeper into how the properties are set, the infobox template used that page is where it happens. But why not, I can give a real quick primer.

• Properties can set on a page in two ways. If you want the value to actually appear where you're setting it in the code, setting is kinda like making a link: [[Has item rarity::Common]] puts "Common" in "Property:Has item rarity", and the word "Common" appears in the text where you set it. When you need to set a property without the value appearing, you do {{#set:Has item rarity=Common}} instead.
• By default, the link syntax actually links as if Common was a page. You change that making a property page for [[Property:Has item rarity]], and on that page somewhere, you include [[Has type::String]] to tell SMW that the individual item rarities don't have pages associated with them; they're just text. Now, SMW will display [[Has item rarity::Common]] just as "Common" without making it a link.
• Just for an example, let's say that the rarity was set to Common on the Flare Gun page (which is know is probably wrong, but not important here). If I want a simple table of all items in SMW's standard format, I can do this: {{#ask: [[Has item rarity::Common]]}} and that will give me a single column table with links to all pages where the item rarity is Common.
• For a slightly more complex example, let's deal with the common problem of disambiguation. Let's say something weird happens in the game and there's two different versions of the flare gun of different rarities, which we name Flare Gun (common) and Flare Gun (rare). The tactic I used to deal with this is have a property called Property:Has name which is usually set to the page name, but on these two pages, I set it to Flare Gun because it is the actual item name for both of them. I want the links to display the actual in-game name, not the page name, and want to change the text color based on the rarity. So, I do this:
  • {{#ask: [[Has item rarity::+]]|?Has name|?Has item rarity|format=template|link=none|template=Itemlinklistitem}} <-- this is called an inline query
    • [[Has item rarity::+]] tells it to show me all pages that have anything set for Has item rarity, no matter what it is.
    • |?Has name|?Has item rarity tell it to add the value of these two properties to the results. SMW calls these parts beginning with ? printout statements.
    • |format=template|link=none|template=Itemlinklistitem tells it to send the results through the Itemlinklistitem template without first converting any of the values to links, even if they are page names.
    • In the Itemlinklistitem template, {{{1}}} has the page name, {{{2}}} has the value of Property:Has name for that page, and {{{3}}} has the value of Property:Has item rarity for that page. This is because the page name is always the first (actually, you can suppress sending the page name in at all, but by default, the page name for the result is {{{1}}}). Property:Has name is {{{2}}} because its the first one I requested in the query, and Property:Has item rarity is {{{3}}} because it's the second I requested.
    • Let's assume we have CSS classes called common, uncommon, rare, etc. that take care of setting the link's text color, because that makes this example easier (and I don't have to bother with showing parser functions that aren't part of SMW, though they tend to come in handy when using SMW). Now my Itemlinklistitem template looks like this (ignoring any documentation and just dealing with the functional part of the template):

*<span class="{{lc:{{{3}}}}}">[[{{{1}}}|{{{2}}}]]</span>

• • • The lc part just converts the rarity to all lowercase.
    • We'll get a bulleted list that includes both links to the two Flare Gun pages, but each will be in the color matching its rarity, and each will display "Flare Gun" as the link text while still linking to the pages "Flare Gun (common)" and "Flare Gun (rare)". That's because it calls the template for each item.

The user manual does become helpful once you understand a practical example like the one above, but as far as I know, they have no good bite-size practical overviews that take you from input to output like I just tried to write here, especially not any that deal with common headaches like accounting for disambiguated pages. — Eyes 21:28, 15 November 2011 (UTC)

OK, so it's actually more like an automated categorization system that uses defined values, such as the parameters of a template, to populate the categories. That's neat, but I don't see many real practical applications for it. Can you search for information by more than one variable? For example, could I search for items that were both Common quality and introduced in the Nightfall campaign? -- Heaven's Agent 22:48, 15 November 2011 (UTC)

Yes, you can use multiple conditions. The query for that is {{#ask: [[Campaign::Guild Wars Nightfall]] [[Item rarity::Common]]}}. You could also do an OR condition with {{#ask: [[Campaign::Guild Wars Nightfall]] OR [[Item rarity::Common]]}}. It's more than just categorization; it's like a basic version of SQL. Your description of it as a database is a good metaphor, though it doesn't quite have the raw power and flexibility of one. It can also query based on standard MediaWiki categories, i.e. {{#ask: [[Campaign::Guild Wars Nightfall]] [[Category:Trophies]]}}, though it lacks some control in that respect. (Automatically gets results from subcategories too; as far as I know, you can't selectively shut off that behavior when you might want to.) Also, for properties (not categories), there are some comparison operators: i.e. I want every item with a merchant value of 100 or more: {{#ask:[[Category:Items]] [[Merchant value::>100]]}}, or I want items that are not from Nightfall: {{#ask:[[Category:Items]] [[Campaign::!Guild Wars Nightfall]]}}. Everything before your first pipe character (or closing braces if you don't use one for that query) is treated as a condition. iirc, each query can take up to 12 conditions. — Eyes 23:11, 15 November 2011 (UTC)

Is there any way to put this function into a user interface, so that the average user can run a search for certain parameters? Or is this something that you would need actual knowledge of the application in order to access? Also, how did this assist you increasing a table of bridge officers? Unless I'm missing something (and I very well might be) you would still have to add each entry to a table by hand. -- Heaven's Agent 23:34, 15 November 2011 (UTC)

Semantic MediaWiki has a special page where you can run these queries dynamically, but sadly it requires knowing the condition and printout statement syntaxes. That's always disappointed me. It's only useful to those who understand the basics. Property pages get a handy feature of having an automatic list of all pages with a value set, though, along with the value in question, like a category page.

The data still has to be entered, yes. What SMW does for us is let us create separate tables of the same data easily. Right now, we have tables of duty officers by their specialization (example) and by their traits (http://www.stowiki.org/index.php?title=Trait:_Resilient/doff example). I plan to set more up by species, and possibly some tables for the higher quality duty officers, both of which won't take much time. Without SMW, that would mean entering the data three to four times. (Actually, with tables by trait, it would be more than that with so many duty officers having three or four traits.) Ultimately, it's not about not having to enter information, but being able to enter it only once.

As I mentioned earlier as well, this case was uniquely suited for Semantic Forms. With so many duty officers and the data for each so structured, we did end relying on the page template approach for them to make the data entry easier. To see the way the pages get created and edited, go here and click Edit with Form. To add new duty officers, we go to Form:Duty officer and type in the new page name. That form then feeds to fields to Template:Doffpage to lay it out. The combination of the two was to help streamline a really data-intensive part of the game. The alternative that was being considering was using only tables by specialization (no duty officer pages at all), which would have been very awkward since it's very difficult to get all the data to fit neatly on one row. For most wiki content, though, the Forms approach is too restrictive; this is just a unique case where restrictive was a good thing.

Another quick note: the page naming conventions they like to use added unnecessary complexity to the system. I wouldn't be recommending fake namespaces like "Specialization:" or "Trait:". If you look at the guts of the system, a lot of the complexity involved is dealing with that. Simpler page name conventions also make the formatting templates easier too. — Eyes 04:55, 16 November 2011 (UTC)

Well, the why and the what makes perfect sense now. It is definitely a very robust tool. That said, you lost me entirely on the how. I can understand Wyn's concerns on that point; I think it would be an amazing utility to incorporate here, but I don't know if I'm ever going to understand how to implement it. I wish it were a tad easier to understand. From what you've said, it not only sounds useful, but enjoyable to use once you understand the thing.

It occurred to me that there's another issue you'll have to overcome in convincing Curse to implement this utility as well. It seems like there's nothing Semantic MediaWiki can accomplish that a database can't handle, and in many cases a database will do a better job of it. Wyn mentioned that Curse is considering the implementation of a true database once the game launches, and adding it to our little community of affiliated projects. If this is indeed the case a lot of the potential value of implementing the utility will be minimized, since the database site will address the same issues. I bring it up as something to think about, as I'm guessing you'll still be promoting its usage here in the future. :D -- Heaven's Agent 05:46, 16 November 2011 (UTC)

(Resetting Indent)
It's a fair point. A database has more robust querying capability. Ultimately, if we don't use it heavily, I'd prefer to have it handy because every now and then a game throws some kind of data or mechanic at you that can be awkward to handle through normal methods. These extensions come with a few side perks that are just generally useful. (The arraymap and arraymaptemplate parser functions are invaluable even if no other part of Semantic Forms is used.) That said, I might be able to duplicate those functions by writing an extension myself (and having such useful functions locked away in an extension to an extension makes me a sad panda anyway).

Anyway, I'm going to wait on make a further case until we see what skills we'll have in the community once it starts to grow. Wyn's atgument is based on what skills and knowledge the community will have on hand; if we get enough people who grasp the fundamentals of this, then I can make a more reasonable case that the wiki won't be in danger of losing the knowledge just because a few editors leave. Since it's a human argument and not a technical one, the best response will be a human argument and depends on what shape the community takes.

Otherwise, I'll have to wait for a specific case in SWTOR where the traditional methods are just so awkward compared to the SMW approach that I can argue for it. That may or may not happen; hard to say. — Eyes 11:35, 16 November 2011 (UTC)

Re: License templates and short-sightedness

Well, my perspective of the situation is based on the fact that you're arguing against the addition of functionality that shouldn't have any impact on what's already in place. There's no reason that the templates can't function both ways. And yes, I'm going to go with not doing so being a matter of lazy design, because the other option is that you don't know how to code a template in this manner, and I'm pretty sure you do. It shouldn't be awkward to implement, either.

Don't misunderstand my hesitation to edit your templates. I simply didn't want to mess with them while you were still tweaking them to this project. You should also not take my statements out of context. I choose my words carefully, and as such their meanings are very specific. Your coding isn't short-sighted, but your refusal to recognize my perspective as a valid concern is. And yes, you may have been prioritizing what you've done based on time available. As a result, though, you're not necessarily giving the design the attention you should be. It may be justified, but it still represents poor design practices.

I like aspects of your template design, and think they will be a great benefit to the project. I brought up valid concerns and additions. If you had stated, from the beginning, that it was purely an issue of time, then I would have been happy to simply take the work upon myself from the start. I had been planning to do so anyway. Instead, you dismissed my concerns, and questioned the validity of my statements. I mentioned some time ago that many of the contributors here are current or former wiki admins. We all have our own unique experiences, and with this in mind it is imperative that all of our perspectives and concerns be seen as legitimate. I've had to bite my tongue a lot since you started your template implementation; to be honest, I was offended when you began. I had already taken time to design a license template format, get it approved by this project's current staff, and then started implementing it. Without seeking approval, and without considering the work that might have been done prior, you brought in your templates in their entirety. When I mentioned to you that an approved format had already been established, you dismissed that format and continued what you were doing. That being said, I reminded myself that you may have encountered something I hadn't. As you continued to add your templates, however, you stomped on my work and disregarded my concerns. When you do this, I will speak my mind. -- Heaven's Agent 00:13, 20 November 2011 (UTC)

Well, it's funny how we both came to feel the same way, then. I will apologize for not realizing that a license template existed. I made the mistake of checking only MediaWiki:Licenses to see if the dropdown was enabled. I admit I wouldn't necessarily have stopped because a single template doesn't work well with dropdown, but I would have more likely to use that as my initial design.

It seems to me I got into this situation by doing exactly what every wiki asks of its editors: being bold. This is now being characterized as negative. Even when I put extra time in to make changes I didn't believe in (because that was what I thought I was being asked to do), I was apparently "stomping on your work and your perspective?" When I decided not to make changes based on a single editor's argument that failed to convince me, I was once again "stomping on your perspective?" Apparently, to not "stomp" on your perspective, I must agree with your point of view?

What you apparently see is you trying to be extremely reasonable and me saying "My-way-or-the-highway", and I'm seeing the exact opposite. If you can't understand why I can see it that way, then we're in trouble. I acknowledged the legitimacy of your template-as-learning-tool viewpoint in more visible templates, yet you say I'm not respecting it. Meanwhile, you continue to challenge mine. But then, maybe you challenge it because you just disagree, and not because you disrespect it? If that's the case, why is it disrespect when I do the same thing?

But I believe you are disrespecting my perspective, because you're stating that the need to consider all use cases is a fact. The only concrete argument given that supports it is the template-as-learning-tool argument, which is an argument whose value depends on the use case of the templates. The rest of your "argument" against is nothing more than a stealth appeal to ridicule: "poor design", which is not an argument at all.

I went out of my way to apply my arguments to the license template context initially, and you expanded it to ridicule the design practice behind it. I gave a concrete reason why considering every use case including the ones unlikely to come up is actually harmful (because of the loss of opportunity to do something even more valuable), and you simply repeated the appeal to ridicule argument. Frankly, I have experience with your viewpoint; I use to believe the same thing, and found my projects turning into unmanageable behemoths because of it. The opportunity costs have been extremely high; I would have much more to show for myself had I abandoned the idea that it was simply "poor design" to decide against supporting very unlikely use cases. Frankly, judging by what I've been reading, this viewpoint is becoming increasingly common and dominant among the IT field as well, so I'm far from the only one beginning to see that characterization for what it is.

That said, the specific context of the license templates is a tighter judgment call because the time involved isn't particularly significant (and apparently, even less so to you than me), and I acknowledge that. I still argue that time is better spent elsewhere, which is why I'm not going to invest the time myself, but you may invest your time as you see fit. I'm arguing the principle not out of disrespect, but because personal experience has taught me there's a significant, nearly universal flaw in trying to design for every case. I only ask that you practice as you preach; whether you agree with the opportunity cost argument or not, stop using the appeal to ridicule, because you don't get to pretend you respect the viewpoint when you do that. — Eyes 10:04, 20 November 2011 (UTC)

In fact, I'm beginning to think you're not even following the philosophy you're advocating. Part of the design was to allow users to easily create a derived template if they were uploading many images under a license we didn't cover yet. You want a tradeoff that increases the complexity of their task (by not just implementing default instead of hardcoded values but insisting that default be implemented with a parser function rather than simple parameter syntax). Both use cases seem unlikely to me in practice, but making another derived seems more likely than license templates becoming some new user's enlightenment into templates. I believe now you're attempting to elevate your preferred use case above all others without real justification, and that's why you have to resort to appeal to ridicule.

I will do nothing to oppose any of your changes, but don't expect to me to believe any longer that your interests are actually trying to examine all perspectives fairly. Based on this, I intend from this point on to remove myself from this controversy, because frankly, this situation started in drama due to one small mistake on my part (which you effectively admitted through your offense that I missed your initial template), and I beginning to believe it was more that drama than honest disagreement that led it to this point, and after consideration, drama is more harmful than the implications of the design decisions we're discussing. So, by all means, make your own decisions on the license templates; alter them if you want, mark them for deletion if you want, present them for approval if you want.

Because this really now seems to be about the newcomer charging in and doing things his way, anyway, and I've effectively denied my own arguments by wasting this much time on it. I'm genuinely sorry for my own role in things getting this far, and I think we both to some degree lost sight of the ball in our own way, so I'm bowing out. It's clear you're willing to address licensing, so I'll try to find something that isn't being addressed at all that (hopefully) won't be controversial. At this point, it's my conclusion that it's best for the wiki that I still contribute, but that I avoid being in your way or stepping anywhere near your footprints. — Eyes 12:14, 20 November 2011 (UTC)

No, I don't expect everyone to agree with me. I do expect my concerns to be addressed and considered, though. Instead you dismissed them entirely, stating that the things I brought forward were a one-time thing and indicating that they weren't even worth your time. And yes, you should be bold, but you failed to recognize a key aspect of that practice: you need to respect the community and the work that's been done previously. You could have used my template design as a foundation, built and improved upon it. Instead, you indicated that you felt it would be better to simply eradicate my work. I believe you said something along the lines of the best thing to do would be to turn it into a redirect. You didn't even try to derive your templates from what was already present. Be bold, but be respectful.

If you think you acknowledged the my template-as-learning-tool viewpoint, you chose a unique way of expressing that. You called it a "one-off case" and rare. You claimed that, due to your experience, this viewpoint would not be a concern, and then proceeded to lecture me on what would actually happen. This is real close to the exact opposite of acknowledging my viewpoint. This is how you stomped on my perspective. The case I presented was how I, personally, learned to edit wikis. You made it clear several times that you doubted the truthfulness of this. Yes, I actually began wiki work by copy/pasting and editing licensing templates to images that lacked them. It's how I gained an initial understanding of wiki editing. This is also how I've witnessed others, on several occasions, gain similar basic understandings of wiki work. By doubting my statements you were doubting my personal experiences, as both a wiki contributor and an Admin of several past projects.

You would be right, I don't have respect for you at the moment. I want to, but if I'm going to be perfectly honest it's hard to respect an experienced wiki contributor who fails to show similar respect to the work that's been done previously. That's a foundation of wiki design: you build and derive your work from what previous editors have written; it is vital that previous work be respected.

I tried to be respectful of your work, despite my feelings for you as an individual. When I brought forward what had already been done, and you dismissed it, I held my tongue. When I questioned the need for such use-restricted templates, and you disagreed, I once again deferred to you. It is extremely hard to respect the work of an individual you do not respect as a person, which is ridiculous since I don't even know you, but that's the situation. By expressing a wish to discard the work done in the past, you failed to earn my respect. By dismissing the validity of another's experiences, in this case simply because your own experiences did not align with them, you actually offended me. Now I pity you; bowing out rather than coming to an understanding is no way to be a part of a community. If we're to work on this project together, we have to find some common ground. Trying to find ways to contribute that will stay out of each others' way simply won't work.

I'll start on the templates, but only if you're sure you're OK with it. I don't come from an IT background, and as such I don't have much understanding of the code you utilized. I would have to rewrite the templates using the styles that I'm familiar with, which would mean replacing your work pretty much in its entirety. I won't do that to another active contributor without their full understanding and their go-ahead first. -- Heaven's Agent 13:36, 20 November 2011 (UTC)

-_- So, this is what you thought I said? No wonder.

Okay, in the interests of trying to achieve an understanding (which I'm beginning to believe might be possible again now that I see how much of this is misunderstanding), I'll try to clarify my points. I believe I understand yours, but your description of my viewpoint is wildly inaccurate.

• License templates are a special case because of how rarely they are directly used. It's almost always select-from-dropdown and go. File pages are also edited rarely. So I saw template-as-a-learning-tool as being a one-off in this context. I never intended to extend that part of the argument generally as you have stated I did. I actually agree it makes sense generally, just not as an absolute to apply to all situations. Either I somehow failed to convey the limited context in which I was discussing the point, or you failed to catch I wasn't arguing against the point as a general concept; just against universal application of it. I felt you were the one widening the scope of the argument when you brought "lazy design" into it; I didn't realize you thought I had already done so.

• By the time I knew the template existed, the work was nearly done. I apologize that my interest was in getting a workable system in place quickly, so I did look at it in terms of what was most efficient to achieve that, and I apologize for missing the template again. Even you seemed to express an interest in getting it done. I admit that in the many things I trying to consider, I didn't consider how you would react to my suggested solution. I'm sorry, I thought I was thinking of the wiki first.

• One thing I didn't say that contributed to my surprise on this: my original plan was to get something in place to get the dropdown working because I've seen that when that dropdown isn't populated, licenses don't get applied. That you guys were applying licenses despite this is to your credit, but I didn't see that being something most users would do.

• Also, as I was mentioning, this was a system I mostly borrowed. I did that because STOWiki had nothing in place, and I wanted to stop adding to the massive backlog of images with no licensing. I made the mistake of believing the same thing was likely happening here. Ultimately, there were even things I didn't like about the system and intended to fix up later--like having a request to edit the page without any instructions for how to do so. I took the initiative to put something in place to address that that while I was addressing the desire for additional parameters.

As far as how to proceed, it occurs to me that the parameter change might be something I can bot with AWB; I think now I incorrectly dismissed that as a possibility. I'll have to run a test to see. In this case, I'll leave it to you which solution you prefer: my quick one that will use the defaults for blank values or your redesign. I still don't think it's a good tradeoff, but it's a minor one in any case. Just do me the favor of deciding if there's any other changes you want made. I just don't want to get into changing them every other day to address really small tradeoffs. (And because it is small, I'm done arguing the case. When the conflict is between two people believing mutually exclusive things even when they understand the opposing viewpoint, compromise in belief doesn't seem possible. Compromise in action seems the only choice.) — Eyes 15:35, 20 November 2011 (UTC)

It was awkward to set up, but the bot can make the template changes automatically. Let me know what you want to do. — Eyes 16:14, 20 November 2011 (UTC)

Actually, it isn't the default for blank values that I have trouble with. It's that this application isn't functioning in this manner in all cases. I think there might be a misunderstanding in this respect as well.

Currently if you include a parameter with a default value, but leave that parameter undefined, it sometimes removes that parameter entirely from the template's output. It might simply be easier to show this, than attempt to explain it with words. Your Fair use image Template, for example, produces the following output in its most basic form:

Copyright Details

View template · Edit template · View documentation

License:	Fair use
Source:	Please add the source to this page. See the template documentation for instructions.
Artist:	Please add the artist's name to this page. See the template documentation for instructions.
Usage:	This image can be used throughout the wiki as long as the usage remains consistent with fair use doctrine.
WikiSWTOR notes:	The editor who uploaded or tagged this believed its use qualified as fair use under United States copyright law, as such display does not significant impede the right of the copyright holder to sell the copyrighted material, is not being used to generate profit in this context, and presents ideas that cannot be exhibited otherwise.

If you believe this image is incorrectly licensed, you may discuss this on the image's talk page.

If some of those default values are included when the template is used, but left undefined, it removes that parameter from the output entirely:

Copyright Details

View template · Edit template · View documentation

License:	Fair use
Source:	Please add the source to this page. See the template documentation for instructions.
Artist:	Please add the artist's name to this page. See the template documentation for instructions.
Usage:	This image can be used throughout the wiki as long as the usage remains consistent with fair use doctrine.
WikiSWTOR notes:	The editor who uploaded or tagged this believed its use qualified as fair use under United States copyright law, as such display does not significant impede the right of the copyright holder to sell the copyrighted material, is not being used to generate profit in this context, and presents ideas that cannot be exhibited otherwise.

If you believe this image is incorrectly licensed, you may discuss this on the image's talk page.

When these parameters are left undefined in this manner, the default value should be included in the output. That they are excluded entirely seems like an oversight to me, so I apologize if this is intended. In any case, this should serve to demonstrate my concerns. In order for someone new to wiki work to gain some understanding from these templates, if these templates are what they work with the most, then the basic parameters used in that template should be included in the output even when left undefined. Anyway, I hope this clears a few things up. -- Heaven's Agent 16:33, 20 November 2011 (UTC)

When I was getting these done, it seemed like it might be desirable behavior in some circumstances and that it'd be nice to keep the code in the derived templates simpler. Maintainability of code is something I believe worth considering too, and I thought {{{use|default}}} was easier to read and work with than {{#if:{{{use|}}}|{{{use}}}|default}}, which would give you what you're looking for. So, yes, I did understand what you wanted. Like I said, we weighed out the tradeoffs differently, but again, they are small tradeoffs. Besides, by figuring how to bot that change, it'll now take a few minutes and should be error-free rather that doing it manually and probably making typos along the way that'd drag out the needed changes.

I know this seems like a simple change to you; it's just after working with really complex templates, I hesitate to add complexity for relatively small gain, especially since templates have a tendency to grow over time. But that applies generally and not really to this case, but it does leave me with an instinct to resist such changes. That tendency might have encouraged to resist more than I should have; I guessed I just started to feel this kind of push was going to become a regular thing. Given wikis never really escape their need for editors with some degree of technical aptitude, the interests of the less-experienced editors should be balanced with those of template writers rather than letting their interests completely dominate, but again, I think I let a fear of a slippery slope unduly influence my objections. I apologize for letting that get so far. So, should I unchain the bot and modify the doc pages, or would you rather take the time to make your own design? Because, no, I don't have a problem with it; I just don't want to see this wiki get into the same situation we're already in on STOWiki by getting the dropdown working for those who don't know what to do without it. — Eyes 17:11, 20 November 2011 (UTC)

It does feel like a simple change, perhaps because I strive for a more organic feel to my work; I rarely utilize bots for this reason, because I think it adds a more human factor to my writing. It can result in errors, I will admit, but I also usually learn something from those errors as I correct them. As a quick aside, though, I find your hesitation to add complexity to a template a bit ironic; I've actually viewed templates specifically as a place to add that complex coding. Since it doesn't need repeated on each article its included on, you can pull of some rather complex code throughout a project simply by adding it to a single page. I guess its simply a difference in viewing templates' role in project design.

Even if I were to rewrite the templates, I wouldn't have any idea how to write the code for the dropdown. And since you're clear on the issue, and seem to now have an easy way to address my concerns, I'll let you take it from here. I do apologize for my zeal; not only am I self-taught, but my personal background is in technical writing, business, and education. As a result, a lot of my perspective is based on writing things that anyone can understand. I tend to gravitate toward the "Wiki Editing for Dummies" approach of things, if you will. I just know that if the template designers on my first project hadn't taken extra steps such as these, I wouldn't be editing wikis today. I hate the thought of missing out on a potentially valuable contributor, a potential colleague and friend, simply because it would save a little time to exclude such functionality from our templates. -- Heaven's Agent 17:38, 20 November 2011 (UTC)

If the template names stay the same, the dropdown code wouldn't need to be changed. That's the only part of the system that gets "locked in" once the dropdown is active. But the requested changes are complete. The dropdown code actually isn't all that complicated: it's posted at the bottom of my sandbox. — Eyes 17:59, 20 November 2011 (UTC)

Template documentation

I really really despise the subpaged template documentation. It's cumbersome and unnecessary, and I'm not sure why you implemented it here. -- Wynthyst talk 13:51, 20 November 2011 (UTC)

I thought this was a very standard performance enhancement to reduce the work the wiki has to do in generating pages--it means the wiki doesn't have to grab the documentation at all during transclusion (since the wiki software doesn't need it). And sometimes it's nice not to have scroll back and forth between code and documentation, trying to find the lines that need to be changed, especially in complex templates. It's easier when there's less to scroll through. I acknowledge there are tradeoffs, but I think there's both usability and performance benefits that outweigh those tradeoffs.

Not to mention I didn't "implement" it here. I saw at least one template here calling {{/doc}} already. I just added a template that makes it easier to deal with the tradeoffs and followed a convention that already seemed to be here. -_- — Eyes 14:19, 20 November 2011 (UTC)

Yeah, the other {{/doc}} page was my work. I wasn't sure why this method was utilized. I've simply used it on every other project I've worked on, and used it here without considering its implications. Without thinking about it at all, really; as Eyes notes, it is a standard, though admittedly not a required one. -- Heaven's Agent 14:36, 20 November 2011 (UTC)