Guild Wars 2 Wiki talk:Community portal/Archive 13
Archive
- 2007 - 2008
- 2009
- 2010
- 2011
- 2012 Jan - Jun
- 2012 Jul - Aug
- 2012 Sep - Mar 2013
- 2013 Feb - 2013 Jun
- 2013 Jun - 2014 Feb
- 2014 Mar - 2014 Dec
- 2015
- 2016
- Dec 2016 - Jul 2017
- Jul 2017 - Aug 2017
- Sep 2017 - Jun 2018
- Jul 2018 - Oct 2018
- Nov 2018 - Apr 2019
- May 2019 - Aug 2019
- Sept 2019 - Dec 2019
- Jan 2020 - June 2020
- Aug 2020 - Dec 2020
- May 2021 - Jun 2022
Event Rewards Templates
While I was adding rewards for defeating bosses in the Nightmare Fractal challenge mode, it came up that the rewards do not come from the bosses themselves, but rather are given out as event rewards (from completing the event objectives). Documenting the rewards for these events required updating both the fractal page in addition to the individual item's acquisition section. This pattern extends to many of the event rewards in HoT maps, where the drop itself may list the events that reward it, but the event itself does not mention the drop (even if it is guaranteed). This seems like a gap in the wiki templates/properties and I'd like the community's thoughts on my proposal.
- Proposal
- Create 2 new templates for event rewards/bouncy chests that you don't gain from rummaging around in the still-warm corpses of your enemies
rewards
to specify what items are rewarded by an event(see Template:Drops):- "This event rewards this item."
{{rewards|Chunk of the Solid Ocean}}
{{rewards|Chunk of the Solid Ocean}} (1-2)
- "This event objective rewards this item."
{{rewards|Chunk of the Solid Ocean|Defeat Siax the Corrupted}}
{{rewards|item=Chunk of the Solid Ocean|objective=Defeat Siax the Corrupted|name=Chunk}}
- Possible example:
- Chunk of the Solid Ocean (1-2)
- "This event rewards this item."
rewarded by
to list what events reward this item (see Template:Dropped by):- "This is the list of events that reward this item."
{{rewarded by}}
- Possible example. I'm not sure what the best format would be, though:
- Nightmare Fractal - Defeat Siax the Corrupted
- Power East Sentry L.O.X. with energy from the ley-line energy collectors (80)
- Spirit Vale - Close the spectral rifts before they erupt.
- "This is the list of events that reward this item."
- Examples of Usage
rewards
- Personal story rewards, e.g., Roots of Terror
- Event rewards, e.g., Against the Chak Gerent meta-event, various other HoT events with guaranteed (or randomized) rewards
- Event Objective rewards, e.g.,
- The bosses in the Nightmare Fractal challenge mode do not drop loot directly, instead you get bouncy chests as "Event rewards" for completing the objective associated with the boss.
- Spirit Woods (where such chests are omitted entirely).
rewarded by
- e.g., Vial of Chak Acid acquisition
- Admittedly, you would lose some of the manual categorization people have done (e.g., Black Lion Chest Key#Story rewards)
--Floodbars (talk) 05:54, 23 December 2016 (UTC)
- We don't have a template for bonus chests yet, but those gives a random item. The map meta reward is based on tier. The meta event progression rewards are more tied to the dynamic event being part of the meta event, rather than the event itself. The Story Journal stuff is covered by {{reward}} (old, bad name). The problem there is the reward is sometimes dependent on profession and the "pick-one" variation in the reward.
- I'd hold off on lookup templates until we have a clear format for how the rewards are presented and where to put them. Seems more likely that we'll create a template for each reward type and at least store the reward item and reward type for presentation.--Relyk ~ talk < 07:10, 23 December 2016 (UTC)
Recent change to effect-based templates
I don't know hat has happened for sure, templates such as Crippled, Bleeding, etc. used to support an optional parameter to change the wording while keeping the icon (i.e. {{crippled|cripples}} would say cripples). There are examples of previous use of this convention like here. As a result, I must use {{effect icon|crippled}}[[crippled|cripples]] for editing combat abilities sections of NPCs, which is extremely long. However, I know now that it was not a result of changes to the specific templates, but something that affects the wiki as a whole. I'm unsure as to what it could be, so, if possible, please offer some insight as to why this is happening. Sythe 02:36, 3 January 2017 (UTC)
- Articles shouldn't be using the templates anywhere in prose.--Relyk ~ talk < 05:00, 3 January 2017 (UTC)
- I'm afraid I don't understand what you mean. Could you elaborate please? Sythe 15:58, 3 January 2017 (UTC)
- I believe Relyk means that when it's used, it should solely be in cases where you'd use the word "crippled" rather than "cripples" - e.g., "this applies crippled" rather than "this cripples" - or in list of conditions. Basically, there should be no need to ever type {{crippled|cripples}}. If I'm understanding Relyk right. Konig (talk) 16:59, 3 January 2017 (UTC)
- Yeah, when there is text like “Using this skill causes a bleeding”, just use normal links like that to keep up the reading flow. Those templates are mostly meant for things outside of text like a list of effects a skill could have. poke | talk 17:31, 3 January 2017 (UTC)
- Ah, I see. I was attempting to follow previous conventions used on the wiki as examples, i.e. Jungle Tendril#Combat abilities under abilities. From now on I'll follow your recommendations, thanks! Sythe 17:54, 3 January 2017 (UTC)
- You can largely thank User:Louise for doing that to the ability section of many NPCs (and many others followed suit), but as you can see... the templates aren't meant to be used in such a fashion. I fixed that particular article since I noticed other things wrong with it, as it is now is how I, personally at least, think articles should be for that template use. Konig (talk) 19:58, 3 January 2017 (UTC)
- Ah, I see. I was attempting to follow previous conventions used on the wiki as examples, i.e. Jungle Tendril#Combat abilities under abilities. From now on I'll follow your recommendations, thanks! Sythe 17:54, 3 January 2017 (UTC)
- Yeah, when there is text like “Using this skill causes a bleeding”, just use normal links like that to keep up the reading flow. Those templates are mostly meant for things outside of text like a list of effects a skill could have. poke | talk 17:31, 3 January 2017 (UTC)
- I believe Relyk means that when it's used, it should solely be in cases where you'd use the word "crippled" rather than "cripples" - e.g., "this applies crippled" rather than "this cripples" - or in list of conditions. Basically, there should be no need to ever type {{crippled|cripples}}. If I'm understanding Relyk right. Konig (talk) 16:59, 3 January 2017 (UTC)
- I'm afraid I don't understand what you mean. Could you elaborate please? Sythe 15:58, 3 January 2017 (UTC)
Coordinates on the wiki
Hello guys. {{Infobox map}} has been up for a few weeks now, and so far I'm pretty pleased with how it's turned out. I'm now thinking about adding coordinates to the following:
- Locations: I'm thinking about adding the coordinates from the API to Cities, Zones (not areas at the moment), Heart NPCs (they're in the api already) and probably Points of Interest. This will be "easy".
- Hero challenges (related to the above): There isn't currently a neat way to pick up all of the hero challenges pages (where context = Events, NPCs, and Objects) with one semantic query, which I think should be possible. I've composed a manual list of the pages here: User:Chieftain_Alex/sandbox2&oldid=1350395. I'm not sure which direction to go. Option A: We could just stick a manual category at the bottom of the page, such as "category:hero challenges", and then move the current content of that category to "Category:Hero challenge events" (since that's what they are). Option B: Alternatively we could add a parameter to all three infoboxes along the lines of "hero challenge = y" (and only use that for challenges with map markers). I'm open to other suggestions.
Side note: there's also the complication that multiple hero challenges share one page, e.g. Statue of Melandru (hero challenge) has four on one page.
(And yeah, eventually I want to be able to give two [x,y] pairs to a query, and it'll tell me exactly what's inside the bounds.) -Chieftain Alex 21:53, 13 January 2017 (UTC)
- Round two:
- I split all the shared hero challenge pages to be one page each. This simplifies maps and dialogue. I've updated all links too afaik.
- I chose to move "Category:Hero challenge NPCs" and "Category:Hero challenge objects" to Category:Hero challenges since the initiators for the challenge encompass everything (i.e. the total of that category should in theory be the same as the ingame total for Tyria+The Mists = roughly 253). Events are now to be found in Category:Hero challenge events. I've added the coordinates to all hero challenge NPCs and objects, but let it default to jpeg maps if available and left coordinate maps as a fallback.
- Hearts and points of interest are next on my list. -Chieftain Alex 19:48, 4 March 2017 (UTC)
- Should I add event coordinates to the wiki too? -Chieftain Alex 22:35, 9 March 2017 (UTC)
- Yes. - Doodleplex 22:39, 9 March 2017 (UTC)
- Events are weird - I know how to convert the "center": [ -45685.2, -13819.6, -1113 ] to coordinates = [x,y], but I have no idea what we want to do with the sphere/cylinder/poly types + their radius. I'm thinking I should still add the X/Y if there's a direct page match. -Chieftain Alex 23:37, 9 March 2017 (UTC)
- Okay 1900 events now have coordinates added to their infoboxes. There are about 2000 historical events in the event_details API (e.g. Mordrem invasion, Scarlet, and a further 900 events which either aren't documented or have duplicate names (e.g. rift events, an event for each rally point in verdant brink, etc) - too many to manually sort out.
- The tango icons look kind of cruddy. We could do with the ingame icons from the dat. -Chieftain Alex 13:04, 12 March 2017 (UTC)
- Noticed two things so far: First, it appears if a .jpg map was uploaded already, like for Help U.N.I.T. find and destroy the Inquest, the coordinates do not show up. Second, the coordinates a great for events that are stationary in one place but are absolutely terrible an escort type event where they go from A to B, as I have no idea if that circle is the starting point, the end point, etc. (edit) Also coordinates don't show up at all for meta events. - Doodleplex 19:25, 13 March 2017 (UTC)
No Periods. Period?
I tried asking this before, but I think it got missed. Similar to how we don't use period in event names, can we do the same for items and effects that have periods in them such as "Ponder the Cobiah Marriner Statue." and "You can not use this skill right now." as it's much more readable without the period. - Doodleplex 22:09, 23 February 2017 (UTC)
- Nah, I think we should leave those as is. The difference is that events with periods are much more common than items are. It's in the api, it's in the game, and it should be listed on the wiki with a period as well. Of course, an argument could be made that we should also put periods on events to reflect their in-game nature, but that's a discussion for another day. —Ventriloquist 09:18, 24 February 2017 (UTC)
- If keeping them does no harm (i.e. doesn't affect look-ups), then there's no need to go and remove the ones with periods. G R E E N E R 06:23, 4 March 2017 (UTC)
- Alright, I just think it looks a bit weird but if that's what seems to be accepted then I'll not poke it. - Doodleplex 06:50, 4 March 2017 (UTC)
- I'd rather remove the periods, the main reason being we don't quote wikilinks and it looks bad at the end of a sentence. The other reason being that having to add the period when searching is unnatural for people. It's much easier to add the period in the alt text if needed, which is moreso easier for less common pages like Vent noted.--Relyk ~ talk < 15:17, 12 March 2017 (UTC)
- To be fair most people don't type things out that far to get to the period, but I do like the above idea to just add it as alt text. - Doodleplex 19:28, 13 March 2017 (UTC)
- Looking from URL viewpoint, the period make stuff confusing. E.g. some softwares like chat and such autoconvert URLs to links and most of them ignore the period as it not being part of the URL, even the official forum itself does that. In fact, the wiki itself does that, if I just put https://wiki.guildwars2.com/wiki/Ponder_the_Cobiah_Marriner_Statue. in plan text (check the source to see it) it leaves the period out of the link destination. --Txon Atana - (talk) 23:41, 6 May 2017 (UTC)
- To be fair most people don't type things out that far to get to the period, but I do like the above idea to just add it as alt text. - Doodleplex 19:28, 13 March 2017 (UTC)
- I'd rather remove the periods, the main reason being we don't quote wikilinks and it looks bad at the end of a sentence. The other reason being that having to add the period when searching is unnatural for people. It's much easier to add the period in the alt text if needed, which is moreso easier for less common pages like Vent noted.--Relyk ~ talk < 15:17, 12 March 2017 (UTC)
- Alright, I just think it looks a bit weird but if that's what seems to be accepted then I'll not poke it. - Doodleplex 06:50, 4 March 2017 (UTC)
- If keeping them does no harm (i.e. doesn't affect look-ups), then there's no need to go and remove the ones with periods. G R E E N E R 06:23, 4 March 2017 (UTC)
Request for Adminship: Doodleplex
RFA page has been created at Guild Wars 2 Wiki:Requests for adminship/Doodleplex. G R E E N E R 22:15, 15 March 2017 (UTC)
External links from item infoboxes
I think we should consider reviewing the links we provide at the moment. Example: Elonian Leather Square provides links to the following sites:
- GW2BLTC
- GW2Shinies
- GW2Spidy
- GW2TP
Also, are there any better options? (as example, anything with a recipe to make it could instead link to gw2efficiency) -Chieftain Alex 21:26, 16 March 2017 (UTC)
- I wouldn't mind seeing it appear under "Chat link" in the {{recipe}} template, if possible. G R E E N E R 22:05, 16 March 2017 (UTC)
The ampersand symbol
I was pondering the other day, since the ampersand or "&" symbol is currently not working right, I was wondering if for the pages that currently have them should be redirected to pages that don't have it in the name so that everybody, not just the few of us with bots, can edit/create them. Or basically, redirect anything with "PR&T" and "R&D" to "PRT" and "RD" respectively and stick the tag for technical restrictions on top. The only trick I don't know though would be how to create redirects for the pages that haven't been made yet (which is pretty much just the NPCs in Jeztar Fall), would creating a page and then moving it to the correct name (with the redirect already on the page to avoid trying to edit after moving it issues) work? I don't want to break anything hence why I haven't tried that idea myself. - Doodleplex 22:38, 27 March 2017 (UTC)
- Issues with ampersand and a few other symbols were supposed to be fixed around January with the update to the wiki backend. Got any examples?--Relyk ~ talk < 23:33, 27 March 2017 (UTC)
- Examples of it not working? Yeah, tried to make "PR&T Mini Ooze Projection" and got the "PR" page which Alex deleted. - Doodleplex 23:36, 27 March 2017 (UTC)
- If we can make a more robust version of
// Encode wiki links that might break, e.g. ampersands. function encodeWikiElements(selector, attribute) { $(selector).each(function (i, element){ var m = $(this).attr(attribute).match(/^(\/index\.php\?title=)(.*?)(&curid=.*|&action=.*)$/); if ((m) && ( $(this).attr(attribute).search('%') === -1) ) { $(this).attr(attribute, m[1] + encodeURIComponent(m[2]) + m[3]); } }); } encodeWikiElements('a[href]','href'); encodeWikiElements('form[action]','action');
- we could stick it in the common.js -Chieftain Alex 00:17, 28 March 2017 (UTC)
- breaks on rollback links at the moment. -Chieftain Alex 00:27, 28 March 2017 (UTC)
SAB request
I'm posting this here because I don't know if there is a more appropriate place to make requests. One thing currently lacking in each of the SAB level articles is a clear organization of things by category, by which I mean the locations of locked chests and destructible furniture counts, things which are relevant to daily and other achievements, but which are not terribly accessible as such when scattered throughout the text of a full walkthrough. If someone could please design an organizational structure to highlight this information - as a starting point you could consider something similar to what is already done for digging spots. Thanks. 76.253.2.43 17:29, 5 April 2017 (UTC)
- You may find this helpful in the interim. SarielV 18:22, 5 April 2017 (UTC)
- I created the above linked page to be a general guide for what you need to do for the dailies, since the walkthroughs on the Zone page are intended to guide players to obtain all of the bauble/hidden shop achievements as well as guide them to the end of the zone. The digging spots are a separate section on the zone page since they aren't required for either zone completion or any of the previous achievements before the dailies came around, but were relevant to the zone. - Doodleplex 23:17, 5 April 2017 (UTC)
On the Community, Administrators, and Reconfirmations
- → moved from Guild Wars 2 Wiki talk:Requests for adminship/Doodleplex#On the Community, Administrators, and Reconfirmations
- Since we're now conducting human experiments, are we going to have reconfirmations for all current administrators as well? Might be a good chance to gather some feedback concerning what the community thinks of and expects from administrators, thus aid in fixing possible issues — all the while establishing some contemporary groundwork in terms of adminship which might ease the processes of possible future RFAs and clarify the actual role of an administrator further. It would also help in identifying whether the lacking activity of this and the past RFA was user-related or the result of general wiki lethargy. I am actually only sharing this suggestion since, based on my evaluations, none of the current active administrators are likely to lose their adminship over a reconfirmation. Thoughts? talk 19:33, 20 April 2017 (UTC)
- Well, having a reconfirmation for Doodle already may not necessarily be the most useful thing in the world without specific reason, but if you (the general you, whoever) wanted to call for reconfirmations on the other admins (me included), that's certainly a thing you're allowed to do. Actually I don't think we have a particular process for calling for reconfirmations, considering the only reconfirmations we've had were the initial round of em back in 2012, but I'm sure we could stumble our way through something. That being said, I think if your main goal is clarification of the admin role without any particular doubts in the current admin team, perhaps a discussion on Guild Wars 2 Wiki talk:Requests for adminship or Guild Wars 2 Wiki talk:Practices and processes would be more in order, either first or instead. - Tanetris (talk) 00:48, 21 April 2017 (UTC)
(Reset indent) You are right, having a reconfirmation for Doodle so soon would make little to no sense, particularly since she already received her, although possibly a bit lacking, feedback. That should suffice for the next few years.
When I suggested reconfirmations I meant ones for the already existent administrators. I am still more inclined to have reconfirmations for all the long-standing administrators instead of just clarifying the role of an administrator, since it would be a valuable experience for all participants.
This is mostly because:
The position as an administrator should not be a secure one, let alone a "title for life". Since most people, particularly new or less committed individuals or even mere passers-by, might not know about the possibility to instigate a reconfirmation, it makes more sense to routinely reconfirm all administrators once in a while (I am aware of the suspended policy proposal that never made it through).
As for the reasons why, there are several, though I shall present the three major ones.
The community as a whole is in constant movement. People come, people go. The ones who voted for you (here and in the following as "general" you; not addressing anyone specifically) when you were first nominated are most likely no longer present. A reconfirmation will show you how you stand with the community in its current state. You will be able to collect (ideally constructive and meaningful) feedback. Positive as well as negative. The former covering the need for praise and appreciation, both invaluable for increasing and/or ensuring productivity and enthusiasm. Personally speaking for a moment; I find acknowledgement and praise are certainly good means to encourage me to try to improve myself further. I would like to believe this applies to most humans, however, I am not claiming that it does. Concerning the good of negative feedback, it should help pointing out areas where some kind of improvement of your admin-self and/or the way you operate is necessary. Lacks and needs may make themselves present, demanding some kind of action — acknowledging that there are lacks would certainly be a step in the right direction already.
Further, reconfirmations serve the purpose of engaging the community. Transparency is ensured. Not only this, it represents the belief that every single member of the wiki community has a say in wiki-related matters. Regardless of what kind of user you are. This is good for the community and should help it grow (closer). In addition, it helps coming to a consensus regarding how adminship should be through the collective of different opinions and persons. Likewise, awareness is raised. There are individuals who are not aware of how this wiki is run (the general belief is still that the information mysteriously appears out of thin air or that ArenaNet or some other single person manages it; i.e., at one time one person asked me to my horror whether I ran the wiki on my own), or that there are administrators, and even if they know that there are, they do not know who actually is one. Yes, we have the list of currently (in-)active administrators. Its usefulness is debatable. How should these people then know they can help administering the administrators? I was sceptical of having a site notice for RFAs at first, but it seemed to have helped. However, it would further aid if we had some sort of guideline that helps (less) experienced editors and the target audience to make the most of their right to vote.
Lastly, reconfirmations help us weeding out the inactive administrators. Some might even come to the realisation on their own that it might be a better idea to step down if they lack the time or commitment they had when they just started out, instead of being a "ghost" admin. Some might need the input of the current community to come to this realisation or be confronted with the reality. Along the way the red names might turn into blue ones, and the list of administrators might grow, particularly since, ideally, the benefits of having reconfirmations come into play and pay off.
I do not wish to call for reconfirmations without prior communication and consent. This is an attempt to turn a new leaf, not to stir up drama and offend individuals. If we are going for reconfirmations, we should keep in mind to try to cater to all kinds of participants. This means that the candidate statements should be a bit more elaborate than: "Hey, I've been doing this for x years, ya'll cool and stuff, let me at it again" but instead briefly state who you are, what you did, for how long you did it, what your domains of expertise are, what you might have noticed about yourself that you want to improve, and what you are going to do or continue to do for the community if they decide to keep you. During the reconfirmations the candidates should try to engage with the ones voting; that means try to answer questions or resolve possible issues and thus show their commitment and interest in this.
This covers what I wanted to convey to a degree. Are there further thoughts, comments, concerns, questions, what have you? talk 12:11, 21 April 2017 (UTC)
- I think you brought up some good points worth discussing. Not an overhaul, but simply a reconfirming of where we are and what the community would like. Could we move the above to a more appropriate page? G R E E N E R 15:12, 21 April 2017 (UTC)
- Sure. Guild Wars 2 Wiki:Community portal or Guild Wars 2 Wiki talk:Requests for adminship? talk 15:52, 21 April 2017 (UTC)
- I'm interested to see what the response is, so I'm inclined to have your above post copied over to the Community Portal. G R E E N E R 15:59, 21 April 2017 (UTC)
- By all means carry out reconfirmations for everyone. I'm sure the majority of contributors expect some level of continuous validation for sysop users. -Chieftain Alex 17:19, 21 April 2017 (UTC)
- "The position as an administrator should not be a secure one, let alone a "title for life". ... it makes more sense to routinely reconfirm all administrators once in a while"
- You're going to give some of the really old hands flashbacks to the GW1W bcrat elections, which were kind of a nightmare. For reference, there were 3 bcrat seats, each with a 6-month term, staggered, and elections took a month, which meant 1-month election, 1 month off, 1-month election, 1 month off, repeat for all eternity (except not for all eternity, as the community eventually got sick of it).
- That being said, it's been 5 years since most of the admin team has had reconfirmations (3 years since the RFAs for Alex and Vent), so a round of reconfirmations every 5 years in addition to 'as needed' is probably not too onerous.
- Opinions are probably always going to be mixed on whether an inactive admin should remain an admin. The age-old argument goes that if we trusted someone with the admin tools then, there's no reason they aren't still trustworthy with the admin tools, and we lose nothing by letting them keep it in case they happen to come back and see something that needs adminning. By the same token, Infinite for example quit the wiki 4 years ago, so there is probably not a great deal of value keeping him on the sysop list. And now I'm worried about Gares realizing I haven't heard from him since an e-mail a year ago... Gonna be looking into that. But that aside.
- The point I was trying to go for was that I personally don't mind going up for reconfirmation, but let's not go crazy with required reconfirmations for no reason every couple months or anything like that. - Tanetris (talk) 23:28, 22 April 2017 (UTC)
- My hiatus from the GW1W admin team lasted a few years, so there's some support for the age-old argument. And please, not that 6-month cycle again...
- I don't want to see anything which results in a "Keep this admin!" vs. "Kick them out!" mentality, either. Perhaps a softer, "Hi, my name is ______. Here's my role on the wiki. How do you feel about this role, or my performance in it so far? Is there anything you'd like to see changed or improved on my part?" I.e. a means of gathering feedback. I believe that if the feedback were somehow overwhelmingly negative, then we could talk about shifting some people out of their current role. G R E E N E R 00:18, 23 April 2017 (UTC)
- I can understand having breaks from, or hiatus from the wiki, but at some point it gets too long imo. There are some admins that I don't recall ever seeing active (even in editing) since I have been here. To me it seems odd that such people would still be considered Admins. To me if there is no trace of editing or admin-ing for a lengthy time, the title should be revoked. Now possibly those people who were once admin could always do a fast-track RFA to get it back if they wanted to, but having an admin list which only has 3-4 of 9 admins appearing in some sort of regular fashion seems strange to me.
- I get that one trusted with admin will be trusted as admin for a long time but after a while it seems like the name is just there to collect dust and the title 'admin' becomes just an empty statement associated with them (at least for me who has never even seen them at work).
- I personally don't know of anywhere else that holds things like this, any group I've seen with a long inactive admin/mod has eventually had the rights stripped (possibly to be re-given later if needed). It doesn't do any harm mind you, just seems... odd. -Darqam 01:20, 23 April 2017 (UTC)
- I fully agree with Darqam concerning the question of meaningfulness of retaining sysop rights after prolonged absence and/or inactivity. Sure, an inactive administrator has been elected at one point, and their trustworthiness is out of question (although if I remember correctly I think I did stumble upon some discussions about someone who, after coming back after a longer hiatus, acted a little wilfully if not out of line), but it shines a bad light on the wiki if we are wishy-washy when it comes to removing people that no longer make an effective use of the rights they earned because of their initial qualifications. Think of it along the lines of "Do, ut des" (I give that you may give). If you cannot or will not make use of the privileges granted, you should not have them — or rather, you do not need them. Period. A bit of strictness, but more importantly consistency (both achieved through regular reconfirmations, and the related consequence that sysop rights will be revoked if you are inactive for an ungodly amount of time), will enhance the position as an administrator and render it somewhat more "important" and "relevant" — not just an empty title or "statement" as Darqam points out. It enforces your position if you have to "prove" yourself occasionally. People will respect you a lot more.
- Regarding the recurrence of reconfirmations, I concur that having them every six months is insane, even every two years (as the failed policy proposal proposed) is too often. Every five years might be too infrequent though. A lot can change in five years, and people are most likely to forget along the way. I would suggest reconfirmations every three years, since it seems like a fair amount of time to gather enough feedback and if we assume that the average core editor might be invested for three years before moving on, we have a good mix of old and new community members to feedback the administrator adequately. A bout should not last longer than two weeks with an additional week if no consensus can be reached. A month seems awfully long. Short bouts can only work if we advertise enough though. Apart from a site notice, threads on reddit and the forums and info posts via the official social media channels might be in order. These advertisements would need to cover the meaning of reconfirmations, the rights of editors and target audience, and the general schedule though. As Greener said, reconfirmations should not end up in a 'Yay'-or-'Nay'-Battle, candidates and participants need to be briefed accordingly to ensure the purpose of gathering feedback (and introducing the administrator at the same time to people less familiar with the wiki) is fulfilled. talk 12:34, 23 April 2017 (UTC)
- I agree with what's been said. This could definitely serve as a way of gathering feedback on what we, as sysops, are doing - how it's perceived, how we can improve and such. I wholeheartedly support the idea. —Ventriloquist 13:30, 23 April 2017 (UTC)
- Regarding the recurrence of reconfirmations, I concur that having them every six months is insane, even every two years (as the failed policy proposal proposed) is too often. Every five years might be too infrequent though. A lot can change in five years, and people are most likely to forget along the way. I would suggest reconfirmations every three years, since it seems like a fair amount of time to gather enough feedback and if we assume that the average core editor might be invested for three years before moving on, we have a good mix of old and new community members to feedback the administrator adequately. A bout should not last longer than two weeks with an additional week if no consensus can be reached. A month seems awfully long. Short bouts can only work if we advertise enough though. Apart from a site notice, threads on reddit and the forums and info posts via the official social media channels might be in order. These advertisements would need to cover the meaning of reconfirmations, the rights of editors and target audience, and the general schedule though. As Greener said, reconfirmations should not end up in a 'Yay'-or-'Nay'-Battle, candidates and participants need to be briefed accordingly to ensure the purpose of gathering feedback (and introducing the administrator at the same time to people less familiar with the wiki) is fulfilled. talk 12:34, 23 April 2017 (UTC)
Pointless tbh. Reconfirm if an admin is out of line. There's no max number of sysop slots - Gares or Infinite being afk doesn't rob someone of the ability to become an admin. The admin team isn't inherently weaker because some are AFK. The list is already color coded to give a hint that they're probably not the best people to contact in case of "wiki emergency."
RfA process is easy enough - create page, discuss. Everyone has a voice. Stupid comments can just be ignored. Bureaucrats make the call. The recent RfAs have been slow as shit because of wiki lethargy.
To make a long story short, we (the admin team) were bracing for a huge wiki population explosion with the launch of GW2 - I figured if GW2 was even a fraction of as big as WoW, we'd have tens of thousands of new editors. That never happened, though, so the admin team that had dreamed of being able to step down and pass on the torch is still around. Majority of the admin/bcrat list are carried over from GW1/GWW wikis. Talk about the community changing all you want, but recent changes is pretty much still the same. The "power users" tend to remain for years and years, and while tenure doesn't amount to shit by itself, typically it means everyone is on the same page - we don't have to have the same conversations over and over again. If a dinosaur admin is very obviously out of touch with a community that changed under their noses, a post on their talk page is generally enough to jar them awake.
But really, small wikis don't change all that much. A big part of what I fought against on this wiki was pointless bureaucracy, policies and red tape. We don't need exact rules to follow with regards to things like RfAs or reconfirmations - and we definitely don't need arbitrary timed reconfirmations. If there's a problem, fix the problem. Talk to the admin if he's wrong about how things are. Start a reconfirmation if you've tried that and he still doesn't get it. But right now it seems like you're proposing solutions to a problem that doesn't exist. Would it make you feel better if the inactive admins were just hidden from the list? -Auron 10:53, 24 May 2017 (UTC)
- Four years should be long enough to say "this dude died or does not care enough to return". It serves no benefit to have inactive admins on the list, and weakens the argument of nominating further admins. ("We have enough admins" is the 100% bingo card on any admin election related discussion). However, I don't think it should require a reconfirmation to remove them, just remove the rights and notify them on their talk page that they're welcome to have them back if they ever return. -Chieftain Alex 17:44, 24 May 2017 (UTC)
- "We have enough admins" is precisely the kind of stupid comment that will already be ignored by bcrats, Alex; it's not the 100% bingo card at all. Anyone who makes that argument clearly doesn't understand the process or the system. Every RfA is judged purely on its own merits; every candidate has a chance to get promoted regardless of any other candidates or the admin list. Are they good? Badge them. Are they lacking? Don't. "We have enough admins" has rarely played into the bureaucrat decisions on this issue, all the way back to GWW and even PvX. The wiki can never have enough good admins - that has never been a problem in the history of these wikis.
- We lost a GWiki sysop to cancer some time ago. It was a simple bcrat action to demote. Didn't need a reconfirmation. If a person is completely inactive and has no intention of returning, our standing bcrats can contact them and make that call - then simply demote. At no point in this process do we need a reconfirmation simply for time gone by. The point of a reconfirmation is to judge community support of the discretion of a user to use the sysop tools for the benefit of the wiki. I agree that 4 years is long enough to say "okay, come back or be demoted," but again that's a bcrat job, not a reconfirmation hearing. -Auron 02:03, 25 May 2017 (UTC)
- Reconfirmation is impossible in the first place. Most of our active users currently do not and will not know who those admins are or the origin of their adminship. Anyone coming on since the release of the game had to accept quid pro quo for the roster of admins and bureaucrats out of necessity. We have to rely on the beauracrats to vouch for returning admins.
- The main reason you want to remove rights is to prevent malicious usage of dormant admin accounts. They can be reinstated later as Alex said and I was under the impression we already do it that way.--Relyk ~ talk < 19:04, 24 May 2017 (UTC)
- Reconfirmation is absolutely possible - in fact, we've already done it once. We did a wave where every carry-over sysop and bcrat was asked to start a reconfirmation, and a fair number of them simply declined and stepped down. A couple more were de-sysopped or de-bcratted. The origin of an individual's adminship is largely irrelevant to the question a reconfirmation is supposed to ask - are they still qualified to use the sysop tools fairly and with impartiality? Long-time sysops have returned after a break and done terribly - Karlos and Tanaric are examples. That's the kind of situation reconfirmations are there to address. Their views were at odds with the community's views, and they no longer held the wiki's best interests at heart. They had to be removed from power.
- Like I already said in my first comment, all of the admins were planning on stepping down when GW2 took off. We wanted to pass the wiki on to a new group who could mold the wiki to fit their needs. We'd stick around to serve as advisers and gurus, but 10 years of wiki adminning takes its toll. It's not like Tanetris is holding on to this wiki with an iron fist. If people want to be admins, they are absolutely free to run. We got a ton of comments on Doodle's RFA, and while several of them were hilariously stupid or missed the mark, it got the community involved in a way they haven't been in years. That's the first step. Now we can educate them and equip them for future success. -Auron 02:03, 25 May 2017 (UTC)
- To jump in here and address Auron's last few points, I've been mulling over User:Greener/Sandbox4 for some time. I'm still not happy with it, but I'll explain how I'd like to see it work.
- First, it's an informal process. I'll stress it again: informal. There's no need for this to be a stand in for an RfA or anything. If it were to try to be formal, it would fail from the get-go.
- I see it existing in an admin's user space, and want to leave the naming up to the admin (e.g. User:Ventriloquist/Community Outreach or User:Chieftain Alex/Hidey ho neighborinos).
- A banner on the wiki to reach out to the community at large.
- Voluntary buy-in. I see no point in anyone starting such a page if they're not up for it, and zero judgments passed.
- Full control of how it works, how it appears (as I've written it or totally revamped), and for how long it goes is in the admin's hands.
- I know that there are a lot of contributors out there who would be willing to invest themselves even more in the wiki if they understood what goes on here. I'd like to pique their interest.
- As for public RfAs for absentee admins, I cannot see a good way to do it for one very big reason: We don't have a community that's well educated on the topic. Asking them in their current state to make decisions on something they know little about is silly. It would be like asking me to make decisions on health care spending: I know it's important; I know nothing about it; You shouldn't expect solid decisions to come from me. G R E E N E R 09:04, 25 May 2017 (UTC)
- isnt that what their user talk page is for? -Auron 12:29, 25 May 2017 (UTC)
- Absolutely, but that's like the difference between giving someone their local politician's office number, and inviting them to a town hall meeting. Both are good, both are useful, but the latter is reaching out and inviting community participation at a larger scale. G R E E N E R 15:17, 25 May 2017 (UTC)
- Admins are not politicians, and treating them as such is likely not a positive for the wiki. - Tanetris (talk) 16:42, 25 May 2017 (UTC)
- Oh goodness, I didn't mean to make that implication. I was simply drawing a parallel between passively waiting for feedback from individuals vs. actively looking for it from a group. G R E E N E R 17:00, 25 May 2017 (UTC)
- Admins are not politicians, and treating them as such is likely not a positive for the wiki. - Tanetris (talk) 16:42, 25 May 2017 (UTC)
- Absolutely, but that's like the difference between giving someone their local politician's office number, and inviting them to a town hall meeting. Both are good, both are useful, but the latter is reaching out and inviting community participation at a larger scale. G R E E N E R 15:17, 25 May 2017 (UTC)
- isnt that what their user talk page is for? -Auron 12:29, 25 May 2017 (UTC)
- To jump in here and address Auron's last few points, I've been mulling over User:Greener/Sandbox4 for some time. I'm still not happy with it, but I'll explain how I'd like to see it work.
(Reset indent) I sadly cannot find the time to write an elaborate response that addresses all new comments at present, so I shall keep it brief for now. I mentioned this to Greener earlier; I support the removal of inactive administrators without further ceremony if that is how it can be done. Reconfirmations for these would more or less serve more of a courteous purpose if anything in either case. Concerning Greener's suggestion, a too formal approach to this administrator spotlight and the gathering of feedback as well as the engaging of the community might be turn out as not feasible. For the sake of consistency, transparency, and accessibility though, I would suggest to treat this process as a community project with its respective page. This way we can collect current and future rounds of these "spotlights" in one place instead of spreading them out over several individual sandboxes, which might end up buried. talk 18:41, 25 May 2017 (UTC)
- It absolutely can exist under Guild Wars 2 Wiki:Projects rather than in an admin's user space. My suggestion isn't the only way we can get the community more engaged, either. What would the admin team feel comfortable with if asked to educate the new guard? G R E E N E R 06:24, 26 May 2017 (UTC)
- The main reason why I think a (at least) quick post when an old admin wants to come back (and presumably get back their powers) is because I could see the following scenario happen easily. Say over the next few months, for whatever reason Alex and Ventriloquist decide they can't maintain their presence on wiki and have to stop being present. Doodle, and possible 2 other new admin, would now be the last remaining active admins. Now if one of the "old guard" comes back; none of these admins may have EVER even seen an edit from this admin, much less an administrative action/decision. Sure poke and tanetris might remember them and their actions back then, but the active team would not. To me this would not be alright both from a sentiment of trust and understanding within an admin team; but also as a regular editor I would be a bit weary of an admin coming back from the dead and resuming activity with not so much as a 'heya I'm back'.
- I'm aware the argument isn't particularly strong, and is more on the domain of personal feelings and impression; but to me if I don't feel I can trust an admin I can't say that I'd want to stick around for very long. With the current set I know very well what's acceptable to say or not with them, if I can joke or not about a mistake they made or if I can undo an edit they made without possible sermons on my talk page. No I don't know that older admins would be bad, but I don't know that they aren't either. I really do think that a formal or informal 'I'm back, here's who I am, ask me questions' post is needed if you want to come back from inactivity. Whether or not giving back admin roles is tied to what is said in the thread I'm not certain where I stand, but the thread should exist imo. -Darqam 13:51, 26 May 2017 (UTC)
- We don’t expect that behavior from regular editors who come back from a hiatus, and it would be ridiculous to do so; just like we don’t require new editors to introduce themselves or otherwise prove that they are accustomed to the wiki rules and guidelines. I think you are all interpreting a bit too much into the reponsibilities of the administrators here. Unlike what the general public appears to think, the admin team is not resposible for how the wiki works and develops, and they certainly don’t have a special say in any discussion. Even this very meaning of the administrators isn’t set in stone because theoretically the community could just decide to revolutionize the whole system and for example introduce a BDFL ruling about everything instead.
- Of course, administrators are assigned with community trust and given their extra powers, it’s done for a good reason. But think about what those tools actually are: None of these can actually cause any real harm. All their actions can be easily undone and cannot do permanent damage. The two “most harmful” actions are deletion and user blocking, and both of these are undone just as quickly. By saying you cannot trust inactive admins that were appointed before your time so you couldn’t build up trust yourself, you are also saying that you do not trust the current admin team to take care if anything ever happens. Do you really think any of the active admins—or actually even just any regular editor—would just stand there and watch when an inactive admin comes back and does something wrong?
- Also, assume good faith! Inactive admins were trusted by the community back when they were appointed; that should give you a good enough idea that they are not terrible people. They were usually well-trusted editors who had proved that they are capable of working for the wiki. I highly doubt that any one of them would just start doing irresponsible things when they decide to come back. It’s a lot more likely that they would be especially careful with their actions, especially if it involves using their admin tools. If my voice means anything, then I can vouch for that, since I have been around long enough to know and remember all of them (this is even true on GWW). And I’m sure Tanetris feels similar here.
- And as Auron said, the community isn’t actually changing that much. Sure, the active editors change eventually, but the overall spirit is still pretty much the same. So to me, trusted by the community back then has the same meaning as trusted by the wiki community now (ignoring those randoms on the RFA). poke | talk 23:05, 26 May 2017 (UTC)
- Sorry poke, but you and Tanetris seem to be ignoring that these three old sysops have chosen not to contribute for such a prolonged period of time that virtually none of the currently active userbase have witnessed any edits by these old sysops, which to me means that they have no mandate to be administrators. Remove the damn rights from the dinosaurs and be done with it. -Chieftain Alex 23:56, 26 May 2017 (UTC)
- Ah, but they also haven't witnessed any abuse of powers by those old sysops. No harm no foul. - Felix Omni 06:44, 27 May 2017 (UTC)
- Yeah, I'm not understanding what the hangup is. Them being admins has no bearing on us picking new admins. They aren't taking anyone's spot. I haven't really heard any arguments with merit in favor of taking away their admin, it's just "but it's been so long." Yes... yes, it has. And it still doesn't really matter. Have they become worse admins in that time? Is the specter of the threat of someone losing their account and "going rogue" really such a concern? I don't think it's happened once on any of the GW wikis going back to GWiki. And like poke said, even if it did, it would be easily reverted. The wiki isn't suffering because Gares and Infinite are on the admin list. Get real. -Auron 10:03, 27 May 2017 (UTC)
- Ah, but they also haven't witnessed any abuse of powers by those old sysops. No harm no foul. - Felix Omni 06:44, 27 May 2017 (UTC)
- Sorry poke, but you and Tanetris seem to be ignoring that these three old sysops have chosen not to contribute for such a prolonged period of time that virtually none of the currently active userbase have witnessed any edits by these old sysops, which to me means that they have no mandate to be administrators. Remove the damn rights from the dinosaurs and be done with it. -Chieftain Alex 23:56, 26 May 2017 (UTC)
(Reset indent) You are right. The wiki isn't suffering because two inactive administrators are on a meaningless list. The wiki is suffering because there are more inactive administrators than active ones, though this is just one of many reasons why it is never progressing. And there aren't just two inactive administrators either. I consider ghost administrators that are out of touch with the current community and rarely ever actively work alongside it as inactive. Even if "theoretically the community could just decide to [revolutionise] the whole system", this is frankly not feasible. We can never reach a consensus with how things are right now. You (the inactive administrators) form a majority. The active ones (admins and non-admins) barely have anything to say apparently, not to mention we are the minority. The wiki is ruled by an old order that opposes changes. Don't you think it's hilarious how you suddenly resurface to oppose suggestions that might endanger your positions? I think that already says a lot.
"I haven't really heard any arguments with merit in favor of taking away their admin, it's just 'but it's been so long.'" — I haven't really heard any convincing counter-arguments so far either, apart from "oh, they've been around for so long, and some people who are long gone now voted for them years ago, so it's all good and dandy, right? Besides, if they aren't present, they can hardly do anything bad and they surely won't cause any damage if they come back one day".
Maybe we should resort to reconfirmations for all of the inactive admins after all, if that is the only way we can achieve something. "Reconfirm if an admin is out of line", nowhere does it state when a reconfirmation might be in order, by the way. By that logic, we can have reconfirmations if the community thinks an admin is out of touch, too. talk 11:48, 27 May 2017 (UTC)
- “The wiki is suffering because there are more inactive administrators than active ones” – citation needed?
- “You (the inactive administrators) form a majority.” – What?! That’s just a ridiculous statement. Not to mention that consensus isn’t based on a majority voting.
- “The wiki is ruled by an old order that opposes changes.” – Sorry, but statements like these come close to fearmongering. And it just makes me believe that you also do not understand how this wiki is run and what role administrators have here. If you really believe what you say, then please show me actual examples from the past of situations where the opinion of an administrator actively hindered you from improving the wiki. And please make sure that in those examples, those administrators acted in their role as administrators instead of a regular editor.
- “Don't you think it's hilarious how you suddenly resurface to oppose suggestions that might endanger your positions?” – Did you ever consider that people are not gone just because they are quiet? Also, no, after eleven years on the wikis, I don’t really feel endangered at all. I’ll gladly give up my position if the wiki community finds suitable replacements. At the moment, with the active administrator list being short and the community being rather thin, I don’t see that happening in the near future, so I’m sticking around.
- One argument I’d like to mention for keeping the admins on the list is chance. There is always a chance that a user from the past returns and find themselves in a position where they can do something useful. That applies to both administrators and users. We do not purge user lists, or remove the autoconfirmed status once a user goes inactive. Proven in the past is an actual thing we use for more than just retaining the user rights. If I see a user I don’t recognize doing odd stuff on recent changes, I can look at their past contributions. If I see that they have a track record of doing edits, I am more likely to trust their work—regardless of when those changes were. To me, trust does not go away by time. It might become more sensitive to changes, but it won’t change just by time. poke | talk 13:17, 27 May 2017 (UTC)
- "The wiki is suffering because there are more inactive administrators than active ones" Blatantly incorrect. What is this even based on?
- "though this is just one of many reasons why it is never progressing." That's odd - sysops actually have no additional say in "progress" of a wiki. We don't police content. We're just here to make sure the kids all play nice in the sandbox, and to scoop up the kitty litter once in a while. If the wiki isn't progressing, look to its community, not to its janitors. In what ways is it not progressing? In what ways is the group of people responsible for deleting unused pages or blocking hostile users responsible for that lack of community progress? In what ways are they holding back said progress?
- "I consider ghost administrators that are out of touch with the current community and rarely ever actively work alongside it as inactive" Cool, but irrelevant. Your argument seems to be closer to a personal judgment rather than one based on anything they actually say or do. If they can come back from a year break and provide a more solid argument than yours, it doesn't mean their argument is somehow less valid, or that yours is more valid. Their break is essentially irrelevant to their comment. Focusing on it is, at best, a red herring.
- "We can never reach a consensus with how things are right now." We've barely started. The only thing that's changed since I went "inactive" is that people seem to think they can get their way by raising their voice, apparently ignoring what the word "consensus" means. You know what "consensus" we've already reached? That Gares and Infinite are inactive, and the wiki doesn't benefit from their continued sysop flags. The community brought it up, we discussed, we agreed, and action was taken.
- "The wiki is ruled by an old order that opposes changes" lmao, I'm having flashbacks. are you yoshida keiji or whatever from gww?
- "Don't you think it's hilarious how you suddenly resurface to oppose suggestions that might endanger your positions?" None of the admins commenting here see sysophood as anything other than a burden. It's not a badge of honor, it's not a symbol of great worth. It's an obligation to serve. We serve the community - not the other way around. This isn't some secret cabal oppressing the common proletariat and keeping him down. That doesn't even make sense. We have nothing to gain by doing that, nor have we ever tried.
- "By that logic, we can have reconfirmations if the community thinks an admin is out of touch, too" Yes, that's literally what I said already. -Auron 14:02, 28 May 2017 (UTC)
"Opinions are probably always going to be mixed on whether an inactive admin should remain an admin" - me, this discussion, a month ago.
There is a line between lively debate (a good thing) and banging one's fist on the table yelling 'do it my way' (Alex, I am looking at you; dial it back). Everyone here (Inc, Poke, Greener, Darqam, Alex, me, and yes even Auron) wants the wiki to continue to function smoothly and to grow. We're all on the same side here, so let's remember that, yeah?
To the actual issue at hand. I said a month ago that based on Infinite actually explicitly quitting years ago now, it probably does not serve any function to maintain his sysop tools. Based on a lack of response to e-mails to Gares in the month since... I'm going to say that we also need to accept he's not coming back at this point either, so it doesn't serve any function to maintain his either. As such, I've talked this over with Poke and I'm removing those two from the sysop list. Not because there are cries for inactive admins' blood or to 'free up space' on the admin list, but because of the circumstances of these two individuals specifically in which this decision makes the best sense.
As for Jon, it's only slightly over a year since he last used his admin tools, so I'm not at all convinced he's the same situation. That being said, Inc, you are correct that there is no reason the community can't call for reconfirmation based on believing an admin is out of touch. If you want a reconfirmation for Jon on that basis, I'll certainly be curious what consensus comes up with. For that matter, if you want a reconfirmation for me, I've already said I'm open to one and I stand by that.
I've talked to Greener a bit in private to clarify my thoughts on his 'Get To Know the Admins' project idea, but I think it's worth repeating one of the most salient points here for its relevance to the rest of the conversation: admins are not in charge. Despite the notable overlap between wiki community leaders and admins, being a wiki community leader is not a requirement for adminship, and adminship is not a requirement for being a wiki community leader. Non-admins deferring to admins in non-administrative matters just because they're admins is something we actually actively try to discourage. When I chime into a content discussion, I don't want you to bow to my will because I'm a bcrat; I want you to bow to my will because I have the better idea and make my case for it well, or you to make me see why your idea is the better one or come up with another idea that's even better than either one.
So that's my piece on this for the moment. I'm gonna go remove Infinite's and Gares's sysop rights now. Feel free to continue discussing the rest, though let's make sure we're doing so in a civil and reasoned manner. - Tanetris (talk) 15:00, 27 May 2017 (UTC)
- I would be happy with reconfirmation as Auron describes it, with primarily looking at sysop tool usage and an evaluation down the road. I never saw abuse of sysop tools or contributions, so I'm not familiar with those concerns as part of reconfirmation. As far as Incarnazeus's comments, I have made those same arguments in my head but the arguments end up being a red herring and doesn't lead to fruitful discussion. I will say that admins have very little presence in contributions and consensus. That's very much on purpose in feedback I've gotten back. As Tanetris said, a majority of the changes have been made by consensus of regular users and community leaders. I can check that by looking through my newsletter.--Relyk ~ talk < 16:35, 28 May 2017 (UTC)
Temporary, Historical, etc
I'd like to make how we mark where something came from and it's status a lot simpler and cleaner. Currently NPC/object/event that were part of past releases currently can only be shown as such by having a {{temporary|Release name}} on top. Of those that use that and aren't reoccurring seasonal content, a good portion of those infobox status were never edited to mark they were historical. However, if in NPC/object/event was marked as historical, such as Champion Toxic Wurm Queen, they have two banners on the top and are categorized twice on the bottom as being both Historical and Temporary content, which can be confusing and redundant. Now that we have Template:Infobox release, I think we should use that to mark which past release the page's content came from and have the release template categorize if something is historical or not. Additionally, I'd suggest making a template just for release banners so that that Infobox release template could pull from there and not Template:Temporary, so basically the Temporary template can really just be a banner/notice template for seasonal stuff. That way simply sticking the release in the infobox means the status will always be correct, no need to write it in the infobox, it gets put into one category(or so I hope), and the nice banners for past releases still get to be used, ie no double boxes at the top, since the box saying "This content was only available during X Release" is essentially just a prettier historical notice tag. Any thoughts? - Doodleplex 03:45, 26 April 2017 (UTC)
- To me temporary implies that the feature will return and historic implies that it’s not coming back. If we can agree on that definition then we can start labeling things properly. Reoccurring events like wintersday and SAB will be temporary and living world season 1 will become historic. J.Tesla (talk) 21:21, 26 April 2017 (UTC)
- Good point, and yeah that's what I think as well in regards to the definition of those two words. - Doodleplex 23:36, 27 April 2017 (UTC)
- I've mentioned my opinion on this before:
- I'm not fond of the use of the historical template via infoboxes removing categories (makes it hard to search for Season 1 content; only way to do so is by knowing the name of the content in search box or navigating an ever-growing list of Category:Historical content, since automated lists search via category).
- Now that Living World content is no longer temporary (the original purpose of the temporary tag being to separate it from purely removed content) I don't think that the temporary template is necessary anymore at all.
- And I don't see much need for a banner at the top for festival content (simply having a line in infoboxes akin to GWW's Campaign parameter for infoboxes detailing which festival would suffice). It'd also be nice if we can use this or a similar line to include when it was added for Living World content, but I don't think it's entirely necessary; I think just denoting which season or boxed release would be sufficient (so core, Season 1, Season 2, Heart of Thorns, and Season 3 as it stands).
- Ultimately, banners are obstructive. They're useful for notice and maintenance templates, but feel unneeded and overplaying for festival or Season 1 content. Konig (talk) 23:48, 27 April 2017 (UTC)
- You'd be wrong about the temporary template. It's purpose as a notice template is to mark that some things only have a limited time frame, so yes it is still necessary for at least for seasonal content like Halloween and festivals such as the Super Adventure Festival. If you have some other definition of what is temporary though, then please say so, as that's one of the things we're trying to figure out here. Additionally if we stopped using the release banners for the season 1 content, those pages would still have the historical content banner on top which is larger and bulkier. Simply moving the smaller, slimmer release notice banners to the historical content template(not really sure if that would work though) or a new template and changing the text on them to say "historical" would actually be less obstructive and better at relaying information about why that content no longer is in game. The question remains, should we use the Infobox release template to make tagging historical release stuff easier, is there a better way, or leave it alone? - Doodleplex 02:36, 28 April 2017 (UTC)
- Good point, and yeah that's what I think as well in regards to the definition of those two words. - Doodleplex 23:36, 27 April 2017 (UTC)
- The way I see it we end up with two types of page:
- Historical content that will not return and was only available for a release. This should use
status = historical
. A sentence at the top of the article would be sufficient to describe which release it was there for. We can add a category for release-only content using the infobox. The temporary template should be removed, resulting in only the historical notice. - Currently historical content that will return. Imo this type of page should not use the historical template, and maybe should use the temporary content template. Again we can add a category to group it with similar content.
- Historical content that will not return and was only available for a release. This should use
- -Chieftain Alex 06:38, 28 April 2017 (UTC)
- I was actually thinking about doing the category thing for the season 1 stuff, so good to know I wasn't the only one with that idea, and the Temporary template actually already categorizes the seasonal stuff into the relevant season's category, so that's already a thing heh. Since so far it seems like the generally accepted definition of temporary and historical is how Telsa said it, we can start working on the how to clean this up. Did a little checking, and of the almost 500 pages that use the Temporary template(well a little less, cause I excluded seasonal/SAB stuff that came back), half of the pages that should have been marked as historical, weren't. It would actually be more than half, but during my current quest to fix all of the old dialogue formatting and add locations to NPC pages, I've already gone through a good chunk of historical release NPC/events/objects that only had the temporary tag and marked them as historical. This is more or less why I'm bringing it up, I think if we use the banners we have already, move them to a new template and just tweak them slightly/have them categorize stuff as historical, then set up the release page for the old releases and to use the banners, it would be an easy 1-Step way of leaving a notice at the top and tagging things as historical: just put the release in and the rest is done. I'd love to do the same thing for temporary, but that I'm not sure how that would work code wise. Just for comparison by the way for the historical banners, I did a mockup on my sandbox page.
- This in my opinion:
{{User:Doodleplex/Sandbox 7|Last Stand at Southsun}}
- ...is a lot more appealing on a page than this:
- Text is always changeable. - Doodleplex 22:42, 28 April 2017 (UTC)
- I meant the introductory sentence outside of any template at the top of the article. -Chieftain Alex 22:51, 28 April 2017 (UTC)
- I don’t think Template:Infobox release should set if something is historic or not; I think it should just be for categorising releases and add a link to the page for the release in the infobox somewhere and leave "status =" to set historical or current. My reasoning is that not everything introduced in a historical release is historical. Items stick around and so do some events. I do like the image that is used in the temporary template (especially the version that gets pulled from the release page with the intractable text). It seems a waste not to use that somewhere but sometimes a simple line of text can work better. J.Tesla (talk) 22:43, 29 April 2017 (UTC)
(2)
Okay I've added a "status notes" parameter to every infobox (as well as removing the old "historical" parameter). This parameter allows you to pass notes to the historical template. I propose we do something like this to all of the permanently-gone-content. My intention is to only leave the "temporary" template on recurring content (halloween, wintersday, lunar new year, SAB). Everything else would be converted to status=historical, temporary notice removed, a note added inside the infobox using "status notes", and a category added to the bottom of the page.
The picture in the temporary template is nice and all but imo if the content is historical I'm expecting gone-quaggan. -Chieftain Alex 21:36, 30 April 2017 (UTC)
- Eliminated quite a few pages from the to-do list, some non-recurring stragglers visible on Guild Wars 2 Wiki:Sandbox. -Chieftain Alex 22:54, 1 May 2017 (UTC)
API links on skill pages
What happened to these? They were really useful when I was double checking and fixing coefficients :B -Towelcat (talk) 10:02, 28 April 2017 (UTC)
- This happened. You can, however include this on your common.js page (like this). —Nefastu 10:10, 28 April 2017 (UTC)
Bounty system
I've been wondering this for a while now. Similar to StackExchange's Bounty system: http://stackoverflow.com/help/bounty. Would it be possible to create a page for bounties that players would like to see completed? I know that Dashface has their specific page for articles needing more information. But say if someone else wanted to see an article completed, then they can award gold/mats/etc. to the person who completes it. Naturally of course this would have to be based on the goodwill of the person posting the bounty, but nevertheless I doubt it would be abused. Sythe 14:17, 29 April 2017 (UTC)
- I like this idea. -- Dashface 06:58, 7 May 2017 (UTC)
GW2Armory Embeds for the wiki
Hi,
This is to start a discussion to see if you guys would be interested in using the embed system made available by gw2armory.com, see: https://gw2armory.com/embeds/example/index.html
Currently being used by metabattle.com and qtfy.eu (and a few other smaller sites) - I think it would be pretty neat if it made its way into the wiki.
Let's talk?
Cheers, madou
- It's neat, but I don't think the wiki would have a way to use it since this seems aimed at build sites. It would also be way more of a hassle compared to implementing the formatting ourselves since we already have all the information available.--Relyk ~ talk < 00:18, 3 May 2017 (UTC)
- Well, I'd like to think its aimed at any site that would like tooltips (or armory characters)! You're not wrong I guess - the main difference here is how the data would be presented - I kind of think having both (hover over icon - see tooltip, click through - see more information) kind of a neat feature. There also was a comment about potentially getting character embeds on user pages (see: https://www.reddit.com/r/Guildwars2/comments/68vw84/flashpoint_devs_here_ask_us_anything/dh1vrj5/), thoughts? Cheers, madou --Madou (talk) 00:28, 3 May 2017 (UTC)
- As requested, I'll add my opinion here. Maybe I fail to assess the impact correctly but as Relyk said, we do have all the information you can possibly collect from the API for items, traits and skills (I acknowledge the holes in items where no one has bothered to create an article yet) so it would be a step back to replace this information and redundant to get it additionally. We also do have an interest in keeping the information up to date, not just since the Skill History project. I suggested a character embed on user pages because I think thats the only place where I see only benefits and consider this introduced dependency as negligible. --Soulblydd (talk) 08:01, 3 May 2017 (UTC)
- Yeah fair enough - do note though that I'm not saying the tooltips would replace the data, but would just be an additional feature, that any page linking to an item etc could have the icon as an armory tooltip, that you can click on to go to the actual wiki page for said item. But I won't press if you think its not worth it. Let's work on allowing character embeds on user pages then? Anything I can do to help? Fyi there also exists a "custom" embed where any user/character/guild data can be retrieved as an embed, but that still needs work before use in production. --Madou (talk) 09:17, 3 May 2017 (UTC)
- Tooltip boxes would only be used for compacting information since we provide information in a tabular format and tables tend to get too large. A tooltip box would be overkill or annoying for most content. This would only apply to specific tables we have and the wiki provides information outside the scope of the embed or what any third party could provide really. We would suffer from content lag due to not being in control of the content, such as the wiki being updated quickly with new content and immediately available but having to wait for the armory site to update.
- For user pages, people can do whatever they what with their common.js and wouldn't need wiki support. For the wiki to provide the service, we would need to create and maintain a widget along with the burden of monitoring and securing content from a third party. It's not worth the resources for something that would only be used for user pages and doesn't provide any benefit to the wiki itself.--Relyk ~ talk < 15:48, 3 May 2017 (UTC)
- Yeah fair enough - do note though that I'm not saying the tooltips would replace the data, but would just be an additional feature, that any page linking to an item etc could have the icon as an armory tooltip, that you can click on to go to the actual wiki page for said item. But I won't press if you think its not worth it. Let's work on allowing character embeds on user pages then? Anything I can do to help? Fyi there also exists a "custom" embed where any user/character/guild data can be retrieved as an embed, but that still needs work before use in production. --Madou (talk) 09:17, 3 May 2017 (UTC)
- As requested, I'll add my opinion here. Maybe I fail to assess the impact correctly but as Relyk said, we do have all the information you can possibly collect from the API for items, traits and skills (I acknowledge the holes in items where no one has bothered to create an article yet) so it would be a step back to replace this information and redundant to get it additionally. We also do have an interest in keeping the information up to date, not just since the Skill History project. I suggested a character embed on user pages because I think thats the only place where I see only benefits and consider this introduced dependency as negligible. --Soulblydd (talk) 08:01, 3 May 2017 (UTC)
- In theory we could do it via a widget for userpages only, but really, as said above, we can generate most of this information locally (we have more stuff documented about gw2 than the gw2 API does). If players really want to use armory, they can visit your site no? -Chieftain Alex 16:56, 3 May 2017 (UTC)
- As others, I also fail to see a real use case for the wiki. Outside of the user namespace, this does not really seem that useful for this wiki given that we almost never present the information these sheets make available. Furthermore, as a wiki, we depend on being able to link to related articles which these embeds would not support out of the box, not to mention that those mouse overlays are rather terrible for accessibility of the content. I also worry about the duplicated information. If we had such things, they would have to load the data from our wiki content and not some outside source.
- And as for use on userpages, I don’t really like the idea of adding such a thing just to allow people to add them to their userpages. I also believe that we might hit the wrong target audience if we had a functionality like that (I remember the Guild namespace on GWW here which mostly attracted people who only cared about their guild page, ignoring all kind of rules etc.).
- Anyway, we might be able to build a simple version of this, using wiki content we get through SMW, no? poke | talk 18:30, 3 May 2017 (UTC)
- In theory we could do it via a widget for userpages only, but really, as said above, we can generate most of this information locally (we have more stuff documented about gw2 than the gw2 API does). If players really want to use armory, they can visit your site no? -Chieftain Alex 16:56, 3 May 2017 (UTC)
- I did trait + skill tooltips on this wiki back in [[User:Chieftain Alex/Templates/Skill bar|2015]]: currently we don't SMW annotate the "facts" bit on skills, traits or food. For food at least we should probably try. -Chieftain Alex 19:40, 3 May 2017 (UTC)
- We still need to semantic objects for skill facts, which hasn't been completely fleshed out. Ishmael started work on it years ago. I wanted to wait for the skill API so we could start structuring our infoboxes and semantic data to more closely much the game API. Tossing around skill fact objects is going to be similar to recipes so we'll need to be somewhat careful.--Relyk ~ talk < 21:56, 3 May 2017 (UTC)
- Tooltips for traits/food/skills would only need a very basic implementation (i.e. no searching required), we could just do a straight dump of the skill fact code unless it adds categories or some property crap... which its bound to. -Chieftain Alex 23:06, 3 May 2017 (UTC)
NPC Appearance Table?
Considering that one of the big ideas of the game is that you can replicate any NPC's appearance that you see in the game (regardless of how well that was actually achieved), I had the idea of creating a new table template to use to add that information to NPC pages. While this would obviously be added rather slowly (because it's a pain in the butt, especially dye colors), having a way to attach this information to NPCs would be a great boon to players. Here's my table idea (using Shining Blade NPCs for this example):
{| {{STDT|npc}} ! Slot !! Appearance !! Dye 1 !! Dye 2 !! Dye 3 !! Dye 4 ! |- ! Head | {{item icon|Banded Helm}} || {{dye|Sand}} || {{dye|Calfskin}} || n/a || n/a |- !Shoulder | {{item icon|Banded Pauldrons}} || {{dye|Sand}} || {{dye|Calfskin}} || n/a || n/a |- !Chest | {{item icon|Draconic Coat}} || {{dye|Sand}} || {{dye|Camel}} || {{dye|Country Teal}} || n/a |- !Hands | {{item icon|Banded Gauntlets}} || {{dye|Sand}} || {{dye|Calfskin}} || {{dye|Country Teal}} || n/a |- !Legs | {{item icon|Banded Legs}} || {{dye|Sand}} || {{dye|Calfskin}} || {{dye|Country Teal}} || n/a |- !Boots | {{item icon|Banded Greaves}} || {{dye|Sand}} || {{dye|Calfskin}} || n/a || n/a |- !Main Hand | {{item icon|Iron Sword}} || n/a || n/a || n/a || n/a |- !Off Hand | n/a || n/a || n/a || n/a || n/a |}
Slot | Appearance | Dye 1 | Dye 2 | Dye 3 | Dye 4 ! |
---|---|---|---|---|---|
Head | Banded Helm | {{dye|Sand}} | {{dye|Calfskin}} | n/a | n/a |
Shoulder | Banded Pauldrons | {{dye|Sand}} | {{dye|Calfskin}} | n/a | n/a |
Chest | Draconic Coat | {{dye|Sand}} | {{dye|Camel}} | {{dye|Country Teal}} | n/a |
Hands | Banded Gauntlets | {{dye|Sand}} | {{dye|Calfskin}} | {{dye|Country Teal}} | n/a |
Legs | Banded Legs | {{dye|Sand}} | {{dye|Calfskin}} | {{dye|Country Teal}} | n/a |
Boots | Banded Greaves | {{dye|Sand}} | {{dye|Calfskin}} | n/a | n/a |
Main Hand | Iron Sword | n/a | n/a | n/a | n/a |
Off Hand | n/a | n/a | n/a | n/a | n/a |
The big problem currently is that including a dye's name and color preview is, frankly, a pain in the butt. Included in the example I made is the *intuitive* way that it should work, as opposed to
<div style="border: 1px #000000 solid; background-color: #{{{2|D9AB95}}}; width: 18px; height: 18px; display: inline; margin: 1px;">[[File:Blank.png|link={{{1|Peach Ice Dye}}}|17px]]</div> [[{{{1|Peach Ice Dye}}}]]
just to create
Peach Ice Dye. Would that be something implementable if this was accepted?
The big challenge to implementation of this is that, as there's no way to pull a list of dyes that an NPC uses, there's an element of subjectiveness in picking the dyes used; however, I don't see this being too much of a problem, as anyone using the lists other players provide will either be satisfied with "close enough" colors or will find a more accurate color and (hopefully) update the wiki.
Krisalys (talk) 06:06, 15 May 2017 (UTC)
- I'm a big fan of the idea of listing the skins. I'm not as convinced of the value of trying to research the dyes, but I'm not opposed to it. -- Dashface 10:05, 15 May 2017 (UTC)
- We had this idea pop up before, and concluded that it's simply too much work. There's over 6000 NPCs that belong to playable races (and a plethora of undocumented ones, too). Sure, a lot of their appearances are repeated, but as it stands, it could be seen as a hefty project that would take months to accomplish. —Ventriloquist 18:35, 15 May 2017 (UTC)
- Along with the reasons Vent stated above, there's also the fact that some of the pieces some NPCs wear are not available to the players in game so the table wouldn't be accurate/complete for every NPC, and I feel like dyes could be fought over as which one is the correct. This might not be a bad idea for a User page, but I'm not a fan of the idea in a Main Space article. - Doodleplex 19:11, 15 May 2017 (UTC)
- We had this idea pop up before, and concluded that it's simply too much work. There's over 6000 NPCs that belong to playable races (and a plethora of undocumented ones, too). Sure, a lot of their appearances are repeated, but as it stands, it could be seen as a hefty project that would take months to accomplish. —Ventriloquist 18:35, 15 May 2017 (UTC)
- I wasn't thinking of it in terms of "Let's try to make this exhaustive", and more "this would be a nice thing for people to be able to add while figuring it out themselves". As I acknowledged, the dyes would be a source of contention, sure, but they're also the part that's difficult to figure out, as armor tends to be fairly easy unless it's one of those "Thaaaaat's not in the game. uhhhh" situations. Having a single resource that's even just *helpful* for it would be a great addition to the available templates, and to stave off *too* many "well you're obviously dumb" arguments, a disclaimer could be added to the bottom of the table that's just "Dyes listed are best guesses and may not be correct". I can see its primary use being for things like guards, priests/priestesses of the Gods, and so on, rather than being super-extensively added to every last NPC (though I might do a decent portion of that depending on how bored I get..... not that I have a problem with constantly making new outfits). Also, the dye name & color preview thing feels like its own valid issue; should I maybe split that off into its own suggestion? —The preceding unsigned comment was added by Krisalys (talk) at 20:44, 15 May 2017 (UTC).
- The way NPC composite/racial model info is stored in the dat doesn't specify an actual color id only the raw data (brightness, contrast, etc). So there may or may not be an actual dye available in game that is an exact match of an NPCs color. And of course, as already mentioned, their actual armor pieces may or may not be an obtainable skin id (or even have a skin id) MadMaxx (talk) 22:16, 15 May 2017 (UTC)
- I just don't consider the wiki a place meant for such information. At best it could be sorted under trivia, but even that is pushing it, imo. Also, even if we were to implement it, we'd have to be consistent and follow the formatting guidelines, but as it stands, I'm against the idea. —Ventriloquist 22:22, 15 May 2017 (UTC)
- I don't think we would ever do this because there are very, very few people interested in tabular description of an NPC appearance if they're on the NPC page. The only time I've seen us note appearance is for the weapons and armor of significant NPC characters who tend to have unique equipment. If we did want to, we would create a data dump page rather than add to individual NPC pages.--Relyk ~ talk < 22:47, 15 May 2017 (UTC)
- I just don't consider the wiki a place meant for such information. At best it could be sorted under trivia, but even that is pushing it, imo. Also, even if we were to implement it, we'd have to be consistent and follow the formatting guidelines, but as it stands, I'm against the idea. —Ventriloquist 22:22, 15 May 2017 (UTC)
- The way NPC composite/racial model info is stored in the dat doesn't specify an actual color id only the raw data (brightness, contrast, etc). So there may or may not be an actual dye available in game that is an exact match of an NPCs color. And of course, as already mentioned, their actual armor pieces may or may not be an obtainable skin id (or even have a skin id) MadMaxx (talk) 22:16, 15 May 2017 (UTC)
Very confusing
Hi, I'm a new user to Guild Wars 2, and I'd love to help out on this wikia. The thing is, this place is a mess to navigate and I have NO idea where to post general feedback comments so apologies I'm doing it here.
That's my first issue, the very confusing community lay out of this website. I tried to leave feedback on the main page but wasn't allowed? Makes no sense at all.
Second of all, your search function is absolutely horrid. If you literally type in "chak eggs", you get NO results of chak eggs AT ALL. What is wrong with the search function?
I'm very sorry if I come over as brusque, but I'm very frustrated with how long I had to look for a place to even GIVE feedback... I hope this will change a bit in the coming months. —The preceding unsigned comment was added by Derigar (talk).
- Of course you weren't allowed, the main page is a crossroads/hub of sort for the wiki, only discussion related to the maintenance of the page itself should occur there. All manners of wiki-related discussions, suggestions, questions and updates take place here on the Community portal or on the Ask the wiki a question page. As for the search bar issue, I don't really see what the problem is. I just did a quick type-in by writing "Chak egg" and I immediately got 4 results. Either you mispelled something or the problem is coming from your end. || Louise || 05:20, 11 June 2017 (UTC)
- When it comes to searching, essentially, less is more. The wiki doesn't understand pluralization. If you type in "chak egg" instead of "chak eggs" it will find Chak Egg, Chak Egg (event item), Chak Egg Sac, and Chak Egg Scrambler, because it is able to add more letters to what you're searching for, whereas none of those have the plural "s" in them, and so it won't find them when searching for "eggs". Also, when you type into the search bar, it should be giving a list of suggestions as you type, which will immediately send you to the page if you click them. If you aren't getting that it might be disabled by a script disabler extension or something in your browser --Gimmethegepgun (talk) 06:00, 11 June 2017 (UTC)
- To clarify on why the Talk:Main Page is protected versus unregistered users, historically there was an issue with it being a high profile target for linkspam robots. We have the robots under control for the most part on this wiki now thanks to improved spamfilters so we could possibly unprotect it (less than 10 spambot attempts each day compared with hundreds historically). That being said, talk pages are generally to discuss the content page, and the community portal is where we'd prefer to discuss important wiki-wide things.
- I have however edited the notice at the top of Talk:Main Page such that its clear (a) why it's protected, and (b) where to go. -Chieftain Alex 20:22, 11 June 2017 (UTC)
Tooltips
Per this revision of Guild Wars 2 Wiki:Requests for comment, User:Shena'Fu asked the following:
"Feature: tooltips of in-game objects
Request scripting capability to pop up a tooltip when user's mouse cursor hovers over a link to game objects that also have in-game tooltips, including skills, traits, items, etc. Added 11:02, 9 February 2017 (UTC)
"
Shena'Fu didn't link to any current conversation so I thought I'd start a topic here.
Personally I think this would add an unnecessary overhead to every page when it's opened, and would probably be difficult to do neatly. For templates like item icon/canonical name, we could stick the game id in the result + then follow up with an API call, but I'm not sure how helpful this would be. -Chieftain Alex 20:54, 24 June 2017 (UTC)
- To add to this, there's a similar topic above which met the same lack of enthusiasm. -Chieftain Alex 21:12, 11 July 2017 (UTC)