GuildWiki talk:Community portal/Archive 17

No Access
A few people in my guild have reported that guildwiki is unavailable to them. They can load the site, but it comes up blank. Works fine for me using ntl, but a guildie on ntl and another on Tiscali both reporting problems with the site.

More info on This Thread

Overuse of Spoiler tags
While I realize the importance of not spoiling the story for those who want the suspense, sometimes I find people's usage of the spoiler tag to be a bit overzealous.

When using the tag, please carefully consider separating the article into two parts, first being general background or common lore that does not spoil the plot, and second part being content that actually spoils the plot. Finally, place the spoiler tag between the first part and the second part. -PanSola 17:49, 7 May 2006 (CDT)
 * Just to add my two cents: I believe spoiler tags should be omitted entirely. Documentation of the nature that this wiki concerns is, by its very nature, a "spoiler". In fact, it is the whole idea. As such, spoiler-tagging is redundant and serves no useful purpose whatsoever. I realise not everyone feels this way, but it is my opinion and I'm sticking to it. --Bishop (rap|con) 19:25, 7 May 2006 (CDT)
 * I think there might be people who are interested in item stats/pictures without wanting to know the story in advance. That is my reason for thinking limited use of spoiler tag (specific to plot that takes place in the course of gameplay) is justified. -PanSola 19:30, 7 May 2006 (CDT)


 * I don't think it's overused. Not one bit! :) --Karlos 09:18, 8 May 2006 (CDT)
 * Without being funny, I like the spoiler tags and encourage some use of them where people feel it's appropriate. Frankly, I want people (self included) to be able to use the Wiki as a resource while being able to avoid blatant spoilers.  If a user finds a single thing here without expecting it that ruins part of the story, and really had no warning, that user will likely leave and never come back for fear of ruining the story more.  While I'm sure that some people don't care about spoilers at all, they are certainly not hurt by their presence.
 * Of course, I'm possibly one of those "overzealous" Spoiler-Tag users. If that's the case, duly noted and considered -- I try not to spoiler-tag everything, so it's still a useful tag.  =)  --JoDiamonds 12:28, 8 May 2006 (CDT)
 * I have no problem with the use of spoiler tags where part of the storyline is revealed; but I'm seeing it pop up anyplace a location name or a boss name is used. For example, it's now sprouting up in skill capture comments.  I ask you, from a one line mention of a location and a bosses name, what in the storyline is really given away?  If we're goig to be that overzealous in the use of the tags, we might as well just add it to the top of every page and be done with it.  I mean the main page revealed there are missions and quests in factions!  Need spoilers for that!
 * Okay, sorry, this devolved into a rant. Sorry about that; it's not targetted at anyone, so I hope no one was offended; but as you can see, I feel spoiler tags are over-used to the point of absurdity already and I'm hoping we can reduce their use to a more realistic level.  --161.88.255.140 12:55, 8 May 2006 (CDT)
 * Geesh: okay, the one example I used was discussed in the discussion page of that skill (the mention of "undead prince rurik"), which is still questionable to me, but at least there's logic behind that one. So I admit, I over-reacted on that one.  But, I still find them over-used in general and would love to see them reigned in some. --161.88.255.140 13:00, 8 May 2006 (CDT)
 * OK. I think the best answer we can probably give is that you've been heard in general, and if you have more specific grievances we can talk about them.  =)  I fall very squarely in the camp of thinking that revealing Undead Prince Rurik is a massive spoiler for players new to the game who are just browsing skills for the first time (after all, what could be the danger in just reading some skills)?
 * Also, I tried to respect PanSola's note above about putting the spoiler tag only where there is actual spoiler, but Skuld moved it back to the top of the page (for Hundred Blades). I'm certainly not going to fight too hard on this, but I mostly agree with PanSola on this one.  Players should be able to read the non-spoiler part of Hundred Blades without fear while realizing that there is part of the page that is a spoiler.  Thoughts? --JoDiamonds 08:31, 9 May 2006 (CDT)
 * Sorry, it looked a mess there as it wasn't really designed for sticking in the middle of the page. Theres always javascript/css expanding links.. :p Skuld  08:36, 9 May 2006 (CDT)
 * Sorry, it looked a mess there as it wasn't really designed for sticking in the middle of the page. Theres always javascript/css expanding links.. :p Skuld  08:36, 9 May 2006 (CDT)

I say we just stick a spoiler tag at the top of the main page and call that good. Remove all the others. "If you're going to read this website, you may encounter spoilers throughout." --Rainith 12:09, 9 May 2006 (CDT)
 * Heh - me likes that idea! BTW: While I feel they are over-used, I also found the tags to look almost DOS-like in appearance (not a bad thing in itself, but a dated look compared to our other notices).  I modified the warning boxes, take a look and discuss and/or revert them if you disagree or dislike the new ones. --161.88.255.140 12:12, 9 May 2006 (CDT)


 * The spoiler boxes are far too exaggerated now. It's not that big a deal. &mdash; Stabber &#x270d; 12:14, 9 May 2006 (CDT)
 * I tweaked it - any better? Or just revert to original? --161.88.255.140 12:26, 9 May 2006 (CDT)
 * In my mind, it's not a big deal at all, and taking up valuable screen real-estate for something this frivolous does actually hurt the users whom, like me, can appreciate the story regardless of having heard of Undead Prince Rurik before actually meeting him in-game. If you want to play the game like a book, this website is not for you. Descriptions of skills you have not yet seen are "spoilers" too. Not to mention maps of places you haven't been! Oh noes! Teh loos of suspeense!! --Bishop (rap|con) 12:54, 9 May 2006 (CDT)
 * I would like the spoiler tag to stay, but the new version is really really too big. The good old small red line was great! No harm in using it as long as people keeo their brains with them when tagging pages. --Gem [[Image:Gem-icon-sm.png|Gem]] 13:07, 9 May 2006 (CDT)
 * Actually I am not aware of any overuse of spoiler warnings. Maybe someone could provide some examples of inappropriate usage? Surely I don't mind if we cleanup and remove unnecessary spoiler-tags. According to less than sixty pages use this template, so this shouldn't be to much work. In my eyes, only content which reveals part of the storyline or the mild plot twists ("Xxxxx Xxxxx dies in hat mission." or "The Xxxxx Xxxxxx later on turns out to be a fraggin' bunch of cultists!") qualify as spoilers. I also agree with PanSola that only the part of an article should be labled which contains the spoiler.
 * On the other side, as someone who hasn't finished either campaign yet, I would find it a shame if the spoiler-tags would be replaced by some general warning at the main page. Such an unspecific announcement doesn't help anyone and could as well be omitted.
 * Concerning the new design of the spoiler tag I found the old version more elegant and less obtrusive. I wouldn't mind if they were reverted. (Sorry.) --MRA 13:13, 9 May 2006 (CDT)
 * For the record; I was kidding when I said that I liked the idea of spoiler warnings on the main page. I had assumed it was made as a humorous exageration of the use of spoiler tags.  I see that others took it more seriously.  For the record - I do NOT like the idea of it on the main page (I see someone has already added it to the edit copy - yecht!)
 * On the spoiler tags themselves. I dislike the originals; but I can see the concensus is clearly towards them, so I'll revert them back.  I honestly thought the newer tags were cleaner, and would fit mid-page easier (the original design really doesn't lend itself well to mid-article spoiler warnings).  Perhaps someone else can find a better alternative. --161.88.255.140 13:42, 9 May 2006 (CDT)
 * For the record, I was not serious when I said that, but I do think that people who use strategy guides (which is what this wiki is, a guide as stated on the main page) should expect there to be spoilers all over the place. If you look at a skill's page, the whole acquisition section is a spoiler.  It may not be a storyline spoiler in most cases, but it is a spoiler in the fact that it tells you where to find that skill as opposed to you finding it out on your own.  Realistically almost every article here has a spoiler or two in it.  So I think us spending an overly large amount of time marking them is pointless.  If you don't want to have stuff spoiled for you, don't use a guide, play the game without it.  --Rainith 15:03, 9 May 2006 (CDT)

How about we just put one big fat spoiler tag on the main page declaring that while we gather information on the game and relay it into articles much of it may spoil the plot of the game for the reader and he/she should take their own discretion about whether or not an article would potentially contain spoilers (like elite captures, greens, etc). 209.34.210.57 13:25, 9 May 2006 (CDT)
 * I'm against this. Again, I'll chime in with MRA here, if there are specific grievances, so to speak, let's review or remove them.  I don't think anyone here is saying we need lots more spoiler tags.  I'm in the camp that likes the amount we have now.  There's some places where spoiler tags are obviously superfluous -- we don't have to state that the maps page will contain maps, for instance.  But there's little reason to expect to see much if any plot revealed by going to a skill page, for instance.  And once you look at one skill page, if you decide you don't want to know boss names or locations, you never look at another.  (And bosses are mostly irrelevant and pointless.)  Quite a different shade of grey, in my mind, to start mentioning the death of main characters.  A shade of grey, but I think we've done a decent job of drawing a useful line (i.e. where the spoiler tags are right now). --JoDiamonds 15:35, 9 May 2006 (CDT)

New template for Armor function type articles
Template:Gallery index. See Style and formatting/Armor for documentation.

This should make those thumbnail tables easier to create (certainly more flexible to arrange them). I'm going to implement them on the mesmer articles. Though technically the old table method is fine (the underlying code are identicle), so existing tables don't have to be updated. -PanSola 21:45, 8 May 2006 (CDT)

Spanish babelbox?
Can someone add a Spanish Babelbox category template thingy for basic, at least, por favor? My Spanish is basic. Here's what I think it is: Este usuario puede contribuir con un capacidad básico de español. Is that right? It's been too long since I've written anything in Spanish... but the only word I had to look up was user! :) For easiness, I believe it should go here. --Tinarto 03:33, 9 May 2006 (CDT)

Here you go, stolen straight from wikipedia, I don't speak a word of Spanish myself:
 * Most (but not all) of the GuildWiki versions of the babel boxes seem to have the text in both english, as well as the language described. I've created one on this site using the above text, but the format of both languages. --161.88.255.140 17:44, 9 May 2006 (CDT)
 * Hot dang I was close. Thanks :) --Tinarto 18:47, 10 May 2006 (CDT)

Taking "idocy" skills out of PvP
Since I'm tired of argueing against "idocy" skills in PvP builds, I'd like to have a general discussion about it. I am talking about hexes like Spirit Shackles, Price of Failure, Spirit of Failure, Empathy and everything else that requrires your opponent to not notice or not know about your hex and act like a NPC that just whacks whatever comes close. I am fully aware that these skills work incredibly well against newcomers or Mending Pallys who just don't care. What I am saying is, that any experienced player who is given the chance to identify such hex on him will do what's right: Stop attacking and and remove it (or have a team member remove it). I don't mean Spiteful Spirit and Diversion - these skills are effectively shutting down any player, not just warriors or rangers and put great pressure on the enemy team. I can also understand that Clumsiness and Ineptitude are very effective in case the target foe is already attacking. I see the value here. Also, I accept that most RA teams don't bring a monk, so you can probably have a few wins with these skills pretty easily hence I advise against it, since there are quite a number of teams consisting solely out of casters. But in any other case, these skills are utterly useless and should not be taken with you except for a very a good reason.

I hope not to stand alone here. --Nilles 16:57, 9 May 2006 (CDT)


 * Whether the person attacks or not means the skill has done something useful. Chuiu (T/C)  17:00, 9 May 2006 (CDT)
 * The point is, that such cannot fill its purpose if the target does not react correspondingly. And there are certainly better things to do than wasting 10 Energy and 3 seconds of casting time on a target. --Nilles 17:11, 9 May 2006 (CDT)
 * I'm worried about making some list of skills and saying that we aren't going to allow them on PvP builds on GuildWiki. It seems like a very harsh line, and probably a bad idea going forward.  New skills from new expansions or rebalancing may totally change things, or even just new discoveries.  There was quite a while where Nature Spirits were considered largely useless for PvP.
 * For the particular comments on Spirit Shackles (for example), the three second cast times aren't as relevant for Mesmers (hence their class). Spirit Shackles is certainly not a good all-purpose spell like Diversion, but if your GvG group gets owned by Ranger Spikes, well, Spirit Shackles is decent on rangers.  And saying that it will just get removed is silly, since nearly all hex-based strategies use cover hexes anyway.  SS will get removed too, but it turns out it's still useful.  (Diversion is a special case, since you can't necessarily remove it without it taking effect.)
 * In short, the builds sections are already one of the few parts of GuildWiki that inspire massive POV-debates and arguments, and I'd really like to avoid stuff like that. Bang on any individual build on the talk page, improve it, or whatever.  As far as I'm concerned, the useful part of builds for guildwiki is showing commonly used stuff (whether good or bad), as a form of reporting what is used in the game.  This is the same way Slang on guildwiki is useful, even though it's not put in by the game designers.  I already think there are probably too many extraneous builds on GuildWiki, and too many people arguing about small points.  Let's report what's there, not invent new things.  There's other websites that do that already.  --JoDiamonds 09:39, 10 May 2006 (CDT)


 * Oh well, it was probably not a good idea to begin with. --Nilles 09:45, 10 May 2006 (CDT)
 * I would disagree with your atempt to bring it down to specific skills, but I see where you are comming from. There is a constant influx of builds that rely on the basic idea of "you do X and because your opponents are to stupid to notice X, they lose" when any opponent that would notice X can easily counter it. That might work against some new players in RA, but it is not what I expect from a good build. However I see no way to formalise that, it needs to be taken to each individual build page and agrued there. --Xeeron 04:23, 11 May 2006 (CDT)

Is anyone else capable of running a bot?
From the current look of things, Stabbot might not come back. There's a HUGE crusade regarding skill boxes that is pending, and I'd hate to do it by hand. So if anyone can do a bot, please respond. -PanSola 03:27, 10 May 2006 (CDT)
 * I could potentially run a bot. It would help tremendously if I knew where to look at the old stuff and how it was run (I vaguely remember seeing some references to Python scripts somewhere, which I have some experience with, but I'm hesitant to try to write stuff from scratch.) --JoDiamonds 09:29, 10 May 2006 (CDT)
 * I'd be technically able to do so, but I have too little time and too many projects already to work on this. However, I have already written a working (offline) parser for the skill pages, using Java and regular expressions. If someone wants to use a similar approach and expand on this, maybe I could be of help. Right now, I'm using the HTML pages, but parsing the wiki markup (to write it back) should work as well. As you might see from my contributions, I'm already fixing the irregulatities I find, which should make writing an edit bot a bit easier as a side effect. - Xanon 09:43, 10 May 2006 (CDT)
 * What's required? I might have the skills but I don't have the knowledge. --Tinarto 18:46, 10 May 2006 (CDT)
 * See User:Stabbot. There's some links to the scripts that were used.  I don't think it's required it be these scripts; the key is that we want the ability to make many similar changes across many pages.  I haven't looked into it much yet. Also, I believe the imminent need has been relieved (Stabbot finished the task that PanSola was referring too, I believe).  --JoDiamonds 16:01, 11 May 2006 (CDT)

Babel box redone
The old babel template has been moved to Template:BabelMsg. It includes a new "nocat" parameter to allow you to use the template without getting the article sorted into the cagetory.

The new Template:Babel is a short-hand for including the category. This should eliminate the need for redundent templates. It also supports the "nocat" functionality.

So, use Template:Babel if you just want a quick and simple way to denote your language abilities. Use Template:BabelMsg for non-serious usage or if you want a customized message.

For an example of usage of new templates, see my user page (which gets categorized) and my user talk page (which does not get categorized). -PanSola 19:39, 10 May 2006 (CDT)

Request for abbreviations
Can we make a namespace abbreviation "GW" for "GuildWiki"? Also, the following (but these can be done by users so I'll do them): Yes, I am a (recovering) Wikipedian. Seventy.twenty.x.x 12:41, 11 May 2006 (CDT)
 * AGF for Assume good faith
 * CONTENT for Content over presentation
 * NOT for We are not Wikipedia
 * ORO and 1RV for Only revert once
 * ulc (edit: and ULC) for Use lower case
 * YAV and YOU for You are valuable


 * plz make them GW:BLAH or it's pointless Skuld  12:42, 11 May 2006 (CDT)


 * I cannot add namespaces... only people who can poke new values into the interwiki table can do that. Who is the superadmin here? Seventy.twenty.x.x 12:45, 11 May 2006 (CDT)


 * User:Gravewit, but you'll be lucky if you get a response. We need OblivioWiki: links too! Skuld  12:51, 11 May 2006 (CDT)


 * Errr ... enlight me ... why exactly do we need these abbreviations again? --Tetris L [[Image:TurningL sml.gif|Tetris L block]] 15:22, 11 May 2006 (CDT)


 * Ease of citation, mainly. Much easier to write GW:1RV than GW:Only revert once. You can even use them in edit summaries for reverts and the like. Seventy.twenty.x.x 15:25, 11 May 2006 (CDT)


 * Just curious, as I haven't played much with namespaces. Why is a namespace required for this? The system provides an edit screen when I go to GW:NOT, from where I could just enter a redirect, correct?  Or is there some system architectural reason to prefer creating the pages within a namespace? --161.88.255.140 15:35, 11 May 2006 (CDT)


 * Hehe my completely uninformed guess: The technicians will come up with some reason that solves a problem you never had but in fact all they do is make normal stuff so complicated that the normal user doesnt understand it anymore and needs the technician. --Xeeron 17:12, 11 May 2006 (CDT)


 * Shucks, my secret is out. Guess I'll have to find a new line of work now. Thanks, buddy. Seventy.twenty.x.x 17:15, 11 May 2006 (CDT)


 * No offense, but IMHO none of the policy articles is cited anywhere near frequently enough to warrant an abbreviation, let alone a namespace abbreviation. Check "What links here" on any of them. --Tetris L [[Image:TurningL sml.gif|Tetris L block]] 04:17, 12 May 2006 (CDT)


 * I vote for removing those abbreviation. Really, they aren't needed. --[[Image:Gem-icon-sm.png|User:Gem]] 04:27, 12 May 2006 (CDT)


 * Well if we had like 1000s and 1000s of editors like Wikipedia then I could understand this, but we're not like that... these rules aren't cited as frequently --Jamie 04:32, 12 May 2006 (CDT)


 * Just keep them as normal redirects, they dont hurts anyone. --Xeeron 04:40, 12 May 2006 (CDT)


 * I dislike these. If I write to in a talk page, "We don't do things that way, because we are not Wikipedia," the reason for my refusal is obvious even before clicking the link. The abbreviation requires a clickthrough, and is all-in-all unintuitive.  I for one will never use these, because the abbreviation is harder to remember than the policy itself. &mdash;Tanaric 21:06, 13 May 2006 (CDT)

Build stub clean up

 * The clean up is nearly over now. As you might have noticed, quite a lot of builds were moved to Category:Tested builds indicating they were successfully vouched for. Category:Untested builds was created to replace the old Category:Build stubs. Build stubs is only for real stubs now (in the wiki sence) no longer for unvouched builds. Builds should always be in either tested builds or untested builds AND at the same time in Category:PvE Builds, Category:PvP Builds or Category:Farming Builds.


 * A special note on builds up for deletion: There are a few builds in Category:Candidates for deletion simply because noone wanted to vouch for them. If you feel any of these builds deserve not being deleted, please go to Category:Candidates for deletion and put your vote down on the talk page now.


 * People generally opposed to deleting builds might want to read about Bishops proposal.


 * Admins, please do not delete builds before the 15th please. --Xeeron 07:32, 13 May 2006 (CDT)
 * Update:
 * Thanks to Bishop, there is now a new "build portal" site at Build.

Vehemntly against new skill box IMPLEMENTATION
I want to register that I am disappointed and frustrated that you guys (PanSola, skuld, whoever) implemented the skill boxes in this way. I have nothing against the skill box itself, but against the whole "You can't really edit this page using the edit link on it, you have to use this special link."

Now, we've had this discussion before, and I thought the overwhelming majority of users were against increasing the number of pages that have the "press this special link to edit this page" design. I have not followed the skill boxes discussion closely and I am sure someone will try and point my attention that somewhere a bunch of you got together on the skill boxes and chose A instead of B or skill box 15 or whatever. That's all fine and dandy. My objection, is that the design you guys chose breaks a standard that the community agreed to. One that I am very vehemently supportive of.

I would have appreciated it if you had announced more prominently that such a HUGE change to the site policy is going to take place. I don't know if you can see where this is going, but I can see it very clearly, next will be the beast boxes, then the NPC boxes, then the location articles, then mission overviews and finally the quest pages. All of these can be made to look EXTREMELY cool (and highly uneditable) if we put in enough time into it. That is EXACTLY what I did not want to happen.

I am not going to revert anything until we decide that's what we want to do, but I am THAT much against it that I am willing to revert so much work. --Karlos 22:40, 13 May 2006 (CDT)


 * I agree with Karlos. This present design that PanSola is pushing seems to be designed solely to ease the server load in rendering a page that includes a hundred different skill articles itself as templates, and it fails even in its sole justification because recaches happen more often than article edits. It's using one broken design to justify another broken design. It's too bad that he seems completely closed off to discussion of this topic. 207.241.227.235 22:48, 13 May 2006 (CDT)


 * Re-cache more often than article edits? Yes, I agree. HOWEVER, whether re-cache happens more often than skill detail edits is the issue that matters.  I do not intentionally close off discussion.  I based my judgement on what was presented before me, and on GuildWiki talk:Style and formatting/Skills at the time I decided to continue on (and even now), there were no evidence that directly suggests re-caching happen more often than skill detail edits.
 * The decision to NOT have redundent skill information scattered across the wiki is a community one, and I am following it. To reduce server load, I am splitting off skill details from the rest of the skill article, so that skill article edits do not cause other articles to re-render.  Between three evils, "Redundent information scattered in different places", "different information on the same skill located in different places (but linked/included)", and "sever performance penalty", we can only remove 2 of the evils, not all 3.  The community has previously voted to definitely remove the first one, though at that time we didn't know that server permance might be at stake. -PanSola 23:34, 13 May 2006 (CDT)

As long as the thing you are opposing is about the edit link, I'll try to work out something (assuming you don't oppose the way collector rewards and weaponsmith catelogues were implemented, becaues that is what I have in mind). -PanSola 23:11, 13 May 2006 (CDT)


 * I can't make heads or tales of the Community Portal page, and am thus requesting a link to the change proposed. If Karlos's statement about the change is accurate, I am equally opposed, but I would like to check this myself before rendering judgement. &mdash;Tanaric 23:18, 13 May 2006 (CDT)


 * I hope you have a bit of time to read it, here are the archives:
 * GuildWiki talk:Style and formatting/Skills/Archive 4
 * GuildWiki talk:Style and formatting/Skills/Archive 5
 * GuildWiki talk:Style and formatting/Skills/Archive 6
 * GuildWiki talk:Style and formatting/Skills/Skill box
 * GuildWiki talk:Style and formatting/Skills/Archive 8
 * Personally I'm less against making it a little more difficult to edit the actual skill info (as that only needs editing when ANet changes/re-balances the skills) than I am against the possiblity of killing the server with all the calls. --Rainith 23:26, 13 May 2006 (CDT)


 * Check out Echo, if this makes you (Karlos) satisified I'll proprogate the change. -PanSola 23:24, 13 May 2006 (CDT)
 * Note to PanSola, doesn't work. I assume you meant the edit link at the top of the article.  --Rainith 23:29, 13 May 2006 (CDT)
 * I'm getting nothing but database errors for that page right now. Reported at the bugs page. &mdash;Tanaric 23:37, 13 May 2006 (CDT)
 * ARG! Back to the drawing board. Why does it section into the If template??? -PanSola 23:38, 13 May 2006 (CDT)


 * Tanaric and others who are lost, check Meteor Shower and Psychic Instability. The change is that in those skill articles, the skill data is actually in Template:Meteor Shower and Template:Psychic Instability respectively. While I think this design is a technical marvel (And the skill boxes themselves look very slick), I find that the average user pressing the "edit" button to edit the page and not being able to and instead having to click the slick looking "click here to edit" link, I find all that very un-wiki like.
 * Now, that discussion was about the skill BOXES and making them look better and a minor (in my opinion) side-benefit of SOMEHOW making the skill box in the skill article and the skill row in skill listings pull data from the same source. Last I checked on that thread, there was no mention of this idea. I have not followed it for over a month as the "issue" seemed benign and the choice of one layout or the other is not a big deal for me. I was not aware (and believe I should have been made aware) that the people in that discussion decided to override such a critical and fundamentla principal of any wiki.
 * It's like me and Tetris engaging in this long debate about Drakes and Dragons and after everyone gives up on the thread, we decide somewhere VERY deep in it that we will protect most Beastiary articles and then proceed to do that. Something that should have had the approval of a lot more people and exposure to a lot more people.
 * PanSola, I never liked the collector's and weaponsmith change, and let it go because that was a small scale change. --Karlos 23:46, 13 May 2006 (CDT)


 * Should we have a major discussion and perhaps a poll/vote on whether we want redundant data at different locations versus server performance penalties (or splitting data off)? Back when most of us were against redundent data, we didn't realize the server performance penalty we would get unless we split the data (like the collector/weaponsmith approach, though those were done for a different reason). -PanSola 23:50, 13 May 2006 (CDT)


 * What I worry about most is that the average new GuildWiki contributor will just get lost and frustrated. I've been using computers for ages and been here for yonks and consequently can keep up with this kind of stuff. But I feel that you shouldn't need much technical knowledege to use the GuildWiki. Basically if you have enough "computer smarts" to know how to post on a forum, you should be able to edit and create articles here. I've been doing tonnes of work on Quests at the moment but a lot of people leave out the category, get the formatting wrong etc. these templates may be beyond a lot of people. If our pages start looking like a high level programming language (ie a simple page with a whole host of subroutines/methods/includes/templates) it might just be too difficult for many people. It shouldn't take a Computer Science degree to work out how to create an article here... --Xasxas256 00:03, 14 May 2006 (CDT)

BTW, to clarify my position, my view and understanding was that having the skill article and skill quick references pull data from the same source was the main motivation that started and continues to drive this entire process, as opposed to being a side benefit. To me, making the skill box look cooler/nicer was the side benefit (and a trivially less important one, as long as they don't collide into progression tables). Splitting the skill data into a different place (whether a template or a subpage) was meant to carry on what I thought was the main point (pulling data from same source) while solving the major server performance problem.

If the community now decides having redundent data scattered at different parts of the wiki is a lesser evil compared to splitting data off, that's fine by me too (if I can't solve the edit section link problem). But it definitely needs more discussion and promotion to get ppl's attention. -PanSola 00:08, 14 May 2006 (CDT)


 * Oh, I hate redundancy as it jeopardizes data integrity in any site/content. So, in that regard, I am with you 100%. Thus, you'll note I CAPITALIZED the word "implementation" in the title. The idea itself is very noble.
 * Now, we can think of solving this issue f data integrity in a different way. Whuy not make a bot that has the sole task of updating all the "reference" and "skill list" articles with the proper data from the "skill's mother article"? Therefore, if ANet changes skills, we simply change their articles and then run the bot, and the bot goes to fix all listings of that skill's data in the reference articles?
 * Implementing this solution is vastly simple. All it will mean is that we maintain a list of skill reference articles, and then (perhaps) within those skill last articles, tag the skill section with some special tag that makes it easy for the bot to find what it needs to edit.
 * It maybe less "chic" than the soltion we have now, but it keeps every article "editable" for everyone. That being said, I don't even know how to write a bot. --Karlos 00:16, 14 May 2006 (CDT)


 * Firstly, no polls or votes. Let's have a discussion without the onus of majority rule hanging over us. I know this's old fashioned, but I find it useful. :)


 * Next, I'm still not sure I understand all the options you're proposing. I currently see:


 * Put skill data in one place, seperate from the skill article, and have it Included in.
 * Put skill data in the skill article, and wherever else (quick references, mostly), and use a bot to update.
 * Put skill data in the skill article, and again in an includeonly section in that article, so it can be Included in.


 * I've heard mumblings about "subst", but I don't know what that is. I've also seen you working on an if-then template, which is an idea I deplore. As XasXas said, it shouldn't take a computer science degree to contribute here. When we start measuring the algorithmic complexity of GuildWiki articles, we've taken things a step too far.


 * PanSola, since you're pushing for change (actually, you've gone and changed things), please delimit the relative advantages and disadvantages of each approach. If I'm missing some approaches, please add those as well. The plethora of Style and formatting talk doesn't ever come to a single point, and so this isn't discussable but by the handful of users involved with that unless you give us a summary.


 * Either way this works, your research on the topic is definitely valuable&mdash;even if we end up reverting to the old style, we know never to do this again. :) &mdash;Tanaric 00:18, 14 May 2006 (CDT)


 * Problem with method 3 is server load. Each quick reference page will need to re-render at least as often as people edit skill articles, if not more often.  I believe some of the major server slowdows that took place earlier this month was related to some of the skill reference page directly including skill articles, and I have reverted those quick reference pages.  Advantage is simplicity.  This is the only option that I am very very very unwilling to consider.  Everything else is at least open to discussion for me.
 * With approach 2 (and the subst approach) we still have redundency, we just make sure the redundent copies stay in since, assuming we can make sure someone remembers to do the subst or have a bot-master position that is not vacant at sensitive times. Disadvantage unique to the bot approach is we have to make sure all articles that make use of the skill data is backlinked to the bot's database or whatever.  It also has a shared disadvantage (with the subst method) in that a remote article that doesn't get paid a lot of attention may have its copy of the data edited by someone (for good or for bad), and the change wouldn't get noticed.  If it's a bad change, the bad data stays there unnoticed and giving ppl wrong data.  If it is a legit change (an unannounced game update), then the user who edited the remote article only affected that article and not the main one (not a problem with old timers, but with ppl new to the wiki).
 * Problem with approach 1 is mostly the edit syndrom (trying to edit the main article won't let you edit the skill info directly, a common disease with the quests lists, the collectors list, the armor gallery indexes, the weaponsmith lists, and a couple of others). Additionally, currently the edit link that allows ppl to edit the article containing the skill info is a non-standard link.  THis is the major complaint that Karlos has which started this discussion, as far as my understanding goes, and I am working on solving this part of thie complaint, or at least minimizing the issues with it. -PanSola 00:54, 14 May 2006 (CDT)


 * Ok, I'll admit that initially I was against the major re-working of the skills, but I don't see how anyone can say it would take a CS degree to edit the articles, when there is a link in the box saying "click me to edit this." It could be made even more apparent by putting a line like    at the top of each skill page.  --Rainith 00:26, 14 May 2006 (CDT)

Alternative proposal
I made this proposal on GuildWiki talk:Style and formatting/Skills, but it was just brushed off with no discussion. I am making it here again. The skill reference page should use subst: in the following way (an example of a small skill reference page) Every time the skill descriptions change (which only happens once every game update), someone has to do the above 3 steps again. This someone can be a bot, or just someone who is clued in.

Benefits of this design:


 * 1) Central skill data (as needed).
 * 2) Not dynamic, so there is no unnecessary server load.
 * 3) (Most important IMHO) the skill data is in a single page--the skill article itself--and it is obvious how to edit it.

Disadvantages:


 * 1) Someone has to sync the many skill reference pages there are every time a skill desc changes.
 * 2) As a result, the reference page and the skill articles might be inconsistent for short periods of time.

I personally think that the benefits far outweigh the disadvantages. Hank 00:38, 14 May 2006 (CDT)


 * Advantage 1 and 3 are untrue. There will be copies of skill data over at different places, they are just synchonized every once in a while.  There is a "presumed" master copy, the skill article itself, but nothing prevents ppl from editing the other copies, unless we hunt down every single page that uses skill data and put big glaring label warnings (and we all know how good ppl are at following the "please upload inventory icons" instruction).
 * Additional disadvantage: we need to somehow somewhere keep track of all the pages that use skill data. That might not be limited to  skills quick references.
 * Additional disadvantage: if someone edited one of the articles containing skill information but not one of the more often noticed ones, that edit might go unnoticed. If it's a bad edit, then then erroroneous info will stay on the wiki until the next time someone do a sync.  If it is a good edit corresponding to a silent game update that most ppl didn't notice, the good info won't propergate to the rest of the wiki, and would actually get erased by the next sync if no one else has noticed the silent skill change and updated the main copy yet.
 * I see one single benefit. How much it weighs compare to the disadvangages is a YMMV thing. -PanSola 01:04, 14 May 2006 (CDT)


 * So protect the reference pages, add a line at the top that says "these are autogenerated, and cannot be edited; see the main skill articles for changes", and I'll make a sysop bot to keep them up-to-date. &mdash;Tanaric 01:20, 14 May 2006 (CDT)


 * Why are 1 and 3 untrue? The skill reference pages can be regenerated from the master copy trivially, which means that the difference you point out is a matter of coherency, not of duplication. And I agree with Tanaric. Protect the reference pages, or better, have a bot sync them up nightly. (Bots with sysop privileges, which would be required to override the protection, are generally a bad idea.) Hank 01:30, 14 May 2006 (CDT)


 * By the way, and I feel stupid to point this out repeatedly, but breaking skill data across two pages, one of which requires a specially concocted edit link, is just BAD DESIGN. This is a Wiki, not a glorified XSLT processor. Editing is supposed to be a completely transparent process. Hank 01:33, 14 May 2006 (CDT)


 * Shrug. It's the same thing we arer doing with Levithan Pits quests module.  Anyways, I think Echo now answers Karlos' original opposition (so we can get back to the offtopic issue of split vs subst vs redundent data) -PanSola 01:40, 14 May 2006 (CDT)


 * No, Echo does not address the problem. What is different about echo? --Karlos 01:45, 14 May 2006 (CDT)


 * You might need to do a cache refresh, not sure. I changed the edit link so it looks like a sectional edit link (though the font size is slightly weird.  css styling is beyond my expertise, and I welcome anyone who can fix it).  So now it's just like the collectors/quests lists, which you still don't like, but at least the edit link looks like it is for a section that includes the skill box and the skill description.  It is still a special link, but it looks pretty much like (as close as I can make it) the other sectional edit links.  -PanSola 01:53, 14 May 2006 (CDT)


 * This random anonymous user favors either Hank's subst idea (by hand or bot). Alternatively, I think a bot that scans recentchanges for skill changes and updates the QR pages (after a delay, to catch multiple edits in a short time) would be nice.  It would remove nearly all the arcane-to-random-users use of templates and includeonly/noinclude.  I think the main problem with the old way of including the skill article, aside from any server load issues, was that users had to keep info inside of the noinclude tags when adding new sections rather than add sections to the bottom.  (This lead to comments in articles like , which would get ignored and people would add sections below the final noinclude.)  --68.142.14.79 13:56, 14 May 2006 (CDT)
 * One minor detail about your comment: the newest implementation doesn't use any inclodeonly/noinlcude tags in the skill articles or the skill templates. Check out Echo.  Thus, the "main problem" has been removed, or at least is different from what you just described.  Of course that might not be sufficient to change your position, but just want to point it out.-PanSola 19:23, 14 May 2006 (CDT)
 * BTW, one bigger problem with your note: the SUBST method actually HAS the "main problem" you noted (since it requires teh skill article be loaded with tags. So you are supporting a move for the exactly opposite reason.  The SUBST is an inclusion-substitution of skill articles, it requires the noinclude tags inside the articles.  On the other hand, the template inclusion technique currently used by Echo does not use the noinclude tags.
 * Just so you know, Pan, the new edit button doesn't quite pass the browser-test. The text is misaligned in any browser but FF (which leads me to believe you're a FF man;)). Observe:
 * [[Image:Ie-op-ff.jpg|600px|IE, Opera, Firefox]]
 * --Bishop (rap|con) 19:46, 14 May 2006 (CDT)
 * Blah, are there any CSS guru who can help me out on this? (it actually doesn't look 100% correct in FF either).  Anyways, still, the edit link is now where it is expected to be, more or less, and look like what it is expected to look like, more or less.  Just need some CSS expert to fix it up (I wonder if it's harder to find a CSS guru or a botmaster...)-PanSola 19:51, 14 May 2006 (CDT)
 * Mmyeas, well, I didn't want to mention this, and thereby get involved in this particular hornets nest, but... I do have some css expertise, and I do have some wiki experience. And yet, because the template on template on template system is so contrived, I can't even begin to find where I'd need to modify the css or the article code to fit. This, among other things, is why I'm generally opposed to anything that's more complicated than flatfiles. But like I said, the whole skill-display-issue has been discussed and churning since long before I even started contributing to this wiki. And my focus is on making the Builds-section more accessible, so I'm not going to comment any further on the whole skill-debacle. --Bishop (rap|con) 20:19, 14 May 2006 (CDT)
 * You could help out with styling without getting involved (in the sense of taking sides). Ie, you can help me make thing look better without commiting to side with me.  In fact you even have the option of saying because you tried helping my cause, you realized how impossible it is to reach perfection, and therefore oppose myside.  So, feel free to help me without getting committed.  I'll put something on your talk page. -PanSola 20:22, 14 May 2006 (CDT)

Title Boxes
Anyone want to try to come up with some title boxes (similar to the babel boxes and the newer PvX and Faction boxes)? I am having a major case of... I don't know ennui, apathy, "the blahs" right now and just can't get up the initative to do this. I was thinking something that would have different levels for the different title levels, but an overall color theme for each title track. --Rainith 23:16, 13 May 2006 (CDT)

A New Section for the Bigger Issue - Split/Subst/Redundant
This is an issue common to Collector lists, quest lists, weaponsmith lists, skill lists, and many others. Though how we arrived at the issue differed for some of the above.

Basically we have several method of dealing with data that are repeated across multiple articles:


 * 1) . Split - Split it off and store it somewhere else. Let other articles that need it use inclusion.  This is the currently most widely adapted technique on GuildWiki.
 * 2) . Redundant - Have multiple copies of the same data whereever they are needed. This is the second most widely adapted technique on GuildWiki.
 * 3) . Subst - Have one article as master copy. Use a bot to periodically synchronize the other articles that need the data.  Protect those other articles from editing.  This is a new idea being introduced.

Note these are just rough ideas, there are/maybe different variations of ideas that differ in the details, but still fall into one of the three main types above.

My first question for the community is, should we handle each subject (quest, collector, skills etc) uniformally, or do it case by case? -PanSola 01:47, 14 May 2006 (CDT)


 * Case by case please. Subst: is totally not needed if there is only one or even up to a dozen transclusions. For skill reference pages, the sheer size makes it all different. Not sure about the quest pages, but my brief study of them shows that they have the same (and other) issues with transclusion as the skill reference pages. Hank 01:50, 14 May 2006 (CDT)