Guild Wars Wiki talk:Suggestion pages restructuring/Archive3

New feedback pages

Starting discussion here as suggested by Pling. I'd like to suggest this time around that we sort everything into users. If each user has a section, they are responsible for it, less drama, no formatting requirements. We could just make it a requirement to register an account, which is not a big requirement. The page per suggestion format was an absolute nightmare to maintain, I personally don't really care what format ArenaNet prefers, because I don't think they will realistically use it that much anyway. Bug pages similar to what exists now should be recreated in the new namespace, but that seems like a separate issue. Misery 15:37, 29 April 2009 (UTC)

Yes, it would be a pain, but certain things would require more group input then others. Suggestions involving skills of the original game spring to mind, along with any group discussion involving things like the Henchman skill bars and such. And we still want to make it easier use the feedback even if we stick to a user page style structure. Subpages and category tags to allow user to differentiate their suggestions on one subject as opposed to another might work. The question for the community, what category tags should be made?--Ryan Galen 15:51, 29 April 2009 (UTC)

I think Misery's idea would result in just as much clutter as we had before :/ Perhaps it would be easier to have a couple of pages, like a page for Guild suggestions, Armor suggestions, Interface suggestions, World suggestions and so on. Then have a couple of strict guidelines like on the Help: pages, so we can easily remove the clutter? — Why 18:38, 29 April 2009 (UTC)

Definitely no. Clutter is a problem we won't be able to solve anytime soon; the best we can do is try to reduce the number of people who add suggestions here by requiring people to register before being able to add their ideas, as stablished with the "suggestions on the userspace" idea above. The main advantage of Misery's idea is by reducing the drama - User X is the responsible for the ideas within the Feedback: User X article, and no one else is allowed to edit that article, and the ideas in said article represent only what User X thinks/wants/ has delusions about.

Group pages are a very bad idea. That's what we had and they were complete waste of wiki space, with people adding ideas madly without bothering to read anything in the wiki at all, much less any rule or whatever. Erasculio 00:20, 30 April 2009 (UTC)

Hmm, I see. Very well, hadn't thought about it in that fashion before. — Why 00:43, 30 April 2009 (UTC)

With all the extra policing it will take anyway, I don't see how anything other that Misery's idea would be workable. Tho' I presume it would havve to be ArenaNet:User Misery, or ArenaNet:User/Misery as page names. A bit clumsy, but workable. Backsword 06:00, 30 April 2009 (UTC)

It won't require any more policing than user spaces and the naming would work exactly like the user space, i.e. Feedback:Misery. Group pages seem to require much much more policing than individual pages. You can't have a disagreement if only one person is allowed to edit a page. Misery 06:44, 30 April 2009 (UTC)

We still need pages for listings and such, as well as psedu templates and categories. As those could conflict with a username we need a distinction. The extra policing is for legal reasons, so that there is no crosscontamination. Backsword 06:46, 30 April 2009 (UTC)

I don't think we should use the same system for all feedback. For example, I believe the system used until recently to report bugs, text errors and art issues works fine. I also think that we should allow collaborative feedback. Perhaps individual feedback pages could be located at subpages of Feedback:Individual feedback/<username>, miscellaneous feedback could be located at subpages of Feedback:Collaborative feedback/<feedback topic or category>, with the rest of the namespace devoted to more specific feedback pages such as Feedback:Text issues, Feedback:Quest bugs. I think we should also have index / summary pages with quality standards, conflict of interest rules and, if necessary, editorial oversight. -- Gordon Ecker (talk) 07:11, 30 April 2009 (UTC)

(RI) I can't think of a single advantage in having collaborative feedback. If a couple users would like to combine their ideas on a single page, they're free to do so in one of their Feedback: Username pages, like Falconeye and that other user already do today. Pages open to anyone are nothing other than a waste of time and a big source of drama. The same applies to "editorial oversight", "conflict of interest rules" and all that nonsense. If there's a lesson to be learned with the failure of the old suggestions section here, it's that people don't want nor like oversight over their suggestions. Between that and how slow the wiki is to actually take suggestions, wasting time to implement an oversight committee or whatever would be counter productive.

What we have to do, I believe, is:

1. Change the css of the new Feedback space so it looks different from the rest of the wiki. A simple template at the top of those pages isn't enough. The entire page has to look completely different, with a different background color and etc. The alternative design for the wiki (the one with the black background and the font looking like the one used in Guild Wars) would be perfect for that, IMO. The idea here is to make it clear how it's something different from the rest of the wiki.
   
   
2. Limit suggestions and skill feedback (merging both conceps, asking for a skill nerf is a suggestion anyway) to Feedback:Username articles. Bugs would have articles in the Feedback space outside that system, but everything else would be within pages named from the users who created them. The responsibility for the maintenance of those articles would belong only to the users who created them, just like userpages are today, with the same few exceptions userpages have.
   
   
3. Make a master list of suggestions, just like the current Arena Net: Suggestions page was meant to be. That list would be part of a locked page (so it would be impossible to manually add entries) and it would be DPL based, requiring a specific template in order to display a page.
   
   
4. Said template would be manually added to each Feedback:Username article by said user. The template would not only allow the display of the article in the master suggestion list, but also allow the list to be sorteable based on different categories, such as if the suggestions on any given article are about PvP, character customization, etc. The template, is just copied from the example in the main Feedback page, would have all options in "no", so just copying it would not display a page in the list at all; a user would have to actually understand what the template does, change the proper options to "yes", and only then his article would appear in the master list.

Then we would have a working system, IMO. Erasculio 00:18, 1 May 2009 (UTC)

This seems reasonable as a general idea, but I have a few questions. Would users be allowed to have subpages? Would the index pages include brief summaries, or just the page titles? How would we deal with miscategorized suggestions? What about really bad or non-serious suggestions, like "bring back classic Signet of Ghostly Might" or "allow botting", what should we do if they start cluttering up the pages? What should we do when an index page hits DPL's 200 page limit, should it be split up alphabetically? -- Gordon Ecker (talk) 01:17, 1 May 2009 (UTC)

IMO,

1.Yes to subpages, but only the main page will be linked from the master list. All subpages would have to be literally subpages, not links to other spaces in the wiki.

2. The index page would not have summaries (I don't trust everyone to not write things like "Th3 b3st 1deas 3v3r ckick plz gogogogogog\!11111"). Rather, the index list would automatically say, based on the template it draws from in order to create the list, what each link is about. The template would have parameters like "PvP modes = yes/no", "character customization = yes/no" and etc; the result would be something like...

Pagename	Date of creation	Character customization	Economy	Pets	PvP modes	Skill system
Feedback: Erasculio	11.07.08
Feedback: Misery	09.12.09
Feedback: Gordon Ecker	13.06.09

(Prettier, of course) With each column being sorteable, so if Arena Net wanted to read suggestions about the skill system, it would be very easy to sort which suggestions they would read.

3. About miscategorized suggestions: IMO, it depends. If on good faith, remove the template and explain the user about it. If in bad faith, delete the article.

4. About really bad ideas: leave them be. If the sarcastic ideas outnumber the good ones, then we would have proved that the community isn`t worth listening to.

5. About what to do when we have more than 200 articles: split the list based on any of its categories. We could split it by subject, alphabetically, by date of creation, etc...

I think that would work. Erasculio 02:14, 1 May 2009 (UTC)

Your proposal seems fine for the main index pages, however I believe it would be useful to also allow more specific index pages which allow linking to subpages. For example, if a developer wants to buff, nerf or rework a specific skill, it would probably be useful to have a list of all suggestions related to that specific skill. I'd prefer DPL index pages to categories because DPL can filter out pages in the wrong namespace. -- Gordon Ecker (talk) 03:52, 1 May 2009 (UTC)

By the way, I think that, for legal reasons, we should keep suggestion page related templates and formatting guidelines in the feedback namespace. -- Gordon Ecker (talk) 05:54, 1 May 2009 (UTC)

That actually looks very similar to the idea I've been attempting to work on for the last couple weeks Erasculio, although due to my recent lack of time on the wiki; partly from having to go through up to and sometimes over 24 hours worth of watchlist edits which includes several hundred edits multiple days the last little while; it usually leaves me exhausted so to speak. One way to solve the 500 page limit of dpl would be to have one dpl check for each letter or set of letters (eg: A-E, etc) although this might cause some slowdown of the page loading, I haven't had a chance to check. If anyone wants to see my current progress on this list, once I get it up to a working state I could save it in my userspace ... at some point in time although I'm unsure of when that will be. I would like to know however what what categories people would like to have listed, either here or left on my talk page whichever is best. --Kakarot 14:45, 1 May 2009 (UTC)

This looks good to me Erasculio, but I have one suggestion: I think we should add to the creation template a required one-sentence description of the idea. I know this opens the door for people to do all those terrible "Th3 b3st 1deas 3v3r ckick plz gogogogogog\!11111" type things. However, I think this can be overcome with strict formatting policies and fearless enforcement. For example, we say clearly in the template that the description can not exceed a certain size, must use understandable English, must be descriptive of the idea, etc. and then be strict in our enforcement of it. If an idea description does not meet all of the policy guidelines, delete it.

The reason I think we should do this is because we should endeavor to increase the browseability of ideas. While being able to organize the ideas by category and having yes/no indicators like you show above are a great idea, and should definitely be used, having some plain English to say what the idea is would also be a needed addition. For one, one of the issues we had with previous suggestion attempts was with repeat suggestions (How many times did we see hairstylist, auction house, mounts, and other such requests?). If we leave the organization to just the yes/no indicators, there will be no easy way to skip over repeat ideas ("Mac compatible!"), or ideas that have no prayer of being put in the game ("sex minigame!"), or other ideas that just simply don't need to be commented upon or even read by the devs at all.

The only hitch is I don't know how this would be done technically, is it possible to transclude a portion of a page? Is there a way to automatically copy text and paste it somewhere else? Worst case scenario, can we get a bot to do it? (Satanael 18:27, 1 May 2009 (UTC))

P.S. Essentially what I was suggesting here is combining Erasculio's table above with this one that I created a while ago for discussion purposes. (Satanael 18:32, 1 May 2009 (UTC))

I'm not sure enforcement works. I would rather have something as automatized as possible, so we wouldn't need people to be constantly watching over the list and telling users "no, your summary is terrible"; that kind of thing creates large amounts of drama, as the old suggestions page here showed. The benefit of having a summary is IMO not worth that much trouble. Erasculio 13:55, 2 May 2009 (UTC)

Hi. Mostly just letting you know there are lurkers sitting around watching and waiting in baited anticipation concerning what you’re all going to decide. Also giving a peanut gallery reaction to what has been discussed so far.

I like the idea of categorizing suggestions, and my only concern is that the categories won’t be broad enough. We would want them broad to make it manageable on our side and to make sure there is a proper place for any type of suggestion. While we want them precise to make it easier on the on the ANet side to browse, if we make it too precise suggestions might start falling through the cracks because they have nowhere to go.

I’m also worried about the need for a description. If we were using subpages and categories it might be a solution to some of the drawbacks of broad categories. If we aren’t using subpages and using a large master table Erasculio presented an example of, then there just might not be space for it. Also, I’m hoping to be allowed to collect my own related ideas in the same space rather than giving them each their own page. If descriptions force that, then I’d be really worried.--Ryan Galen 14:58, 2 May 2009 (UTC)

Broad and narrow categories don't need to be mutually exclusive, I think we should have both in order to accommodate both browsing and precise searching. For example, a Shadow Form suggestion could be categorized in over a dozen categories including Shadow Form feedback, Shadow Arts skill feedback, assassin feedback, assassin PvE feedback, tanking feedback, PvE feedback, PvE profession balance feedback and assassin elite skill feedback and elite skill feedback. If the balancers want to change Shadow Form, they could find that suggestion in the Shadow Form feedback category, if they want some ideas for elite skill changes, they could find it in the elite skill feedback category, and if they want to change some tanking skills, they could find the suggestion in the tanking feedback category. -- Gordon Ecker (talk) 02:39, 3 May 2009 (UTC)

(Reset indent) I understand the concerns about enforcement if there is a brief description, and I want to avoid drama as much as anyone, but I think those concerns can be overcome. For one, we can devise guidelines that are purely format based, and thus reduce the amount of "opinion" the enforcer needs to make the delete decision. By providing clear, numbered guidelines and requiring deleters to cite the violated guidelines, this should help reduce the amount of drama. Also, instead of delete being the only recourse, we could provide a simple warning template that cites the reason for violation and provides the poster an opportunity to fix it within a certain amount of time to avoid deletion.

As I said, one of the primary reasons for this is to help the devs avoid repeat ideas, but it also helps to avoid repeat posts. If the only thing to differentiate ideas is their yes/no categories, then there is nothing to stop me from posting the same idea once a week until one of the devs says something. Whereas if there is a description with the post, then we would know right away if someone does that, and could take appropriate action. Without the description, then the enforcers will have to go in and read every suggestion to make sure people don't do that.

I agree with the hope of making it as automated as possible, but it also has to achieve what is necessary to make it work. Also, even if everything is completely automated, we are still going to need people to police these pages. No matter what we do, people will find a way to screw it up, so we have to be prepared for that and have people available to fix it. I actually think the description makes enforcement easier in many respects. (Satanael 05:15, 3 May 2009 (UTC))

I don't think we are going to allow someone to have more than one entry on the list. So I don't think it would be possible for someone to post the same idea under the same username multiple times; the list is going to link only to that person's master suggestions page, no matter how many ideas and how many subpages that user has. This would help with the cluttering (as we would have at most as many entries as we have users) and to keep things organized.

Unfortunately I don't think that would prevent different people from posting the same suggestion over and over. The old suggestions pages here were plagued with repetitive content despite how easy it was to find out which ideas had already been submited.

As far as categories go, I think we could use more or less the same ones we have here, only streamlining them a bit (Armor, Art and Character are a bit redundant, etc). Erasculio 12:53, 3 May 2009 (UTC)

Forgive me, but if we limit people to one entry per user, this will nearly ruin browseability. Eventually, if someone has enough ideas, you'll end up with numerous entries that say "yes" to every yes/no query in your template, thus negating their purpose. Furthermore, if all of someone's ideas are on one page, you will be asking the devs to monitor that page in case someone has a new idea they want to share, or you would be asking people to put down all of their ideas the first time they make an entry. In the case of the former, I don't think the devs are interested in flooding their watchlist with a page for every user. And the latter is just not feasible.

I agree that a description would not prevent more than one user from posting the same or similar idea, but what it would do is allow the devs to simply skip over the ideas they don't want to bother with and only read the ones they are interested in, and not require them to go to every page and read every suggestion. (Satanael 15:16, 3 May 2009 (UTC))

Subpages. Instead of having Joe cluttering the list with one entry for "Add a mini me minipet!" and one for "Add a mini Gaile mini pet!" and one for "Add a mini my internet girlfriend minipet!", the list would link to Joe's page, which would have one subpage for each of his three ideas, and would appear on the list with a "yes" to the Minipets (or whatever) category.

This would not only prevent cluttering on the main list, but also allow the developers to filter what they read or not based on what is said on each user's main page. A developer who's not interested in "mini person X" minipets would only have to look at Joe's main page, see that the three linked subpages are about that subject, and then go somewhere else without having to bother reading the ideas themselves. At the same time, we leave the task of making suitable links from main page to subpage as a responsibility of the users, given how they are the only ones responsible for their own master pages, without polluting the main suggestions list with that kind of thing. Erasculio 15:26, 3 May 2009 (UTC)

Ok, I can see how that would help a lot, but ultimately the devs still have to monitor each user's main suggestion page. For example, if Joe makes an idea "I want a Gaile minipet!" and another idea "I want minipets to be able to fight with me!", these ideas would have the same yes/no queries, so his entry on the list would stay the same, while he is still providing fundamentally different ideas about the same topic. So a dev, who is interested in minipet ideas, would have to know he added a new idea even though his entry in the list has not changed, thus they would have to put his main suggestion page on their watchlist. And with hundreds of Toms, Dicks, and Harrys out there, the devs have a ginormous watchlist.

With an entry fo each idea, it's true, maybe ideas come in at a dime a dozen, but devs can more easily pick the ideas they are interested in and only read those. As for maintenance, is it possible/easy to archive a portion of a list? If so, then I say there is nothing to say that big lists chalk full of ideas is necessarily a recipe for disaster, so long as we are diligent with archiving. Even when suggestions were on Gaile's talk page we did not get more than 5-10 ideas in a day, the issue there was as much with the wall of discussion on each idea, and the responsibility for archiving resting solely with Gaile.

Also, there does not have to be one master list of ideas, there can also be several sub-lists, i.e., the yes/no queries decide which list the entry gets put into, and devs interested in armor can go to the armor list, etc. This could help solve space issues for the table and allow us greater freedom for more specific yes/no queries. Even on the master list, would it be possible to make certain columns collapsible? (Satanael 16:30, 3 May 2009 (UTC))

There is no reason not to use a summary parameter, and pass that to a list. "Bad" summaries are good summaries: they tell you exactly what you want to know about the readability of the idea.

I'm surprised that Erasculio after all the arguments he's made againt an oversight commity wants to set one up for categories.One would expect all the same problems there.

Also, minor note: "Without the description, then the enforcers will have to go in and read every suggestion to make sure people don't do that." Given how they will have to do that anyway, it's a complete nonissue. Backsword 13:46, 4 May 2009 (UTC)

I'm not worried about people adding the wrong categories to their ideas. That's something I wouldn't even bother to correct; for those more obvious cases ("yes" to everything for a suggestion about minipets) in the middle of a very big table, I wouldn't be surprised if the owner of the suggestions didn't even notice a change to his categories.

Enforcement does not work. This is something with way too many contributions to expect the community to reliably monitor what's happening, and which causes way too much drama when users complain about the "you are doing something wrong" notices that those enforcing the rules need to use. A system that relies on that kind of thing is going to fail sooner or later, just like the old suggestions page here did.

I believe it's much better to use a system in which each user has very little input and in which everything is automatized. Preventing people from even writing something in the master list of suggestions is the minimum input reasonable, at the same time it keeps the list sortable. In order to prevent the developers from having to add pages to their watchlists, it's just a matter of adding the date of the last change on each article as one of the parameters for the main list. Erasculio 23:58, 4 May 2009 (UTC)

Note: the DPL limit is 500, not 200. Limit it to one index page per user and there is no practical problem. Backsword 13:37, 4 May 2009 (UTC)

I think you overestimate the difficulty in enforcement under this structure, the problems we had with previous suggestion structures were not exactly because of enforcement, per se, as there was nothing really there to enforce. We were not clear at all about how things should be done, because we didn't really know ourselves, even those who were maintaining the space didn't really know what a suggestion should really look like and what suggestions were not acceptable. This is what really created the drama, because people thought it was their idea and the maintenance people treated it as a collaborative community idea, so people would go in and change or re-write ideas to "comply" with rules that were never really clearly stated in the first place. By the time we did get some rules in place, it was well after people had started posting suggestions, and were all in response to issues that had come up and decisions made after the fact. As far as enforcement in previous structures, it is not comparable because there just wasn't any in the previous structures.

The other problem we had with the last structure was that it was just too easy to create a new suggestion. When we first started the anet portal suggestions, we had a special button to create a new suggestion, so suggesting was as easy as posting a comment in a forum. That's not true in this case. I do think we will see far fewer one-sentence suggestions under this new structure, and we may even see fewer suggestions altogether, simply because it is not as easy to create a new suggestion.

In this new structure, in order for enforcement to work, it can not be about enforcing anything on the idea itself, as that will cause drama, but rather deal solely with format of entries in the list. So long as they comply with the format, then they are free to suggest anything, and present it on their suggestion page however they like. I don't see how there can be a lot of drama if a sysop or someone simply says, "please re-write your one-sentence description because I can not understand it."

As for your suggestion of having the date-of-last change automatically update on the list, I don't think that will solve the issue because then you would be asking the devs to remember the last time they looked at each entry and whether or not the date has change since then. With hundreds of entries, that's not feasible. Even if the change to the date shows up on their watchlist, the watchlist only shows the last change that occurred. In order for them to know which entries have changed they would have to go dig into the history of the list everytime they look at it. Given that many of the devs here don't even know how to archive their own talk page, that could be asking a lot (no offense to any of the devs, I'm just recognizing who we are dealing with).

I'm okay with automation, even a lot of automation, but over-automation renders the whole thing pointless because it simply doesn't provide the information necessary for it to be useful. At this point, I don't see how a list without an entry for each idea and with a one-sentance summary for each entry can be that usefull to a dev trying to decide which ideas to read and which ones are garbage. (Satanael 16:03, 5 May 2009 (UTC))

Ok, I agree with Satanael that having rules will work as long as we have the rules ironed out before we open the floodgates and start letting people post the suggestions in the Feedback namespace. What those rules should be... I’m not even sure if we’ve started talking about “rules” yet. I think we’re still on "formatting". Given the user page like format, though, there is certainly no reason to go out of our way to prevent duplicate ideas. Multiple people coming up with the same idea is probably just going to be one of the ways ANet can judge the popularity of some of the more fringe ideas in the community.

As for dates... this may or may not help. ANet may not be keeping track of what is done on every single page, but they will be keeping track of when they last checked the pages in general. Problem is... if we’re linking to the main pages only, but the person uses subpages, then date system might be pointless if the person is only makes changes to his subpages without changing main page. Not to mention if you change an idea about one subject without changing the rest of them. There are ways to alleviate this in the ways we handle the individual handles their main page, but it won’t go away completely.

Now, to move forward rather than just only talking in circles, I’d like to propose some broad general categories. As Gordan responded to my last comment on categories, it will be fine to have more narrow categories under this, but it is still my belief that we need to start with something as broad as possible.

User Interface

Game Mechanics

Media Quality

Story Content

We also need to differentiate between Guild Wars suggestions and Guild Wars 2 suggestions, particularly since some of the narrow categories will be needed in one but not in the other. Individual Skill suggestions would probably be a prime example of something needed with the GW suggestions but far too early to add to the GW2 suggestions.--Ryan Galen 17:37, 5 May 2009 (UTC)

Yeah, I agree, there's no need to delete repeat suggestions per se, I was just saying that it would be good to easily identify them so the devs need not read them. And yes, I was assuming that GW1 and GW2 suggestions would be held in different places. (Satanael 17:54, 5 May 2009 (UTC))

I think you're way overestimating people. No matter what kind of rules you make, the moment someone breaks one of those rules (as someone will do) and is told so, there is a large potential for drama. See the suggestion pages here, see the reactions to the rule against removing content from an user's talkpage, see the complains when action was taken against NPAs, and etc. Enforcement only works so far before someone who believes himself above the rules decides to vandalize just to avenge his ego.

I also think you're underestimating Arena Net. If you assume the developers don't know when they last looked at a page, it's likely they wouldn't remember what they saw, so they would have forgotten whatever idea was seen when they forgot when did they see each idea. That's the same as saying that a suggestions list would be pointless because Arena Net would just forget all suggestions one day after reading them.

It would be rather easy to change an user's main page when changing a subpage, if only to tell people reading the main page how something new has been added. That kind of thing is only what is expected - we need those who create and post their suggestions to do the maintenance of their own suggestions. If someone chooses to not do so, I don't think we need to change the entire formatting of the master list just to accommodate such choice. Requiring the community to do a lot of work (enforcing this entire system) and expecting everyone else to do nothing (people to not take care of their own suggestions and developers to not remember what they are reading) is never going to work.

Lastly, I don't think such broad categories would work. They would leave room for too many different things within each category, to the point that browsing based on categories would be almost pointless. IMO, we need to use at least the categories we saw in the old GW1 and GW2 suggestions lists here, with some adaptations. Erasculio 01:27, 6 May 2009 (UTC)

Even if it's too large to be useful for direct browsing, a broad category could be useful for cross-referencing using DPL. For example, if one of the balancers decided that dervishes should be able to specialize as dedicated healers, he or she could use DPL to create a list of all suggestions categorized as both healer suggestions and dervish suggestions. -- Gordon Ecker (talk) 08:49, 6 May 2009 (UTC)

Erasculio, I don't think we're overestimating people at this point since we aren't even talking about what the rules will be but if we'll even have them. The rules that might be implemented given what we're talking about is probably going to be very simple: how the main reference pages are going to be treated by the community, and where you can put the category tags on your suggestion pages are allowed to be. Such basic rules are going to have to be made to even make this work at all.

Yes, some people are going to violate the rules, but some people are going to cut you off in traffic. Doesn't mean we should get rid of traffic laws. ...ok, bad analogy, but it's the best my brain can come up with right now. The real point is that this is the internet: drama comes with the territory. Some people might consider the civil discussion we're having right now drama; honestly, ask me a month ago and I'd be one of them. I always told myself I wouldn't touch policy discussion with a ten foot pole, but I really want the Feedback namespace to workout.

As for Categories, yes, those broad categories aren't going to be helpful for browsing; they aren't intended to be. Broad categories are to make sure suggestions that fall between the cracks of the narrow categories still have someplace to go. You want to avoid drama? Well we don't want people complaining that their suggestions didn't fit in the narrow category options. Start with the general, work our way down to the specifics.--Ryan Galen 17:33, 6 May 2009 (UTC)

(Reset indent) The rules that I am talking about enforcing are not content based, they are purely format based. In that respect, enforcement of rules on the summaries would be no different than enforcement of the categories. Saying "your suggestions has nothing to do with armor" actually has greater potential for drama than saying "please re-write your summary because I can't understand it."

On the other hand I also agree with Ryan, it would be a tremendous suprise to me if we can make any feedback structure that completely avoids drama.

Though ultimately, arguing about what will cause drama and what won't is pointless, we just don't know what inane minutiae will piss people off and what won't. But if we put in an option for summaries, with rules from the start, and it doesn't work, we can always remove it later. Whereas if we start without it and try to add it latter with a bunch of rules people know nothing about, then we will be making the same mistake we made with the last suggestions. Taking rules away is easy, adding them later is a mistake. Maybe I am right about idea summaries, maybe you are, let's give it a try and see, if you are proven right then I will be the first to demand its removal. ~ (Satanael 17:52, 6 May 2009 (UTC))

Eras isn't saying we should enforce the cats, apparently. SO no drama, but then, they'll be effectivly random, so not much use either. And again, making summaries a communal project with all it's subjective nature will cause plenty of drama. The only thing that should be enforced on a summary is strict tenchnical limits. There will still be some slight drama over that, but at a level where the benefit outwights the cost. Backsword 12:51, 9 May 2009 (UTC)

I don't think we should go out of our way in order to avoid pissing off the kind of people who would throw temper tantrums whenever someone tries to correctly categorize their suggestions or clean up poorly written summaries. That type of person is also likely to take other things, such as reversion of edits to main namespace articles or disagreements on talk pages, personally. I don't think we should try to stir up drama, but I don't think we should let hypothetical uncooperative, irritable editors hold us hostage either. Drama will happen regardless of what we do, and I feel that slighly more drama is an acceptable price to pay for better suggestion organization. -- Gordon Ecker (talk) 05:23, 10 May 2009 (UTC)

While I respect standing up for principle, in the end it is not what the wiki resources are provided for. We have to look for what is best for the projects, so for me, it comes down to a simple cost benfit calculation. Backsword 19:30, 14 May 2009 (UTC)

To Summarize

Okay, so, to summarize:

1. We are looking at several lists, a main one that links to main suggestion pages for each user, and several categorical lists that link to each subpage (i.e., idea specific) each of the subpage lists looking something like this:

Pagename	Date of last edit	Character customization	Economy	Pets	PvP modes	Skill system	Summary
Feedback: Erasculio/IdeaA	11.07.08						We should have raids on other guild halls.
Feedback: Misery/IdeaB	09.12.09						Ritualist and necromancer roles should be merged.
Feedback: Gordon Ecker/IdeaC	13.06.09						We should be able to buy consumables that give us temporary extra skills.

2. Each Subpage list will be organized into different categories, similar to the categories used in the last suggestion organization though likely paired down some and reworked a little. Perhaps this will effect what yes/no cats are showed in each subpage list?

3. We will have specific rules for the summaries, though these rules will govern only the format of the summary, not the content. My initial thoughts on the rules are something like:

1. Summaries must use plain English (no 1337-speak)
2. Summaries must be clearly understandable and discriptive of the idea (No "advertising" summaries like "Best idea ever!" or non-descriptive summaries like "GW2 should not copy WoW")
3. Summaries may not be more than 75 characters in length.

I think the above can work, as far as an end product with the lists is concerned. Unless there are any more major diagreements about how these lists should look and what they should do, I think we can move on to other issues. For example, the creation of a suggestion. We should have some sort of step-by-step instruction for new users on how to create their main suggestion page, and create a specific idea subpage, within the namespace. We should not make this process too easy, that's the mistake we made last time, but we should at least tell people how to do it so the process is possible for new or inexperienced users. (Satanael 18:16, 11 May 2009 (UTC))

IMO...

1. Using multiple lists is not going to work. That's going to increase maintenance for the community without giving those who actually make the suggestions (and thus should be the ones doing most of the work) the responsability of making their subpages to work. A single list, linking only to each user's feedback page (which would then link to all subpages, each with a different idea) would be far better, and also less confusing for Arena Net.
2. Those categories are not good enough. They are way too broad, almost useless for a developer who is looking about feedback for a specific subject, as opposed to looking what some players think about a few vague topics. We need a considerable larger list of categories, with (maybe) those in the current example as categories in which we would need subcategories, but in a single list.
3. Summaries are not going to work. As already discussed above.
4. Making a step by step instruction letting people know how to create suggestions would not be a good thing.

Again, those who should do most of the work here are those making the suggestions. They are the ones who want to be heard, so they should be the ones tasked with most of the maintenance work, with figuring out how the wiki code works, with finding the best way possible to present their ideas so it's as easy as possible for Arena Net to see and understand them, and with making sure everything they do is within the rules we have here. I don't believe any system in which most of those tasks belongs to the community, and not to those making suggestions, is going to work. Erasculio 01:27, 12 May 2009 (UTC)

In response to point 2, if the lists are automatically generated using DPL, they would require only marginally more maintenance than categories. -- Gordon Ecker (talk) 10:10, 12 May 2009 (UTC)

In response to Erasculio:

1. I’m pretty sure you’re talking about is the policing of the tables by the community to ensure that only properly categorized items are on each table, and the drama any policing will cause. Honestly it is up to the community to decide. We’ll have to have some policing with this idea, but the point is to decide as a community strategically where to have it so as to at least avoid maximizing stress on the community and to minimize it as much as reasonable.
2. Agreed, assuming you mean [ArenaNet:Guild_Wars_2_suggestions/Sidebox|these] categories? They fail at being either broad or narrow, with some ideas falling through the cracks and in some cases more than a little pointless. (World?) I’ll collect myself on the issue and start new section to discuss which categories should be used later in the day.
3. Agreed. Giving the breadth of categories we’re going to have, I don’t see there being any room (width wise) for them on the main page list, and policing the magnitude of subpage lists is one place I’ll agree with you and say that is too much to ask for the community to do.
4. ...honestly, I agree with you only up to a point. Spoon feeding people formats is a bad idea. Giving them expectations that will have to be fulfilled is a very good idea. Problem is... new people either start out as timid little mice in the corner or elephants in the china shop, and we're going to be getting a lot of new people when the Feedback section goes live. As a timid little mouse who is only starting to venture out of his corner, I think there isn’t enough effort put into telling people how to do what we expect them to do. It took me half a day to figure out how to delete a page; after searching for the answer I got the wrong answer, was told another wrong answer, and was finally referred to the deletion policy and deletion template. I don’t have any suggestions on what to do, but if we want to avoid drama, we should put some effort into doing something to make the rules easier to find.

--Ryan Galen 18:35, 12 May 2009 (UTC)

Just one point, there are 16 of those categories that were used before, and if you guys want to make categories that are even more specific than those (which is fine by me) then there is going to be a space issue whether we do summaries or not. Fact is, sub lists is not an option, given how many categories we are going to have, we will have to have sublists. The sublists will be broken up into broader categories with the more specific categories being columns in each sublist. For example, we have a "PvP" sublist which will have categories named "GvG", "World PvP", etc. The template for suggestion creation remains the same, with all the more specific categories listed, and a suggestion can then be listed on more than one sublist (automatically).

Therefore, since we have to use sublists, then there will be room for summaries as well. Each sublist should not have more than 5-8 corresponding categories, which leaves plenty of room for a short summary (the above example has 5 categories and there is plenty of room for 2-3 more). Policing these summaries will not be any more or less difficult if we use sublists, because they will all be listed on the master list anyway, so policing need only be done there.

As for the actual categories to be used, I have no strong opinion, though we should probably figure them out soon so we know how many we are dealing with. Also, I agree with Ryan on point 4, we should not make it too easy for people to create ideas, but there should be a balance. If we don't tell people anything, then they will just attempt to edit the lists directly, rather than fill out a template they don't know exists. (Satanael 19:38, 13 May 2009 (UTC))

I think we should add categories as needed. For example, if there are dozens of suggestions involving a specific skill such as Ursan Blessing or Shadow Form, I think that skill should probably have its' own category, however if there are only a dozen suggestions relating to a specific attribute or profession, one category for that attribute or profession would probably be sufficient. I don't think it would be harmful to have small categories, and could be beneficial in the long run when those small categories become larger. For example, if I was going to make the first suggestion on the new suggestion pages, and that suggestion was to nerf Fireball in PvP, I might categorize it under "nerf suggestions", "PvP balance suggestions", "skill suggestions", "Fire Magic suggestions", "Elementalist suggestions", "non-elite skill suggestions", "Guild Wars suggestions" (as opposed to Guild Wars 2 suggestions) and "Fireball suggestions". Early on, it might make sense to create a temporary list for all skill sugestions because there are only a few of them. As more suggestions are added, narrower lists could be made for things such as "PvP balance suggestions", "elementalist sugestions", "elementalist PvP nerf suggestions" or "fire magic PvP nerf suggestions" using DPL, and the main "skill suggestions" page could change from an index of all skill suggestions to an index of skill sugestion lists. In the unlikely event that Fireball becomes the keystone skill of some gimmick build like Shadow Form or Ether Renewal and gets dozens of suggestions relating to it, it might make sense to create a "Fireball" suggestions list, which, if necessary, could be further split into PvE buff, PvE nerf, PvE reword, PvP buff, PvP nerf and PvP rework lists. If Fireball only gets one or two suggestions, the category wouldn't be that useful, however a balancer who wants some ideas for changing Fireball could still use it to get a list of all suggestions related to Fireball, and people thinking of making Fireball suggestion could check it to see if other people have already made the same suggestion. I think the most likely category problem would be redundant categories, which I believe could be dealt with through category naming conventions and the merging of duplicate categories (such as "PvP suggestions" and "suggestions for PvP"), which could be handled by a bot. -- Gordon Ecker (talk) 04:26, 14 May 2009 (UTC)

@Satanael; It's actually my hope that we won't be expanding the list too much. It's just that that list... really doesn't work. The section I said I would have up yesterday has been started, and as you can see it only has one more category then old faithful. If we talk debate with the intent of keeping the list as small as possible while still meeting our needs, we can hopefully keep things manageable.

@Gordon; ...I can see what you're envisioning, and it would be the ultimate in category browsing for the developers, but you might be taking it a few steps too far. We need more than old faithful gave us, but I'm still hoping we can have a "less is more" philosophy. The worst I imagined happening for GW1 were tables for every single skill in the game. What you've just presented goes far beyond that "worst" case scenario. My mind has been focused on the GW2 categories, so I don't have any counter suggestions for you, but I imagine what I feel like you're suggesting and I feel like I'm drowning.--Ryan Galen 16:59, 14 May 2009 (UTC)

That wouldn't really be prqactical with just one namespace. If we had gone with the seperate wiki solution, and thus had various wiki functionality available, I'd suggest going further to full keyword system, but with just a list in a namespace, with inducidual pages, it wouldn't be practical. Backsword 19:11, 14 May 2009 (UTC)

Sorry, just to hammer this home in the interest of clarity, regardless of the above or below, we all seem to agree that there are going to be too many categories to fit into one list, right? And therefore we will need more than one list in some shape or form? (Satanael 04:39, 16 May 2009 (UTC))

Categories, GW2

Sorry for the delay. Thinking clearly on something is unfortunately not something I can do on demands these days. In quick summary, the suggestions are going to need to be categorized for browsing. Some have been very happy suggesting taking the lazy route of old faithful recycling, while others including myself look at that and see huge room for improvement. I started out on the suggestion of broad categories, but was easily argued into the position that we can have the best of both worlds.

As a small note, this section will only be dealing with the GW2 suggestions. GW1 is a completely different can of beans which will requires less in some areas, more in others, and some that GW2 can’t even have at the moment.

Now, I’ve already suggested the broad categories to be used. I’m confident that they are broad enough, and certainly haven’t got any arguments to the point that they too narrow... though not much discussion have been had on them so that is mostly pointless. Still, my suggestion on the broad categories still stands unaltered.

User Interface

Game Mechanics

Media Quality

Story Content

Now, to come up with my first suggestions for narrow categories, I looked at old faithful and trimmed the redundancy, merged some ideas, split others, and played with the naming until I got what was at least a good starting point. That list is as follows.

Professions

Races

Companions

Guilds

Economy

Inventory

Equipment

Inventory Management

Quests and Missions

Mobs

PvP

Character Appearance

Environment

It covers most of the common areas, and for the less then common areas we have the broad categories. These are only suggestions so nothing is set in stone, but I would encourage anyone who wants to argue the point to be specific on what they want to add or subtract.--Ryan Galen 16:39, 14 May 2009 (UTC

"In quick summary, the suggestions are going to need to be categorized for browsing." I disagree strongly. If categorisation is left to happen on it's own, it becomes effectivly random and thus uselss, only causing extra work. If it is to be impossed from on high, it becomes a nightmare in effort and drama. Backsword 19:13, 14 May 2009 (UTC)

IMO, we need main categories with subcategories in each of them. So I would suggest:

• World

• Lore ("I want the gods to have been killed by the dragons!!!!")
• Places ("I want to play in the Jade Forest!!!!")
• NPCs ("I want Gwen to be still around!!!!")
• Story ("I want us to free Ascalon and save it from the Charr!!!!")

• Character customization

• Races ("I want to be a mudkip!!!!")
• Professions ("I want my Charr to have a mudkip profession!!!")
• Armor ("I want mudkip armor for my Sylvari!!!!")
• Body & face ("I want my character's face to be just like a mudkip!!!")

• Items

• Weapons ("I want to have a big hammer!!!!")
• Consumables ("I want a 'Big Hammer' consumable!!!")
• Inventory ("I want a lot of room for big hammers!!!!")

• PvE

• Companions ("I want Undead Gwen as my companion!!!")
• Enemies ("I want Undead Gwen as my enemy!!!")
• AI ("I want my enemies to think like they're Gwen!!!")
• Missions ("I want a mission to find Gwen's body!!!")
• Quests ("I want a quest to play with Undead Gwen!!!")

• PvP (only a single large category)
• Skill system (only a single large category)
• Player Interaction

• Chat system ("I want to be able to scream!!!")
• Emote system ("I want to be able to /scream!!!")
• Trade system ("I want to be able to scream WTS!!!")
• Guild system ("I want to make a guild called [SCREAM]!!!!")

Other (only a single large category)

And IMO that's enough. Erasculio 00:05, 15 May 2009 (UTC)

Hmm, maybe I'm just too visual a person, but what would this look like, in your mind, Erasculio? I mean, how would you organize all those categories? Would you have a master list that shows all the main categories with separate siblists for the subcategories, or would you somehow fit all of the above on one main list? If the latter, how? (Satanael 19:00, 22 May 2009 (UTC))

Policing suggestion pages

How much policing should the community be doing on individual suggestion pages? I think it should limited to removing content which violates policies (such as personal attacks and copyright violations), fixing problems which spill over beyond an individual editor's section of the feedback namespace (for example, if a page is miscategorized, it doesn't just affect the page itself, it also affects the category, while formatting problems on a suggestion could potentially break the formatting of a DPL sugestion table) and the enforcement of any applicable guidelines. -- Gordon Ecker (talk) 08:55, 22 May 2009 (UTC)

I believe the goal of separating them into user based suggestion pages was so that they would require the same level of policing as the user space. I.E. very little. Misery 09:56, 22 May 2009 (UTC)

^ Yeah, I got the same impression too. --Antioch 14:54, 22 May 2009 (UTC)

I think that we should do very little, if any policing of the actual suggestions, similar to what we do with the user space. The policing I am envisioning is concerned solely with how a suggestion looks on/effects the dpl lists, i.e., is it categorized correctly, does the summary meet format guidelines, etc.

I understand that in order to "fix" a suggestion, we will have to make changes to the actual page that the suggestion is on, but our fixes should be limited to the dpl list template, and not touch the actual suggestion. Even with summaries that don't fit format guidelines, I think we should simply inform the user of the violation, give them time to fix it themselves, and if they don't, remove the suggestion from the dpl lists. This will not only vastly reduce the amount of policing necessary, but should also help keep the drama to a minimum. (Satanael 18:48, 22 May 2009 (UTC))

I think should avoid that sort of subjective edits. Lots of drama with no benefits. (Yes, Satanael or whomever would be happier, but the user whos page it is wouldn't, so it cancels out). We should restrict edits to the level we currently do in user space:policy enforcement (this includes the key copyright issue) and maintenance edits. We should peobably arrange a schedule before going live as it might not be that easy on the fly.

I think Gordon asked about the namespace after licensing change, so that's what answering on. Backsword 19:00, 22 May 2009 (UTC)

Okay, maybe no policing of category choice, I can see that, there really isn't that much harm if a suggestion is not listed in the right category, especially if we have a summary. Although, policing of the summaries would not be any more or less subjective than policing policies. In fact, I am saying that we should make them almost exactly alike. We create a format policy for the summaries that must be adhered to, and if it is not, then there are consequences just like other policy violations. So long as the format rules are simple and clear, like our current policies, then the drama should not be a real concern, because it will not be any more drama than we already have with policies.

What I was really trying to get at above is that the actual body of the suggestions should not be edited any more than the user space, i.e., almost not at all. (Satanael 19:10, 22 May 2009 (UTC))

Or, don't have a summary and don't worry about policing at all. I agree with those above, the idea is to have as little policing as possible. I wouldn't bother editing anything other than vandalism, NPA attacks and etc. Erasculio 23:34, 22 May 2009 (UTC)

Or, have summaries and make the lists useful. I'm glad we agree otherwise though. (Satanael 18:09, 24 May 2009 (UTC))

Yeah, I was thinking of a level of policing comparable to that on user pages (removing personal attacks, tagging and removing copyright violations, removing pages from categories they don't belong in etc.). I think we're going to need to do some policing of categories. Otherwise people could put their skill proposals in categories meant for actual in-game skills. I also think we should fix clearly inaccurate categorization. -- Gordon Ecker (talk) 05:32, 25 May 2009 (UTC)

Obviously, any categorisation you make, Gordon, will be clearly inaccurate in my eyes.

But if they use real cats, then we would have dealt with that under the copyright policy anyway. Backsword 10:56, 25 May 2009 (UTC)

Eras, you'd agree that info on the hature of the suggestion would be helpful for people who decide wheter to read the suggestion or not? But that there is also a cost in the time, effort and drama policing entails? SO it is simply a matter of making sure the former outwighs the latter. Which we can do be sticking to techinical rules, and avoiding the subjective. Backsword 10:56, 25 May 2009 (UTC)

See I actually have no interest in making the suggestions more accessible for Arenanet staff, certainly not in discussing policy to make that easier for them. If they want things to be more accessible they should be here discussing how they would like things summarised or organised. I have already mentioned this on Mike's talk, but apparently no member of staff has taken up the invitation. I almost feel like any categorisation or organisation we attempt to implement without input from Arenanet, the end users, is going to be largely a waste of time. We can make it so it spews out any kind of DPL lists we want, but if they don't use it we just wasted our time. Misery 11:31, 25 May 2009 (UTC)

I think ANet has made it pretty clear that they want the option of using player suggestions, and that they are going to at least read the suggestions. We can be as pessimistic as we like about them looking at one idea and thinking it's such a great idea they have to use it; but I was thinking that one of the greatest uses of this type of thing (at least for ANet) is to allow them to see how often ideas are repeated. I have to believe that one of the reasons they heeded the cry for a hairtstylist, pet stable and other things was because there were tons of suggestions asking for it. Similarly, I'll be surprised if GW2 doesn't have something like an auction house or some way to deal with the trade issue, and part of the reason for that is because our suggestion pages get flooded with requests for them.

My point is, we as a community may hate repeat ideas, but seeing how often an idea is requested can be helpful for ANet, so they can see where they are failing to provide what players expect. And that's why making this easy for ANet to use is important, because it can have an effect on the game. It is useful for them to be able to walk into a meeting and say "we are getting 5 suggestions a week asking for auction houses", that's a pretty compelling reason to start investing in the time to figure out how to make player trading easier to use. But if we make DPL lists that are tough to read or don't provide enough information, then they won't be able to figure out statistics like that and thus will have a tougher time understanding what the community wants/expects.

Furthermore, what is the point of making a dpl list in the first place if it is not useful to ANet? I mean, if not for the dev's sake, why would we bother putting the list together at all? Suggestions have little value for the community itself, so we are not directly serving the community by putting the list together, we are first serving the devs, but that in turn serves the community. The better tools the devs have for hearing the community, the better the devs can serve the community. Kind of a "help me help you" type thing I guess. (Satanael 17:49, 26 May 2009 (UTC))

That is exactly my point. They should be telling us what would be useful instead of us retardedly arguing in circles about what we think would be useful for them. Misery 17:55, 26 May 2009 (UTC)

*shrug*, you're probably right, it would be helpful for them to jump in and resolve some issues about what would be useful for them, but I'm not going to hold my breath. They've always taken a pretty arms-length approach to how the wiki is organized, preferring to let the community figure it out. I don't have a problem with it, but it's true a little more guidance on stuff like this could save us all a lot of trouble. (Satanael 18:12, 26 May 2009 (UTC))

Some general thoughts

Hiya guys! Sorry I haven't been active on this page. I've been keeping an eye on the discussions here, but haven't commented up until now because I have been extremely busy. Since the licensing language is getting very close to complete, I wanted to jump in and try to give some thoughts based on topics posed.

1.) Organization of the feedback namespace

There seems to be a lot of back and forth about how organized the namespace needs to be, how exactly it's cordoned off, and how/if data should be pulled from individual suggestion pages into a more central location. I've read your discussions, and here are some thoughts:

• In general, we don't want to dictate to you guys how this space should be organized. This isn't because we don't care/are lazy/want you to do all the work/<insert other reason>. This is simply because we know that you guys are ultimately the ones that are going to be actively working in the space. There are going to be a LOT of suggestions that will probably span across everything in the game (plus more). Because of the sheer volume of content that's going to be here, we don't want to get into a situation where you guys are basing the organization of this space on our feedback or suggestions.

You guys know the site a lot better than we do because you built it and you work on it every single day. By now (from experience with working on the current suggestions pages), many of you have a pretty clear idea of things that work, things that don't work, and things that kind of work but need to be improved. Out of everyone here in the studio, I follow the wiki and the discussions about organization and policy closer than anyone, and even I can't pretend to know all of the stuff you guys have tried and discussed. With that being said, I can help by letting you guys know information like what formats will be most likely to be used by the team, and I can give reactive feedback on things you build and let you know if something isn't working out too well. Beyond that, the general rule is that this site is your wiki, so you guys should feel empowered to organize it however you'd like. It's probably going to take time to get it to a point where it's going smoothly, but that's expected since this is new territory. We'll help where we can, but we don't want to tell you how to do things.

Again, to be extremely clear: this is NOT because we don't care or have no plans to use the space and the suggestions housed in it. I'm bummed out that this sentiment has even come up, especially since it's obvious that we've put quite a bit of time and energy into legally researching, reviewing, and revamping all of the submission language on the site in order to be ABLE to take suggestions. The amount of effort put into this project is actually pretty staggering, and it came about because we DO want to read suggestions, and want to make sure we're doing it in a legal way that's safe and fair for everyone. So understand that even though we may not be commenting and actively participating in the organizational debates, we're aware of them and the end result IS important to us.

2.) Formats that will be simplest for devs

Here are some thoughts on ways that may make the suggestion pages simpler for the broader dev team to check out and browse:

• The simpler it is to quickly scan a page and see suggestions, the more likely it is that they will be read. You guys all know how busy the dev team is, and you know that using the wiki is generally something that people do on their free time (off hours/lunch/between tasks). Additionally, there's a varying degree of wiki-savviness around the studio. Some people (like me) use wikis a LOT, so we're able to browse articles and find what we're interested in quickly and easily. Others are less aware, and have a more difficult time finding information that they need. On the other end of that spectrum, there are others that aren't really familiar with wikis at all, and may need to be directly linked to an article to know how to get to it. Nothing's wrong with any of these cases - everyone's got their own interests and abilities.

The thing to consider, though, is that when you make suggestions, you can't know the wiki-level of the dev needing to read your stuff. So, for instance, if you make a suggestion about creatures and it's buried deep inside a suggestions page tucked away in some remote category of the wiki, it's probably not going to be seen by the creatures guys (no slight on them...this is just an example). The only way they could find it would be if someone else around here noticed it and pointed it out to them, or if they happened to stumble upon it (which is probably unlikely).

With that being said:

• Sorting pages by users may be a good back-end organizational method, but it's probably not the best way for devs to read information if that's the only organization method. If someone goes to a category filled with a bunch of names, the only way they'd know what's on those pages would be to start clicking through them. To be honest, that probably won't happen much (or if it does, only a few people would do it). Also, I could see an issue where the first page (or first few pages) of the category are read, but ones at the end of the list (or alphabet) aren't as trafficked. That's probably not very fair to the user, and I could see that causing issues.

• Sorting pages by topic might be easier to look at from a category perspective, but I can see there being big problems with page sizes and each page basically turning into a mini forum. As soon as a page's main topic takes that left turn into arguing and back and forth, most people will probably tune out and move on. There's also the questions of what to do with duplicate pages about the same topic, page sizes, etc. This stuff is more logistical, though.

• I agree with the statement that you guys will probably need to have a pretty robust system of categorization in this namespace. My only caveat with this from a usability standpoint is pretty much the same as my earlier point. I'd advise making sure that you use categories for back end organization and NOT rely on them as receptacles to link to and point devs to.

• I really like the ideas posted above that have tables listing pagenames, last updated dates, and types of feedback contained on the pages. A system like this would be Extremely USEFUL for devs that want to pop in and check out a specific topic. The last update dates are a really good idea (especially if the tables are sortable), because it's going to make it simpler for people to see if pages have been updated since they last read them.

• It seems like it might be difficult to enforce having user make a separate subpage for every suggestion, especially since many people write feedback in the form of longer essays with varying topics. Maybe a system of tagging a piece with multiple categories would work, possibly combined with a header template that allows users to say that topics x, y, and z are covered in their piece? That would probably require a lot of good faith and possibly a lot of policing, but it would still allow for DPL organization (I'd guess at least).

• If having a huge list of suggestions is too cumbersome, what if there are "official" suggestion pages created by topic? For instance, there could be a page like "Miniature suggestions". Instead of having people post their suggestions to this page itself, the page's contents could just be a DPL list pulling in lists of suggestion pages pertaining to miniatures. There could then be a separate master page that lists each of these individual suggestion topic pages.

As a general rule of thumb: the simpler you guys can present the information, the more team members will be able to use it. If a team can go to a single page and see clearly where they need to go from there, chances are they will. If they can see a hint of what's on a cryptically named userpage, they'll be more apt to click on it to check it out. If information is presented in a clean and easy-to-understand table, it's going to be more effective than a cluttered page or category.

3.) The topic of enforcing rules in the namespace

I don't really want to get into this too deeply, since many of you have probably read my admin philosophies elsewhere. Here's a quick rundown of my personal thoughts on any kind of enforcement (which I believe cover the general thoughts of the team):

• While organization and structure are extremely important (as lack thereof causes wiki chaos), I believe that everyone needs to be understanding that many people have never used a wiki before, and don't really understand etiquette and how to do things. On any public site, there are people of all ages and backgrounds, so there needs to be a level of tolerance and leniency when it comes to disciplining or reprimanding over conduct of mistakes. Kindness, gentle guidance, and patience should always stand above rudeness, criticism, and blocking/banning/etc. You guys already do this, and it makes you really awesome to work with. I just wanted to point it out again, though, since there will probably be an added level of complication involved with posting feedback to the site.

I can imagine that things will be a little rocky at first while the space is getting it's legs, but I'm sure it will balance out once a good structure is built and people get comfortable with using it (and then mentoring others on how to do the same). As always, we'll leave it to you quite capable admins to figure out the best way to keep order in the space. I'm confident that everyone realizes the value of every contribution and every user, so I don't think anything more really needs to be said on the topic. Just be reasonable, understanding, encouraging, and fair :)

I read through the topic above (started by Gordon), and I think that you guys are going in the right direction for this stuff, so yeah. Carry on :)

4.) GW2 comments

I'm not sure what to say about this topic, because I honestly don't know what the dev team's plans for taking feedback on GW2 are. All teams will be made aware of the new feedback areas, but the decision to read and use the space is completely up to the individual. Since GW2 is in development, I'd expect that no comments will be made by any members of the team.

The only thing I can think about saying is that it would probably be best to keep the feedback organization as broad as possible for this area. Keep sections and subsections as generic and encompassing as you can. Getting too specific may not be the best thing, because anything too granular would be based on assumptions andcould cause confusion for some users. For instance, if someone put a "Ninja Robot Turtle suggestions" category in a professions section, it's likely that some people would assume that that is legitimate information and something to make their own suggestions about. Next thing you know, we'd be coming into the studio and seeing "GUILD WARS 2 DEBUTS NINJA ROBOT TURTLE PROFESSION" on gaming news sites, and...yeah. I'm being silly here, but you probably get what I mean.

Until we start talking about GW2, my suggestion would be to keep organization broad. Also, don't expect ANY interaction in these areas from devs, because I don't believe they'll be able to comment on anything they see.

Miscellaneous comments

OK, this is getting huge, but here are some more comments:

• "Change the css of the new Feedback space so it looks different from the rest of the wiki. A simple template at the top of those pages isn't enough. The entire page has to look completely different, with a different background color and etc. The alternative design for the wiki (the one with the black background and the font looking like the one used in Guild Wars) would be perfect for that, IMO. The idea here is to make it clear how it's something different from the rest of the wiki."

I agree with this. Anything that can be done to let users clearly understand that they are in the feedback namespace is a good idea. This will be helpful both to users and to devs looking around for ideas.

• It seems like you guys are going to want to use the muscles of bots, the DPL, and other tools to grab as much data and spit it out as possible. Trying to manually organize this amount of information will lead to massive headaches. If you guys feel that you'll need a head start in setting up structure on the namespace, let me know. If you decide it's best, it's possible that we could create the namespace itself first and temporarily limit it's initial use only to admins (or even create a separate, temporary task-force-like group comprised of people you guys decide). That option could let you get in there and set up categories, templates, and basic structural components before any content floods hit. If there's something we can do to help make this easier, let me know and I'll bring it up to the IT team.

I hope that this text wall helps a bit, and I hope it makes some sense (I know I tend to ramble when I'm hungry, and it's past my dinner time =P)! I apologize that I haven't had a chance to hop on here earlier. If there are any specific questions you'd like to direct towards me, feel free to do so. If not, I'll keep reading discussions and comment when I can. Thanks guys! -- Emily Diehl (talk) 03:27, 11 June 2009 (UTC)

Thank you very very much Emily for giving us all this to think about. I especially like the idea of setting up the namespace with limited accessibility to get the structural work done before opening it up to the general community for contributions. I think the idea of a "task force" to do this would be great, and I think that the community would be able to come to an agreement of who those people should be. -- Wyn 03:38, 11 June 2009 (UTC)

My god, this is the most epic wall of text I have ever seen. I'm gonna TL;DR for now, but I will read it soon. Thanks for putting so much time into it. ~Shard 03:44, 11 June 2009 (UTC)

Yes, thank you very much Emily, when Misery and I asked for your input, I don't think either of us expected this kind of effort.

I only have one direct question right off the bat: You mentioned that you really like the idea of having "tables listing pagenames, last updated dates, and types of feedback contained on the pages" and in light of your dicussion of the importance of keeping it simple, do you have a sense of how valuable short descriptions of each feedback page being included in these tables would be to the devs? I'm referring to the discussions above about, essentially, a far-right column in these tables having a sentence or two from the feedback creator just describing what exactly is on the page being linked.

I understand you don't want to get overly involved in the organization, and may not want to be too direct in this regard, but part of the question about this is how valuable such an addition would be for the devs, or whether simple categorization alone would suffice. This also has some bearing on the degree to which we need to narrow our categories (i.e., if there are summaries for each page, then the categories can be a little bit more broad, and thus we can have fewer of them, than if not). Your thoughts on this would be most appreciated. (Satanael 04:00, 11 June 2009 (UTC))

I still advocate the backend organisation by users to minimise conflict and I understand wizardry can be used to make things more accessible for devs, although that seems more like the field of people like poke or Max2 than me. One suggestion per page in the user subspace may work best in terms of pulling things out for DPL lists and direct linking. The complicated nature of the system may make less wiki-wise people have their suggestions lost in the depths of the wiki, but that happened with the old system anyway. The success of the system will probably largely depend on the categorisation and list generation, which is something mostly out of my hands. Misery 16:05, 11 June 2009 (UTC)

As with Shard, wow, epic text wall. I do like the idea of a "task force" as what Wyn said. With Mis in the comment above, the success depends on readability and organization. --Antioch 21:49, 11 June 2009 (UTC)

Isn't that what I said? Or were you just agreeing? Misery 06:53, 12 June 2009 (UTC)

Suggested table

(RI) So...

• We know, from the old suggestions pages here, that a comunal suggestions space doesn't work. We need a system based on userpages, with a single user responsible for his/her space and his/her ideas.
• This is something massive in size, that we couldn't hope to control manually. We need something we may automatize, and the best tool we have for that is DPL.
• Arena Net wants something simple. They also agree that tables are good for your health.

So for Guild Wars 1, let's have this:

1. A single suggestions page, from which every idea may be reached through one link. This is the simplest way for Arena Net to find the suggestions, avoiding the bad scenario described by Emily in which a developer would have to go from page to page to page just to find a suggestion.
2. A suggestions table from which the ideas would be linked. The ideas would be categorized by theme, and displayed first by user name, then by last date modified, then by theme. Each page would be linked with its own name.
3. Given how we would be using page names, there would be no need for strict categories, only broad ones, and also no need for summaries.
4. Page name would have to be limited in number of characters to avoid breaking the table, though.

Something like this (only DPL based and looking a lot better, of course):

Username		Last modified		World		Character		Items		PvE		PvP		Skills		Other
Erasculio		06.06.2009								Changes to Urgoz Changes to the Deep				Nerf Shadow Form
Cynn		02.12.2008				New hairstyles						Changes to RA		Buff Meteor Shower

For Guild Wars 2:

• Replace the current license on the GW2 wiki so all pages there are legally safe for Arena Net. Before someone comes with the “but there's nothing there!” argument, that's exactly the point. One year after the release of GW2 we (hopefully) won't be using the GW1 wiki to hold the GW2 suggestions, and changing the license now, when the GW2 wiki is empty, would be the best way to prevent this problem from happening then. We may even delete the few feedback based articles on the GW2 wiki.

Erasculio 12:41, 12 June 2009 (UTC)

While I agree that DPL is an excellent tool, keep in mind it has a limitation of 500 responses. I can see this area quickly outgrowing DPLs capabilities. Of course, I'm a complete noob when it comes to DPL, poke and others are much better at addressing this sort of infrastructure. I also agree with Erasculio regarding GW2W, and it's licensing. -- Wyn 13:34, 12 June 2009 (UTC)

You're right, Wynthyst. I guess our next option would be something I'm not fond of, but anyway: using different tables, each for one category, and in each category list suggestions based on username, date last modified, and subcategory (such as "buffs", "nerfs", "mechanic changes" and etc for the main Skills category). All those tables would ideally be on the same page for easier access. Erasculio 15:29, 12 June 2009 (UTC)

I agree with the above, I think housing suggestions on the backend according to user is our best option, and it seems like we will have to have more than one table of ideas. However, I do still think suggestion summaries are a must, and broader categories only heighten this need, not reduce it. I know Erasculio doesn't like this idea, and I don't want to reopen that can of worms, so the only thing I'll say is: when we actually get to designing these tables, let's see if we can put summaries in, and if they fit and work okay, then let's at least start out with them in. If they prove problematic once we go live, we can always get rid of that option later.

Also, even with using more than one table, we are going to reach the 500 limit at some point anyway, so we will have to work out how to archive and when. Better to work that out now than wait for it to hit us in the forehead later. (Satanael 16:20, 12 June 2009 (UTC))

Regarding the summaries, my suggestion now is to link directly to a page, with each page hosting one idea, using the pagename as a link. Instead of having a summary saying, "ideas on how to buff Shadow Form", the link is going to be "buff Shadow Form". While this is going to be something troublesome to format, I think it's fitting for Emily's request for simplicity, while making a summary redundant, IMO. Erasculio 18:04, 12 June 2009 (UTC)

Username		Last modified		World		Character		Items		PvE		PvP		Skills		Other
Erasculio		06.06.2009								Changes to Urgoz Changes to the Deep				Nerf Shadow Form
Cynn		02.12.2008				New hairstyles						Changes to RA		Buff Meteor Shower
Mhenlo		25.12.2007		New RA arena				hairstylist equipment				Buff Meteor Shower
Eve		03.03.2009		Merge the Deep and UW.		New pets				Buff Meteor Shower		TA suxors

Added some entires to showcase some issues. Backsword 07:39, 13 June 2009 (UTC)

I think the current plan is not to use that table, rather split it in multiple tables, one for each theme. We could use those to give more room for each cell, to explain better what each topic is about, and so on. Users are not going to manually add entries to the table; if we accept poke's idea on making his bot add entries based on keywords, entries on the wrong column hopefully won't be an issue. There are going to be things the community will have to policy, though; I would rather delete & ban users who did something wrong, but given how Emily is far nice than I am, I think she would rather have us explaining to people what they are doing wrong and teach them to fix those mistakes. Erasculio 11:58, 13 June 2009 (UTC)

@Erasculio, regarding your page name suggestion: Ok, I think that can be a workable solution. Only issue I have is telling people to describe their suggestion and telling them to name it or provide a title is not exactly the same thing, so we will have to make sure that our instructions tell people that their title should be descriptive of the suggestion. This won't really cut down on the policing issue, but it will certainly save space in the tables. (Satanael 15:47, 13 June 2009 (UTC))

These ideas are really cool! If you guys run into problems with things like summaries (since it seems like that could be an easy thing to break...both because users will have to enter them themselves and because size may be an issue...well, unless you character restrict), even moving to a system like you'd proposed before where there's a check in each category discussed on the page should be ample. If you can go nuts with the details, though, even better :) -- Emily Diehl (talk) 22:45, 15 June 2009 (UTC)

Infrastructure

Ok, the namespace is up and much discussion has occurred over the look but we need to finalize the working infrastructure and get that going. While the look is good, without the actual structure it's all for nothing. Have we come to any final decisions on how it should be done? It appears from Emily's posts that all feedeback (suggestions, skill feedback, bug reports and localization) should be relocated to the new namespace. With the Bug reports and Localization, I see no problem in simply copying the existing structure to the new space, locking down the existing pages until outstanding issues are resolved and archived, and having all new issues directed to the new space, but what about the Skill feedback? Is it functional the way it is? or should it be reworked? The mass of discussion above is regarding suggestions only. -- Wyn 01:58, 24 June 2009 (UTC)

Set-up task force

Emily indicated that implementing the Feedback namespace in advance with limited accessibility is possible. I would like to suggest that we decide who are the best minds for this job, and get it started as soon as possible, so that when the new licensing goes into effect we have a head start, because you know how restless the natives are already getting about not being able to post their suggestions. It could potentially cause a wiki riot if after waiting so long for the new terms to be finalized they are forced to wait more weeks while the infrastructure is put in place. I believe there are enough raw ideas here that everyone is pretty much agreed on that a basic format could be started, as well as getting the css designed. I would like to point out, that the css will need to be implemented for each available skin (I learned that the hard way), to insure that users who have chosen to use a skin other than monobook will also see the visible difference in the new namespace. Let me take this opportunity to nominate poke, Satanael, and Erasculio as lead members of this task force as they have demonstrated the capabilities we need. -- Wyn 13:46, 12 June 2009 (UTC)

Thanks for the nomination and I accept, but IMO more important than people like me and Satanael (who, as far as I know, don't know that much about wiki code and programming), are people like poke who can actually implement the stuff we're talking about. Is there someone else with that kind of knowledge who has been following this discussion? Erasculio 15:26, 12 June 2009 (UTC)

Totally agree with Erasculio here, I am happy to help work on this and implement design, but my wiki code skillz leave something to be desired. Maybe Wyn would be willing to lend her design and layout abilities as well? (Satanael 16:12, 12 June 2009 (UTC))

You guys have a much better idea of how the organizational structure of this should work than I do, I've been only skimming along the edges of these massive wall of text discussions. My talents are all in fluff, yours are more in substance. I do agree that poke has got to be a vital component of this as I don't know anyone else currently active on the wiki with the coding skills this is going to require (he could probably do it in his sleep, I swear, the boy eats, sleeps and breathes code). I am happy to offer any suggestions or opinions as I see fitting as the process goes along, I'd just like to see the namespace implemented as soon as possible so this structuring can start. To do that we need to know more of who is going to have hands on access, because it will require special user permissions. -- Wyn 16:19, 12 June 2009 (UTC)

Fluff is precisely what I thought we might need. I mean, I am fully respectful of poke's abilities, after seeing what he did with our ideas about the main page, I would actually not feel very comfortable doing this without him. And while Eras and I may have several ideas about organization, I was thinking it would be good to have someone in the group with a real flare for the aesthetic, so this doesn't come across looking like a rush job. I don't want to force you, Wyn, in on it if you don't want to, and if poke thinks he can add that little extra something to make this whole thing look and feel right, then I'm fine with the three of us. All I'm really getting at is that aesthetic and polish matter, and it would be good if there were someone paying attention to that while we design. (Satanael 16:36, 12 June 2009 (UTC))

If you want my input, you merely have to ask. /bows at the compliment -- Wyn 16:39, 12 June 2009 (UTC)

Okay, after completely avoiding this page for some weeks now, Wyn got my attention by saying "I nominated you"... <_< I read through most of the discussion above and I think I got the basic idea of that whole thing now. And the more I read the more I would not like the wiki to host the suggestions (instead using some bug tracking system administrated by some elected users), but it seems that we now have to go with it. So if you guys want, I will help you with whatever I can.

I'm really not sure if what Emily said above about limiting a namespace to only a group of users will even work, so it might be a bit complicated to set the namespace up (even if I don't think there is that much to set up anyway..). For generating the list, I'm not sure if DPL would really be the best solution for that, but we will see what implementation ideas the others come up with. poke | talk 18:27, 12 June 2009 (UTC)

What options do we have other than DPL? Do you know something that would work better? (Help us poke-wan, your wiki-chu is our only hope!) Erasculio 18:32, 12 June 2009 (UTC)

Yes, that is exactly what I thought about. It would be possible to generate static lists (for example every 24 or 12 hours) that adds all new feedback articles to static lists, based on defined keywords on that page; or to show what pages have updated. That way it would be possible for the developers to actually track what ideas they have read, or where something was updated. Of course it would not allow a by-user tracking system (which is not possible with a wiki), but at least we could add things that are not possible with DPL (for example DPL will make the request regardless of the edit dates and will mix new and old suggestions into each other); and we wouldn't have the 500 edits limit either. But still, it is something that would need to be developed and it would be quite dependent on the structure we set up at the beginning. poke | talk 18:44, 12 June 2009 (UTC)

So, if I understand this correctly (and I'm not saying I do), we would essentially create static tables that, every 12 hours or so, would add new suggestions to the table already there. Would it be possible for the table to add new suggestions every time the table is loaded, similar to our watchlists? Or is that somehow not how it works? If not, how often could we have new suggestions added to the table? Every hour? I only ask because it would probably be best to do it as often as possible, so devs don't have to wait if they want to check the list often, and users don't get antsy about seeing their ideas listed. (Satanael 21:16, 12 June 2009 (UTC))

No, the lists would be 'manualy' edited by pokes bot, whenever it's set to run. It would work just like a normal user did it, except a bot won't get bored with the repetetive task. Backsword 07:18, 13 June 2009 (UTC)

Much have been made out of the 500 limit of DPL; but frankly, it's an make excuse. Any list with that many entries needs to be split for human readability anyway. Backsword 07:18, 13 June 2009 (UTC)

Ok, one more question about poke's static table idea, will users (i.e., devs) still be able to re-organize the tables to list in different ways? I mean, I think one of the things we were originally hoping to be able to do with the tables was to make it so that clicking on one of the columns would re-list the entries according to that column, e.g., clicking on the user/creator column would organize the table entries in alphabetical order by user, or clicking on the "last edit date" column would organize the entries by how recently they were last edited, etc. Is that still possible to do with the static tables? (Satanael 15:52, 13 June 2009 (UTC))

Yes, sortability can be added to any wiki table. -- Wyn 15:54, 13 June 2009 (UTC)

(Reset indent) Heya guys! I chatted with IT about this topic a bit today, and we believe that restricting posting to a namespace to either a specific usergroup (or just sysops) is definitely possible. We're going to look into the details of this more, since it would be optimal if we could just create a temporary usergroup for this purpose (and get rid of it after things are set up). If permissions don't actually differentiate permissions based on manually created groups, there's always the option to temporarily promote requested members to sysop for the duration of the project. Granted, that means that someone technically could do stuff on the mainspace, but I have faith that this wouldn't be an issue with folks that are designated as task force helpers. Anyways, this is up to you guys. Language is in the final stages here, so it should be coming soon. Just let me know what you guys would like and I'll work with you to get it going. -- Emily Diehl (talk) 22:40, 15 June 2009 (UTC)

I don't know, I'm not sure I'll be able to handle all that power at once, I might be corrupted by it and "accidentally" permablock everyone with the pvp usertemplate on their page... (Satanael 15:31, 16 June 2009 (UTC))