User:Shard/Emily1

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!