Wikipedia talk:Template editor/Archive 1

Archive 1

Archive 2

Password advice

On one hand, I understand that admonitions for strong passwords apply generally, but I think it is worth the reminder. Given that a compromised account could affect millions of pages with a single edit, it doesn't hurt to have a reminder.--SPhilbrick(Talk) 16:58, 17 October 2013 (UTC)

Do you mean there should be more advice than there is currently? Lego removed the bulk of it. I'd ideally like a note on leaving yourself logged-in at a machine accessible to others. Given that there's enough consensus of damage potential with this that it required a user right, I think it's rather logical that a somewhat substantial warning about security should be here beyond an offhand gesture. equazcion� 17:18, 17 Oct 2013 (UTC)

Wise template editing

The most important thing in software is testing, testing, testing. Accordingly I've adjusted the wise section to emphasis that, and make it much more concise and to the point. I removed the first subparagraph -- this still a wiki and editors should be encouraged to improve things, not leave them fossilized. NE Ent 23:52, 17 October 2013 (UTC)

This is true, but I think we should still address the matter of differing areas of expertise. I mean, if we only used Lua and didn't use parsers, there's no way in Hell I'd have been given this right, so obviously I shouldn't think this gives me free license to edit complex modules like I know what I'm doing. That's the reason I cited the +2 policy, since it also deals with giving people broader access than their abilities may allow. I'm not trying to discourage anyone from editing pages they want to improve—I'm just reminding people that they should only edit pages they know how to improve. Ent, do you think there's any way we could rephrase that sub-paragraph to address your concerns, without removing it wholesale? — PinkAmpers&^{(Je vous invite à me parler)} 16:52, 18 October 2013 (UTC)

Well, I'm sure there is, but the point is, I don't care if you don't know anything about lua (I don't either, currently), but that's not important. You've been around enough that I'm confident that if you started editing lua templates you'd figure it out enough before you started changing things. The whole protection thing was supposed to be "remove an easy way to do a lot of vandalism," not some sort of licensing bureaucracy. NE Ent 00:21, 19 October 2013 (UTC)

criteria

Way too bureaucratic. We should, at a minimum, lose:

1. The editor should have worked on the sandbox version of at least three protected templates.
2. The editor should have requested and successfully enacted at least five significant edits at protected templates.

What's important is the editor has been around long enough to demonstrate that are not here to vandalize and are not a doofus.NE Ent 23:55, 17 October 2013 (UTC)

Sounds reasonable. I think it's okay to trust admins that are curating the request page to make good decisions rather than hold them to specific rigorous requirements. And if, by some miracle, a vandal slips through, they're likely to be blocked fairly quickly. —Locke Cole • t • c 22:42, 18 October 2013 (UTC)

I've reverted the change. It's not just about vandalism, but about the disruption that good-faith but broken changes to high-risk templates can cause. It's also about the load on the job queue that results if editors make several minor changes to a highly transcluded template rather than making all the changes in a single edit. Editors need to demonstrate that they understand this and that they take an appropriate level of care when testing their edits, not just that they are not vandals. While I'm happy to change the details of the criteria, I think we need something in the granting guidelines that requires candidates to show that they are careful when editing templates. — Mr. Stradivarius ^{♪ talk ♪} 23:38, 22 October 2013 (UTC)

I also just want to note that yours isn't an uncommon view, NE Ent -- several others have expressed the feeling that allowing high-risk template editing should just be about choosing people who aren't idiots. The problem is, that's just one of several views. This right in its present form represents a sort of compromise between all the different ideals people have expressed. Also keep in mind that one need not have these specific prerequisites -- admins can and have been approving people based on other evidence. This is just an illustration of things that would show someone meets the general standard, but other things can as well. equazcion → 23:50, 22 Oct 2013 (UTC)

revocation

What's the appeal procedure? The usual discuss first with the admin and then a noticeboard (WP:AN)? Or at WP:RTE? NE Ent 23:57, 17 October 2013 (UTC)

My guess would be the admin and then a noticeboard. RTE isn't likely to get much attention especially once the implementation hubbub settles down. equazcion� 00:15, 18 Oct 2013 (UTC)

Oops, I was looking at the wrong shortcut. RTE or a noticeboard are fine I guess. equazcion� 00:18, 18 Oct 2013 (UTC)

pp-meta and pp-template

I have proposed changes for the {{pp-meta}} and {{pp-template}} templates, please discuss (especially the wording used) at Template talk:Pp-meta#Update_for_template-protection - Evad37 (talk) 04:48, 18 October 2013 (UTC)

4th criteria for revocation

I propose that it be changed from "The editor used the permission to perform blatant vandalism." to "The editor performed any blatant vandalism."

I think any user blatantly vandalizing anything doesn't hold the level of trust needed to have access to editing the kind of project-critical pages under Template-Protection. I'd hate to have users arguing that the vandalism they performed wasn't done with the use of this user-right, and thus shouldn't lose their access to it. The change may seem pointless to some but I think these early stages are the perfect time to agree on the minutiae of the policies surrounding the user-right. ☺ · Salvidrim! · ✉ 21:39, 18 October 2013 (UTC)

Seems like a no-brainer, so I made the change. equazcion → 21:47, 18 Oct 2013 (UTC)

I fixed the WP:LW link to WP:WL. --Jakob (Scream about the things I've broken) 22:02, 18 October 2013 (UTC)

*shrugs* Seemed pretty evident to me, but when it comes to policy I'd rather propose than jump in and do it, it's rarely uncontroversial. (And thanks, @King jakob c 2:!) ☺ · Salvidrim! · ✉ 22:13, 18 October 2013 (UTC)

I'm not an admin, so I can do whatever the hell I want, and people see it as taking the initiative rather than being draconian. It rocks. equazcion → 22:19, 18 Oct 2013 (UTC)

Want me to kill this red link? ;) ☺ · Salvidrim! · ✉ 22:25, 18 October 2013 (UTC)

God no :) equazcion → 22:28, 18 Oct 2013 (UTC)

Yes, life without WP:ADMINACCT is awesome. Some of us have to keep iar alive and well. NE Ent 00:24, 19 October 2013 (UTC)

Main page templates

This page currently only seems to deal with working on protected templates. Does/should it be given to those who help out with the DYK/ITN/OTD/TFA/POTD processes, as these templates are protected as well, and some users who don't often edit technical templates and modules would probably be trusted to update these. --Jakob (Scream about the things I've broken) 22:02, 18 October 2013 (UTC)

This was discussed during the RFC a bit, and more recently at Wikipedia talk:Cascade-protected items#Proposal that this page be unprotected. The problem is that the main page is cascade protected, meaning that anything on it is automatically fully-protected. There's currently no way to technically allow template editors to edit those pages without also giving them a couple of other admin abilities, which isn't a popular prospect. Some MediaWiki software development would be needed in order to make something like this happen, which I'd be in favor of with some details worked out -- but I don't think it would happen any time soon. After this user right has successfully been around a while it will probably get proposed again, I think. equazcion → 22:10, 18 Oct 2013 (UTC)

This isn't even something that software development could fix. There's literally no way to let users edit cascade-protected pages without also letting them protect and unprotect pages. Jackmcbarn (talk) 22:34, 18 October 2013 (UTC)

What if cascading protection was removed from the main page and the handful of templates transcluded there were manually protected? --Jakob (Scream about the things I've broken) 22:45, 18 October 2013 (UTC)

Cascading protection removed from main page -> 1 template accidentally left unprotected -> fixed-position vandalized. If I recall some old forum post correctly, this has happened before. Ginsuloft (talk) 01:06, 19 October 2013 (UTC)

Editnotices

Hi! If an admin involved with the template editor userright would like to complete (or comment on) Wikipedia_talk:Editnotice#Edit_request_on_19_October_2013:_Template_editors, that'd be great. Just cross-posting here due to the obvious connection. Theopolisme (talk) 01:53, 19 October 2013 (UTC)

In case the "Protected Template" protection gets put on a page outside the Template namespace...

Just curious, is anyone in the act of creating a bot or bot task that searches all of the pages that are protected with "Protected Template" protection, and then change and/or mark the pages with that protection that are not in the Template namespace? I'm asking this ... given the fact that this protection level on a non-Template namespace page would cause edit conflicts for editors ... and the fact that this protection level accidentally ending up on a page outside the Template namespace is bound to accidentally happen at some point in the future by someone clicking the wrong thing, etc. (It happens with everything at some point.) Steel1943 (talk) 05:46, 23 October 2013 (UTC)

There actually are several non-templates with this protection now, mostly for testing. And if some non-template page happens to become transcluded to a high enough degree to warrant protection, it would likely be template-protected despite it not being in template space. Besides which, I don't think this would happen often enough to create a bot task. It's about as likely as mistaken protections of other types, I would think. equazcion → 06:26, 23 Oct 2013 (UTC)

True, it might be something to consider later, if it becomes an issue. But, then again, if this protection level is implemented in some highly-visible non-template space pages in the future, then this user right might need to be renamed, eh? :) Steel1943 (talk) 06:31, 23 October 2013 (UTC)

Like the module namespace, you mean? :) — Mr. Stradivarius ^{♪ talk ♪} 07:30, 23 October 2013 (UTC)

Yeah, like that, or the user namespace. :) Steel1943 (talk) 07:41, 23 October 2013 (UTC)

@Mr. Stradivarius: I just got what you meant... go me and taking a few weeks to understand something! Steel1943 (talk) 04:12, 18 November 2013 (UTC)

Script

• User:Equazcion/SafetyEdit.js

I made this for myself and thought maybe others might find it useful. I like to use "preview" on templates and get paranoid I might save by accident.

This adds a "safety switch" when editing template-protected pages. With this installed, you have to click a check box before being able to save template-protected pages. It not only disables the Save button but also disables pressing Enter from the summary line to save. If you want to use it, add this to your common.js:

{{subst:iusc|User:Equazcion/SafetyEdit.js}}

equazcion → 05:39, 26 Oct 2013 (UTC)

Should "Template Protection" also apply to pages in the "Module" namespace?

With the increasing number of templates that are starting to be converted to Lua coding, I think it is fitting to bring up this question. I started thinking about this when I was looking at Template:Automatic archive navigator and noticed that the Lua code was on a completely different page: Module:AutomaticArchiveNavigator. When I noticed this, I also noticed it a bit odd that Template:Automatic archive navigator had template protection, but Module:AutomaticArchiveNavigator had NO protection. I have since used WP:RFPP to request full protection on Module:AutomaticArchiveNavigator; in this specific case, I would believe that template protection should apply to the protection level, but as of right now, template protection only applies to pages in the Template namespace (so I had to ask for full protection). Even though I, personally, am still trying to understand Lua, it seems one of the primary uses of the Module namespace is to create Lua code similar to/used in templates with the "#invoke" code, as well as other functions that, for the most part, should only be trusted by someone who "has proven to know what they are doing."

If anyone else wants to present ideas why this is a good/bad idea, please do so. Or, better yet, if there could be specific criteria that would determine whether a page in the "Module" namespace should be fully protected as opposed to template protected (but still have the option for both), please present it. Thanks! Steel1943 (talk) 03:40, 18 November 2013 (UTC)

I'm not totally sure, but I think we already OK'd having template protection on modules. And there's definitely no technical reason it wouldn't work. Jackmcbarn (talk) 03:43, 18 November 2013 (UTC)

Ah, looks like it was. Disregard this section. Steel1943 (talk) 03:51, 18 November 2013 (UTC)

(edit conflict) Yep, the module namespace was specified in the template editor RfC from the start. From Wikipedia:Requests for comment/Template editor user right#Proposal: "Create a new user right that will allow editors who have earned the trust of the community as knowledgeable and responsible template coders to modify templates, modules, and edit notices that have been fully protected for precautionary reasons." (my emphasis) — Mr. Stradivarius ^{♪ talk ♪} 03:54, 18 November 2013 (UTC)

Looks like it might be time to start requesting the protection level changed for some modules. Good thing I just created {{Lmd}}! Steel1943 (talk) 03:57, 18 November 2013 (UTC)

No "pink lock" in the upper right corner of template protected Module pages?

I have a sort-of related question to the section above, since I am assuming that this is part of a "MediaWiki" page: I noticed that after Mr. Stradivarius template protected Module:AutomaticArchiveNavigator, a "pink lock" with the wording when hovering over it "This high-risk module is permanently protected to prevent vandalism." did not appear on the module's page. I'm not sure what needs to be edited to fix that, but I'm assuming it is in the MediaWiki namespace. Is this fixable? Steel1943 (talk) 04:23, 18 November 2013 (UTC)

It appears automatically if you create the documentation page, via some magic in MediaWiki:Scribunto-doc-page-show. There are three more MediaWiki namespace pages that Scribunto uses as well - see mw:Extension:Scribunto/Lua reference manual#Module documentation for the list. — Mr. Stradivarius ^{♪ talk ♪} 04:33, 18 November 2013 (UTC)

Got it Mr. Stradivarius. I thought the lack of a /doc page was the key (due to patterns I have seen before, but was not sure). Thanks for the info! Steel1943 (talk) 04:35, 18 November 2013 (UTC)

Announcing edit requests for template-protected pages

You may be interested to know that we now have a new template, {{edit template-protected}}, for making edit requests to template-protected pages. These requests can be viewed at Category:Wikipedia template-protected edit requests, and can be answered by any editor with the template editor user right. There is also an annotated list of edit requests automatically updated by AnomieBOT at User:AnomieBOT/TPERTable. You can put this on your watchlist to see when new requests have been made. Editors with the template editor right are enthusiastically encouraged to help answer the requests. :) You can see guidelines for answering requests at Wikipedia:Edit requests#Responding to requests. — Mr. Stradivarius ^{♪ talk ♪} 15:19, 24 November 2013 (UTC)

Re-examine granting criteria

@Mr. Stradivarius, Acalamari, Debresser, Technical 13, and Jeremyb: @Mark Miller, Armbrust, Legoktm, Kudpung, and Sjones23: @Ritchie333, Steel1943, Rschen7754, WOSlinker, and NE Ent: @Mr.Z-man, Locke Cole, and Mlpearc:

It may be time to take another look at criteria #5 and #6. I say this mainly because of a trend I see in watching Wikipedia:Requests for permissions/Template editor -- If you're a pretty well-established editor in good standing, who doesn't technically meet 5 and 6, your chances of being granted this permission basically depend on which admin answers your request. Mr. Stradivarius appears to be the only one stringently enforcing those two items, while the other granting admins see the indication of trust as the primary factor. I think we should either retire those two criteria, enforce them consistently, or set out further specifics regarding in which cases they can be overlooked.

Just as food for thought, one issue I see with these is the difficulty of finding evidence of them in a reasonably long-term editor's contribution history -- even the user making the request will often have a hard time finding them, as they aren't part of any normal statistical listing. equazcion → 11:36, 27 Nov 2013 (UTC)

Thanks for the notification. I am surprised to hear that this is the case and that there is such a lack of consistency that can be pointed to a particular editor over, even more surprised to learn it is Mr. Stradivarius. Not because they denied my request, but because I trusted that this new user right would be given with consistent use of the criteria. I did see an issue when I first requested the user right and asked: "I thought those guidelines were not actually a requirement, ..." to which Mr. Stradivarius replied: "You're right that these are guidelines and not strict requirements - but that doesn't mean that we can ignore them, in my opinion.". I admit...that pretty much confused me, but I simply assumed good faith and let it be. I also agree with Equazcion's food for thought. I am still not clear that I didn't have such work in my history, but trying to find it from a nearly 7 year history was not a task I was prepared for. I support removal entirely of those specific criteria. However, I could support them simply being added directly to the criteria as listed without the current ambiguous wording and requiring a standard that can be held equally to every request regardless of the responding admin.--Mark Miller (talk) 12:01, 27 November 2013 (UTC)

I don't necessarily think this is a Mr. Stradivarius problem, just a problem with ambiguity and the resulting way that differing views can sway the outcome. These criteria were added (by WOSlinker in their first form, to the original proposal) in order to narrow the focus of the permission and see that it doesn't get presented as something that will be handed out simply to every established editor who requests it. My own personal view was that they would become questions to ask of less experienced editors who nevertheless meet the other criteria. For example, an editor here for 2 years with 200 template edits might not necessarily be trusted with this otherwise, but if they also sandboxed and enacted five protected edits, we can be reasonably assured they know what they're doing. I didn't see them as necessarily blocking acceptance of a more prominent editor, let's say one here for 5 years with 700 template edits and whose edits and discussion showed a reasonable understanding of template coding and procedure. This is just my personal view now though, and I'd like to hear what others think. equazcion → 12:18, 27 Nov 2013 (UTC)

Thanks for the clarification. I don't wont this to be about Mr. Stradivarius specifically just that I did question the need to be so strident and now it does at least appear that the admin has been consistent themselves if no one else. So there is that. I don't even know if, without even those criteria, that I would have been approved. But I believe the discussion is a valid one.--Mark Miller (talk) 12:28, 27 November 2013 (UTC)

(edit conflict) My intent has just been to apply the guidelines as they have been written, without regard for number of template edits or length of time spent on Wikipedia (as long as the editor is over the minimum values, of course). I get the feeling that other admins have been looking to see whether editors are trusted in general, whereas I have been looking to see whether whether editors are trusted to edit protected templates specifically. I think that guidelines #5 and #6 are pretty good at showing whether editors are aware of the level of care needed when editing protected templates, but I'm also open to developing new criteria and/or relaxing the existing ones if others think they are too strict. I do think we need some criteria other than just being a generally trustworthy editor, though, as there are aspects of protected-template editing that you don't get to understand through general editing, or even general template editing. I also think we need to be consistent about how we apply the guidelines; either we should actually make sure that editors fulfil them, or we should get rid of the guidelines. I don't think we want to be in the situation of invoking WP:IAR every time an experienced editor asks for the template editor right; we want newer editors to be able to trust that the process is being followed fairly and that there is no special treatment going on. — Mr. Stradivarius ^{♪ talk ♪} 13:38, 27 November 2013 (UTC)

I think #5 and #6 should be replaced with:

5. The editor should have a demonstrated knowledge of at least three of the following subjects:
   1. HTML, CSS and/or wikitext
   2. template syntax
   3. parser functions
   4. Lua/module syntax
   Whether this knowledge is demonstrated by edits to sandboxes or edits directly to templates is irrelevant.

I think specifically requiring X "significant" protected edit requests (and the term "significant" is hopelessly subjective) and X sandbox edits is onerous and unnecessary when the goal should be to demonstrate that the editor is familiar with editing templates. Requests for this user right should be like applying for a development job; demonstrate you're competent, won't vandalize the project, and hopefully have a cool head, and that should be it. Competence is covered by my proposed #5. Vandalize the project is covered by the earlier requirements (X edits/X years active). Cool head would be covered by the recent blocks/3RR requirement. —Locke Cole • t • c 13:21, 27 November 2013 (UTC)

I think we need tests for a few other things as well. First, I would like editors to show that they have an idea of which changes require gathering consensus beforehand and which don't. Second, I would also like to see that they have a basic understanding of what the job queue is and why it is a bad idea to make many small changes to highly transcluded templates. Finally, I'd like to see that they know the basics of how to test whether their changes have introduced errors or not. I don't think that prospective template editors need to be perfect, by any means, but I think that it is important that they have at least thought about these issues and had a little practice in applying them. — Mr. Stradivarius ^{♪ talk ♪} 13:45, 27 November 2013 (UTC)

The job queue is confusing, and has lots of random quirks that very few people understand. (I say this as a person who has spent weeks trying to figure out how it works and is still not clear on a lot of things). I would be more concerned about a broken template breaking thousands of pages rather than the job queue having an extra 10k jobs. Legoktm (talk) 18:15, 27 November 2013 (UTC)

The job queue requirement sounds like WP:AUM all over again. Unless MediaWiki devs have specifically said there's a problem with editing certain pages on the site, we should stop throwing up barriers for legitimate editing. FWIW, I have thought about those issues, but requiring prospective template editors to understand something that may not affect their work is, again, onerous and subjective. If anything, WP:JQ appears to exist to alleviate server strain from editing templates used on many pages (the old method likely running synchronously and causing the site to stall, which would be cause for concern when editing a highly-used template). —Locke Cole • t • c 20:21, 27 November 2013 (UTC)

I don't mean that users should understand exactly how the job queue works technically, as that gets very complicated very quickly. I mean that they should know that there is such a thing as the job queue, and that if they edit a highly-transcluded template it means that all the pages with transclusions get put into the queue and have to wait to be processed by the servers. Just the basic stuff. — Mr. Stradivarius ^{♪ talk ♪} 22:06, 27 November 2013 (UTC)

I'm saying the job queue is irrelevant, as to my knowledge no MediaWiki dev has come forward saying we should stop making small edits to highly used templates. The reason these templates were protected wasn't because of the job queue, it was because vandalism to them could be highly visible. —Locke Cole • t • c 15:21, 28 November 2013 (UTC)

Well, we could ask a dev to comment here, I suppose. It would be interesting to get their perspective. I think that the advice in WP:PERFORMANCE (written in 2006 I think?) is still relevant today - we shouldn't hold back needed improvements and fixes just because of the job queue. I wouldn't say that the job queue is irrelevant, though. As well as the server load itself, there are visible on-wiki consequences for having a high job queue lag. Categories don't get updated on time, and blue links don't turn red after pages are deleted. This can confuse editors and hold up maintenance work, and I have seen several editors express displeasure at the general sluggishness of the job queue for these reasons.

Also, the scale of the pages affected is a lot larger than it was in 2006. For example, Module:Portal is now template-protected, and it is transcluded on 5 million pages. That takes a long time for the job queue to process - when I moved the portal images from Module:Portal/images to its various subpages, I was still seeing transclusions of that page a month or more later that hadn't yet been updated. Having said this, right now the job queue doesn't seem too high (167,000 jobs at time of writing), so maybe that is the result of improvements to the job queue processing that I remember that the WMF was going to make.

In any case, I agree with you that the job queue is not the most important concern when updating protected templates. I don't think vandalism is the only thing we need to be concerned about, though. Although the initial reason for high-risk templates being protected was because of vandalism, I have also seen it argued that protection is useful for preventing well-meaning but broken edits to templates by editors who have not fully tested their changes. I think this is a good point, as some complex templates can be broken very easily, even by experienced template coders. I don't think we should be giving this user right to users who are not used to testing their changes, or are not sure how to. — Mr. Stradivarius ^{♪ talk ♪} 02:42, 4 December 2013 (UTC)

Let me be clear: if an editor is aware of the job queue, excellent, that's one more thing that is favorable when reviewing an applicant. However, if they were unaware of it, I wouldn't think it should be held against them, as this is a wiki, and software development of MediaWiki has been to make it editable by all. Afterall, what's the point of an editable encyclopedia that can't be edited... WP:HRT was the rationale used to protect these templates, and it only covered vandalism as a reason for protection. That is the standard, and demonstrating someone is a reliable editor should ideally be all that's needed to be a template editor. I conceded above that demonstrating technical ability is reasonable, and I could support that. But I do not support requiring sandbox editing nor using edit protected requests. It's too specific, and wholly unnecessary (especially considering someone that met my original requirements, set out above, would likely know how to use their own sandbox and/or use protected edit requests). —Locke Cole • t • c 21:51, 5 December 2013 (UTC)

I'm not really a fan of bureaucracy, so for anyone who I gave the right to, I didn't actually check that they met the specific requirements. I used rough guidelines of 1) I trust them to not screw up the site, 2) they know when to be bold, and when to discuss first, and 3) they're technically competent. If someone didn't meet my criteria, I would just leave it for another admin to handle. Legoktm (talk) 18:10, 27 November 2013 (UTC)

• (edit conflict) I happen to agree with Mr. Stradivarius's slightly more literal following of the guidelines as they exist and would be strongly opposed to removing them. I realize it is difficult to obtain some of the information required to quickly and easily carry out the background checking (as I have done some myself) and am still in the brainstorming phase of creating a method to easily fix that (perhaps with a clerical bot that can look for key indicators or a userscript/template combination that makes it fairly quick and easy to access the information). I realize that existing TEs can't grant or revoke the right, but I encourage others with the right to assist administrators in determining qualifications for applicants (as I've done a bit of myself). Technical 13 (talk) 18:17, 27 November 2013 (UTC)

{{ec}} Legoktm's guidelines are similar to what I would look for before granting, but consistency would be best, this is a problem across all of WP:PERM Mlpearc (open channel) 18:28, 27 November 2013 (UTC)

re Legoktm: your criteria technically competent. Isn't that a replacement/interpretation of #5 and #6? Or, if not, aren't you introducing a very personal attitude judgement, just as Mr. Stradivarius is said (OP) to be doing by some? -DePiep (talk) 10:42, 4 December 2013 (UTC) -DePiep (talk) 11:23, 4 December 2013 (UTC) (struck distracting imprecise text)

On a somewhat related note, I'd be curious how many editors got the new user right out of process. I haven't done a thorough investigation, but I could have swore I saw one or two names listed having the user right that I hadn't seen at the permission request page. If I'd known that was going to happen, I could have avoided the rejection and gotten an admin that knows me to give me the right instead (something I probably will do in a few months unless the requirements here change). —Locke Cole • t • c 08:51, 1 December 2013 (UTC)

*raises hand* I didn't ask for the right or anything, Legoktm just gave it to me (as a frequent template editor/programmer-type guy), and since then I've found it useful. As far as others... Special:Log/rights from when the template editor permission was initially introduced might be useful. Theopolisme (talk) 03:29, 2 December 2013 (UTC)

I got it without request from Mr. Stadivarius. That wasn't a buddy thing though -- I'd never had any experience with him that I can remember prior to my penning the template editor proposal, and I'm assuming that and my work surrounding it was the basis of his assessment. equazcion → 17:32, 2 Dec 2013 (UTC)

Yes, in the first couple of days that the right was introduced I did give it to a few users outside of process. In addition to Equazcion, they were DePiep, Frietjes, and John of Reading. They are all experienced template coders who I was familiar with from answering protected edit requests. To be honest I had been wanting to give them the right ever since I had seen the template editor proposal, so that I wouldn't have to spend quite so much time answering their requests at CAT:EP. In Equazcion's case, I was familiar with his script work, and his template work seemed good; he was also clearly familiar with all the issues through his work on the rights proposal itself. — Mr. Stradivarius ^{♪ talk ♪} 02:03, 4 December 2013 (UTC)

(Whoops, I've just seen that I've been assuming "he" in the case of Equazcion - my apologies if that should be "she"...) — Mr. Stradivarius ^{♪ talk ♪} 04:11, 4 December 2013 (UTC)

Also, @Locke Cole: rather than asking another admin out of process, why don't you just submit a few edit requests so that you actually fulfill the granting guidelines? Five edit requests and work on three sandboxes really isn't that onerous - I could do that in a few hours if I put my mind to it. If you did that right now and your edits showed that you knew what you were doing, I would give you the template editor right today. — Mr. Stradivarius ^{♪ talk ♪} 02:52, 4 December 2013 (UTC)

Just to add to that, you should really only request it if you actually have some use for it -- and if you do have use for it, fulfilling its requirements (even in their strictly interpreted sense) shouldn't be an issue, as far as I can see. Ie. You assumedly need to edit protected templates, so the first few times you need to do that, submit them as requests; then you can get the right. Try not to think of user rights as prizes, even though it's tempting to do so. equazcion → 04:00, 4 Dec 2013 (UTC)

I don't think of them as prizes... as I said before, the only reason I stopped editing them was because they were protected. Having said that, the requirements to get the user right shouldn't read like a contest list either. :-/ —Locke Cole • t • c 22:01, 4 December 2013 (UTC)

...but now that the right exists, and therefore continuing to edit a little through requests would now offer you an avenue to being able edit them directly again, why not just do that (instead of waiting a few months and requesting out-of-process)? If you just don't want to do that out of principle since you disagree with the criteria, I guess I could understand that though. equazcion → 07:54, 5 Dec 2013 (UTC)

It's the principle. And looking at it now, the vote for this user right almost looks like a backdoor way of saying the community agreed these pages needed protection of this level in the first place (there again, I just recall seeing templates getting protected without any prior discussion and I honestly wish I had challenged it then). The original reasoning was that the protected templates were "high risk", and if you look at the talk page there, you'll see there's been some serious objection to the whole idea of preventive protection as a guideline. —Locke Cole • t • c 21:51, 5 December 2013 (UTC)

I think that loses sight of the fact that these requirements and the process here weren't followed, but thank you for offering. —Locke Cole • t • c 22:01, 4 December 2013 (UTC)

From the various comments here I think my take falls in between two sides (possibly extremes) I'm seeing. I think there are several things that can adequately suffice to prove what the sandbox experience criteria are meant to indicate, and at the same time, I think going by trust alone doesn't reflect the guidelines here and ignores the consensus. equazcion → 17:32, 2 Dec 2013 (UTC)

I haven't read the discussion, but I generally have granted rights only when I know the user meets the criteria without having to look, or when they have an overriding reason they need access to the templates, or when they have extensive crosswiki experience that qualifies. Otherwise, I leave it to others. --Rschen7754 10:44, 4 December 2013 (UTC)

{{ec}} After reading this all. I conclude this. First of all, a template protection is there for a reason. Clearly not just to prevent vandalism (otherwise we'd leave it to vandalism-partrols as other pages). PP exists for a reason, way before TE comes in play. It exists because template edits can be disruptive far worse than a single page. Leaving out #5 and #6 would check only on general trustworthyness of an editor. I do not see why an example editor who has done very good work by adding 10.000 references to WP, is to be "trusted" into this template editing. Especially while there is a more rational "check" option: look at their template edits. Why would a new template editor (who never dived into any intricacy that lead to a protection in any way) would need TE right away? Why has that editor not edited open templates?

And this is new here: how is the editor behaving in template disputes? Is there a habit of discussing templates, open for change of mind? Last thing I want is an edit war in template space, performed by "trusted" editors. Editors who think too easily of skipping the sandbox. TE should not be an lowly vetted admin-light route.

I conclude upkeeping the criteria, and apply them as strong guidance. All granting editors should follow them more strictly, and motivate any reason for exceptions. I see here that the issue is not about phrasing of these rules, so I skip that.-DePiep (talk) 11:14, 4 December 2013 (UTC) (TE only, by invitation)

Protection actually doesn't result from intricate coding. I forget this myself sometimes, admittedly. Protection just results from a template being mass-used. The admins relying more on trust and general experience aren't entirely off-base, because it's somewhat valid to say a generally trusted editor would probably know their own limits, even if they don't know intricate coding; and they would probably know when an edit shouldn't be made without discussion.

Templates have a special discussion aspect, which is sandbox testing. As long as an editor is generally trusted (ie. extensive Wikipedia experience) and verifies verbally that they're aware of the sandbox aspect, we could probably assume they'll again know their own limits, be careful, and learn what they need to before doing anything serious.

I'm partially playing devil's advocate here. My own stance was always leaning towards making people prove they know what they're doing, versus making sure they're experienced enough, in a general sense, to know what not to do before learning more. I think, at least, that clarifies the two actual sides we're arguing over. equazcion → 17:47, 4 Dec 2013 (UTC)

Templates were only protected because of the potential for easy vandalism. End of sentence, full stop. Other reasons to ban templates or protect them were rejected by the project, but the vandalism argument was a hard one to ignore and won out over ease of editing (I believe at one point a heavily used template was vandalized in such a way that clicking anywhere in the active window took the victim to a "shock" site; you couldn't even edit the page through the normal interface, and back then there was no help regarding "which template is used on this page" so you could track down the actual template that was vandalized). —Locke Cole • t • c 22:01, 4 December 2013 (UTC)

Ugh

The granting of a user right to edit protected templates should be granted to those that meet the reasons those templates were protected in the first place. They were not protected to shield the project from:

• inexperienced template editors;
• the "server strain" of editing a highly used template (see WP:AUM);
• an overabundance of editors not acting with consensus (which is better resolved through means other than protection; blocks come to mind)

The only reason they were protected was because of vandalism (or the risk of vandalism). With that in mind, really the only qualification should be "has this person vandalized the project; have they displayed enough experience editing here that I'm (the reviewing admin) comfortable they're not going to subtly vandalize a highly used template". That's the problem proactive protection was implemented to resolve, and any "solution" that allows 'regular' editors to edit them should be on the basis of believing the candidates won't cause the problems protection was meant to prevent.

Having said that, I have no problem with there being some additional minor qualifiers. As noted above, I think asking for demonstrated experience with editing templates isn't necessarily a bad thing. It's when we veer off into this over-protective system of requiring protected edit requests and sandbox editing that we run into problems as those aren't relevant to the reason these templates were protected in the first place.

BTW: I have zero problem with this user right being revoked for editors that do decide to edit war in template space (ex: someone violates 3RR in template space; block them and remove the user right for a period of X months minimum). That makes sense (I'd dare say "common sense"). —Locke Cole • t • c 22:01, 4 December 2013 (UTC)

I wonder if there's some evidence to substantiate the claim that the whole "high-risk template" concept originated from vandalism concerns alone, to the exclusion of inadvertent damage concerns, etc (or if there's evidence of the contrary). In all the user right proposal stuff I don't think that claim really surfaced, even though there were some editors who expressed that trust not to vandalize was the only real factor of interest when considering granting. Regardless of the history though, my view of the consensus at the user right proposal discussion seems to have been that vandalism was actually not the sole concern. equazcion → 00:10, 5 Dec 2013 (UTC)

Promoting ultimate liberty is not Wikipedia's role—articles are anyone can edit because experience shows that benefits the encyclopedia (with the high cost of nonsense and POV pushing). If someone thinks they would like to edit a template used on 100,000 pages but they are not aware of the "what" and "why" of using a sandbox, they need to find something else to do. In an article, the effects of an edit are generally immediately obvious and problems are readily resolved. Templates are not like that. Johnuniq (talk) 01:09, 5 December 2013 (UTC)

re Locke Cole. The only reason they were protected was because of vandalism (or the risk of vandalism). I beg to differ. Opening lines of WP:PROTECTION use the word: "damage", which would include good faith disruptions and more. Also, following your conclusion the template protection could have been simply semi-protection, opening them for "established editors": exactly the target audience, "trust" and so. Maybe after cranking up the treshold numbers a bit for these autoconfirmed users. But: we see that PP does not do that. So there must be other reasons. Then LC too does introduce reasons to limit access. However, since these are not quantified or even qualified, we are left to guess for LC's actual proposal. Overall, I do not want #5 and #6, currently the only template-related qualifiers, replaced by "admins judgement of trust" i.e., removed. Edit experience in template space is the available and sensible check to prevent the damage envisioned by WP:PP. -DePiep (talk) 07:41, 5 December 2013 (UTC)

WP:PROTECTION speaks generally about protection used on the site, and I think you're reading into the choice of words ("damage") more than the page means. Besides, WP:HRT is the oft-cited reason for protecting templates, and it only mentions vandalism. It makes no mention of inexperienced editors, or casual/accidental damage. It also doesn't mention the job queue. My proposal is spelled out very specifically above, BTW. One of the very first replies in this overall topic section. —Locke Cole • t • c 21:51, 5 December 2013 (UTC)

"Reading more" in words could have happened to you too. The "vandalism" in WP:HRT is not in the lead, only in the supporting reasoning. The reasoning does not say why unintended disruption would be acceptable. And if that all were enough, we still don't know why not simply all WP:autoconfirmed editors may edit these templates. -DePiep (talk) 14:26, 8 December 2013 (UTC)

WP:HRT lays out the vandalism-only argument for permanent protection, and is the reason they are protected. WP:PP applies more generally to the project as a whole. WP:HRT, on the other hand, was the reason given for almost all of the permanently protected templates. WP:HRT as a proposal dates back to December 2005, I didn't look to see at one point it went from being proposed to actually accepted (or if there was even a !vote involved). I think it probably went something like.. proposal, mass protection of "high risk" templates, wikt:fait accompli. —Locke Cole • t • c 21:51, 5 December 2013 (UTC)

99% of the reason these are fully protected is to keep vandals and noobs out. Anybody with a decent understanding of template syntax should be eligible to receive this privilege, provided that he has been around here long enough to show he isn't a sock puppet of one of the template vandals. Reaper Eternal (talk) 20:56, 6 December 2013 (UTC)

WP:HRT makes no mention of "noobs". You'll get no argument from me over vandalism (other than thinking the worries are overblown; I think semi-protection would make sense for a lot of "HRT"). —Locke Cole • t • c 14:29, 8 December 2013 (UTC)

I disagree; part of the reason is to make sure that people get consensus before making controversial changes to major templates that could cause a lot of damage. --Rschen7754 20:58, 8 December 2013 (UTC)

This smells of WP:BEANS, and the requirements here are instruction creep. How do you know a change is controversial in advance? Why do we ignore WP:AGF? And how is a disagreement over functionality/layout/design "damaging"? Remember, they were only ever protected permanently to reduce the risk of vandalism (vandalism which, I will add, only occurred infrequently, and probably wouldn't happen at all if the template namespace was semi-protected by default).

From instruction creep, this would be like creating a rule that affects everyone because ONE person did something insanely stupid (or broke an already existing rule; in this case, don't vandalize the project). Don't do that. Enforce the existing rule. —Locke Cole • t • c 03:07, 9 December 2013 (UTC)

From WP:HRT: "If fully protected, so that they can only be edited by administrators, or template-protected, so that they can only be edited by administrators and template editors, these templates should be changed only after consensus for the change has been established on the template's talk page." --Rschen7754 03:26, 9 December 2013 (UTC)

The primary criteria for granting TE should be "this editor is not a clueless asshole." Beyond that, we're getting into bureaucracy. Although I've been away for a bit, wp:five remains unchanged.
If we accept the logic presented for keeping the tech hoops to jump through, then every Rfa candidate who does not meet them should be opposed, right. NE Ent 20:56, 7 December 2013 (UTC)

Housekeeping

Just now I moved a template that is protected to template editor level. I noticed that the pink warning message reads:

WARNING: This page has been locked in accordance with the protection policy so that only those with administrative rights can move it.

It would seem appropriate that the message should accurately reflect what user rights are required to move template editor pages. Perhaps it might read:

WARNING: This page has been locked in accordance with the protection policy so that only those with template editor or administrator rights may move it.

—Trappist the monk (talk) 22:26, 7 December 2013 (UTC)

Which template is that? And where exactly is that warning message? Is it in a tooltip? equazcion → 00:26, 8 Dec 2013 (UTC)

Silly question, did you clear your cache ? Mlpearc Phone (Powwow) 00:34, 8 December 2013 (UTC)

I moved {{venn}} to {{acad}}. The warning message is visible here: Special:MovePage/Template:Acad (in the big pink box). First time I've moved a protected template so isn't it unlikely to be a cache problem?

—Trappist the monk (talk) 00:44, 8 December 2013 (UTC)

Yeah, looks like that does need to be changed. MediaWiki:Protectedpagemovewarning, I think. equazcion → 01:53, 8 Dec 2013 (UTC)

We have MediaWiki:Protectedpagemovewarning/en-gb as well. — Mr. Stradivarius ^{♪ talk ♪} 21:47, 8 December 2013 (UTC)

Permissions

Can be edited pages in MediaWiki namespace by template editors? --XXN (talk) 13:47, 27 January 2014 (UTC)

No, they can't. If I remember correctly, the only editors who can edit the MediaWiki namespace on enwiki are admins, WMF staff and interface editors. — Mr. Stradivarius ^{♪ talk ♪} 15:13, 27 January 2014 (UTC)

It looks like interface editor encompasses the privs of template editor (which makes sense). Is it technically possible to have a local-only interface editor? ⇔ ChristTrekker 18:44, 3 April 2014 (UTC)

It's technically possible, but it would need configuration changes (and consensus, which would be trickier to get). Jackmcbarn (talk) 18:46, 3 April 2014 (UTC)

Stabilization?

This discussion has some thoughts such as pending changes protection instead of full protection to a certain user right level. It has some comments such as these:

• I'm sort of fed up by all these people suggesting ideas for tricking the job queue. The job queue is there for a reason and you shouldn't bypass it. You guys are solving the wrong problem. If you don't want to accidentally cascade a template change into all pages, you need to use a turnstile instead of a seesaw to toss people back into the row [line] after they have passed the door. What you need is some form of flagged revisions. Be it PC or I don't give a crap how we configure and call it. THAT is what you need. We can FIND reviewers, we can ASSIGN groups and permissions. As far as I'm concerned, we retool template protection into a PC1 like protection, apply it to all templates used in mainspace (bot controlled) and we use PC2 where needed. This is not content space, content space decisions don't matter, we can use PC1 and PC2 just fine, as long as we set it up properly. —TheDJ (talk • contribs) 20:06, 2 January 2014 (UTC)
• The strongest support that I can puff out. We need good faith IP editors! Dreth 17:32, 30 December 2013 (UTC)

This consencus appears to have been rejected despite some of the opposes bearing a nature of "oppose any protection at all" (which means oppose to what we have with template editor now, too) and the discussion wasn't analysed properly as I could say personally. It wasn't put clearly either.

---

I would like to see this considered:

1. Wait for a massive amount of template editors to apply, get approved, and gain practice. Give it a hundred, or a couple hundreds, for instance.
2. Move most templates to stabilization. They shouldn't be protected at all other than by requiring someone to review a change before it comes into force.
3. Grant all these template editors reviewer right. (This makes sense to me, since reviewer right requires being responsible, which both template editors and reviewers are.)
4. Remove template editor right from the wiki, since reviewer user right would already cover it (and there would already be enough reviewers by the time we approach step 2).

Such style is mainly due to reviewers being a responsible user group who like to test their changes and read documentation, and to be specifically ready for things to break. We could, in theory, have 2 different user rights - for reviewing pending changes to templates and to content pages - but reviewers already know how to ignore something they're unsure in, anyway. Obviously we can replace steps 3 and 4 with a rename of template editor to template reviewer, if desired, but I personally find that redundant.

Thoughts? -Gryllida (talk) 01:23, 10 September 2014 (UTC)

Note that fixing bugzilla:59102 would have to happen before this would be technically possible. Jackmcbarn (talk) 01:25, 10 September 2014 (UTC)

ta. --Gryllida (talk) 04:04, 10 September 2014 (UTC)

How does your proposal address WP:HIGHRISK templates – the reason for indefinite full or template protection? If your going to let anybody with reviewer permission edit (who haven't had to show technical proficiency before acquiring the right), then aren't those templates just going to be put back up to full protection – ie, defeating the point of getting more templates to be able to be edited by more of editors (rather than just admins)? The only way I can see pending changes replacing template protection is if template protection becomes Pending Changes Level 3, with only template editors (renamed template reviewers, if you wish) and admins able to accept changes. - Evad37 [talk] 02:05, 10 September 2014 (UTC)

User rights and protection levels are meant to signify a level of trust.

To address knowledge of existing reviewers, we can write a guideline on template review and mass message about it and new additions to the queues of existing reviewers. They should be quite capable of reading a "this is a massively popular template" warning and instructions on template test cases in such guideline. Perhaps I'm overestimating the complexity of work of existing reviewers and the amount of documentation they read and responsibility they have, but I do trust our existing reviewers with such task. And that user right is technically and conceptually sufficient for satisfying our current purpose.

An alternative would, as I mentioned, be to introduce "Template reviewer" user right. In my view, although it's an overkill and redundant, as such template edits may occasionally come together with edits to (some of) the articles where a template is used. However, it's still, in my view, better than the current situation, for the reasons explained above. --Gryllida (talk) 04:04, 10 September 2014 (UTC)

Additional userrights

There are a few userrights which I think would be beneficial and relatively uncontroversial to grant to the template editor usergroup, considering it requires a high level of trust. All of them are much less sensitive than template editor, and any user trusted for it would be trusted for them.
Those can offer significant advantages to template or technical work :

• move-subpages, should be useful when moving templates (there's almost always a documentation, and some templates have lots of subpages)
• movefile, due to occasional overlap between file and template work (makes file mover usergroup redundant)
• apihighlimits, this would likely be helpful to some members of this group, there's been repeated interest for it

Those aren't directly related but template editors can be trusted with it, and it would save time in granting rights or other users' work :

• massmessage from WP:MMS (makes mass message sender usergroup redundant)
• review and validate from pending changes (makes pending changes reviewer usergroup redundant)
• autopatrolled, see WP:Autopatrolled (makes autopatrolled usergroup redundant)

I'm not including rollbacker because it's somewhat intrusive and may be superfluous for some template editors. Cenarium (talk) 02:25, 13 November 2014 (UTC)

Someone more clueful than me should comment on this, but apihighlimits needs rather more sophistication than would be expected of template editors, IMHO. The first link in "repeated interest" shows someone who (in 2009) mentioned two examples: listing all of a user's contributions in one step (that's over a million in one case!), and listing all pages in a category in one step. I think more would be needed to show what benefit would arise from these very expensive operations. Johnuniq (talk) 06:47, 13 November 2014 (UTC)

It's not particularly sensitive, cf the comments by Gurch and Happy‑melon, both are devs. If a template editor decides to turn on Wikipedia, apihighlimits certainly won't be the preferred attack vector. But since TEs tend to be interested in technical matters, having this higher API limit would be useful to a number of them, for example for AWB. Cenarium (talk) 02:20, 15 November 2014 (UTC)

• There was a quite lengthy discussion not that long ago on: Wikipedia talk:Requests for comment/MediaWiki editor. Happy editing! — {{U|Technical 13}} ^{(e • t • c)} 16:04, 13 November 2014 (UTC)

• I can't find the description of apihighlimits by Jackmcbarn mentioned there and why it would automatically grant the supressredirect right (and if it does, it seems like a bug that should be fixed). Cenarium (talk) 21:18, 13 November 2014 (UTC)

@Jackmcbarn: Could you point me to your comment that is mentioned here ? Thanks, Cenarium (talk) 02:20, 15 November 2014 (UTC)

@Cenarium: Special:Diff/614811238. All I really said about it there, though, was that it wouldn't be useful in a bundle that was otherwise intended for editing protected pages. (And it doesn't automatically grant suppressredirect. I'm not sure why anyone ever would have thought it did.) Jackmcbarn (talk) 04:15, 15 November 2014 (UTC)

The user misunderstood then, it sure wouldn't have made sense. If I'm proposing to add those rights to TEs, it's because I think it makes a good "trusted technical usergroup", so a few more lower risk technical rights should be appreciated. Cenarium (talk) 05:15, 15 November 2014 (UTC)

• This discussion seems to have gone idle quite some time ago. This proposal would reduce the number of hats I have from eight to five (which is a good thing in my book, I honestly dislike having to be in so many various groups to do all the tasks I enjoy doing) and give me permission to rename files (which I was actually thinking about working on trying to improve the consistency with some of the icon files this morning before landing back at this discussion I had forgotten about). That said, I support this proposal. @Cenarium, Johnuniq, and Jackmcbarn:, what do we have to do to move this proposal forward? Is there a consensus here amongst the three of us to put in a Phab ticket or should it go to VPR to gain further consensus/die? — {{U|Technical 13}} (e • t • c) 01:40, 4 May 2015 (UTC)
  • What extra right is needed to perform what operation? The devs are welcome to overrule my concern and give the 105 template editors apihighlimits if they want, but I hope they would not act because of this very limited discussion. Johnuniq (talk) 02:01, 4 May 2015 (UTC)
    • If apihighlimit is your only concern, that particular bit improves users with TE permissions to do technical work requiring api access such as working with AWB to clean up transclusions of a template they modified per consensus for example (see Wikipedia:Village_pump_(proposals)/Archive_66#User_right_modifications in relation to this) more efficiently. I don't see having the tools needed to update transclusions of templates as a bad thing. I'd even be willing to take this a step further in that direction and suggest that TE's shouldn't need to be on the AWB checkpage specifically just like administrators aren't required to be on it. I'd also suggest that the checkpage be editable by TEs. Thought's on that part of it Magioladitis and Xeno? — {{U|Technical 13}} (e • t • c) 02:34, 4 May 2015 (UTC)
      • I haven't checked the checkpage in a while; is it often backlogged? –xeno^talk 11:06, 5 May 2015 (UTC)
        • Xeno, what do you mean by is the checkpage backlogged often? I do believe that many TEs are already on the checkpage (and since most of us are already on the page, why not make it implicit like administrators get, or are you suggesting that administrators shouldn't be implicitly included and should have to add themselves to the checkpage? I'm confused by what you mean, and my logical mind can only see it as logical to add TE to the implicit list). The main point is that AWB runs 10 times slower only being able to process 500 instead of 5000 at a time, and TEs should be trusted enough (without having to use our bot accounts) to have apihighlimits. — {{U|Technical 13}} (e • t • c) 20:17, 5 May 2015 (UTC)
          • I'm fine with template editors having apihighlimits (as long as the sysadmins don't have any issue with it) and being auto-approved by AWB, but why would they need the ability to edit the checkpage? –xeno^talk 20:39, 5 May 2015 (UTC)
            • Oh, I understand your comment now. It doesn't really matter much, I'm just thinking it's technically a template used by AWB to determine permissions for the tool and since it isn't protected due to edit warring, it probably wouldn't hurt to allow TE's to edit it (this is probably true for most checkpage type tools). — {{U|Technical 13}} (e • t • c) 20:58, 5 May 2015 (UTC)
            • Xeno, I will note that there were requests that sat there almost a week (page says requests should be answered in 48 hours or adminbacklog should be activated) until I poked an admin on IRC. Maybe it wouldn't hurt to have 184 more technically inclined people that can edit that page. — {{U|Technical 13}} (e • t • c) 15:31, 12 May 2015 (UTC)
              • Probably that should be discussed there, but I don't really think it fits. It's an administrative task and template editors aren't selected for such. –xeno^talk 17:14, 12 May 2015 (UTC)