Guild Wars Wiki talk:Feedback organization/Archive 2

Feedback portal, Feedback:Main

For here I just started naming things as the made sense, but I know there has been some concern with how to name some pages, so someone to doublecheck them while they are still red would be valuable (i.e., doublecheck that that is the correct page title we want for that particular thing). In particular, I am concerned about this as it is in Gaile's space in the Feedback area. (Satanael 19:26, 2 July 2009 (UTC))

Personally I don't like it looking like the Main Page and it has too much an advertising factor imo (it was worse with those texts). poke | talk 19:29, 2 July 2009 (UTC)

I just used Eras' example as a starting point, I am open on the aesthetic. (Satanael 19:30, 2 July 2009 (UTC))

I'm not real happy with the idea of making this just a page of links that looks like the Wiki main page. I believe the Rules of the namespace should be spelled out clearly here, not some link in a bottom box. I would prefer it to be laid out more like the the main pages of things like Projects. I think it will be confusing to people to have a duplicated main page, and they won't really understand what it is. -- Wyn talk 19:31, 2 July 2009 (UTC)

(Somewhat unrelated)For wiki pages, all you have to do to get back to the main page is to click on main-page or the icon. However, with the feedback namespace, I currently don't see a good way to get back to Feedback:Main. --JonTheMon 19:33, 2 July 2009 (UTC)

I see your point, the problem is that the different types feedback of feedback will have different rules, so it will be hard to come with overarching rules for all feedback that is not already covered by the more general wiki-wide policies (e.g., don't be a dick). Though I agree, some sort of text intro to where they are would be valuable. (Satanael 19:35, 2 July 2009 (UTC))

As with the ArenaNet pages, a link can be placed to allow easy return to the portal page. -- Wyn talk 19:38, 2 July 2009 (UTC)

I removed the link to ArenaNet staff. The staff pages in the feedback namespace are nothing but replacements for their user talk pages, and should not be represented as an official feedback vehicle. -- Wyn talk 20:18, 2 July 2009 (UTC)

I saw that, and I'm fine with it, I think I was hasty to throw it in there, especially since that page is little more than a page full of links, there's no real need to move it. (Satanael 20:20, 2 July 2009 (UTC))

(Reset indent) I'm not sure about the boxes on the bottom, Bugs seems okay, but the other two, I had a tough time figuring out where to put website suggestions and international cultural references, in particular because if you leave one of those boxes with only 2 links in it, it looks... lonely. Any ideas on how to better utilize that bottome row? (Satanael 20:20, 2 July 2009 (UTC))

I'm rather happy with how much discussion has happened in the last day. Beginning with the main page, my objectives when designing it were:

1. To have something with a clean look. IMO, the ArenaNet:Portal is way too cluttered, with a distribution of subjects that doesn't make sense (why do the localization bug pages take more space than all the other bugs?). The Feedback section has been created because of the suggestions, so let's make it clear from the front page how important those suggestions are.
2. To have something with a consistent look, hence the similarity to the main page. It also helps people to understand how, despite being on the same wiki, the Feedback section is different and has different rules from everything else.
3. To have something simple. From Arena Net's point of view, the simpler everything is, the more likely the developers will be to read the suggestions. A long main page stating all the (rather complex) rules would be against such idea, IMO.

Therefore...

The main page has its top section dedicated exclusively to the suggestions, so they are very easily found (by contrinutors and developers alike) and have their importance highlighted.

Other things take the bottom row: all bugs in one cell (with the localization bugs as part of the text bugs), all of support on another.

The rules and the FAQ have their own pages. Ideally the rules would be in the suggestions pages, but I believe the GW suggestions and the GW2 suggestions pages are already going to be way too big, preventing us from displaying the rules there. Having a page dedicated only to this subject would allow us to go into details of how the system works without having to worry about page size.

Some things that could be improved, IMO:

A. Changing the blue on the top of the boxes to the same green used on the background.

B. Changing the second row (the one which will link to the GW and to the GW2 suggestion pages) so it looks prettier. Maybe splitting it into two cells?

C. Changing the images at the right top of the boxes so they are not a copy of the main page. For example, with a Rollerbeetle on the Bugs box, and so on.

Erasculio 14:22, 3 July 2009 (UTC)

Well, for one thing, while the localization bugs may be a trivial topic to you, they affect easily 50% of the player base worldwide (probably more, but I'm just guessing) so yeah, they do take up space. Again, I don't like the replication of the main page look, but am willing to talk about it as well as other options. -- Wyn talk 14:25, 3 July 2009 (UTC)

While it might make things more complicated, I think there should be some rules spelled out, and at the very least a "Read these rules" link in the top section. And as the colors of the namespace aren't set in stone yet, the headers can't properly reflect that yet. I also agree that different images than the mainpage would be a plus. --JonTheMon 14:33, 3 July 2009 (UTC)

I agree with Jon on the "Read these rules" thing. And Wynthyst, it's not a matter of localization not being important, but of it not being more important than the other text bugs; in fact, localization bugs are a subtopic of text bugs, so I think the wiki should reflect that. Erasculio 14:47, 3 July 2009 (UTC)

The FAQ's aren't in the new namespace, so they should not be linked from the portal imo. This should be for stuff that is specifically in this namespace. -- Wyn talk 17:40, 3 July 2009 (UTC)

The FAQ mentioned in the Feedback section is actually a FAQ about how this area works, not a link to the mainspace FAQ. Erasculio 20:56, 3 July 2009 (UTC)

Once again, I have removed the references to ArenaNet staff on the main page. We should not be representing their talk pages as official feedback locations, regardless of the fact they reside in this namespace. -- Wyn talk 17:32, 10 July 2009 (UTC)

I perfectly understand the desire to protect the dev talkpages from feedback inundation, but we have to recognize that they are offical feedback locations, that's why we are putting them in the feedback namespace. I mean, for example, official support pages are located in Gaile's namespace. Having one link to a list of devs on the wiki at the bottom of the main page is not a tacet encouragement to use those pages instead of our other feedback locations, it is only a recognition of one of the many locations at which feedback can be provided within the feedback namespace. If the devs don't want any feedback on their talkpages, then they should have told us to leave their talkpages in the userspace. (Satanael 18:06, 10 July 2009 (UTC))

No, they aren't, they are only being placed in this namespace because people are stupid. There is a link to the staff presence page on the main page I believe. It doesn't need to be here. What's with the about face? You agreed with me the first time I removed them..... Once again, you are giving mixed signals. <edit> The devs are all revising their posting rules to indicate that feedback should NOT be posted on their page. and the OTHER reason their talk pages are being put in this namespace is so that stuff that IS put on their pages can be moved to where it SHOULD be in this namespace instead, which we couldn't do if they were left in the the user namespace. -- Wyn talk 18:22, 10 July 2009 (UTC)

As for Gaile's space being where the support stuff is, that is something that her bosses requested of her, as they do not with to have an "Official" support area on the wiki, so her's is the unofficial area that she maintains on her own. That makes it different from the rest of this stuff, there are going to be Official locations now for all forms of feedback. The dev pages do NOT need to be one of them. -- Wyn talk 18:28, 10 July 2009 (UTC)

It's not an about face, what I agreed to earlier was to leave the actual list of staff presence in the arenanet space, whereas I had originally foreseen it being moved over like most of the rest of the arenanet portal. This time around I added the link again, but left it going to the page in the arenanet portal, thinking it would be a useful link to add into an otherwise pretty empty box. I'm not sure what other "mixed signals" I have sent, but I would love it if people would tell me specifically, rather than vagueries, so I can be sure to avoid them.

In any case, you're right, and this isn't that big of a deal. I don't want to start a big discussion over something minor. I'm fine with leaving the link off. (Satanael 19:03, 10 July 2009 (UTC))

Color and Design

We still really haven't decided on the color/design for the Feedback space. It was left at green, but is that what we want? Do we want to change any of the elements? The watermark? I personally like it the way it is, including the watermark, but it's all open for discussion. I have made a table of some color options here. I think most of you have seen it, but I thought I'd link it anyway. -- Wyn talk 19:45, 2 July 2009 (UTC)

I'm currently working on slight modifications to satify my own expectations (to allow me actually to look at the namespace for longer than a short moment :S). I will make you know when I have something to show. poke | talk 19:56, 2 July 2009 (UTC)

Could the green borders come down a little on thickness? --Antioch 08:36, 6 July 2009 (UTC)

I think the colors can be modified after it goes live. until it the most simplest and functional is what you need. I suggest greyscale color themes without any unnecessary extras like logos. --Boro 09:43, 30 July 2009 (UTC)

We don't want to make it the most simplest and functional and then make decisions after the fact. It takes little to get it decided on prior to it going live. And the longer people hold off on commenting the more likely it is that it will stay as you see it now. -- Wyn talk 09:52, 30 July 2009 (UTC)

Sorry I'm a DOS addict. cmd forever --Boro 08:56, 31 July 2009 (UTC)

Watched that test page and that Anet logo is quite distracting. --Boro 18:08, 31 July 2009 (UTC)

I agree. Since we have the white ArenaNet logo in the top right corner, it's unnecessary to have the large watermark spread across the middle of the page, particularly when it gets in the way of the content. -- Brains12 \ talk 20:42, 31 July 2009 (UTC)

Also, I'm not fond of the main logo; are we planning on changing that back to the original? In Guild Wars Wiki talk:Suggestion pages restructuring#Initial attempt, Emily and a few others were hesitant to have a different logo too. -- Brains12 \ talk 20:51, 31 July 2009 (UTC)

The test page looks the same to me as any other page in the wiki (using latest firefox), except the border at the bottom has a greenish tinge. The background of the lorum text is white, the left navbar is its usual color until just below Transclusion list. For my eyes, there are no visual cues that this page is any different from anything in mainspace (the green tinge is fairly close to the gray navbar background, the bottom section is often outside the screen. I'm not sure whether this is intended or not.

Personally, I would like to be able to have a more visible reminder that I'm in the suggestion space, i.e. I would prefer that all borders be different in color (if that is even possible): navbar, bottom bar, and top orientation bar (user name, my talk, my pref...). I would especially like to see stronger cues when one is editing in the feedback space (again, I'm assuming that it's technically and humanly possible).   — Tennessee Ernie Ford (TEF) 02:12, 4 August 2009 (UTC)

You should be seeing this; not sure why you're not. -- Brains12 \ talk 13:51, 4 August 2009 (UTC)

Removing the changed logo and the watermark are going to remove two of the biggest changes. It would seem that having the arena net logo in the upper right corner on a green background, and the green overall theme are not enough to indicate to people it is a separate space. The other problem with making all these changes only in the css is that anyone who has altered their personal css are not going to see these changes at all regardless of what we do. Of course the logo was my idea, so I'm going to think it's a good one, considering it's so close to the original (which I personally hate btw) as to be almost completely invisible as far as a change goes. But I will do whatever it takes to keep this moving forward. -- Wyn talk 14:15, 4 August 2009 (UTC)

I personally think the logo and watermark are going too far and, in the case of the latter, may disrupt page content; design and 'prettiness' should never do that. I think if people are experienced enough to alter their own css to change the design of pages, they're experienced enough to recognise which namespace they're in - these design changes are mostly for those people who might not realise that. -- Brains12 \ talk 14:50, 4 August 2009 (UTC)

Feedback:Rules & Feedback:FAQ

Can we outline the rules for posting suggestions? We can at least go to work on the text. -- Wyn talk 17:35, 3 July 2009 (UTC)

The most important rules are where they can and can't post suggestions. Other than that, it doesn't matter too much. If they don't properly use the templates/code to get their information listed, not our problem. And if they post suggestions on Regina/Linsey's page, it gets nuked. So, short verion: Rule 1: You may only post suggestions on your own feedback page. Suggestions elsewhere will be removed. --JonTheMon 18:35, 3 July 2009 (UTC)

Ok.. let me rephrase my question... Can we outline the PROCESS and rules for posting suggestions? /me looks for a dead fish to slap Jon with! -- Wyn talk 19:01, 3 July 2009 (UTC)

In that case, my idea on process would be something similar to the skill feedback, with a pre-made page that gets generated based on the user's name. Not quite sure how that'd work with IPs though... Anyhow, I'd say the pre-made page should have hidden comments that walk the user through putting the ideas down and categorizing the page. --JonTheMon 19:05, 3 July 2009 (UTC)

Not sure it's gonna happen that way, but if it is, someone had best start working on the code that will make it so. Since that is totally beyond what my brain can do. -- Wyn talk 19:06, 3 July 2009 (UTC)

Independent from the process of creating feedback, we have to make the rules and especially the licensing clear to anybody that visits the Feedback namespace, Jon. poke | talk 20:08, 3 July 2009 (UTC)

I think we need two pages: one explaining why the Feedback exists, why people can't just make suggestions on their (normal) userspace and copy it on the Feedback space, how the license works and etc; and another page explaining how the system works, in other words how to create a suggestions page and how to have added it to the suggestions lists. My first thought was to have the first of those pages as the FAQ and the second as the Rules, but probably the opposite way would work better.

Regarding pre-made pages: I'm against those. As discussed on the old GW suggestions pages, pre-made pages basically invite people who have not read how the system works to hastly write something without paying attention to what they're doing and leave that suggestion there, never looking at it again. I believe the new system has to be something slightly complex so people have to understand how it works before adding their suggestions to the list. How exactly to make these pages, however, depends of exactly which system we are going to use for the suggestions lists, and that's something we still have not talked about. Erasculio 20:54, 3 July 2009 (UTC)

I would like to see at least some explanation of the namespace, it's licensing and purpose on the main page. If this is going to be the main portal into the area, I think those basics should appear immediately, and not require them to click a link to a different page, because I think a lot of people will be unlikely to do so. -- Wyn talk 21:31, 3 July 2009 (UTC)

Yeah, I agree. When there is a small link to important rules somewhere below but big boxes above advertising the ability to post suggestions, people won't bother reading the rules at all. So they should really be put at the very top, like a disclaimer.. poke | talk 22:31, 3 July 2009 (UTC)

Ok, I made some changes to the text on the main page, and added a box matching the Welcome box on the original main page that tells them in very simple terms about the licensing, and links to what I believe will be the new copyright language. -- Wyn talk 01:12, 4 July 2009 (UTC)

Rule #1

"Rule 1: You may only post suggestions on your own feedback page. Suggestions elsewhere will be removed."
Nearly everyone of you danced around this proposal in the first major discussion about Dev pages and by that I mean condoned it in one manner or another. Are you prepared to make it official? --ilr 01:29, 6 July 2009 (UTC)

Just where are you quoting that from? And yes, I would have no problem making it official. -- Wyn talk 03:43, 6 July 2009 (UTC)

Lol, I had to look it up too, and it was my suggestion in the first response. Maybe tweak it a bit to not just be a single page, but page and sub-pages. But that's just a technicality. --JonTheMon 03:46, 6 July 2009 (UTC)

While it would be nice in a perfect world, we all know this isn't a perfect world. There will always be those who will post on the dev's pages, but I would have no problem actually stating it as a rule, and enforcing it with warnings and bans for repeat offenders. We are trying to set this up to make it as user friendly for both the community and the dev's as possible. The simple fact is the dev's are not going to have more time for the wiki because of it, so we need to give them as much time to look at suggestions as we can, which means them taking less time on frivolous stuff on their own pages. Also, considering how much work is being put into this, if everyone can just by pass everything by posting directly on dev pages, it's pretty much all for nothing. So, yeah, if people don't care enough about their ideas to post them properly, then I'm not going to give them the easy way out of just putting them on dev pages. The Staff are also going to be posting new rules for their pages, and will not be responding to issues that are inappropriately placed. -- Wyn talk 03:54, 6 July 2009 (UTC)

I totally agree with the above, but I think we should bear in mind that we should strive to find a balance with enforcement of this rule. I mean, the very fact that we are moving the dev talkpages to the feeback spcae means that we recognize and, in some subtle way, encourage people to give devs feedback directly. I guess what I'm saying is that we should not be automatons about "suggestion=move/delete" and be a little pragmatic about it. I mean if someone posts some text wall proposing a whole new system of pvp, that's one thing, but if someone just jumps on and says "hey Linsey, you guys should fix Tombs." maybe that type of thing can slide, even if it is technically a suggestion. (Satanael 04:18, 6 July 2009 (UTC))

Well, the benefit of having the devs' talk pages in feedback is that ideas placed there can be moved to the right place and still be valid. Whereas suggestions put on devs' talk pages now can't just be moved to feedback. --JonTheMon 16:17, 6 July 2009 (UTC)

Pragmatism?? Did I enter the right Wiki URL today? Am I even in the right Universe today?? --ilr 21:53, 6 July 2009 (UTC)

FAQ

I think that the FAQ is short enough that we can do without the TOC. The long titles on the sections mean that it pretty much takes over the header part of the page. -- Wyn talk 06:13, 31 July 2009 (UTC)

TBH, I kind of like it there, I looked at it with the TOC hidden and the header seemed kinda empty, since the box was no smaller. Also, the TOC makes it easier to refer people to a specific question in the FAQ. I don't know, I'm not ademant, so if you still feel strongly about it, I'm okay with getting rid of it, too. (Satanael 18:58, 31 July 2009 (UTC))

I can just view it hidden, it skews the layout of the entire top section imo, but w/e like you, I'm not adamant. -- Wyn talk 14:31, 4 August 2009 (UTC)

Categorization structure

I thought it might be easier to wrap our heads around the categorization issues if we could see it in a visual structure, so I have created User:Wynthyst/Sanbox/Feedback categorization tree‎. Any thoughts? -- Wyn talk 22:23, 5 July 2009 (UTC)

I'm not entirely sure of which categories to use (we could probably remove the "character customization" one from GW1), but I agree with that overall structure. I don't think we would have to make categories for each individual skill; given how we may use the page name to mention which skill it's talking about, I think categories based on attribute will be enough. Erasculio 01:33, 6 July 2009 (UTC)

Okay, the 4th tier categories under GW1 (i.e., PvE, PvP, Items, Mechanics, etc.) can all be copied into GW2 suggestions as well, since all of those things are general enough that we can feel safe they will be in the game. GW2 should not have any subcategories thereof, though.

For GW1 suggestions, though, I think we can add more 5th and sixth tier categories, under PvP, for example, we can have general PvP feeback, GvG, AB, HA, HB, RA, TA, etc. Item feedback can be split into consumables, weapons, tonics, summoning stones, minis, miscellaneous, etc. Mechanics can be split into UI, AI, etc. Player Interaction can have Guilds, Parties, trading, chatting/emotes, etc. and PVE and World can have a wide wariety of stuff, some of which could overlap, so we should think a little carefully about those. (Satanael 04:08, 6 July 2009 (UTC))

I think we could try to categorize through a more detailed approach, but I'm somewhat worried about the practical aspects of that. IMO, the reason beyond the categorization structure is to split the suggestions between the suggestions lists. We could use a main category and many subcategories for those lists, but at the same time the lists are already going to show the name of the suggestions, so I'm not sure the subcategories would be necessary or useful. We would also need the users to assign the subcategories properly, given how there would be too many options for us to do so automatically, and that's something that could lead to problems.

In less words, I think this:

User		Last modified		Suggestion
Erasculio		22.07.2009		Remove consumables
Erasculio		09.06.2009		Add a Gwen-Doll tonic

...Would be as useful as this:

User		Last modified		Subcategory		Suggestion
Erasculio		22.07.2009		Consumables		Remove consumables
Erasculio		09.06.2009		Tonics		Add a Gwen-Doll tonic

Erasculio 04:17, 6 July 2009 (UTC)

lol, ironic that now you are arguing in favor of user-generated text to take the place of categories (whether you call them summaries or titles) and I am advocating more categories! I certainly agree that the titles will be helpful, even necessary, but in your case above, what if you have someone suggest this:

User		Last modified		Suggestion
Satanael		23.07.2009		Bunnies

Wouldn't sub-categories be really helpful there? (Satanael 04:29, 6 July 2009 (UTC))

You might want to speak to Aiiane, she has determined that no discussion about categories is necessary, and has started creating categories. Good luck with all this, I'm out. -- Wyn talk 04:39, 6 July 2009 (UTC)

Ack, my secret weakness, bunnies D : Seriously, though, those lists would still be under one of our main headers, so even the Bunnies thing would fall under one of the main categories. What bothers me, to say the truth, is less the kind of thing you mentioned, and more things like...

User		Last modified		Subcategory		Suggestion
Erasculio		22.07.2009		Tonics		Remove consumables
Erasculio		09.06.2009		Consumables		Add a Gwen-Doll tonic

We already expect users to categorize properly regarding the main category, I'm not sure they would categorize properly through main category and subcategories. But then again, the lists do have some empty space. Erasculio 04:43, 6 July 2009 (UTC)

(Reset indent) Wynthyst, I would appreciate it if you would not misrepresent my comments. (Aiiane - talk - contribs) 04:55, 6 July 2009 (UTC)
Regardless of which system among the ones that have been proposed we end up using, they require a solid categorization system. Since Wynthyst was working on this and Aiiane has already began implementing some categories under that system, I think we could use what they have started. I think we still have to discuss which categories we will have, though, so we know the most common suggestions have fitting categories.
If we use the system I have proposed, I think it would be better if any suggestion has one or two subcategories within a single category, although in Satanael's system a suggestion could have as many categories and subcategories as desired. That's the only difference between both proposed systems, as far as categories go.
I believe we could have:

• GW World feedback
  • GW Lore feedback: for suggestions about things that would have happened in the past of the current Guild Wars timeline, such as having the Scarab Plague being a curse from Abbadon.
  • GW Story feedback: for suggestions about current events, such as having our characters learning about Primordius.
  • GW Locations feedback: to suggest new areas or changes to existing ones, such as increasing the number of enemies in Gyala Hatchery.
  • GW NPCs feedback: to suggest things about NPCs, such as bringing a dead character back to life.
• GW Items feedback
  • GW Weapons feedback: to suggest new weapon skins, changes on weapon damage, new weapon types, changes to weapon mods, etc.
  • GW Armors feedback: to suggest new armors, changes in how armor works, etc.
  • GW Consumables feedback: for suggestiong such as nerfing consumables, adding new tonics, etc.
  • GW Inventory feedback: for suggestions about adding more storage, adding a sorting feature to inventory, etc.
• GW PvE feedback
  • GW Quests feedback: for the proposal of new quests or changes to current quests.
  • GW Missions feedback: for the proposal of new missions or changes to existing missions.
  • GW Enemies feedback: for the proposal of new enemies or changes to existing enemies.
• GW PvP feedback
  • GW General PvP feedback: for ideas about PvP as a whole.
  • GW GvG feedback: for suggestions about GvG.
  • GW HA feedback: about Heroes' Ascent.
  • GW RA/TA feedback: for suggestions about the arenas.
  • GW Hero Battles feedback: for suggestions about Hero Battles.
  • GW Other PvP feedback: for suggestions about new PvP modes, FA, JQ, etc.
• GW Skills feedback: one subcategory per profession and within those one subcategory per attribute, to propose skill buffs, nerfs or changes in functionality. All would follow the naming convention "GW [profession] skills feedback" and "GW [attribute] skills feedback".
• GW Player interaction feedback
  • GW Trade system feedback: for the proposal of new trading systems or changes on the economy.
  • GW Chat system feedback: for ideas about the chat system.
  • GW Guild system feedback: for suggesting new guild features, new Guild Halls, etc.
  • GW Emote system feedback: for suggestion new emotes, changes to current emotes, etc.
• GW Mechanics feedback
  • GW User interface feedback: for suggestions about changing the UI.
  • GW Graphics feedback: for ideas about changing the graphics as a whole.
  • GW AI feedback: for discussing the AI seen in the game.
  • GW Professions feedback: for discussion the profession system, asking for things like having three professions, and etc.
  • GW Game features feedback: to ask for new game features such as mounts and alikes
  • GW Inventory feedback: for suggestions about adding more storage, adding a sorting feature to inventory, etc.

I think those categories are enough, but I'm not happy with the Mechanics feedback category (I think it has way too much stuff, with things that aren't exactly connected to each other), and I'm not sure the most common suggestions have good fits. What do you people think? Erasculio 03:12, 14 July 2009 (UTC)

Inventory under items? feels awkward, I would consider storage etc. more of a mechanics issue. You also have to include a "miscellaneous" sub category under each category for those suggestions that just won't 'fit' into the other pigeon holes. -- Wyn talk 03:20, 14 July 2009 (UTC)

I think the mechanics category is getting a bit too bloated...Any idea of how we could try to split it between subjects more closely related to each other? Erasculio 03:28, 14 July 2009 (UTC)

What's too bloated? Issues are what they are. I don't see that it matters whether there are 5 subs of Mechanics or 10, if it's a mechanics issue it should be under mechanics. I mean, the Skills feedback is going to have 10 subs each with 5-6 sub subs... I just want to see them in their proper places. -- Wyn talk 03:48, 14 July 2009 (UTC)

I think it's a bit counter-intuitive if the category for proposing a new color for the health bar is the same for proposing a new profession or asking for more storage, but that's not a big issue. If no one has a better idea, I think we could use those categories as they are. Erasculio 03:51, 14 July 2009 (UTC)

Isn't that why subcategories exist? (Aiiane - talk - contribs) 06:09, 14 July 2009 (UTC)

Wasn't there also going to be a "Character" main category? This would be where people put suggestions for character customization, we could put professions there, and I think we could also put stuff about companions like heroes, hench, and pets in there as well.

Also, Lore and Story feedback seem awfully similar, unless people read our description of what each category is (which we know most of them won't), it could be easy to confuse these two. Maybe just combine them? I don't know, in the past I think people have often confused PvE and World suggestions, so I might even suggest combining those two main categories as well. What do you guys think? (Satanael 14:22, 14 July 2009 (UTC))

I agree with merging Lore and Story categories, but I disagree with merging World and PvE (IMO, one is about the setting, the other is about gameplay). I also disagree with the "Character" category - although I had mentioned it earlier on, I don't think there's anything in GW1 which deserves that category. However, I'm not proposing to use those same categories for GW2; the newer game needs different categories, IMO. Erasculio 23:14, 14 July 2009 (UTC)

Just a note, if you have to err, err on the side of more categories as opposed to fewer - it's better to have more categories than we need, than it is to realize later we should have split things up more. (Aiiane - talk - contribs) 23:26, 14 July 2009 (UTC)

I have implemented some categories in order to test if this works. If someone believes I should have waited more, remember that the wiki is fluid, everything here may be changed later. Erasculio 00:59, 15 July 2009 (UTC)

Don't have to wait, necessarily, but it'd be nice if you could follow the standard capitalization scheme used by everything else on the wiki (i.e. only capitalize the first word unless it's an acronym). (Aiiane - talk - contribs) 01:02, 15 July 2009 (UTC)

I was actually trying to do that, I just forgot about the "GW" preceding all the category names xD I'll fix it later. Erasculio 01:11, 15 July 2009 (UTC)

If you don't want to have a character main category, I don't have a huge problem with that, but there needs to be a place for character customization, H/H, and pets, where would you put those? PvE? (Satanael 02:50, 15 July 2009 (UTC))

Heroes and henchmen I would place in the Mechanics section under AI (given how they are used for both PvE and PvP), same with pets. Character customization isn't something I'm worried about, at least in GW1; if someone would like to make a suggestion about the Stylist, I would place it under Game features. Erasculio 03:05, 15 July 2009 (UTC)

I think I have to disagree about H/H and pets going under AI, since suggestions about those do not always have to do with AI (for example). They deserve their own subcategory (whether together or individually), and putting that subcategory under mechanics is a little counterintuitive. But you are right, they aren't strictly PvE either. Maybe a Miscellaneous main category to catch not only these suggestions but any others we're not thinking of? (Satanael 03:21, 15 July 2009 (UTC))

I agree we could use more categories, but I'm a bit worried about having a Miscellaneous category as I think people are just going to add everything there without stopping to think of which category would have been the proper one. Maybe we could figure out a new category in which to place the kind of idea you have mentioned? Erasculio 03:27, 15 July 2009 (UTC)

(Reset indent) I understand the worry about a miscellaneous category, but in a way that's their own problem. At some point we have to make it clear to people that if they don't take the time to correctly place their idea, then it won't get the visibility they want. At the same time, no matter how many categories we come up with, there are always going to be suggestions that don't fit into any of them, so we have to have a catch-all category in some way. Maybe that is not a main miscellaneous category, instead go with something more like what Wyn suggested, a miscellaneous subcategory for every main category (although a miscellaneous main category would be even more of a catch-all than that).

As for pets and H/H, if not a character main category, and not a miscellaneous main category... I'm not sure. I can't think of anything obvious, and I worry about coming up with something awkward that is not intuitive. I'm open to ideas though if anyone has them. (Satanael 03:44, 15 July 2009 (UTC))

How about an "Allies" main category, for people to ask for more heroes, to suggest increasing the maximum number of heroes allowed in a party, to suggest new henchmen, to suggest new henchmen skill bars, to ask for buffs for pets, and etc? I was actually going with subcategories called "Other [category] feedback" as our miscellaneous thing, so people would always at least give their ideas a main category. Erasculio 10:23, 15 July 2009 (UTC)

Both of those ideas sound good to me. (Satanael 16:38, 15 July 2009 (UTC))

(RI) Two new concerns:

• Does anyone bother if we stick with "GW World feedback" as opposed to "GW world feedback"? The former fits the text for the infobox better, and IMO it kinda looks better, despite how it goes a bit against the usual wiki convention of having only the first word in anything capitalized.
• What about the categories above the ones mentioned earlier? Wynthyst had proposed categories called "Guild Wars suggestion feedback" and "Guild Wars 2 suggestion feedback", but I would rather use "GW feedback" and "GW2 feedback". What do you people think?

Erasculio 00:03, 16 July 2009 (UTC)

I'm fine with the shortened names Eras. Is there anything I can do to help you? Just for the record, you have earned your cookies with this, and my admiration and I want to say thank you. -- Wyn talk 00:21, 16 July 2009 (UTC)

I'd prefer lowercase, and to have the full "Guild Wars" instead of "GW" - I think our general formatting guidelines should more or less apply to the structure. -- Brains12 \ talk 00:24, 16 July 2009 (UTC)

Thanks, Wyn : ) It's thanks to your vote of confidence making me and Satanael temporary sysops that I have been willing to invest so much time in this, so I'm glad to know you're happy with what we're doing.

I would prefer the shorter category names, but whatever. I would only ask you people to decide more or less quickly, as that's the only thing preventing me from trying some next steps. Erasculio 00:34, 16 July 2009 (UTC)

If you need to create something for testing purposes, go ahead - I only meant it for the finished product. Things can always be changed after testing and whatnot. -- Brains12 \ talk 00:37, 16 July 2009 (UTC)

I know, it's just that it's kinda annoying to make all those categories and then delete all of them later : D I wish we could move a category instead of deleting it. But it's ok, I guess I can create just a few and we can change them later. Erasculio 00:42, 16 July 2009 (UTC)

(Reset indent) I agree that the capitalization looks better, so why not "World feedback - Guild Wars". While it will mean redoing the categories that have already been set up if we specify the game after the hyphen, it will alleviate Brains' concern about following the general formatting guidelines. So we could do:

• Category:Game suggestion feedback
  • Category:Game suggestion feedback - Guild Wars
    • Category:World feedback - Guild Wars...
  • Category:Game suggestion feedback - Guild Wars 2...

I do agree it would have been nice if this had been mentioned when you posted the list of categories 2 days ago.... or when the categories were created last week. It's just slowing up this process to have you waiting all these days to voice your opposition to what is being done. And I agree that we ARE working on a finished product here, not some test run. -- Wyn talk 00:47, 16 July 2009 (UTC)

I'd personally prefer the acronyms over the full names - the category names are getting long enough without tacking the full Guild Wars onto them. Also, the prefix structure means that in category listings the categories for the same game will all sort together, instead of being interleaved with the ones from the other game, which is why I'd prefer that. (Aiiane - talk - contribs) 03:02, 16 July 2009 (UTC)

I haven't been waiting until today to voice my opposition, I simply only noticed it today and saw this section with Erasculio bringing up his "two new concerns", which happen to be the two I'm most concerned about; a consistent category tree is always nice. However, if that's getting in the way of getting something done, I'll back out of this discussion. -- Brains12 \ talk 13:50, 16 July 2009 (UTC)

Having slept on it, I don't really like dashes in category names if it can be avoided. I'd prefer if we stuck with what's already there, but with proper capitalization. I'm willing to do the deletions/recreations if necessary, if that's okay with you all. (Aiiane - talk - contribs) 16:36, 16 July 2009 (UTC)

Whatever keeps this moving forward. -- Wyn talk 16:52, 16 July 2009 (UTC)

Erasculio, is that alright with you? If we want we can always change what's displayed in the infobox w/o changing the category name itself. (Aiiane - talk - contribs) 17:22, 16 July 2009 (UTC)

That's great. I'll begin working on it a bit later today. Erasculio 13:29, 17 July 2009 (UTC)

Summaries

I think the index pages should include summaries, with a strictly enforced character count limit. Can DPL be used to truncate oversized summaries? -- Gordon Ecker (talk) 04:42, 7 July 2009 (UTC)

I've always been strongly in favor of this, and Erasculio has always been strongly against it. Our compromise at this point is the inclusion of the suggestion title. Unless, of course, my friend Eras has changed his mind... (Satanael 04:58, 7 July 2009 (UTC))

Depends on how it's done. If parsed as a parameter it would need a phantom template with sting operators, which extention I haven't checked if is installed on this wiki. Sections are fine, otoh. Backsword 09:44, 7 July 2009 (UTC)

If we use a system like this...

User		Last modified		Subcategory		Suggestion
Erasculio		22.07.2009		Consumables		Remove consumables
Erasculio		09.06.2009		Tonics		Add a Gwen-Doll tonic

...Then I don't think summaries would be needed, given the amount of information already available. Erasculio 10:16, 7 July 2009 (UTC)

Personally, I would prefer something that combined this table with this one. In other words, it looks like the above table only allows for a suggestion to have one sub-category, but I'm sure there will be some ideas that will encompass multiple subcategories. Therefore, if we have all subcategories applicable to a certain list available as seperate columns like in your original GW2 table that I linked, this issue could be easily solved. Of coruse, this leaves less room for the suggestion titles, but that is not necessarily a bad thing. (Satanael 17:30, 7 July 2009 (UTC))

While I believe that will be a problem regarding GW2, I would rather have a system that prevents people from adding every possible category to their suggestions in order to make them more visible, and limiting it to one subcategory per idea would be better for such goal. Besides, if we eventually have to make multiple lists, one per subcategory, having an idea under many subcategories would make said idea appear in multiple lists, conflicting with the goal of not having too many entries in total (be it to avoid the 500 DPL limit or just to avoid cluttering the pages too much). Erasculio 22:20, 7 July 2009 (UTC)

To a certain extent, all of those concerns you have are unavoidable. No matter what system we have it will be up to the user to decide what categories and subcategories apply to their suggestion, and having more of them will always make the suggestion more visible. So there will, no matter what, be those who check "yes" to everything. Furthermore, we have to allow for ideas that span more than one subcategory, that's just simply the nature of ideas, some ideas will span many categories. For example, if you only have the option of one category or even one list, where would this idea go? It applies equally to the PvE, PvP, and World main categories, let alone all the subcategories it could apply to. (Satanael 04:38, 8 July 2009 (UTC))

What about skill suggestions? IMO many skill suggestions could easily be summarized in a single line and nearly all of them could be adequately summarized in a few hundred characters, however quite a few could not be adequately summarized in a reasonably sized page name. Also, I don't think we should encourage people to cram summaries into page names, and using page names as summaries would force people to move their suggestion pages in order to revise summaries. -- Gordon Ecker (talk) 10:03, 8 July 2009 (UTC)

We do have the problem of what to do with a suggestion belonging to more than one category if we use those categories to decide in how many places that idea will appear. I don't think it would be fair to allow one idea to appear in all the lists, taking space that could have been used by a suggestion that would appear in a single list. Besides, we can have a system that prevents those suggestions which had "yes" to everything checked from appearing in any table at all (notcategory), and that's something we would lose if we allowed that kind of thing.

I think all skill suggestions could be summarized in "Nerf X", "Buff X" or "Change functionality of X". Those are all viable page titles, and IMO they would work even as subcategories for better listing. In fact, I believe the skill suggestions are the ones that need a summary the least, given how limited they are by nature. Erasculio 10:14, 8 July 2009 (UTC)

User	Last modified	Subcategory	Title	Summary
Username	dd-mm-yyyy	Divine Favor	Self:Remove Smiter's Boon from PvP	Nerf Smiter's Boon to death in PvP.
Username	dd-mm-yyyy	Fire Magic	Self:Raise Savannah Heat's PvP energy cost	Split Savannah Heat, raise its' energy cost in PvP.
Username	dd-mm-yyyy	Swordsmanship	Hundred Blades rework	5 0 25 Elite Skill. (15 seconds.) Deals 10...22...25 slashing damage to all adjacent foes whenever you attack with a sword.

Here are some examples based on previous balance changes. The Smiter's Boon and Savannah Heat nerfs are adequately summarized by the titles, however the Hundred Blades suggestion would be really messy if it was summarized in a page title. MediaWiki allows page names up to 255 characters long excluding the namespace prefix, which would allow considerable abuse. -- Gordon Ecker (talk) 10:21, 8 July 2009 (UTC)

RE: subcategories, I think we can find a happy medium in there, Erasculio. I understand you don't think it's fair to allow one idea to appear in all lists, but nor do I think it's fair to cram a big idea into one subcategory or even one list. But our options are not one or the other. We can still prevent people from checking "yes" to every category while allowing them to check "yes" to more than one. We can even prevent them from checking "yes" to more than 80% of the subcategories. If someone complains that their idea really does fit into that many subcategories (which I think will be rare, if ever), we can always ask them to just split their idea into multiple ideas, which should be acceptable for an idea that big. However, asking them to split may not really be possible for some ideas that hit, say, 2 or 3 of the main categories. (Satanael 14:51, 8 July 2009 (UTC))

Satanael, if you can find a way to allow people to have more than one subcategory per idea while preventing them from having every subcategory on said idea in a way that does not require users to manually check if each idea has the proper categories or not, then I would be all for it.

And Gordon, I don't think you understand the point of those lists. We could not reasonably even try to show directly the suggestions to the developers from the list, given how we are speaking about 5000+ suggestions. Instead, we are considering a system from which the developers will find links showing what the idea is about, and if they are interested, click on said ideas. Having the entire suggestion on display on the list, as in your example, would never work, and it's not something we should even strive for, IMO. With that in mind, no summary in your example would be useful at all, given how the page names already show what the suggestion is about. Erasculio 22:20, 8 July 2009 (UTC)

Well, if we're going with a template that will auto-categorize things, the template could only have a limited # of category slots... (Aiiane - talk - contribs) 22:55, 8 July 2009 (UTC)

IMO it would be far more convenient to be able to skim over concise summaries of 50 proposed skill changes on a single index / summary page than it would be to have to load and read through 50 separate suggestion pages. IMO the skill list pages are good examples of the usefulness and feasibility of summary pages. -- Gordon Ecker (talk) 04:00, 9 July 2009 (UTC)

Maybe I don't understand the limitations of what we can do with these templates. Would it be possible to have "if...then..." rules built into the templates? In other words, could we code into the template something like "If # of 'yes' responses to category query is greater than 10, then all category queries get reverted to 'no'"? If that is possible, then we should be able to limit the number of categories that can be applied to a single suggestion, no? (Satanael 07:07, 9 July 2009 (UTC))

Gordon, let me explain you one thing. "Buff Shadow Form" is a summary; "Change Shadow Form so it costs 1 energy and has infinite duration" is not a summary, it's the entire suggestion. The skill lists don't show summaries, they show the entire skill description. And it's not really feasible to list 500 skill changes on a single index given how that's way too much content for those pages, and how the probability that a developer would like to read all suggestions at once (as opposed to only those belonging to a category he's interested in) is extremely low. Erasculio 11:54, 9 July 2009 (UTC)

Since there seems to be such strong opposition against summaries on index pages, I've started a separate topic about the possibility of summary pages in addition to index pages. -- Gordon Ecker (talk) 05:15, 11 July 2009 (UTC)

Getting Started page

So, I went ahead and created the Getting Started page. Obviously, it's got some holes that will need to be filled in, but I thought we could at least, well, get it started. Thoughts on wording and organization, bold slash editing, personal insults and threats of violence are all welcome. (Satanael 05:08, 7 July 2009 (UTC))

I'm not sure we need a "Getting started" page and a FAQ and a rules section; IMO that's a bit redudant. I would like to have the instructions on how to create a suggestion to either be within the rules (so people who did not read the rules would not know how to make a suggestion) or within the FAQ (again, so people would have to read the FAQ in order to submit stuff), so people literally wouldn't get started without reading one of those two. More importantly, the text on the "Suggestion template" implies that we are going to implement a system in which the suggestion template is automatically added to suggestion pages; I would be against such system, as I'm sure a lot of users would try to use it before reading anything (be it the FAQ or the rules or even the "Getting started" page), and we would end with the same problems we had here with the "easy page creation" system. Forcing people to read stuff before creating their suggestions isn't a way to drive people away, it's just a way to prevent the hastly addition of pages under bad formatting. Erasculio 22:28, 7 July 2009 (UTC)

I actually have an idea in that regard, but I'm going to need a little more time to experiment/refine it before I'm going to present it as an option. (Aiiane - talk - contribs) 23:01, 7 July 2009 (UTC)

Okay, here's my thoughts. Since each user is going to have their own page with subpages of that for each of their suggestions, why not have a double-layered system: a createbox on a 'Getting Started' type page which walks them through the basic guidelines, and then has that first createbox to create their personal "home page"... and on that created homepage, there are both links to the rules/FAQ, and then a createbox to create subpages for their section? That way, any given user is forced to visit the page with the first createbox their first time around, but for subsequent times after that, they need only visit their personal page. (Aiiane - talk - contribs) 00:57, 8 July 2009 (UTC)

I think people are just going to ignore the rules/FAQ links, although I think it would be a good idea to keep the first "Getting Started" createbox and then leave just the links, telling people to look there to see how to create suggestions. But whatever, feel free to add this system if you feel like doing so, if we don't agree we can always change it later. Erasculio 01:00, 8 July 2009 (UTC)

Well, see the mini-example I cooked up: initial create (Aiiane - talk - contribs) 01:03, 8 July 2009 (UTC)

Also, I think that our best bet for keeping things "clean" is to simply have something that needs to be set in a template in order for the suggestion to be listed - and tell people that in the instructions. If they don't read the instructions, they'll be able to create the page and edit it, and even save it and see how it looks, but it won't show up in listings until the proper parameter is set. (Aiiane - talk - contribs) 01:04, 8 July 2009 (UTC)

That's fine by me. It's probably as close to what I wanted as I'm going to get. Erasculio 01:12, 8 July 2009 (UTC)

I really like Aiiane's idea. I had thought of something similar, but hadn't had a chance to figure out how to put my idea into words. In any case, green light to Aiiane as far as I'm concerned. In particular, I like this idea because it ensures that page names will be consistent and correct. This should help with coding anything that needs to have consistent page names. I was afraid that if we left the page creation completely up to the users then we would end up with Feedback:UserExample, Feedback:Example, Feedback: User/ Example and all kinds of other weird incantations of page names. Anyway, /positive reaction (Satanael 03:20, 8 July 2009 (UTC))

Sounds good. I like the idea of a guided reading before creation. --Antioch 04:30, 8 July 2009 (UTC)

Jfc, no! If we wanted the wiki covered in pointless, often blank, pages we could create them ourself. Backsword 10:40, 8 July 2009 (UTC)

Maybe to avoid that we make the users manually add the template to the page that decides where their suggestion is listed. This will be pretty easy and just adds another step to slow them down and make them think about their suggestion. If they don't bother with the template, then their idea doesn't get listed. (Satanael 14:33, 8 July 2009 (UTC))

Out of curiosity, what immense harm does a blank page do? (Aiiane - talk - contribs) 08:47, 9 July 2009 (UTC)

Eh, I may back off a bit on that concern. For me it wasn't so much about blank pages as it was about a potential flood of poorly thought out, one-liner suggestions if we make suggestion creation too easy. But I think with the addition of the template they need to fill out, coupled with most of the other fundamental facts of our system (user account requirement, user page creation, etc.), the threat of this is not that big. IOW, carry on. (Satanael 14:13, 9 July 2009 (UTC))

Sample system

Made a version of a useable system, as an example of what can be done with DPL. (no prettificatioin done.)

Page: User:Backsword/Sandbox/fndpls/mlist

Note that the sample user pages are intentionally..nto well made. This will be an issue, whether we go with DPL of 'pokachu'. Backsword 15:41, 9 July 2009 (UTC)

I've also thrown together an idea for automatically listing suggestions. It is based on using a template that categorizes ideas both on ideas and time period. So, when we want to generate lists, we just specify the time frame we want suggestions to be from.

Idea is here. The first method is just based on using templates to generically categorize. The second method categorizes based on the time given and is more useful to us. Both methods use a parameter in the template to generate the summary, and I haven't worked it out yet to give a shorter page name. --JonTheMon 19:43, 9 July 2009 (UTC)

Well, since no-one's responded yet (QQ), I'll start listing pros and cons

Pros

• Utilizes category system which is well-known
• Cutting down main lists would just require taking away categories from the DPL
• If users don't use the template/use it wrong, it just won't get listed

Cons

• Reliant on getting everything exactly right to be listed
• Keeping the feedback lists current would require constant maintenance

Changes needed

• Allowing multiple categories (?)
• Possibly having the time frames shorter than a month.

--JonTheMon 20:50, 9 July 2009 (UTC)

I have tried making a small system myself, based on the skill system we have. Here are...

• A sample suggestion page.
• The template behind the page above.
• A sample of a list.
• The template behind the above list.

Things I would like to do, but I don't know how:

1. In the suggestion infobox, make the name to automatically match the page name, or, in the list, make the page name appear in one column replacing the description (so far, all I can do is add the page title to one of the headers).
2. In the list, give it a row above the current one with the title of the list (a single cell with "World suggestions" or "PvE suggestions" and so on).
3. Add the date of creation of the pages somewhere, be it directly on the list or in the infobox to be used by the list.

Erasculio 01:16, 11 July 2009 (UTC)

Each of your parameters would need to be a subcategory. With the 3 sub sub categories for skill changes. -- Wyn talk 01:23, 11 July 2009 (UTC)

Well, ideally the lists would be able to sort by any parameter. I think we would need true categories for all parameters with the exception of what I have called subcategories, at least in the beginning. For example, I think (for now) a World feedback category is enough, without the need for splitting it into a "NPCs feedback" category, a "Lore feedback" category and so on. If we end with so many suggestions that we would have to split the World list in multiple smaller lists, it would be possible to change just the suggestion infobox and thus create the new categories without having to edit all the suggestions themselves. Erasculio 01:37, 11 July 2009 (UTC)

That's not how categories work. World feedback is a primary category, with subcategories for each parameter. It's the only way you would be able to use any sort of dpl to separate NPC feedback from Lore feedback. This is why I wanted to come up with a firm category structure. <edit>Splitting categories later as Aiiane pointed out is just a bad idea, because then you would have to redo every page that had previously been created. -- Wyn talk 01:39, 11 July 2009 (UTC)

Let me give you one example. I have created another suggestion with NPCs as first subcategory and Story as second subcategory. Those subcategories are not categories on their own, so I cannot use them to create new DPL tables. However, I can use them as parameters in my list, and use those parameters to sort the table, as seen on this link. Even without a "Lore feedback" category, I can still sort that list by the entries with "Lore" as their second subcategory.

However, let's say the World list becomes so big that we have to split it into multiple smaller lists, one for each subcategory. We would need a "Lore" list, and "Story" list, and etc. All of those would be impossible, given how there are no categories for those subcategories. However, that's something simple to change: by just using a slightly different infobox, we can create the new categories without having to edit the current suggestions. Given how simple that change is, I think we could wait to do it if it becomes necessary.

(Although this system would work much better if users were allowed only one subcategory per suggestion.) Erasculio 01:56, 11 July 2009 (UTC)

So, based on the subcategory, you would update the infobox to add category:World NPCs Lore as a category? --JonTheMon 02:04, 11 July 2009 (UTC)

(Edit conflict) If we did, however set up each parameter initially as a category, splitting the lists would be relatively simple. I'm not saying it's not workable, and it's really not that much different from the category structure I had in mind. The only thing is that people would have to know exactly what to fill in in those infoboxes to make it work properly. I can tell you from experience in the Guild namespace, that regardless of what mechanics you have set up for the infobox, people will put whatever they want. So rather than World, they will put Explorable, or instead of Items they will put Trophies... the options are never ending. What will end up happening is a gazillions various categories will get created. I can tell you absolutely no one will read the "instructions" on how to fill in the infobox. We have commented instructions on the Guild infobox, and people still fail to get it right 70% of the time. -- Wyn talk 02:06, 11 July 2009 (UTC)

Wyn, I'm not against beginning with the system you have proposed, as opposed to adapting it later on. But there is one important point in my example: if people write Explorable instead of World...Nothing is going to happen. The system has been made to reply only to specific entries, so if people write the wrong thing, it would simply ignore it and not create any category. Here is an example: I have made a new suggestion with a category and subcategories that are not meant to exist (Explorable, People, Mudkip) and, as a result, no category has been created. That suggestion would not appear in any list, either.

Jon, I would tell the system to create a Lore category and a NPC category, and move the categories to within the World category. Erasculio 02:17, 11 July 2009 (UTC)

Well, your box needs some work, because you say... Nothing happens if you put in the wrong stuff, and that's not really true. It creates a bunch of red links that will then trigger them to create a bunch of meaningless pages..... -- Wyn talk 02:32, 11 July 2009 (UTC)

I meant how no category would be automatically created if people write the wrong thing, but fine, if you would rather not have those links there, we will leave just the category links at the bottom of the articles : P Erasculio 02:38, 11 July 2009 (UTC)

I would rather have the categories more structured. I'd rather have it trigger the subcategories on the bottom of the page. I know some people think using Categories to find stuff is "archaic" but in my mind it's a valuable search tool. By creating a better category structure you'd be able to go to the World category and see a list of the subcategories, and then find the pages for each... rather than have every page go into the World category directly. I don't know if I'm making much sense, I need food. -- Wyn talk 02:49, 11 July 2009 (UTC)

That makes sense. Just adjust the categorization system to prioritize sub categories. --JonTheMon 03:05, 11 July 2009 (UTC)

(RI) The change would be simple. There's a problem, though. Imagine I have a suggestion under the World category, and under the Lore and NPCs subcategories. When I make a list of World suggestions, that idea would appear three times: once for being under the World category, another for being under the Lore subcategory (that would be inside the World category) and the third for being within the NPCs category (which would also be inside the World category). If we change the system so the idea would only be within the subcategories, it would still appear twice on the list. We could fix this by...

• Adding each suggestion to a single subcategory. It would fix the problem, as any given suggestion would be only under one subcategory, that would be within a main category. However, some users may have problems picking a single subcategor for their ideas.
• Giving each suggestion two subcategories, with one of them being the main one and the other a secondary one, and adding the suggestions to the category lists based on the main subcategory only. An idea to marry Cynn and Mhenlo would have "NPCs" as its main subcategory and "Story" as its second subcategory; the list would show both subcategories, but someone who went to Category: Story would not see that suggestion there. I'm worried this would be too complex for some users, though.
• Leaving subcategories and using just the main categories, as it is right now. This has the problems Wyn has mentioned above, and it's likely that sooner or later we will need subcategories.

What do you people think? And for the records, how do I add the date of creation to those lists? Erasculio 03:51, 11 July 2009 (UTC)

I am horrid with the #if coding, but there should be a way (and I'm hoping that someone with better technical knowledge like Aiiane or poke might show us how) to see if the subcategories are in the same primary category and eliminate the double listing on a main list, but allow separate listing if the subcategories were divided into separate lists. With categories, I would always want to shoot for the page being added to the lowest common denominator. Again, I may be thinking backwards. You are focusing on the list, and I'm focusing on the categorical structure. -- Wyn talk 04:13, 11 July 2009 (UTC)

If you are referring to dpl generated lists in regard to adding the date of creation Erasculio, then simply add the following code to the dpl: | userdateformat = m.d.Y H:i | addeditdate = true | ordermethod = firstedit| order = descending and use %DATE% to show the date where you wish it to appear under the format section. The userdateformat can be changed to whatever format you wish and the ordermethod can be changed to lastedit if you want it to list the last modified date instead of creation date but as I said before not both at once.

Also since apparently I'm going to get very little time to work on this due to the amount of extra hours I'm having to do at work I might not have a chance to modify my original list as I had hoped. --Kakarot 10:26, 11 July 2009 (UTC)

Thanks, Kakarot, that really helped : ) This is almost exactly what I want: a system with the username (and there's a category with suggestions from that user), with the date of creation, with the category and subcategory (and there's a category for each subcategory) and with the page title (which is both descriptive of what the idea is, and is also a direct link to the suggestion). The only things yet to be fixed there are...

• Make categories based on date of creation. I don't know how to make the suggestion infobox to show the date.
• Change the page title so it only shows the title of the article, not its "wiki title" ("Marry Cynn and Mhenlo" instead of "Erasculio/Marry Cynn and Mhenlo")
• Fix the cell color: those cells were supposed to be yellow, like the warrior skill list, not gray.

Erasculio 13:03, 11 July 2009 (UTC)

For the title part, you use the | replaceintitle command with a regexp. Look at my code for how it's done. If you want both times, the simplest way would be to have people manual add | date = ~~~~~ to your infobox. Otherwise, there are maic words for time. Plenty of them. Backsword 13:49, 11 July 2009 (UTC)

I can use the | replaceintitle command to replace, in my list, my name with nothing, creating the look I want. However, is there a way to make it automatically replace the user's name? Otherwise the replaceintitle command would have to list all possible usernames, and so it wouldn't work. Erasculio 14:09, 11 July 2009 (UTC)

If username is standarised, or if it is a known variable, you can just use that variable in the argument, instead of your own username. Backsword 14:17, 11 July 2009 (UTC)

The suggestion infobox has an entry for username under "user =", but trying to use {{{user}}} as the variable doesn't work. I'm guessing I'm using the wrong code to summon that variable. Erasculio 14:21, 11 July 2009 (UTC)

For the variable to be known to the DPL template, it must be passed to that template when invoked as a paramter. SO you can only do that when it's known before. Backsword 14:24, 11 July 2009 (UTC)

(RI) Updating. I have found the allrevisionsbefore command, which allows the DPL to list pages based on when they were edited. This allows us to pick which articles each list will show based on their date, without the need to create a category for date of creation, making it a lot easier to have lists showing only the most recent suggestions. The things I have yet to fix are:

• I can't add more than one list to the same page, as this happens. Any idea on how to fix it?
• I still haven't figured out how to remove the username from the title of the page. Backsword's idea, the replacetitle command, is great, but I can't figure out how to make the list template to call a single parameter from the infobox template. Using {{{user}}} would call a parameter from the list, not from the infobox; and using {User:Erasculio/User feedback template}:user within the replacetitle command doesn't work. Does someone know how to do this?
• The problem with categories, as mentioned by Wynthyst above: adding the same suggestion to more than one subcategory would make said suggestion appear twice in the category list (an idea with the NPCs subcategory and the Story subcategory, both part of the World category, would appear twice in the World list).

Everything else appears to be working, though. Erasculio 15:03, 12 July 2009 (UTC)

Issue one is simply you forgetting to close your tables in the format command.

I'm not quite sure what you are trying to do in issue two. If you could give one or two examples and the wanted outcome, that would help. That said, you seems to have include calls mixed up with variables. They're not: you only list like that in the include command, then do operations in the secsepartors command, or in a phantom template.

For the third, there is a DPL command for including (or not) duplicate pages. Backsword 15:29, 12 July 2009 (UTC)

So per issue...

1) Ah...How do I close the tables? Using }} isn't working (noobz question, I know).

2) I want the title section to show only the title of the page ("Buff Meteor Shower") instead of the username and then the title ("Erasculio/Buff Meteor Shower"). Currently my tables are not showing "Erasculio/Buff Meteor Shower" because I'm using the replacetitle with my name, but that would not work with the real list, as I would not be the only one making suggestions. I'm trying to find a way so the DPL will, for every row of these tables, use the name under the User section (the first column) as the replacetitle for that title (the last column). Or failing that, to find a way of not showing the usernames without adding the replacetitle command with all the usernames in the wiki.

3) Thanks, I'll find out which command is that!

Erasculio 15:43, 12 July 2009 (UTC)

Table closing is |} instead of }} - }} is for templates. (Aiiane - talk - contribs) 21:07, 12 July 2009 (UTC)

Thanks, Aiiane, that problem has been fixed. And I was being rather dumb - DPL automatically avoid showing duplicates, so I didn't even have to worry about the category thing. Erasculio 22:53, 12 July 2009 (UTC)

Summary / quick reference pages

If a few lines can be used to summarize all the major points of a suggestion, or describe the suggestion in its' entirety, I don't see any significant drawback to including dozens of those brief summaries and brief suggestions on one page so that they can be read or skimmed through more quickly. Since there seems to be strong opposition against summaries in index pages, I'm proposing that we also allow separate summary pages. -- Gordon Ecker (talk) 05:15, 11 July 2009 (UTC)

I think only Eras have been agaisnt them, and I'm not sure why. Otherwise, the argument have been to who should write them. Backsword 13:42, 11 July 2009 (UTC)

I think it's too much of a headache for something redudant. Do we really need to list more information than, for example, this? Erasculio 14:10, 11 July 2009 (UTC)

I'd say yes. For example a "nerf Shadow Form" link could lead to a page with a suggestion which would bring perma-SF tanks down to the level of other tank builds for the sake of balance, a page with a suggestion which would make Shadow Form a waste of a skill slot or a page with a suggestion which would actually be a buff due to an ignorant or deceptive author. However I don't think that there will an urgent need for summary / quick reference pages until we have a large number of suggestions. -- Gordon Ecker (talk) 00:17, 13 July 2009 (UTC)

System proposal

Thanks to a lot of help in the above section, I have made a system that I now believe could work for the suggestions lists. Here's how it works:

• Each suggestion has a suggestion infobox, as seen here. We can add that infobox to the auto page creation system Aiiane has implemented (as seen here). The infobox has few parameters: the name of the user and to which categories the suggestion belongs to. Filling the category and subcategory fields with wrong choices doesn't do anything; filling with the proper expressions add the page to the proper category and allow the suggestion to appear in one of the suggestion lists. Wynthyst had began planning a system of categories we can use for this (the one I have began using in my examples).
• The suggestions appear in DPL based lists such as those, being sortable by username, date of creation, category, main subcategory, secondary subcategory, and title. The page title is already a summary of the suggestion, to make browsing the list easier, and the skill feedback list may have the profession and the attribute as its subcategories, making it easier to find suggestions specifically about a given subject. Given how the list is DPL based it may only host 500 entries, but we can use the "date" parameter to show only suggestions with revisions after a giving date, making sure we have only the most recent entries.

It's far from being perfect, but the code is simple enough (I don't know anything about DPL and yet I was able to make it with some help, anyone who gives it a look will probably understand how it works better than me : P) and I think it has most of the traits we need. Of course, there are still some problems (such as the page titles showing more stuff than they should) and those who actually know DPL are likely going to cry when they take a look at the code (it's a big mess), but I think it could work.
(Lol at the edit conflict with Satanael's section above. Just when I thought this was going to be somewhat easy xD.) Erasculio 23:11, 12 July 2009 (UTC)

The username shouldn't be a necessary parameter; that can be pulled out of the path to the page. (Aiiane - talk - contribs) 00:44, 13 July 2009 (UTC)

How? I could use the %USER% parameter for the DPL list, but that would display the user who last edited the article, who may not be its creator. I don't know how to make the infobox to summon the name of the user who created the article, or how to call part of the path of the page to appear on the DPL list. Ah, never mind, I think I have figured out how to do it, by using the addauthor command. Still, I like how the infobox looks showing the username. Erasculio 01:34, 13 July 2009 (UTC)

The infobox can still show the username. {{#titleparts:{{PAGENAME}}|1|2}} evaluated on a suggestion page will resolve to the name of the author as specified by the page's location. (Aiiane - talk - contribs) 01:47, 13 July 2009 (UTC)

Done. Also, thanks, that apparently solved the problem I was having with the page title. Erasculio 03:20, 13 July 2009 (UTC)

(RI) While testing the templates to see if they work on the Feedback namespace, I learned that the infobox template works. However, the template for the suggestion lists is not working; after copying the template to the Template namespace and trying to summon it from there, all I get is an empty list, like here (the upper list calling the template, and the lower one calling from the original template in my userspace). Does anyone have an idea of what the problem is? Erasculio 01:57, 15 July 2009 (UTC)

I actually think the block on editing the Feedback namespace is somehow preventing the DPL from summoning the articles within the Feedback namespace. Erasculio 02:41, 15 July 2009 (UTC)

Why do you invoke a template that is in the template namespace with {{Template:___}} ? You can omit the Template: from it. --JonTheMon 02:43, 15 July 2009 (UTC)

That brings up another problem: keep track of your spaces. For dpl, "Template:Feedback table" =/= "Template: Feedback table", but invoking both of those will give the same thing. --JonTheMon 02:47, 15 July 2009 (UTC)

Actually, I think the correct way is without the spaces. With them, the first table here is empty; without the spaces, it has one row. Erasculio 02:52, 15 July 2009 (UTC)

Ok, yes, the correct way is without the space after the : and for the "uses" parameter of dpl you have to specify the Template: sorry about screwing up your template. --JonTheMon 02:54, 15 July 2009 (UTC)

Damn it, we're just circling. Ok, if you invoke the template on the page with {{Feedback infobox then in your dpl you'd use |uses = Template:Feedback infobox and |include = {Feedback infobox}. If you go with {{Template:Feedback infobox then in your dpl you'd use |uses = Template:Feedback infobox and |include = {Template:Feedback infobox}. I need to go, so have fun, especially since i'm not screwing you up anymore :P --JonTheMon 03:01, 15 July 2009 (UTC)

(EC) Well, now my head hurts, but you have fixed the problem (now the articles on the Feedback space are appearing on the lists). Thanks! : D Erasculio 03:03, 15 July 2009 (UTC)

Green Outline

How would I go about getting the Green Outline around the tabs as shown here? -- Lacky 05:51, 17 July 2009 (UTC)

You have to change your monobook.css file. Haven't we already been through this? -- Wyn talk 05:53, 17 July 2009 (UTC)

Yes, I know, but what would the code for it be? -- Lacky 05:54, 17 July 2009 (UTC)

I have tried looking for the Feedback namespace .css file page, but I cannot seem to find it anywhere. -- Lacky 05:55, 17 July 2009 (UTC)

It's not a separate page. It's in MediaWiki:Common.css near the bottom. (Aiiane - talk - contribs) 07:19, 17 July 2009 (UTC)

^_^ Thanks Aiiane. So I just copy it it to my monobook.css file or do I have to change something in there as well? -- Lacky 07:35, 17 July 2009 (UTC)

RESOLVED: I have gotten it working with some help from Poke. Cheers! -- Lacky 23:54, 17 July 2009 (UTC)

Guild Wars suggestions

Ta-daaa! Things to do:

• I'm rather sure you people are going to complain about the color scheme. I'm rather fond of it myself; it's in the order of professions in the game.
• This page is waaay too big. What do you people think of archiving some sections?
• Jon had a very good point: currently, the feedback infobox does not show if a suggestion is about GW or GW2. We could add an entry on the infobox about this, but...I have copied the skill infobox box (it's rather fitting, IMO, given how the green table mixes well with the feedback space) when creation the feedback infobox. A side effect is that the feedback infobox has that large gray symbol, and I was wondering what to have in its place. How about replacing it with the Guild Wars logo for GW suggestions, and the Guild Wars 2 logo for GW2 suggestions? We would need tango-like versions of those icons, but I think that's something feasible.
• There are still some things I would like to change (having the skill list showing the icon of the professions instead of their names, for example), but it's mostly fluff.
• Do you people like the current system? If so, we have other things to build around it (the help page, etc).

Erasculio 18:06, 17 July 2009 (UTC)

Well, this looks good, and you've obviously put a lot of work into it, which I appreciate a lot. However, it has some obvious issues, as you mentioned this page is going to get way too big. And, given that there is a separate list for each main category, the main category column in each list is redundant. Why not make each list their own page rather than a section on the page?

Also, what is your thinking about this? I really think that would be a better way of doing it, since it looks like we're going to have to split this page up further anyway, it makes sense to do it that way, if we can. (Satanael 18:20, 17 July 2009 (UTC))

I think he meant this discussion page was too big... --Freedom Bound 18:23, 17 July 2009 (UTC)

(EC) When I talked about the page being too big, I meant this one in which we're discussing stuff : D I would rather keep each list as part of a single page just to make it easier for the Arena Net developers, so they would be able to, from a single page, read all Guild Wars suggestions. Eventually we will have to split each table in a page, and later split each table in multiple tables (one per subcategory) and so on, but for now I think the page I have proposed works.

I haven't forgotten about your proposal. It requires things I still haven't learned how to do, although I'm trying to figure it out. Once I learn how to do it, I think it's worth a try; I believe that system would be better at least for the GW2 suggestions. Erasculio 18:26, 17 July 2009 (UTC)

I see, and yes, I can see the value in having all suggestions on one page. I note that my above proposal does that as well. However, I do think that having 8 lists on one page can be as confusing as anything, especially since we are likely to have the same suggestion show up on more than one list. In that light, I would suggest trying to limit it to one list per page, and just have the master list be limited to main categories. Similar to the organization of my proposal above, even if the presentation is different. (Satanael 18:33, 17 July 2009 (UTC))

We could forbid people from having more than one main category per suggestion, like Jon said here, at least for the GW suggestions. Erasculio 18:38, 17 July 2009 (UTC)

Yeah, as you know I'm generally against limiting people in that way, I foresee a lot of complaining about it, and legitimate complaining at that. However, I like to think that I am at least a little bit pragmatic, and if that is the only way we can do it technically, then that's just the way it is. Whatever works. (Satanael 18:58, 17 July 2009 (UTC))

Hmm.. i'm seeing a couple of issues here. Like, how would this system deal with a person having all his suggestions on 1 page and someone with 1 suggestion each on several pages. As it stands now, it's setup for the latter, whereas the thing satanael pointed out was the former. --JonTheMon 19:05, 17 July 2009 (UTC)

No, I've assumed that each suggestion will be on a different page, because that is how we have agreed to set it up. What I'm saying is that one suggestion can span more than one category. (Satanael 19:08, 17 July 2009 (UTC))

(RI) Howdy. I was invited to comment on this page, woo, so here are a few thoughts:

• I like the colour scheme, personally. It's not-too-boring, but not garish either.
• The whole thing would possibly have been more robust, more customisable, less limited and possibly a bit simpler it you'd used a bot, which is what I would have advocated from a technical standpoint, but as you're running from the DPL side, it's done well.
• It looks like the 'User' column contains the last editor and the 'Title' column contains the username (as well as the title). Yikes. From a usability point of view, that's awful You should totally remove the user from the title field (why is it there at all?), rename the 'User' field to 'Last editor' and add a 'Created by' or 'User' field that contains the idea creator. You could even scrap the last editor field altogether - does anyone really need to know this info at a glance?
• As the tables themselves are split based on main category, there is no need to display it in the list. A standard rule of GUIs is: don't display anything more than once, unless you significantly improve the workflow by doing so. I don't think that is the case here. Kill it. :)
• How are you going to make people use the infobox correctly? You have it so malformed suggestions don't show up in the lists, I think, but this is also not good from a usability standpoint. While you may want to limit the number of suggestions by preventing people who haven't done it right from showing up, that it an invalid solution to the problem.

I think that you should have a JavaScript tool (in common.js) that hooks itself in place of the standard creation box when creating a suggestion page and provides a full form with individual selection boxes/input fields for people to fill out. When submitted, it fills out the infobox and performs the creation. In combination with the standard method for the (extreme few) who have JavaScript disabled totally, you'd have a much more accurate and more efficient workflow for people making suggestions. As you can verify input on the client-side, you can instruct users on what to fill out and what is formatted wrong before the page is saved, and directly.

This will result in less effort cleaning up in the long run. Instructions and tips that pop-up while people are typing are also far more likely to be read than a long page that people have to scroll through to reach the create box like I saw above (EULAs anyone?)

• The list page itself. Hmmm. I do worry about the massive influx of suggestions that will probably appear when it goes live. I think the page will become essentially unusable, possibly faster than you are expecting. I would strongly support splitting each one into a page, with a central list showing the categories. It's unlikely that an individual anet person will be viewing more than one category at once (they're heavily team split, I think?) and if they are, several tabs of a few page changes isn't really too much to ask. I believe splitting it would be a net benefit.
• Filtering. I also think that a list of elements 500 long (and any archives/whatever that might involve additional 500s) is difficult and annoying to browse - alphabetic sorting on this scale just isn't good enough. If you truly intend this to be a far better solution that the existing ones, and one that will hold up when (yikes) GW2 comes out and all the hype and popularity of the game comes back in full force (possibly increased), I think a proper filtering/search system would be important.

If I were designing a system to handle this, I would put a second javascript in common.js to handle the filtering by category/creator/subcategory/title searches by selectively hiding content on the page. There, you would have checkboxes of the possible (sub)categories for that page, as well as an input box where text would be checked against suggestion headers. By making selections there, you could filter the current entries on the list.

End. :) Ale_Jrb (talk) 20:08, 17 July 2009 (UTC)

I asked Ale Jrb to take a look at this, not because I don't like what you've been doing Erasculio, but because I trust his coding knowledge and wished to have someone who might be able to help us make this better in the long term. I do have issues with the colors you've used, since they are already colors that represent the specific professions on GWW, it might cause some confusion for people from a purely visual perspective. I cannot comment on the technical end of stuff, and I can guarantee that Ale Jrb's comments are not intended to diminish what you've accomplished. The questions are, Ale, are you willing to help us ramp this up in the ways you have described (I myself couldn't create a javascript hookamabob if it meant saving my soul), and are the rest of us comfortable with doing that? I do agree that we need something that is going to handle more than lists of 500 since there is no time limit on suggestions, I see the dpl limitations being hit relatively quickly, and becoming totally unworkable within a year or less. I am all for keeping this project moving forward however, and getting this open soon, so if that means going with what Erasculio has developed that's what we do, and just deal with the issues as they arise. -- Wyn talk 20:45, 17 July 2009 (UTC)

I also would like to thank Erasculio for your system so far. I mean, the fact is you have created something that can work, and if all else fails we can work with this system, and that means we have successfully taken this thing from theory and ideas to a workable system, which is no small feat in an of itself.

Furthermore, I think that every one of us can agree that it would benefit us all to be able to create a system that will stand the test of time with minimal maintenance and redoing. If either Erasculio or Ale believes he/she can create a system that will accomplish everything we need it to while still being able to handle or at least be flexible enough to handle future issues, then I will support and happily work with whoever is willing to bring this thing to the next level. (Satanael 21:26, 17 July 2009 (UTC))

Incidently, if it wasn't clear above, the current system is a work of art, and Eras has put a huge amount of effort into it. It looks nice, works well, and it pretty darned awesome. :) Ale_Jrb (talk) 21:41, 17 July 2009 (UTC)

And yes, I would be able to put together the scripts I mentioned above relatively quickly. I think that the DPL system will expand OK in time to come. It will involve, though, creating an 'XXXXXX Suggestions/Archive List #' every time one fills out and using the correct allrevisionsbefore parameter in the archive, along with the current date and time. I believe with a few enhancements to increase the ease with which pages are created, and the whole thing is browsed, it would work pretty well. Ale_Jrb (talk) 23:10, 17 July 2009 (UTC)

Heh, people, it's ok, I don't mind if the system I have created is trashed and something new is built in its place, that's part of what a wiki is. I would only ask you to not spend too much time discussing what could possibly be but rather try to implement it as soon as possible - my idea was to open the Guild Wars (1) suggestion area relatively soon, even before we have finished the GW2 suggestions thing, just so we could learn about the problems in the current system and try to improve them. Three points I don't agree with, though:

• The User field is actually showing the name of the author of the article, or that was my intention (it's using the addauthor command, which as far as I know shows the article, not the last editor). I haven't figured out a way to remove the username from the Title field, which is the only reason why it's showing it for now (although I have been trying to fix that; I still haven't learned what's the equivalent of the {{BASEPAGENAME}} command for DPL).
• We could make the lists to show only the most recent 500 entries with the allrevisionssince command, which is already a part of the DPL. Between that and the ability of splitting the tables more and more (one per category now, later one per subcategory, and then one by combination of subcategories), I think we could overcome the 500 limit for DPL without too many problems (although it appears Ale has a far better idea 0.O). I'm not fond of allowing an user to have his idea on multiple categories, though, as that would add an incredibly high number of entries to the lists; IMO, asking everyone to assign one main category for their ideas could work.
• And lastly, I'm really really against making it too easy to create a suggestion. I still believe one of the main problems of the last incarnation of the Guild Wars suggestions system was the auto page creation thing, as was discussed near the end of its life. If we add something which allows users to make suggestions just by clicking on a box, I think we will have a lot of suggestions on the wrong page.

Other than that, carry on. As soon as this is done, I'll be happy : ) Erasculio 23:21, 17 July 2009 (UTC)

It wouldn't be too easy - as an example, go to Wikipedia and hit 'Upload File' to be taken through the upload walkthrough. Something like that. As a developer, however, trying to overcome technical issues such as organisation and sorting by making things difficult for the user makes me feel ill :P. If the 'User' field is showing the author, great. I got confused because everything is written from the point of view of a user named 'Example' (it's in his feedback space, I think) but that wasn't showing up. I don;t know if my archiving system would work. DPL isn't installed on Wikipedia, we do everything like that using bots, so I don't know it that well. I think it should be in one main category, there's just no need for the category column in the list as the lists themselves are already split by the main category. I think the lists are awesome though, and see no need to change them. Ale_Jrb (talk) 23:32, 17 July 2009 (UTC)

For validating the infobox, you could simply check the entered data with parser functions, based on a "list" of valid combination and if that won't work, disable all categories and display a big red error instead.. So that wouldn't be a problem and wouldn't really require a client side script (which will fail, if a user decides to edit the suggestion later again anyway, because then he is able to simply invalidate the template call..).

Erasculio, you have to use the #titleparts parser function to get the username, as BASEPAGENAME would only return "User" (as in Feedback:User/...).

Also, I don't really think we need to worry about listing "archives" at all. If we ever come to the point where we exceed the 500 page limit (when going the DPL way), which we really shouldn't because of the category splitting, then we should prefer making simple static lists instead. Having DPL calls for archives, whereas those archives would be just "pages" (and no real archives) would make it just too complicated. poke | talk 23:32, 17 July 2009 (UTC)

I actually can't see what the tutorial for uploading images on Wikipedia looks like, because I don't have an account there xD But it's ok, I trust you people, go for it.

Poke, out of curiosity, how do I make the #titleparts function to call from the suggestion article, as opposed to the list article? I have tried using that (which is why the example list on my userspace doesn't show the username on the title; it's removing my name, as it appears in the list page title), but I couldn't make it work with the real list. Erasculio 23:38, 17 July 2009 (UTC)

You have to call the #titleparts function in the output section of DPL and give it the pagetitle from DPL (%TITLE%) to work with. To be able to use the %TITLE%, you have to put the parser function inside of ²{ }² so it gets executed when the output is generated. poke | talk 23:46, 17 July 2009 (UTC)

| replaceintitle = ²{/%TITLE%|1|3\//,}² ? Erasculio 23:54, 17 July 2009 (UTC)

Uhm, no that won't work. I was rather thinking of adding ²{#titleparts:%TITLE%|1|3}² in format or secseparators at that point, where the username should appear. poke | talk 00:05, 18 July 2009 (UTC)

Was more thinking of what I just did :P Btw. it is much easier to work with DPL, when you don't use a template that does the DPL call. Just put the call in the suggestion page directly and make it working well, then you can always decide to move it to a template. poke | talk 00:24, 18 July 2009 (UTC)

Erh, poke, you fixed the part that didn't have to be fixed xD That section was linking to the feedback Userpage of the author of the article; it was only showing my name because I was the one who had written the articles as opposed to User:Example (who doesn't really exist). I actually liked that feature, in case someone decided to write an article on someone else's page (I think it's Falcon Eye and his friend who are sharing suggestions in his userpage). What I was trying to do was fixing how the title column is showing the username too, as opposed to only the name of the suggestion. Erasculio 00:33, 18 July 2009 (UTC)

Ah, misunderstood you then, but I really think the creator's or owner's username should be included, too. (btw. need help, or are you just experimenting there?) poke | talk 00:49, 18 July 2009 (UTC)

It's ok, you're right. Would you mind if I change the username so it's also a link to the userpage on the feedback space (this one)? Also, do you happen to know how could I set the size of the column showing the suggestion title? I'm trying to set it so it has a fixed size (given how in theory it's the most important column, I wouldn't like it to always be the smaller), but I don't know where to add the width command now. Erasculio 01:06, 18 July 2009 (UTC)

(Reset indent) Not to sound doom-and-gloomy or anything, but if you try to put all of those lists on the same page you're going to end up with something that takes up 100+ screens after a month or two. Whatever that is, it's not "easy to use". Having multiple pages for multiple lists does not making things harder, if anything it makes it simpler. Simply provide an easy way to move from page to page (navboxes work well) and things will be fine. (Aiiane - talk - contribs) 10:50, 18 July 2009 (UTC)

Wow, this is confusing. This is a response to poke from up there.

Yes, it's possible to verify using the parser functions and display an error once the page has saved - that should be done, in case JavaScript is disabled. That system, however, is inferior to a 'wizard' type interface that splits the template infobox creation into a few steps, which would work for everyone who has JavaScript enabled (and most people do). Relying solely on the parser verification is clumsy, unnecessary and slow. Also, most people will completely ignore any warning given after they've saved the page. We have similar warnings on several templates (such as the reference template) over on Wikipedia, and the number of people who completely ignore the massive, bold red text in the middle of an article they've just written is mind-boggling. This will slowly mess up the whole thing and make it much harder to manage in the long term, which is what this solution is aiming for.

Also, it is possible to make the hook attach itself when the page is being editing, and extract the required data from the template so that the template can't be messed up by accident when editing either. Combined with the parser verification for people without JavaScript, or running noscript etc., and the system is robust, fast and much cleaner.

With regards to the lists, I advocated a static list created by a bot above, which wouldn't have the same limitations. If you want to start copying data from DPL lists into static archives, that's definitely a strong possibility as well, but it would be annoying and quite time consuming. I don't know the actual rate of growth of the previous suggestions system, but I think 500 would be reached quite fast. And even if it isn't now, if this system is meant to handle GW2 when released, it needs to be able to handle epic amounts of growth extremely rapidly.

And like Aiiane, I also think that even from the beginning, it is necessary to split each of the major categories into separate pages. Ale_Jrb (talk) 11:03, 18 July 2009 (UTC)

I was rather talking about the separated lists already, it will take a while until those lists (split by multiple categories) will have 500+ entries. And getting a static text from a DPL call is not hard at all, by simply using the #tag:pre parser function.

You say people will completely ignore any warnings; that is okay in my opinion. Because in the past discussions about the game suggestions, we wanted to give more responsibility to the users (which is also one of the main reasons for only allowing registered users to host suggestions). So if they don't care about the suggestions, we will simply erase those invalid suggestions. Also building a validation into the template is necessary anyway, as you said it would work then for those without javascript, so we would have that downside for everybody, with or without javascript. Also personally I wouldn't really feel comfortable to have a completely different editing system for suggestions, given that we actually want to give more freedom to people in the style of those pages (and only making the infobox a required part). poke | talk 13:38, 18 July 2009 (UTC)

I don't see it being a problem that if they mess up their infobox that it doesn't get listed with other suggestions. If they mess it up, nobody's gonna look at the page and the bold red text and so no harm. --JonTheMon 15:27, 18 July 2009 (UTC)

What's the downside for everybody? If a script is filling out the infobox, people with JavaScript enabled won't make the mistakes and won't ever cause a parser error. If they don't, the parser error can tell those who bother reading it that there is a problem, and the rest won't have it listed. This results in the fewest people with unlisted suggestions, which is a net benefit. Obviously, it doesn't completely replace the editing interface; it helps fill out the infobox (which is where the problems will occur) with the correct information, and as it is more present during the edit flow, instructions and tips given are more likely to be heeded. A system without JavaScript is possibly adequate, but a system with is superior. I don't really mind either way :) - if you think it's better without, keep it without. There is currently no verification in the actual template, I think, only in the lists, so that needs to be added, and can go on the to-do list.

And if ArenaNet announces that they're taking suggestions in the new feedback namespace on the main site, I think a few hundred people making a few burning suggestions each is quite reasonable, so I think it will fill up quite fast. That's a bit irrelevant though, if you are going to archive the lists. Ale_Jrb (talk) 16:33, 18 July 2009 (UTC)

Also, I think that if the parser verification gets an error, it should be categorised (suggestions with errors or something similar) so that cleaning up is easier. It's probably better if we don't have hundreds of non-working, unlisted suggestion pages all over the place: messy is bad. Ale_Jrb (talk) 16:38, 18 July 2009 (UTC)

I have split the suggestion lists in individual articles, and since they have been split, I have also made a list for each profession in the skills suggestions article. We need to change the template so it can hide the first Subcategory column, though, in order to avoid redundancy (saying "Subcategory: Elementalist skills" in the list marked as "Elementalist skills suggestions"). Erasculio 16:40, 18 July 2009 (UTC)

Perhaps I can clear something up here, Ale jrb. You write "This results in the fewest people with unlisted suggestions, which is a net benefit." However, this is the thing, many here don't see that as a positive, far from it. A massive amount of linked pages that have a filled out template but absolutly garbage for content is not desirable. That's why people want to make it harder to make suggestions, not to deal with some technical issue.

I think perhaps it is fundamentaly about which users one is trying to benefit. You thinmk it is the ones making the suggestion, but the viewpoiint has been to make it good for the reader. And had it not, we would simply had Feedback:Sandbox and naught else. Backsword 20:08, 23 July 2009 (UTC)

But you forget: the easier it is to create a suggestion with the correct formatting, the easier it is on a reader. People suggesting it should be hard to make suggestions, in order to filter out crap, are approaching the problem from the angle of a user or administrator - not the angle of a developer. You are, however, trying to develop a system, so coming from the angle you are is incorrect. A system should be able to scale according to its usage - and more importantly, it must be able to scale effectively, so the usability for everyone is not affected by the useage levels. The MediaWiki software itself is a good example, so long as you use it for what it was designed (documented, not taking feedback). GWW, a small wiki, works just as well for everyone as Wikipedia, a very large Wiki - there is crap on Wikipedia, but it doesn't stop you using it effectively. The scale is irrelevant to the success. This is what you should be aiming for in this project.

This is made more difficult by the fact we are using not only a wiki, but a DPL based system. With a different system, you could have a peer review/ranking system in place, as well as content analysis and better layouts. This is impractical here, obviously. Nevertheless, we can create helpful tools that assist with reading the suggestions, whether that be list filters, deletion assistance tools, content sorting, administrators wandering about checking stuff; whatever. Combined with a streamlined interface that makes it easy to create a useful suggestion that's easy to read, and you have a far superior system to a shot-in-the-dark, complicated and difficult to use one.

By saying this, you seem to be forgetting an important point. Presumably anet does want suggestions, at least to some extent, or why would they bother with all this? They aren't doing much, true, but if they really didn't care they could just have left it how it was at no effort to them at all. Thus, more suggestions is generally good. This is especially true when you consider the fact you are under a serious misapprehension. You seem to be suggesting that making it harder to add suggestions will filter out the rubbish ones. Why should it? You could easily have a situation where two users, one of whom is a newbie at wiki-ing but has a really awesome idea, and one of whom contributes to loads of fan wikis but wants to add sapceships, both wish to make a suggestion. With a difficult system, the spaceship suggestion would go through while the other wouldn't. With an easy system, both would go trhough and the rubbish one could be deleted or delisted. This is the net benefit to which I was referring above. Ale_Jrb (talk) 20:55, 23 July 2009 (UTC)

I agree with Ale here but from a slightly different perspective. I think we need to make an important distinction with regard to our last system. It was not, technically, that we got inundated with one-liner suggestions because suggestions creation was merely easy, rather we got inundated because suggestion creation was quick. This is an important distinction because we can, and should, make a system that allows for easy suggestion creation, while extending the amount of time it takes to create a suggestion. In our last system, a user went to the suggestion page, hit one button and started writing their suggestion. This quickness lent itself to quickly made (and therefore thoughtless) one-liner suggestions.

Our current system of suggestion creation, as Aiiane has currently built it, is easy, but it is not as quick as the previous system. Before you hit one button, wrote your suggestion, and then hit save. Now you create your userpage, you create your suggestion page, you write your suggestion, then you fill in the template to get the suggestion listed. No matter what we do to make those steps easier and well explained, the fact that the users have to go through all those steps means they will have to put more thought into their suggestion than they previously had to. Therefore, making those steps clear and obvious to accomplish (i.e., easy) will not necessarily mean we will once again be inundated with one-liner suggestions.

And Ale is right, we don't actually want to reduce the overall number of suggestions, we want to reduce the number of poorly thought-out one-liner suggestions (e.g., "Don't copy WoW!") that contribute nothing to the game developers. Making the system complicated and difficult to use will reduce the overall number of suggestions, and will also reduce the quickness with which suggestions are made. However, frustrated users will likely inundate admins with questions about how to make a suggestion, or impatient ones will just go to the dev talkpages and flood those with their ideas. These are consequences we don't want.

Therefore, the best system we can make is one that makes it easy to create a suggestion, but not quick. (Satanael 21:57, 23 July 2009 (UTC))

It's a nice sentiment, but it's terribly naïve. And the notion that Wikipedia doesn't actually need it's 1600 extra asmins is right out there.

But since it is not me who will be doing the work, I'm leaving it up to those that will to decide how quickly they want to burn out. Backsword 14:31, 28 July 2009 (UTC)

Seriously Backsword, some of you comments are about as helpful as a monkey in a nuclear power plant. Naïve why? In what way? Who cares how many admins wikipedia has? And what does admin burnout have to do with this dicussion at all? I'm not trying to create drama, but if you have nothing of any substance to add, then what are you saying and why are you bothering? (Satanael 22:06, 28 July 2009 (UTC))

Arbitrary section break

(Reset indent) Sorry to jump in the middle here guys, but I really wanted to get this out before you all get too far down on making the lists. I assume that now that we have some more heavy hitting code guys in on this, then my previous proposal, which was archived, is now possible. That proposal was to have a master list which looked like this:

Username		Last modified		World		Allies		Items		PvE		PvP		Skills		Player Interaction		Mechanics		Page Title
Erasculio		06.06.2009																		Add mudkips to the Gyala Hatchery

If we can do it this way, with yes/no columns for each category rather than the "subacategory" columns, then I think this would be preferable. In other words, there would be two kinds of lists, the first would look very much like this one above, and be like the master list for, say, GW1 suggestion (which could be located here), and would have all the main categories as the yes/no columns above. At the top of these lists, the title of the yes/no columns would link to more specific sublists: a list for each main category. On these sublists they would look the same but the yes/no columns would list the subcategories.

So for example, if you went to the GW1 master list and then clicked on the "PvP" link, it would take you to a sublist that looks something like this:

Username		Last modified		GvG		AB		HA		HB		TA		RA		Page Title
Erasculio		06.06.2009														Make Guild Lords usable heroes in PvP

Eras and a few others will already have seen this, and I apologize for being a broken record, but I just wanted to bring it out again so that people who were not as involved then (ale, poke, or whoever) can take a look and see if this can be done. If it can, I really think we should organize the lists this way. (Satanael 17:40, 18 July 2009 (UTC))

That puts quite a stringent limit on the number of possible subcategories, as you would have to have a column for each one. The styling is also a bit iffy, but that's something that could be sorted later. It could probably be done, by outputting the relevant yes/no templates based on a parser check of whether the category matches, but I'm not sure it would necessarily be a better system. It might make it easier to sort by an individual category on the list; the DPL sorts could sort the yes/no rather than alphabetically doing the categories. I dunno. Is there a particular reason why you prefer each category with its own columns rather than simply having them listed in one? Ale_Jrb (talk) 20:18, 18 July 2009 (UTC)

I believe the reasoning behind it is to allow things to be in multiple categories at once. 134.173.63.21 20:20, 18 July 2009 (UTC)

That's the purpose of subcategories. The main categories should be set up such that there is virtually no overlap; I think these categories basically achieve this goal. There will always (IMO, I can't think of any counter examples) be a main category that fits much better than the others. Ale_Jrb (talk) 20:22, 18 July 2009 (UTC)

From the examples above, at least, the subcategories were what the checkbox columns were for, no? (Aiiane - talk - contribs) 20:24, 18 July 2009 (UTC)

I see it as there is a main list with each of the main categories as a column - anything in each category has a check next to it. When you click on a main category link, you are taken to another page containing all the pages in that main category, with a column for each of the sub categories it is in. I see two problems: if you wish to add more subcategories (there could be easily 10 for one of the bigger mainn categories, and over time, maybe many more). These won't scale well, and the system will have to be changed in the future. In the current live example, it will scale well. Keep in mind that the current system could be adapted to allow pages into multiple main categories - they will simply be shown on more than one list - it would just take another field in the infobox, which would be easy to add. Ale_Jrb (talk) 20:31, 18 July 2009 (UTC)

The problem I see with the section-and-list-per-subcategory format is that it can become a pain to tell what subcategory you're currently in if the lists are larger than a single screen of data, and there's no good way to sort results by anything other than subcategory once you're on that page. TBH, I'd prefer to see a system without multiple lists on a single page - web pages were designed to be linked together for a reason, and the Feedback namespace has subpaging turned on, there's no reason why that shouldn't be utilized. (Aiiane - talk - contribs) 20:35, 18 July 2009 (UTC)

(Edit conflict) x2 As IP pointed out, the principal purpose is to allow for a single suggestion to span more than one category and more than 2 subcategories. We've discussed this before, and the simple fact is that suggestions can often span more than one category and easily span more than 2 subcategories. Limiting users (as we have done with the other tables above) to only 2 subcategories will accomplish little more than to cause a lot of users to complain that they are being limited by the listing system in their freedom to create a suggestion. Sometimes a suggestion is as simple as "buff meteor shower", but sometimes the suggestions go on for pages upon pages and cover almost a complete game. We can tell people to break up their suggestions, but for one they won't want to, for two it causes a big policing issue, and even then we are still going to have to deal with suggestions that are pretty expansive. Therefore, we need our system to be able to handle all of the above. And Ale is right, I also like this system because it makes things easier to browse.

True, it will limit us to a maximum of about 10 columns per list for categories and subcategories, but frankly I don't see that as a bad thing. We need to remember that we are going to be asking our users to pick the categories and subcategories themselves. Wih 8 main categories with a maximum of 10 subcategories each, we are already asking our users to sift through 80 subcategories to figure out which ones fit their suggestions. I don't really see how allowing for more than that is a good thing from a usability standpoint. (Satanael 20:39, 18 July 2009 (UTC))

Other organization topics

Making a new section given how this isn't about the more technical aspects being discussed above.

1. For the suggestions subpages, what name do you people want? "Guild Wars world suggestions", or "Guild Wars World suggestions"?
2. Who would like to make the suggestions navbox? I think we should have one for GW and another for GW2.
3. About the icon used in the background of the infobox (currently the grey circle here), what do you people think of using stylized versions of the GW and GW2 icons there to make it visible with a quick glance which game a suggestion belongs to?

Erasculio 13:55, 18 July 2009 (UTC)

RE:1, I think it's been determined that it's "GW world feedback". --JonTheMon 14:52, 18 July 2009 (UTC)

Oh, the pages themselves, not the cat.... Probably "Guild Wars world suggestions" in keeping with using lower case when possible. --JonTheMon 14:54, 18 July 2009 (UTC)

I don't really care about #1, so I won't bother to muddle the discussion with a meaningless comment. #2 I was thinking it could be cool to have one nav box that was present throughout the feedback namespace. This would link to the main feedback page, the FAQ, Rules, GW1 master list, GW2 master list, getting started, etc. For #3, I think that is an awesome idea and I fully support it. (Satanael 17:44, 18 July 2009 (UTC))

RE3: As explained on my talk page, I will later make a specialized layout for the feedback namespace. I won't be able to push it live today, but you can expect something tomorrow morning. poke | talk 18:03, 18 July 2009 (UTC)

Ah, ok. I would like to keep the infobox green if possible, though. I have seen some other examples with red, pink or purple colors, and I think the green (not necessarily the green in the current infobox, just some green) would match better the current layout of the Feedback space. Erasculio 20:54, 18 July 2009 (UTC)

NOOOOO The green is for the skill infobox, I would like to use the muted purple that I have made all the rest of the feedback stuff.... it is different from the purple guild hall infobox, and would keep it tied with the rest of the feedback space. (I'm determined to have purple if you haven't noticed :P) -- Wyn 21:53, 18 July 2009 (UTC)

Javascript

Ok, Ale has brought up using a javascript wizard like thingy to aid people in constructing their infoboxes. It would be something nice, but I don't know how maintainable it is. Like, how many users can understand what's going on, fix any problems, and make any change? --JonTheMon 17:21, 18 July 2009 (UTC)

In general, I'm all for improving the usability of the space, and it seems like the javascript stuff will certainly do that. Jon does have a point, I certainly wouldn't even know where to begin with maiking any changes we might need later. poke, would you? Ale, will you be around to assist with making changes even if that is like 2 years from now? (Satanael 17:48, 18 July 2009 (UTC))

Maintainability is indeed something that is more complicated than any of our ideas before (for example the bot approach could be replaced by manually adding list items - even if it might be very boring); especially if we decide to be able to add categories and such at a later point it might be not too easy to edit it. I, for one will concentrated on making this work alone first, and add things to the infobox to make an easy customizable validation and such. poke | talk 18:11, 18 July 2009 (UTC)

Yeah, the maintainability is an issue - I do think that holds true for the system itself (with quite a lot of different templates and DPLs), as well as any JavaScript additions that we choose to add. I might have a look at a simple script to see how it would work. It should be relatively easy to maintain, and I personally can always be reached by email (at least, that held true more than two years ago, and still holds true at the moment :P) - it would work outside of the main system, though, so that should be finished first, probably. I do prefer this approach in that it doesn't put a bot (and thus the system) in the hands of a single user, in case they decided to stop running it or something, so in that sense it is more maintainable. Ale_Jrb (talk) 20:12, 18 July 2009 (UTC)

Dev-talk no longer for Feedback

→ moved from User talk:Linsey Murdock

Alright Era, then let's have a little Honesty-Session right now. We're doing this b/c you just brought it up. To quote Wyn: "There will be some new rules in the Feedback. No skill feedback, no bug reports, no suggestions on staff pages." ...in other words, NO COMPLAINTS ABOUT THE GAME DESIGN, PERIOD... none. No actual Feedback in the Feedback namespace so long as Linsey must read it on her own page. Just Admit that your real position on this is even stricter with regards to enforcement than Wyn's is. And it's already been decided without anything resembling a Majority!
To Everyone else, including Lin and Emily... this is only going to turn into a long drawn out battle with twice the seething drama over time unless the rest of you get more involved. I can't speak FOR any of you. And given how I'm always dismissed and vilified like Boro or Shard, there's no sense in me speaking for myself either. All I can do is hope that the rest of you get involved and stop these two from highjacking the only direct line of communication we have with Anet ...your turn Era. I can dig up some of your quotes if you need help remembering how much of a hardliner you are on this issue... --ilr 01:19, 31 July 2009 (UTC)

So you have made a new section to talk about the Feedback namespace, specifically adressing me...On Linsey's talk page? Do you realize there are pages on this wiki other than this one? Erasculio 01:28, 31 July 2009 (UTC)

No (that stuff) on staff pages. There is a large portion of the Feedback namespace (namely the entire rest of it) devoted to such matters. The move of staff talk pages to the Feedback namespace isn't an open invitation to put all your suggestions on them, it's just to ease licensing issues with putting them in their proper places. The organization of the namespace is meant to help Anet actually be able to find things, rather than get their talk pages filled with walls of text that may or may not even be relevent to their jobs. If you have a better idea to accomplish that, make a convincing argument (yes, decisions are made with convincing arguments, not votes of "I want this!", and more importantly decisions are made by people who show up. I see your name on this page (not including this section) exactly twice, both times a one-line complaint with no actual counterproposal, let alone a reason why). - Tanetris 02:13, 31 July 2009 (UTC)

But I did propose alternatives! I recommended very specifically an automated system of carrot and stick, as enforced by the Devs through their own wiki-browsing, instead of by the Sysops and Sysop-wannabes. It's been the least labor intensive proposal to date, but ironically the worst-received simply b/c it required a little transparency. But since no one would even consider it, I'm left defending the only verifiable means of direct communication we have left. --ilr 23:40, 5 August 2009 (UTC)

Seriously ilr, there is feedback, and there is QQing. What I see you wanting is a QQing section. Not gonna get it. You can provide feedback on any aspect of the game you wish. If it's a bug, it goes on a bug reporting page, if it's something you'd like to see changed, you can create a suggestion page. If you just want to generally bitch about the state of the game, and point out what a failure the Live team is, take it to a fansite or keep it in your own userspace. The rules are being put in place to try to give the Devs time to actually utilize the new namespace. Their workloads aren't being adjusted to make time for it, their workday isn't being expanded to give them time to read and comment on suggestions/feedback, that time has to come from somewhere, and having less of this stuff on their personal talk page is where. -- Wyn talk 02:48, 31 July 2009 (UTC)

@ILR, You have to bear in mind the last portion of Wyn's statement that you quote above, that there will be no skill feedback, no bug reports, and no suggestions on the dev talkpages. We are creating entire dedicated pages for all of those kinds of feedback. We have multiple pages where bug reports can be provided, we have an entire system of creating feedback for skills and other suggestions, we are even developing ways for people to browse all of these suggestions and bits of feedback more easily so that anyone, including anet staff, can easily find suggestions that interest them. The only thing that Wyn was pointing out was that, because there will be dedicated pages for this kind of feedback, then such feedback will no longer be welcome on the dev talkpages. The only exception to this is regarding support issues, those will still be allowed on Gaile's various support pages. You will still be able to provide "COMPLAINTS ABOUT THE GAME DESIGN", just not on dev talkpages. (Satanael 03:59, 31 July 2009 (UTC))

Wyn if anet wants feedback about game balance every guy that even has a clue about how gw works won't talk about how balanced frenzy is Lilondra *poke* 07:14, 31 July 2009 (UTC)

Ow and satanael I think by design guildwars is a great game.So I don't think alot of people will be ranting about the design Lilondra *poke* 07:15, 31 July 2009 (UTC)

HUH? Lilondra, what does anything I said have anything to do with what you said? As for what Satanael said, he's quoting ilr's cry of not being able to complain about game design on Linsey's page anymore. So point your comment at the right person. -- Wyn talk 07:43, 31 July 2009 (UTC)

"Seriously ilr, there is feedback, and there is QQing. What I see you wanting is a QQing section. Not gonna get it."Lilondra *poke* 11:48, 31 July 2009 (UTC)

Way to bury the topic again... How are normal people supposed to know what you're even planning for Lin's page if you never leave it where they'll actually read any of it? --ilr 21:42, 31 July 2009 (UTC)

(Reset indent) Hi guys! I see that there are concerns about the direction that staff talk pages are going, but I'm going to admit that I'm a little confused about this. I thought the system that it moving forward makes a lot of sense. We need to move the talk pages into the new namespace because if they're in the main space, we can't even read anything that may be a suggestion. Since we can't move items that have more than one author, there's no other way to transfer the pages other than to lock/archive/reopen running topics. That part seems pretty straight forward, and won't really be anything that the broader community should really even notice. The only thing that will change when the move happens is that there will be a small period where the existing talk page is locked and there's a link to the new one (which will function just like the old). Once the archiving/etc happens, the pages will just be redirects, so there's no interruption to flow. Beyond that, I'm not really sure what the concerns are. I can give my thoughts on the topic, but if I don't know where the dissension lies, I can't comment effectively. Is there something that I'm missing? -- Emily Diehl (talk) 22:00, 31 July 2009 (UTC)

It's been spelled out several times by Wyn, Emily... The current plan is that we may no longer make comments of any kind to any of the Dev's talk pages regarding the direction of the Game's design or worst exploits; and multiple "abuses" will result in bannings. Only those who already had direct contact with the devs through Non-Wiki channels, will retain the option to comment immediately to them about various changes. Those of us who relied on the Wiki for that will be at the mercy of the Category options in areas that may take months to be read, and we'll have even less chances of receiving direct answers on those issues that may require more immediate attention. (IoW: Inequality) The current plans are to intentionally shield the Anet staff from the "Feedback" and questions of its most passionate fans. In other words: Your's and Anet's lofty goals of greater Transparency and improved communication, is the exact opposite of the current Feedback plans as stated by Wyn and Erasculio.
Their goals are, and I quote: "You may only post suggestions on your own feedback page. Suggestions elsewhere will be removed" // "we all know this isn't a perfect world. There will always be those who will post on the dev's pages, but I would have no problem actually stating it as a rule, and enforcing it with warnings and bans for repeat offenders", even though She's on the record stating: "I find your "Make this as difficult as possible and they will all go away" attitude really distasteful Erasculio. I think it violates the entire spirit of this wiki, and the spirit of why ArenaNet has gone through the process of revising the licensing terms." ...and granted, these might not be the fairest quotes to use... but my case stands: You can't trust such a tiny minority alone to do what's in Anet's best interest, Emily. ...just like Mike, Jeff, and Patrick couldn't solely trust the loudest "enforcers" of the BNET boards a decade ago to do what was in Blizzard's best interest (yes I was a member of that community too, so I'm speaking from experience). In any case, thank you for atleast looking into this issue. --ilr 22:55, 5 August 2009 (UTC)

What you are neglecting to consider is that while the dev talk pages will be technically in the Feedback namespace, it is still the dev's talk page, and the rules are there to keep those pages from being cluttered or flooded. Bans will be handed out based on abuse of a talk page, not on feedback being given. --JonTheMon 23:17, 5 August 2009 (UTC)

I personally think you are failing to understand any of what has been said on purpose ilr. And you are correct, those are NOT the fairest quotes to use. I have no desire to "shield" the devs from honest feedback, you are being provided an ENTIRE NAMESPACE to provide them with it. If you find a game stopping issue, it should be posted on the bug reporting pages. If you have a suggestion you feel would make the game better, including changes to skills, you will be welcome to create a suggestion page describing it. My comment regarding making this easy that you quoted, is in regards to creating those suggestion pages, not that I feel you (or anyone else in the community) should have carte blanche to bring every single issue directly to the developers on their pages. You will continue to have the specific game update talk pages to address issues related to specific updates. The problem arises when everyone wants to (and does) bring every issue directly to the developer talk pages, and then the community proceeds to discuss each ad nauseum, creating 300kb+ size pages that NO ONE can navigate, and that Linsey (or any other developer) just cannot find spare time to read let alone answer. With your suggestion pages, you and the community will have the associated talk pages to discuss suggestions to your hearts content, and if you have constructed your page according to instructions, it will appear on a clearly defined list of suggestions for the developers to browse through and comment on. Face it, taking stuff directly to Linsey's page has not been a very effective means of getting a timely reply, I mean, her page is currently 2+ months behind as far as questions and answers. I know you have this idea that my friendship with Linsey gives me some sort of advantage, but I can tell you, there is only one game item I have ever discussed with her outside of this wiki, she gets enough QQing about stuff from everyone here, she doesn't need it from me, besides, I know she knows much more about what she's doing that I do. -- Wyn talk 23:24, 5 August 2009 (UTC)

I already stated my case and provided alternatives without partisan attacks. I'm not going to bother with these silly attacks against me and the insulting terms accompanying them ("QQ'ing"). If you value concise and organized systems as much as you claim to, then you'll do the same. --ilr 23:59, 5 August 2009 (UTC)

Given how big this page is, is there anyone opposed to archiving quickly the QQuest sections? Erasculio 03:01, 6 August 2009 (UTC)

I kinda find this whole discussion a little ironic, since we already discussed it, with ILR, a month ago, and with much less drama all around. Frankly, I doubt if ILR's concerns are in good faith. Let's move on. (Satanael 22:13, 6 August 2009 (UTC))

Not in good faith? #1: NPA. #2: No archiving an active discussion. You don't get to change the existing rules while making up your own rules. Granted, I obviously can't stop you from making up your new rules, but I can expect some kind of standards to be upheld here. --ilr 22:51, 6 August 2009 (UTC)

#1, that's not really a personal attack, as it's discussing your actions not you. #2, where did Satanael talk about archiving? --JonTheMon 03:06, 7 August 2009 (UTC)