Wikipedia:Requests for comment/Template editor user right

---

Proposed: Create a new user right that would give trusted template coders the ability to edit templates, modules, and edit notices that have been fully protected for precautionary reasons. This RFC is scheduled to close on 11 October 2013. equazcion ^(talk) 10:07, 11 Sep 2013 (UTC)

The following discussions were precursors to this proposal:

• This Administrators' noticeboard thread
• Request for adminship: Trappist the monk

The most pervasive templates on Wikipedia are generally fully protected: They are considered high-risk, because they make it possible for malicious or unknowing people to adversely affect many thousands of pages at once by editing a single page. High-use templates are therefore systematically full-protected as a precautionary measure. When any page is fully protected, administrators are the only editors who have the ability to edit them.

While full protection is an ideal temporary solution for articles that have demonstrated a state of overwhelming controversy, it is less ideal as a permanent precautionary measure for templates. Many editors who have shown an aptitude for coding templates, and have earned the trust of the community in doing their work, may not necessarily be administrators, nor even be interested in becoming administrators.

Non-administrators do have the ability to request edits at fully-protected templates for administrators to enact on their behalf, but there is a significant shortage of administrators who have the time and necessary skills to do this reliably. Coders also tend to find this extra step more than a mere annoyance: Technical work is largely rewarding to technically-minded people in that they value the hands-on experience. Many end up choosing to avoid having to verbalize uncontroversial edit requests made to convince someone else to enact an edit on their behalf, by simply avoiding work on fully-protected templates altogether.

As there is currently no measure that would allow access only for trusted editors with template know-how, some editors have resorted to applying for adminship, as is the case for Trappist the monk's RfA. Note the many comments from all sides saying that the optimal solution would be to grant a user right specifically to allow this editor access to high-use templates.

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.

This permission will be limited, via technical means, only to pages in the Template and Module namespaces, as well as edit notices.

The protection levels of pages, only within the Template and Module namespaces, that are currently fully-protected for precautionary reasons, will be switched to a newly-created protection level. Pages with this new protection level will be editable by the new Template editor user rights group, as well as by sysops and above. This way, the new rights group will have its namespace restrictions enforced on a technical level; it will be impossible for them to edit full-protected pages in the article or project ("Wikipedia:") namespaces, for example. Actual full "sysop" protection will then be available as an extraordinary measure in the Template and Module namespaces, to temporarily disallow editing by anyone but administrators, should the need arise.

It should be understood that the standards for what constitutes a high-risk template should remain unchanged and not be expanded, despite this newly created protection level and rights group. Vigilance should be maintained in making sure this development does not grant a de facto license to protect more of Wikipedia's less risky templates on the grounds that many editors will still have access to edit them now that this rights group exists. The Template editor user right should not result in more templates becoming uneditable for the general editor population.

Editors will be permitted to exercise this permission to perform maintenance, answer reasonable edit requests, and make any other simple and generally uncontroversial edits to templates, modules, and edit notices. They will also be permitted to enact more complex or controversial edits, after those edits are first made to a test sandbox, and their technical reliability as well as their consensus among other informed editors has been established.

Editors will be able to request this permission via Wikipedia:Requests for permissions/Template editor, which will be created upon passing of this proposal.

The new template editor user right will be granted by administrators. Administrators will use their own discretionary assessment of an editor's template contribution value, as well as the following general guidelines:

1. The editor should be a registered Wikipedia user for at least 1 year.

2. The editor should have made at least 1,000 overall edits.

3. The editor should have made at least 150 edits to the Template namespace.

4. The editor should have no behavioral blocks or 3RR violations for a span of 6 months prior to applying.

Additionally, an editor should have demonstrated a need for the right, as well as a familiarity with the care and responsibility required when dealing with high-risk template modification:

5. The editor should have worked on the sandbox version of at least three fully protected templates.

6. The editor should have requested and successfully enacted at least five significant edits at fully protected templates.

Items in this section are merely guidelines. An administrator may choose to substitute other proofs of an editor's competence in handling high-risk template responsibilities.

The user right can be revoked at any time by an administrator without any process or prior notice in any of the following circumstances:

1. The editor demonstrated a pattern of performing obviously controversial edits to protected templates without first determining consensus.
2. The editor demonstrated a pattern of failing to exercise sufficient care when editing protected templates, resulting in serious errors appearing on pages.
3. The editor used the permission to gain the upper hand in disputes.
4. The editor used the permission to perform blatant vandalism.
5. The editor has been inactive for 12 months.

Additionally, the right may be removed immediately at the request of the editor.

1. Betty Logan (talk). Seems a reasonable suggestion to me. No reason why a trusted member of the community should have to go running to an admin every time. Betty Logan (talk) 10:24, 11 September 2013 (UTC)[reply]
2. TheDJ Yes please, can we enact this already ? I see no reason why a talented coder needs to be an admin on this site. Trust is enough. —TheDJ (talk • contribs) 10:57, 11 September 2013 (UTC)[reply]
3. Fram. The reasons for removing it perhaps need to be expanded a bit, and the requirements for granting it perhaps loosened a bit, but this is basically a sound approach. Fram (talk) 11:01, 11 September 2013 (UTC)[reply]
4. The ever-increasing minimal standards required for a user to have a remote chance of succeeding at WP:RFA coupled with the complete lack of a requirement to possess knowledge of the wiki parser functions or Lua coding makes this user right a long overdue tool to bestow upon technically proficient editors who have shown competence and proper understanding of our rules/policies/guidelines, but whom either doesn't desire the responsibilities associated with full adminship, doesn't edit frequently enough to require the full toolset, or doesn't have the squeaky-clean demeanor expected of potential administrators. If there is a fear that certain templates are too delicate or high-visibility for even our trusted, experienced, and skilled editors, a new level of protection could be created. It could also be applied when edit wars erupt. - Floydian ^τ _¢ 11:03, 11 September 2013 (UTC)[reply]

   Floydian: Just to note, under this proposal, access will be granted to this group via a new protection level below full, so the usual full protection will still be available if any templates should ever be deemed too sensitive for this new user group. equazcion ^(talk) 11:20, 11 Sep 2013 (UTC)

5. I frequently patrol Category:Wikipedia protected edit requests, and I see plenty of editors who I would trust to edit high-risk templates, but who either don't want to take an RfA or who don't have the broad range of experience necessary to pass one. At the moment, there are only two or maybe three admins actively patrolling edit requests, and if we all disappear for a time (or, more likely, get caught up with writing templates and modules of our own), it can be days or even weeks before requests get answered. The proposed user right would make this situation much more efficient. — Mr. Stradivarius ^{♪ talk ♪} 11:06, 11 September 2013 (UTC)[reply]
6. Pointillist. If this is technically viable, I can't see any downside to this proposal. It is obviously a much better approach than granting full admin powers without performing a conventional RfA: it's simpler, less demanding for the candidate and less risky for the community. - Pointillist (talk) 11:12, 11 September 2013 (UTC)[reply]

   I've just read Acalamari's oppose. I understand that position but see this as a one-off rather than being "a stepping stone to having multiple and confusing protection userrights for non-admins". However, if this proposal isn't a one-off, then I agree that would be a downside to some extent. - Pointillist (talk) 16:20, 13 September 2013 (UTC)[reply]

7. Looks good to me - subject to ironing out the details. I'd suggest getting the technical people to say if this is indeed viable before that, though. Peridon (talk) 11:22, 11 September 2013 (UTC)[reply]
8. Probably every experienced editor has basic knowledge of wiki markup—but Lua and Parser Functions are a different story (I can barely read Lua, let alone code it!) Experienced coders don't need to be admins. ~HueSatLum 11:58, 11 September 2013 (UTC)[reply]
9. From my experience as an admin on another wiki ([1]) I know full well that template changes can cause untold performance problems, without any obvious and immediate side effect to the user making changes, even when those changes have been completely in good faith and seemingly compliant with policy. Moreover, the technical skills required only have a small overlap with the diplomacy and policy understanding skills that are generally tested at RfA. One word of caution - the bulk of my template edits are related to WP:DYK, which generally have nothing to do with the problem this RFC is supposed to solve, and I suspect I'm not the only one in that position. Ritchie333 ^{(talk) (cont)} 13:11, 11 September 2013 (UTC)[reply]
10. I don't see why not, in fact, I'd love to see it expanded to allowing them to work with Edit-protected requests (there's always a backlog) that are uncontroversial (typos, etc). ~Charmlet ^-talk- 13:31, 11 September 2013 (UTC)[reply]
11. Definately a step in the right direction. I am disappointed though that we have to create a whole new user right primarily because there is a major lack of good faith in the community to not trust our users and fierce protectionism over the Admin tools...which are no big deal. Kumioko (talk) 13:32, 11 September 2013 (UTC)[reply]

    I don't see any harm that can come from this. Jackmcbarn (talk) 14:57, 11 September 2013 (UTC) Changed to Oppose, see below. Jackmcbarn (talk) 12:33, 12 September 2013 (UTC)[reply]

    @Jackmcbarn: Please remember to indent !struck votes. — PinkAmpers&^{(Je vous invite à me parler)} 07:15, 15 September 2013 (UTC)[reply]

12. I came here on the premise of opposing due to this proposal makeing it even harder for people to take the admin hurdle. We do want more admins not less. But: The proposed extra protection layer coupled with the argument of speedy corrections swayed me to support. Agathoclea (talk) 15:40, 11 September 2013 (UTC)[reply]
13. The skill set for admins and technical tasks are very different. Some folks I would trust to do one and not the other. The alternative to this are dropping protection to some high use templates to semi-protect or keeping status quo with sandbox main template model. Semi-protection is just too low for some templates as editors with no template experience could make uninformed edits to crucial templates. The sandbox model is good and I would expect any editor worthy of this status to test all major changes in a sandbox first. Minor edits with change some of wording don't need the review process. Further the TemplateData system does introduce a new use for this status - to update the TemplateData documentation for a template requires a null edit and many of those adding template data don't have the admin bit so can't complete their job. There has been a good number template just waiting for a null edit.--User:Salix alba (talk): 16:16, 11 September 2013 (UTC)[reply]
14. Qualified support I support the concept but the qualifications, etc. and won't block consensus to implement this as-is, but the criteria and other items in the proposal aren't exactly what I would prefer. For example, I would add a big bold statement reminding editors that edit over protection that they will be held to a higher standard, just as administrators are held to a higher standard when they use the mop. We can discuss tweaking the criteria after it is implemented. Also, see my discussion item below about an alternative way of doing the technical aspects of this proposal to allow other Wikipedias to have more options in delegating user-rights. davidwr/(talk)/(contribs) 17:09, 11 September 2013 (UTC)[reply]
15. I support the creation of the user right as outlined. We have a number of editors with the technical skills to know how to edit a template (more so than many admins), who can be trusted to make the edit and not delete the main page. I would have preferred a little more discussion of the granting process, which looks a little loose, but we can tighten that up as we go along. --SPhilbrick(Talk) 18:14, 11 September 2013 (UTC)[reply]
16. Support. This is a namespace that doesn't have very much attention from current administrators (not that I am blaming them or anything) and it is very, very disappointing and frustrating to have to see skilled editors in these areas go through the RfA process when all that is required is basic conflict resolution skills in addition to the technical knowledge and foresight required to know how to improve templates. I like the idea of encouraging editors who enjoy their work in this space to be able to do their work more effectively without taxing an already burdened and busy admin pool. I, JethroBT ^{drop me a line} 18:30, 11 September 2013 (UTC)[reply]
17. Support A good compromise between needlessly clogging the edit-request list and single-purpose RfAs, with which the community (including myself) seems uncomfortable. Miniapolis 19:29, 11 September 2013 (UTC)[reply]
18. Support essentially per User:Floydian. In the Criteria for Revocation, I would prefer "demonstrated a pattern of performing" to become "has performed" and "demonstrated a pattern of failing" to become "has failed". But notwithstanding such details, I think this will benefit the project. --Stfg (talk) 20:53, 11 September 2013 (UTC)[reply]

    Stfg If I remember the drafting, the reason why "a pattern" was chosen over the explit "has" was to prevent one (potentially minor) mistake be grounds for a pitchfork mob (or a dedicated opposition) call to arms for removal of the user right. Hasteur (talk) 21:08, 11 September 2013 (UTC)[reply]

    I see, thanks. I don't think pitchfork mobs are going to be that common or effective at getting this rather esoteric right removed; it isn't like the block/unblock buttons. Also, on the other side there's scope for wikilawyering about how far one can go before it constitutes a pattern ;) Still, one way or the other, this won't affect my support. --Stfg (talk) 21:17, 11 September 2013 (UTC)[reply]

19. I'm find with giving trusted users access to the admin toolset even if all they want to use it for is template editing. However, such RFAs create needless controversy, and so creating a seperate system for it makes a lot of sense. I can say personally, I don't feel comfortable fulfilling an edit protected request unless I feel I fully understand what the changes will do, and for more complex templates, that can be very hard. Monty₈₄₅ 21:27, 11 September 2013 (UTC)[reply]
20. I see no reason to hand out the full kit (with all the issues surrounding it) to someone who only wants to work in a specific area such as this. That, coupled with the ease of revocation should the tool's use prove problematic (something that currently isn't possible with the full set), makes this a good solution. Intothatdarkness 21:36, 11 September 2013 (UTC)[reply]
21. I don't even care about the specific granting/removing criteria or details; they can be worked out/modified later, and I'm certainly not going to risk killing this idea by suggesting tweaks to the criteria now. I only supported the RFA in question because this doesn't currently exist, so my support there shouldn't be taken as evidence that we don't need this option. This is better. --Floquenbeam (talk) 22:00, 11 September 2013 (UTC)[reply]
22. Clearly needed given recent issues at RfA and elsewhere. Nicely written proposal btw. Hobit (talk) 22:21, 11 September 2013 (UTC)[reply]
23. Support per Floydian, there are many editors capable of editing templates that for various reasons will not become administrators. This can only be a net benefit to the project. AIRcorn (talk) 22:57, 11 September 2013 (UTC)[reply]
24. I support this proposal with very high enthusiasm. It's very clear that there are users who could do a lot of good here, but who should not have the other administrative tools. I've read the opposes so far, and on balance I'm not seeing any downside. --Tryptofish (talk) 00:11, 12 September 2013 (UTC)[reply]
25. Support - Agree with most of the above supports. This approach deals with the real problems of allowing skilled coders from working on templates as well as encourages good practices by highlighting the importance of sandboxes and testing. The proposal allows for reasonable safeguards, including the ability to treat protection over content disagreements separately then protection over high visibility or high usage. It addresses many of the real problems of the current situation such as the ones most familiar with some of the protected templates. Even with testing there is always the possibility that bugs related to say unusual usages of the template might still get missed. With the current situation the admin that approves the edit request might not be familiar enough with the template to quickly fix the issue that it introduces which means that broken versions make exist longer. This is true even if the admin that applied the requested edit was skilled in template or lua coding, as someone unfamiliar with the details and usage of a particular template might not understand the reasoning behind all the pieces of the implementation. By allowing trusted editors involved in the design and creation of the particular templates to make the changes themselves it means that they can also fix such bugs much quicker. Finally as others mentioned while protecting heavily used templates is an unfortunate necessity these days it can alienate editors that worked or created those templates. One of the reasons that I personally slowed my own editing was getting discouraged after some templates that I heavily worked on ( and was about to do a redesign to ) got fully protected after they got hit with some minor vandalism. PaleAqua (talk) 02:18, 12 September 2013 (UTC)[reply]
26. Support as proposed. Kudpung กุดผึ้ง (talk) 02:27, 12 September 2013 (UTC)[reply]
27. Support - this simply makes WP:COMMONSENSE. Unfortunatly there are some things - such as heavily transcluded templates - that must be protected, even fully, both for being easy vandalism targets and because of the technical load on the already-overstressed job queue, and there are plenty of editors who are more than able, as well as willing, to tweak those templates as and when needed but who have no interest, or no time, for adminship. This lets them improve their ability to help the encyclopedia, without the baggage that comes with the mop. - The Bushranger _{One ping only} 02:59, 12 September 2013 (UTC)[reply]
28. Support - The increasing complexity and specialization of high-risk templates makes it basically sensible that this should exist. Trying to filter highly-technical edits through willing but non-technical admins is a recipe for problems. Choess (talk) 03:36, 12 September 2013 (UTC)[reply]
29. Seems like some long-overdue common sense. Joefromrandb (talk) 04:22, 12 September 2013 (UTC)[reply]
30. Support - Useful for good coders who don't want to or cannot become admins. -- King of ♥ ♦ ♣ ♠ 06:07, 12 September 2013 (UTC)[reply]
31. Support per many others - Bushranger, KoH, etc. I won't nitpick the proposed criteria; I mostly agree with them, but that can be dealt with later. — This, that and the other (talk) 08:29, 12 September 2013 (UTC)[reply]
32. Support Sure, does no harm. Adminship criteria is too tough these days. jni (talk) 09:07, 12 September 2013 (UTC)[reply]
33. Support. This would reduce bureaucracy for those such as Trappist who want to undertake this activity. It would also reduce unnecessary time wastage at RfA. Axl ¤ [Talk] 11:12, 12 September 2013 (UTC)[reply]
34. Support - per Wikipedia:Requests for adminship/Trappist the monk. This will help solve conundrums where template people who aren't good with other things or don't want to do other things can still edit what they are determined to do. öBrambleberry of RiverClan 12:58, 12 September 2013 (UTC)[reply]
35. Fully protected templates due to visibility is just that -- means to avoid issues propagating over thousands of pages. This is not mistrust in editors, this is a precaution against that one vandal that can cause damage and ridiculous loads that 1000 vandals couldn't in individual articles. Otherwise the templates are no different from any other area of WP, except that inexperience can cause issues. So I think this proposal is a good middle ground. Consensus and testing are still paramount when making changes. —  HELLKNOWZ  ▎TALK 13:50, 12 September 2013 (UTC)[reply]
36. Support per most of the above – experienced coders should be able to do their stuff without needing a mop. - Evad37 (talk) 15:14, 12 September 2013 (UTC)[reply]
37. This is an elegant solution to a longstanding problem. This will allow us to maintain high standards for the most sensitive permissions without inconveniencing experienced editors who don't have the variety of credentials and/or the desire to pass RFA. Small note that I think "template editor" probably isn't the best name, as it could give people the mistaken impression that others can't edit templates—maybe "protected template editor"? — PublicAmpers&^{(main account • talk • block)} 15:51, 12 September 2013 (UTC)[reply]
38. A sensible suggestion. AutomaticStrikeout (₵) 20:01, 12 September 2013 (UTC)[reply]
39. Support - No reason not too. The reason for protecting templates was to protect against vandalism, not to stop good editors from editing templates. This proposal would solve that problem. Garion96 (talk) 20:20, 12 September 2013 (UTC)[reply]
40. Support- Based on Trappist the Monk's RfA. Single purpose RfA's shouldn't be here. buffbills7701 22:31, 12 September 2013 (UTC)[reply]
41. Support - This new user right would help cut down on the backlog of fully protected template edit requests. This would allow trusted and experienced users to continue work without having to go through the RfA process when they would just be requesting the mop to edit templates. All in all I feel it is a good thing for the community. — -dainomite   23:06, 12 September 2013 (UTC)[reply]
42. Support - Looks like a well thought-out proposal that solves a long-standing problem. This would solve some of the single purpose RfAs. It could also be a step toward proving the trust required for an admin. - tucoxn\^talk 23:24, 12 September 2013 (UTC)[reply]
43. Support. Allowing edit-access per namespace seems workable in the MediaWiki software, and might need to restrict editing of the protected Lua script modules, as separate from template namespace pages, due to extreme complexity of Lua script as generally very difficult for many users to understand without extensive discussions with other editors, who might already have module-edit access. -Wikid77 (talk) 04:42, 13 September 2013 (UTC)[reply]
44. Support although it will only releave a small amount of admin work, it is likely to disproportionately fall on those admins that are competent with template editing. So if we have more competent template and clueful editors to help out that would be good. Adding the modules part sounds good. Edit notices not so good, but we should be able to trust these people not to embarrass themselves with edit notices either. Graeme Bartlett (talk) 10:33, 13 September 2013 (UTC)[reply]
45. Support - I see a great potential of this right in the future. -- ^t numbermaniac ^c 12:03, 13 September 2013 (UTC)[reply]
46. I acknowledge the point that Acalamari raises, I just think that the benefits of this outweigh any downsides. NW (Talk) 15:49, 13 September 2013 (UTC)[reply]
47. Support DavidLeighEllis (talk) 17:24, 13 September 2013 (UTC)[reply]
48. Support, per Mr. Stradivarius. If proliferation of user rights is a problem, I would gladly solve that by trading this right for File mover. File movers sleep a lot here ; Wbm1058 (talk) 19:40, 13 September 2013 (UTC)[reply]
49. Support. But, comment: you can't describe a user "right" as a "privilege"! That part needs to be rewritten. Or maybe the issue is that "user right" is the wrong name for this kind of thing in the first place. — Scott • talk 00:25, 14 September 2013 (UTC)[reply]

    Point taken. I've changed it to "permission", which I hope will suffice. equazcion ^(talk) 01:10, 14 Sep 2013 (UTC)

50. Support Editing a protected template and editing a protected article need different skill sets and different kinds of trust. -- John of Reading (talk) 07:10, 14 September 2013 (UTC)[reply]
51. Support --Rschen7754 09:06, 14 September 2013 (UTC)[reply]
52. Support – I'm an expert template coder (day job). On WP I'm not allowed near them and I have to ask a teenager to do it for me. This has long been a crazy way of working. Andy Dingley (talk) 12:34, 14 September 2013 (UTC)[reply]

    @Andy Dingley: I don't think any of the admins who patrol CAT:EP are teenagers. I'm quite a bit older than that, at any rate... — Mr. Stradivarius ^{♪ talk ♪} 15:20, 14 September 2013 (UTC)[reply]

53. Support As an admin (though not a teenager) I realize that there are a lot of non-admins who know a hell of a lot more about templates than I do, and we should definitely give them a chance to help out more. Mark Arsten (talk) 20:27, 14 September 2013 (UTC)[reply]
54. Support. Yes, please, and where do I sign up? –Fredddie™ 23:31, 14 September 2013 (UTC)[reply]
55. Support - You shouldn't need to pass an RfA to be able to code templates. Simple. TCN7JM 00:26, 15 September 2013 (UTC)[reply]
56. Support as sounds a great proposal. →Davey2010→→Talk to me!→ 01:02, 15 September 2013 (UTC)[reply]
57. Support I think it's a good idea. Why not? Bananapeel89 (talk) 01:33, 15 September 2013 (UTC)Bananapeel89Bananapeel89 (talk) 01:33, 15 September 2013 (UTC)[reply]
58. Support Indeed. This might help some users around with their work. — ΛΧΣ²¹ 02:03, 15 September 2013 (UTC)[reply]
59. Pointless support - This will just be shot down (largely by admins) like so many other attempts to create the "protected page editor" usergroup. Perhaps admins should be restricted from voting in unbundling discussions.... Reaper Eternal (talk) 02:17, 15 September 2013 (UTC)[reply]

    Huh? This is at 61-8 support, and even higher among admins only, at 23-2 by my count. — PinkAmpers&^{(Je vous invite à me parler)} 07:13, 15 September 2013 (UTC)[reply]

60. Support A good idea, protecting templates will only help to protect against vandalism, not stopping proven editors from modifying templates.Hughesdarren (talk) 03:51, 15 September 2013 (UTC)[reply]
61. Support – sounds sensible to me. Graham87 04:14, 15 September 2013 (UTC)[reply]
62. Support. Sounds okay with me. Jianhui67 Talk 07:20, 15 September 2013 (UTC)[reply]
63. Support the benefit of increasing access outweighs the instruction creep for me. VQuakr (talk) 07:47, 15 September 2013 (UTC)[reply]
64. Support as making the tasks here easier. (aka Ched) — ChedZILLA 07:59, 15 September 2013 (UTC)[reply]
65. Support. Protecting templates is fundamentally different from protecting articles in several respects, so it makes sense to grant access separately. GregorB (talk) 09:22, 15 September 2013 (UTC)[reply]
66. Support per my road template editing colleague Fredddie. As someone who will apply for this immediately, it's about time! -happy5214 09:45, 15 September 2013 (UTC)[reply]
67. Yes! I have needed this many times, and have mentioned the idea several times myself. Ideal solution. Debresser (talk) 10:21, 15 September 2013 (UTC)[reply]
68. Support, definitely needed. I certainly hope there aren't any opposers below that are also opposing the RFA of the editor who is only running because this currently isn't in place (and if there is, well, You can't have your cake and eat it too). Steven Zhang ^{Help resolve disputes!} 13:34, 15 September 2013 (UTC)[reply]
69. Support, assuming technical implementation is feasible. Ironholds (talk) 17:27, 15 September 2013 (UTC)[reply]
70. Support, It is going to encourage many users to stay with Wikipedia. I don't see why not. SHIVAM SETU (U-T-C-E) 17:58, 15 September 2013 (UTC)[reply]
71. Support per User:Mr. Stradivarius Chris Troutman (talk) 18:38, 15 September 2013 (UTC)[reply]
72. Support. Seems quite reasonable (and needed) to me. Trusted editors should be trusted. -- Wikipedical (talk) 21:04, 15 September 2013 (UTC)[reply]
73. Support Templates and articles are protected for two entirely different reasons, so I am prepared to support this, even though I would not support a similar unbundling related to article protection. Ryan Vesey 21:20, 15 September 2013 (UTC)[reply]
74. Support, mostly based on Trappist's RfA.Tazerdadog (talk) 22:03, 15 September 2013 (UTC)[reply]
75. Support. How come this doesn't already exist? Azylber (talk) 22:28, 15 September 2013 (UTC)[reply]
76. Emphatically support the creation of the Template bit. I see a number of arguments opposing the "general guidelines", but I feel that there is no point of quibbling over those until after the motion is approved (if it is at all). In other words, what's the point of discussing the finer details of something that may or may not succeed. – AJL^talk 23:14, 15 September 2013 (UTC)[reply]
77. I hope this doesn't turn into a slippery slope of the unbundling of the admin toolset, but I have seen many instances where this sort of user right would be helpful. Killiondude (talk) 00:47, 16 September 2013 (UTC)[reply]
78. Qualified support, though I would much rather see granting and revocation done only by the 'crats than by any admin. Something like the way the "translationadmin" right is granted on Meta would strike me as far superior; lightweight, but allows community comments on candidates. Courcelles 00:50, 16 September 2013 (UTC)[reply]
79. Support, RFA is broken, and people shouldn't need to do everything just to contribute into one specific area. —Locke Cole • t • c 01:19, 16 September 2013 (UTC)[reply]
80. Suppprt Seems fairly sensible and safe. wctaiwan (talk) 01:53, 16 September 2013 (UTC)[reply]
81. Support, Seems good. Will be a good and useful feature for trusted editors. ///EuroCarGT 01:56, 16 September 2013 (UTC)[reply]
82. Support seems efficient and useful. Don't quite agree with the exact criteria, but as others have said above, these can be worked out later. --LukeSurl ^{t c} 08:28, 16 September 2013 (UTC)[reply]
83. Support, let trusted editors perform directly, --Gerda Arendt (talk) 09:29, 16 September 2013 (UTC)[reply]
84. Support full protection of templates, while necessary to prevent abuse, also has the effect of making it difficult to work with many templates if you're not an administrator. Adminship may not be an option for these people, as RfA not unreasonably expects expertise in areas that have nothing to do with template editing. Many administrators who can edit protected templates don't have the required technical skills. The template namespace is also fundamentally different from other areas in that it is the only place where protection is used pre-emptively. Hut 8.5 10:36, 16 September 2013 (UTC)[reply]
85. Support - per comments, and with strong Administrator support. Respectfully, Tiyang (talk) 12:36, 16 September 2013 (UTC)[reply]
86. Support this proposal, since it leaves full-protection open as an option to be used on Templates just as it is currently used on articles – i.e. in the event of edit-warring/what have you. It Is Me Here ^{t / c} 12:50, 16 September 2013 (UTC)[reply]
87. Support Jamesmcmahon0 - This seems like a good compromise that means coders do not have to apply for adminship or pester admins to make changes and admins don't have to understand the code or review requests. Provided the admin is diligent in granting the privilege I'm sure the editors that are granted this right will follow the usual rules on potentially controversial editand community consensus. Jamesmcmahon0 (talk) 13:43, 16 September 2013 (UTC)[reply]
88. Support Though it probably won't have much of an impact on me personally, I can see how it would be very frustrating to be unable to make necessary changes quickly to high-use protected templates. If one know what they is doing, I see no reason to stop them from doing it. RfA should not be a required milestone for this, IMHO. The guidelines listed seem reasonable, though I would probably add something to the effect of "if you don't meet the listed guidelines, you can still apply, but must give a reason", as we have for the other user rights you can request for. Double sharp (talk) 14:04, 16 September 2013 (UTC)[reply]
89. Support I've long thought we need a level of certified trusted editor below admin, with more limited rights, but a less political vetting process. This is more narrow than what I would prefer, but a step in the right direction.--agr (talk) 14:19, 16 September 2013 (UTC)[reply]
90. Support, let trusted editors perform work on protected templates, and let Admins do other work. There should be a very limited number of such permissions, starting with User talk:Trappist the monk.DThomsen8 (talk) 15:03, 16 September 2013 (UTC)[reply]
91. Support - The reason we protect templates is different from the reason we protect articles. A template is protected because we do need to ensure that certain high-risk templates are only edited by certain trusted people. However, not all of our admins are good coders, and not all of our good coders are admins. Thus it makes sense to allow the people we ought to trust with high-risk templates (competent coders) to edit those templates. ItsZippy ^{(talk • contributions)} 15:36, 16 September 2013 (UTC)[reply]
92. Disappointed Support I support this because it will allow serious coders the ability to edit templates. I am disappointed that it is needed, that template coders are not trusted enough to be admins. I am disappointed that we are going to add another level of trust to wikipedia.Martin451 (talk) 17:41, 16 September 2013 (UTC)[reply]

    I am going to add wrt. edit requests mentioned elsewhere. An edit request to an article is often clear cut, and if a spelling mistake happens or text is put into the wrong place (etc.) it does not really matter. If I were to request an edit to a template, and there was a bug in that edit, or the sysop implemented it incorrectly, then it could affect a large part of wikipedia, and also take hours before someone in the know corrected it. Giving this right will allow those in the know to get it right the first time, or very quickly correct their mistake. It will also allow those in the know to monitor edit requests for templates, and make a better decision than most admins, and debug/revert if needed.Martin451 (talk) 23:32, 17 September 2013 (UTC)[reply]

93. Support -- This user right makes sense. Template editing is obscure, and, from reading a couple of Requests for Adminship, it appears that no ability in this area is required. I also read a few heated discussions about templates, where administrators edited fully protected templates without discussing the edits on the template talk page; having a category of trusted and competent users might help remove some of this heat, also. I also hate editing templates; it is frustrating to attempt it, and I think I have only edited one. I would also like this category of users so I could identify and ask specific users to do this for me when necessary. --(AfadsBad (talk) 17:54, 16 September 2013 (UTC))[reply]
94. Support - This is a reasonable use of trust which shall remove some unnecessary administrative overhead. kencf0618 (talk) 20:55, 16 September 2013 (UTC)[reply]
95. Support - Removes admin overhead and allows for a gradual unbundling or admin rights, which will help with some of the RfA silliness. Shadowjams (talk) 23:20, 16 September 2013 (UTC)[reply]
96. Support, but we shouldn't need it. Trusted editors should be admins! Since we've got absurdly high standards for adminship, let's at least give the trusted non-admins some of what they need. By the way, we really need a fourth criterion for removal: template vandalism. If I catch you using your template editor userright to perform blatant vandalism, I'm going to remove your rights in addition to blocking you, and I'd prefer that the relevant policy explictly permit removal, rather than having to rely on WP:IAR. Nyttend (talk) 00:03, 17 September 2013 (UTC)[reply]

    I think this is covered by WP:COMMONSENSE, but it doesn't hurt to say so explicitly :) I made the addition above. equazcion ^(talk) 00:24, 17 Sep 2013 (UTC)

    Agree with your comment, and of course your change. I'm willing to IAR when necessary, but it's better when we can do what's needed without ignoring rules — if nothing else, it removes a possible wikilawyering strategy. Nyttend (talk) 00:38, 17 September 2013 (UTC)[reply]

97. Support. Some of the oppose votes raise important issues, but this seems like a helpful and useful addition to the project. NinjaRobotPirate (talk) 05:44, 17 September 2013 (UTC)[reply]
98. Support. - filelakeshoe (t / c) 10:48, 17 September 2013 (UTC)[reply]
99. Support. Perhaps only a few tens of coders will be granted this responsibility but it seems helpful to the wiki to have these people engaged. Binksternet (talk) 13:37, 17 September 2013 (UTC)[reply]
100. Support. I see no reason why this shouldn't be enacted. —Gordon P. Hemsley→✉ 15:06, 17 September 2013 (UTC)[reply]
101. Support. Since a lot of talented editors don't want to subject themselves to the hoop-jumping circus that RfA has become, turning individual admin tools into user rights is a good solution. An RfA overhaul would be nice, too. Yintan  15:22, 17 September 2013 (UTC)[reply]
102. Support, as increasing the number of users who can edit these will dramatically reduce the workload of some. Zach Vega (talk to me) 16:55, 17 September 2013 (UTC)[reply]
103. Support per Mark Arsten. 28bytes (talk) 17:38, 17 September 2013 (UTC)[reply]
104. yes per yintan Dlohcierekim 20:30, 17 September 2013 (UTC)[reply]
105. Support Sounds reasonable and appropriate given the current circumstances. Templates can be a pain and users who know how to edit them (well) are in short supply. EvergreenFir (talk) 03:48, 18 September 2013 (UTC)[reply]
106. Support - On the Dutch Wiki I have seen cases where this could be usefull. Some people are not right for admin functions due to human skills, but are great with wiki skills, hyperactive, and mean well. Taketa (talk) 07:28, 18 September 2013 (UTC)[reply]
107. Support - Any attempt that leads to unbundling of admin rights is welcome. This one too, is an excellent idea, do go ahead. --Ekabhishek^talk 09:44, 18 September 2013 (UTC)[reply]
108. Support Support efforts to facilitate template/module development by experienced editors, and separation of this authority versus full admin rights. Rjwilmsi 13:48, 18 September 2013 (UTC)[reply]
109. Support, this is a good idea, and will help lessen the admins' workloads. --Funandtrvl (talk) 17:03, 18 September 2013 (UTC)[reply]
110. Support; this is a good idea. -sche (talk) 18:58, 18 September 2013 (UTC)[reply]
111. Qualified support I support the concept, qualified at least: [a] some long-term positive indication of neutrality, [b] a definition of "demonstrated a useful purpose". [c] (possibly) a longer time on Wikipedia. –DjScrawl (talk) 19:21, 18 September 2013 (UTC)[reply]
112. Support. - We only need trusted users to do this task; they need not also be an admin. GabeMc ^{(talk|contribs)} 21:14, 18 September 2013 (UTC)[reply]
113. Support The current situation is a bit odd. For example, I've created a number of templates, including one that was recently vandalized and I had to fix. If I ask for it to be protected to limit vandalism, I won't then be able to edit it. Peter coxhead (talk) 21:47, 18 September 2013 (UTC)[reply]
114. Support. The oppose rationales that I read seem misguided at best. A good many templates are permanently full-protected, and that's not going to change. The alternative to this proposal is the status quo, wherein even fewer people can edit templates. Let's not allow standing on principle to get in the way of improving Wikipedia. Someguy1221 (talk) 05:17, 19 September 2013 (UTC)[reply]
115. Support. The details of eligibility etc may need some fine-tuning, but the general concept is good. • • • Peter (Southwood) ^(talk): 10:02, 19 September 2013 (UTC)[reply]
116. Support the general principle, and the specific proposal with some suggestions:

     I don't think that hard-and-fast numbers are a good idea. We don't ask for specific length of editorship or numbers of edits in RfAs, and this should be easier to get than the mop. since it's strictly less powerful.

     I would like to see an additional requirement that prospective template-editors should have not only made the changes, but that their code is of good quality, that they aren't cowboys and do proper testing before going live and that they document their stuff.

     One feature of the current 'system' is that editors without a template-editor bit (right now equal to adminship) need to get their changes to important templates past a second pair of eyes. I realise that, with a lack of able and willing reviewers, this doesn't currently amount to much, but it could be built upon to try and make sure that applied changes are good quality, but it should be easier to build a cadre of able-and-willing committers if they don't need to ask for and receive the full monty. I think we should try and set up a norm that admins and template-editors should thoroughly review requests to change templates and bring them up to scratch if they aren't. KleptomaniacViolet (talk) 15:54, 19 September 2013 (UTC)[reply]

117. Absolutely. No reason not to. Writ Keeper ⚇♔ 17:03, 19 September 2013 (UTC)[reply]
118. Total support - I am an admin and I sometimes complete edit requests, but Template ones are something way beyond my own expertise and I'd rather let someone who knows more about them fix them up, admin or not. :) ·Salvidrim!· ✉ 17:47, 19 September 2013 (UTC)[reply]
119. Support. Would fill an irritating hole in the privilege system. A step in the right direction. —Stepheng3 (talk) 18:10, 19 September 2013 (UTC)[reply]
120. Support this and all other thoughtful efforts at debundling the admin toolbox. Carrite (talk) 18:19, 19 September 2013 (UTC)[reply]
121. Support; the reasons those templates are protected is one of safety, not "normal" protection and it makes sense that being able to edit them only requires a demonstration of skill. — Coren ^(talk) 19:58, 19 September 2013 (UTC)[reply]
122. Support I am a very skilled template coder, but all of my work is located on Wikis protected by NDA's using MediaWiki software. That said, having administrated multiple sites with protected templates, I can see the need for non-admins that are proficient with template coding to edit templates. For high-traffic protected ones, though, I would still suggest some kind of procedure where notice and a sandbox version worked out in advance be given for some time before the edit is made. I would like to inquire as to the role of trusted template editors and template edit requests by people that have an improvement and can code the template with improvements well, but don't have the role assigned. I feel like it'd increase accessibility for improvement, but could also be a gateway for other users to piggyback on a user that doesn't have to face any sort of consequences external to Wikipedia should they cause mass vandalism. Having implemented a workflow system on MediaWiki software in php, I find Wikis to still be lacking for accessibility even with this change. Penitence (talk) 21:00, 19 September 2013 (UTC)[reply]
123. Support. Necessary given how "liberally" WP:HRT is applied. Someone not using his real name (talk) 21:40, 19 September 2013 (UTC)[reply]
124. Support. I think that this tool could be helpful for the "admin toolbox". An experienced user could help. --Dэя-Бøяg 23:04, 19 September 2013 (UTC)[reply]
125. Support --AmaryllisGardener (talk) 00:10, 20 September 2013 (UTC)[reply]
126. Support - With Lua now available the growing number of templates and modules justifies the need for a right like this. It's born of necessity and arrived at the right time. -- œ^™ 04:29, 20 September 2013 (UTC)[reply]
127. Support - Eligibility might need some tweaking (points 5 and 6 are probably too restrictive) -- Nbound (talk) 05:37, 20 September 2013 (UTC)[reply]
128. Support - Seems reasonable to me. --Kevjonesin (talk) 08:52, 20 September 2013 (UTC)[reply]
129. Support I've supported this a million times in the past, so I'll support it again now. Headbomb {talk / contribs / physics / books} 12:41, 20 September 2013 (UTC)[reply]
130. Support - Seems reasonable to me.--Unionhawk ^{Talk E-mail} 21:13, 20 September 2013 (UTC)[reply]
131. Support - This seems entirely reasonable to me. Aneah|talk _to ^me 00:03, 21 September 2013 (UTC)[reply]
132. Support - Seems like a no brainer to me. It'll make it easier to fix up protected templates, without exposing them to the risk of vandalism across thousands of pages simultaneously and/or wikipedia exploding that you'd get if you let just anyone march in and edit whatever templates they pleased, like some of the people down in the "Oppose" section think we ought to do. --Lost tiree, lost dutch :O (talk) 01:51, 21 September 2013 (UTC)[reply]
133. Support A logical move. Spencer^T♦C 17:20, 21 September 2013 (UTC)[reply]
134. Support as someone who would request having that right. Having to propose a simple change in which I have high confidence doesn't seem like a good use of everyone's time. Particularly when it's something nit-picky (like a clear MOS issue), I feel guilty having to "waste" someone's time to read, understand, and make the change, when I would have happily done it quickly myself. Some things, I don't even report, though I would gladly do them myself if I could. I know when to ask for help or input if it's something that could cause disruption or controversy. I'm sure there are others like me. —[AlanM1(talk)]— 20:19, 21 September 2013 (UTC)[reply]
135. Support, largely per Someone not using his real name and Betty Logan. It's been said many a time above that not all of our admins are skilled enough to feel comfortable editing templates, and I am going to assert that not all of our template coders are skilled enough to feel comfortable running for adminship. Go Phightins! 20:27, 21 September 2013 (UTC)[reply]
136. Support: This is really needed to speed up template editing. I do suggest one minor modifications though. The editor should have worked on the sandbox version of at least three fully protected templates. should be changed to The editor should have worked on a sandbox version of at least three fully protected templates. Some technical people like copy-pasting templates into their userspace to work on them over time without having someone else overwriting their changes (which may happen on the standard sandbox).--Siddhartha Ghai (talk) 20:52, 21 September 2013 (UTC)[reply]
137. Support - seems to be a good idea. APerson (talk!) 21:49, 28 September 2013 (UTC)[reply]
138. Support - After doing a thorough review of this proposal, it seems legitimate to have a separate user right for editors who are experienced in editing/modifying templates, modules and edit-notices. This will definitely help in reducing a bit of workload for many Administrators and other users, since the editors who are proficient in this area can do this work by themselves as they would already have the required skills and knowledge to do it by their own. Overall, the proposal and the reasons provided look valid to create this new user right. TheGeneralUser (talk) 15:04, 2 October 2013 (UTC)[reply]
139. support - sounds great to me. we need to have technically skilled users who can edit such sensitive templates without much issue. adminship is overkill if all they are going to do with the bit anyways is edit restricted templates. WP:buro tends to be grossly misinterpreted anyways. -- Aunva6^{talk - contribs} 07:15, 5 October 2013 (UTC)[reply]
140. Support---- — Keithbob • Talk • 16:59, 6 October 2013 (UTC)[reply]
141. Support as one of the drafters/proposers. Technical 13 (talk) 11:29, 9 October 2013 (UTC)[reply]
142. Support as proposer -- not that there was any doubt, but just for the sake of an accurate count :) equazcion� | 15:47, 9 Oct 2013 (UTC)
143. Support and I hope that the process for granting (and revoking) this right is kept light-weight. In fact, along the lines of Acalamari, my first preference would have been if editors granted the new right were technically able to edit any template (ie, no added complexity of new protection level was created). In rare instances when, for some reason, it was desirable that only admins edit a particular template, that could be indicated by an edit-notice on the page and the new right holders would be trusted to follow that (cf, how page protection due to WP:OFFICE-action is not undone by admins even though they are technically equipped to so so). In general we should be cultivating a culture of trust and norms, not relying on technical barriers. Abecedare (talk) 11:06, 12 October 2013 (UTC)[reply]

     For that solution to be technically possible, either a new extension would have to be installed, or users with this right would have to be able to edit any protected page (except user .js and .css, pages in the MediaWiki: namespace, and cascading-protecting pages). Jackmcbarn (talk) 14:31, 12 October 2013 (UTC)[reply]

     Thanks for clarifying the tradeoffs. I fear that targeting a new software extension (and re-running this RFC to test support for the approach I prefer) will just delay, and possibly derail, the whole process. And I am not comfortable with editors granted with template-editor rights being able to edit (almost) any fully-protected page, because if that were possible, eventually 1) template-editor right would come to be regarded as admin-lite and earning it would become as onerous a process as RFAs and 2) many RFA candidates would be told to apply and prove themselves as admin-lites before gaining additional rights...increasing wikipedia bureaucracy. Long story short: I do support the proposal on the table, although in an ideal world I would have it different. Abecedare (talk) 18:38, 12 October 2013 (UTC)[reply]

     Support. About half a year ago, I had proposed that a similiar right exist in this discussion. However, it seemed that my proposed discussion did not go anywhere, probably due to it being proposed at "closing time" for the Wikipedia talk:Protected Page Editor discussion, where I had posted the proposal. Glad to see that this proposal is getting a lot more attention than the one I tried to start did. Steel1943 (talk) 00:58, 13 October 2013 (UTC)[reply]

     Moved vote to Neutral. (see below.) Steel1943 (talk) 01:32, 13 October 2013 (UTC)[reply]

144. I Support this proposal, primarily as a way of "unbundling" some tasks that are currently restricted to admins. We need a control against preventing template vandalism &c but the current approach - full protection of much-transcluded templates - isn't a perfect control, because admins aren't required to have any template expertise - it's not one of the RfA exam-questions, and it shouldn't be. Let admins focus on core admin tasks, let template specialists work on templates - sounds good to me. bobrayner (talk) 12:54, 14 October 2013 (UTC)[reply]

1. There needs to be a better rationale before I could support this. Saying that coders don't want to have to verbalize their reasons for wanting the changes and therefore shouldn't have to isn't a suitable reason. If these fully protected templates are that important, shouldn't changes to them be made only by consensus? Wouldn't the reasons have to be explained anyway to get that consensus? I understand, though, that coders enjoy their work and want to do it themselves, so I would support a temporary right that was given by an admin, after the rationale for the change was explained, allowing the coder to make the changes him/herself rather than by proxy on a particular template or set of templates. —Anne Delong (talk) 11:54, 11 September 2013 (UTC)[reply]
   • Thanks for your question Anne Delong! Many of the requested changes are trivial and non-controversial; fixing a punctuation error, fixing a misspelled word, adding a new optional parameter, or expanding a template to allow more input based on an established pattern. Technical 13 (talk) 12:43, 11 September 2013 (UTC)[reply]

   • Typos should be easy to explain and have an admin fix. The other items you mention I feel should have consensus. Coders sometimes make changes that they consider trivial that may not be considered so by others. For example, in the Afc script the word "hoax" keeps being deleted from the decline reason "joke or hoax", with no discussion among the reviewer community. Someone perhaps thought (more than once) that this was a trivial change. Last week the decline template for a while neglected to list the name of the decliner. Before that, one day the link to the help page mysteriously disappeared from one of the templates. Since the protected templates must be considered more important than these ones, I would feel more comfortable if the coders had to explain what they were going to do, get permission from an admin, so that said admin could check afterwards to see that the result was correct and within policy. —Anne Delong (talk) 13:29, 11 September 2013 (UTC)[reply]

   • The situations you're describing are just as likely to occur when an admin makes the edit. Minor mistakes will occur from time to time no matter who is involved (incidentally, admins are not required to check with someone else before making their own minor edits, and we do have some admin coders). Adminship doesn't guarantee or even indicate any level of coding knowledge that would prevent mistakes. The best assurance that mistakes will be kept to a minimum is to get more competent coders involved, and currently, most of those are not admins, nor do they want to contribute their expertise at fully-protected templates, for the aformentioned reasons. equazcion ^(talk) 13:42, 11 Sep 2013 (UTC)

   Actually most of the admins admit they wouldn't know if the code was right, they just make the change in blind faith. So its better for the one who knows what the code is going to do makes the change so if there is a problem it can be fixed quickly without having to submit an edit request and wait anywhere from several hours to a week for it to get fixed. Kumioko (talk) 15:01, 11 September 2013 (UTC)[reply]

   ...which also touches on the problem of there being relatively few admins around who take it upon themselves to handle the queue of protected edit requests (I make no judgments there, it's just a fact). Forgetting about improvements, mere maintenance and required fixes can therefore take a while. equazcion ^(talk) 15:14, 11 Sep 2013 (UTC)

   • (edit conflict) The issues that you are describing Anne are with the Yet Another Articles for Creation Helper Script of which there has been a lot of rapid changes going on lately with many new features to adapt to using the latest code (the team has been converting much of the script to jQuery and adapting to use CSS3 / HTML5 lately) to improve load times and prevent mass failures when the old code is no longer supported by browsers and to offer an in-house option for reviewing drafts which fall under the fairly new CSD:G13 criteria. It was determined by the lead developer of the script that the decline template was not showing the the decliner and timestamp of decline on your report because the edit was made manually and not using the script (ticket on GitHub). Also, for the record, the decline template is fully protected (verify) which means that when things go wrong, none of the AFCH developers (mabdul — Nathan2055 — Technical 13 — Theopolisme — Hasteur: — APerson241) can quickly fix it and it needs to sit there until a request is answered by an admin, which usually takes days to fix. Technical 13 (talk) 15:48, 11 September 2013 (UTC)[reply]

   Well, I said that I opposed because I thought the rationale was weak. Some of the items being brought up here are legitimate points and should be added to the rationale. —Anne Delong (talk) 22:56, 11 September 2013 (UTC)[reply]

   (opposition weakening..) Although I still don't think that this new privilege is really necessary, some good arguments have been made about why it would be convenient and maybe desirable. The template editing qualifications seem well thought out. The edit count seems a bit low; that's about two weeks of editing for me, and it takes experience to work within Wikipedia's policies. I'm also little concerned about the weakness of the "trust" qualifications. Just not being blocked or edit warring lately isn't much of an endorsement. How about adding having demonstrated an understanding of the consensus process? And I wouldn't like to see admins wait until there is a "pattern" of controversial editing without consensus before suspending the privilege. —Anne Delong (talk) 16:18, 13 September 2013 (UTC)[reply]

   • I had the same concern on reading the proposal. If "verbalize justifiable edit requests" is changed to "verbalize uncontroversial edit requests", my concern would disappear.--Wikimedes (talk) 23:38, 14 September 2013 (UTC)[reply]
     • That seems reasonable, so I made that change as suggested. equazcion ^(talk) 23:44, 14 Sep 2013 (UTC)
2. Qualified oppose For the same reason as the last time something like this came up several months ago. I remain unconvinced this is a serious problem, to such an extant that such drastic measures are rerquired to resolve it. I also still support the much simpler idea of re-purposing pending changes level 2, which is currently more or less unused, to accomplish the exact same thing 'without creating new user rights and protection levels, which by the way we cannot simply will into existence. Do we even know if the WMF is aware of this idea? Will the devs even work on it? Do those proposing this realize that even if this is approved and the WMF agreees to implement it it will probably take six months to a year to become a reality? Despite all the previous discussion this still strikes me as a poorly thought out proposal that ignores a much simpler option using tools we already have. Beeblebrox (talk) 15:39, 11 September 2013 (UTC)[reply]

   See this discussion in the drafting talk page of this proposal, where the possibility of using PC2 this way was discussed. There are a few problems with using PC2 this way currently, and would require changing the way the permission works in a number of ways, ie. coding. It's actually simpler to create a new permission, as that would only require a little new text in the MediaWiki configuration file. In that same discussion, you'll see that a few developers are aware of this proposal, and one of them stated that a new permission is feasible should the community decide on it. equazcion ^(talk) 15:44, 11 Sep 2013 (UTC)

   PS. There is also the fact that PC2 has been given out to many, many users already without this functionality in mind. If we're to assume the ability to edit high-risk templates should require some degree of special vetting, it doesn't seem feasible to reuse a permission that's already been given out exhaustively to those who haven't gone through any such vetting. equazcion ^(talk) 15:53, 11 Sep 2013 (UTC)

   Is the administrator toolset a response to a drastic situation, or do we not provide it to trusted users in order to assist them in the kinds of efforts they already carry out? This provides a... drastic... increase in productivity to experienced coders. - Floydian ^τ _¢ 18:09, 11 September 2013 (UTC)[reply]

3. Oppose Once upon a time, some visionary people set out to build an encyclopedia based on the absurd notion that the general populace could be trusted to do the right thing. Further, that any would be evil doers would be so out numbered by the good people that the end product would be exceptional. They were right. Here we sit upon the mount of 4.3 million articles created by this mass of general population who were trusted to do the absurd thing of creating an encyclopedia. And now we set forth to say "No, we do not trust you. No, what you have created must be protected from you. No, you must now seek out special privileges in our ever expanding bureaucracy". Look at yourselves in the mirror people. If the attitude expressed here existed when Wikipedia began, Wikipedia wouldn't even exist. TRUST the masses that created this damn project and unprotect the templates. Not ONCE have I ever committed vandalism, but I can't be trusted to edit a template even though there's been numerous times when I've needed to. No, instead I need to ask someone who is "trusted" to do it for me, because I'm not trusted. What asininity. --Hammersoft (talk) 21:33, 11 September 2013 (UTC)[reply]

   You may have a point, but in the absence of your ideal situation, wouldn't it be good to get things a step closer to it by providing access to more of the people who need it, rather than taking an all-or-nothing stance? equazcion ^(talk) 21:42, 11 Sep 2013 (UTC)

   No. Either you trust people or you don't. You don't expand bureaucracy to solve the problems of the expanding bureaucracy. --Hammersoft (talk) 21:53, 11 September 2013 (UTC)[reply]

   This seems like letting the perfect be the enemy of the good, Hammersoft. I think I understand your perspective here (although I tend to disagree), but I think that argument has already been lost. I don't imagine there's going to be a consensus to unprotect highly used templates back to semiprotection or no protection. If that's true, then what's the best way to enable you, and experienced users like you, to edit these templates? I think this is. --Floquenbeam (talk) 22:11, 11 September 2013 (UTC)[reply]

   Hammersoft, this proposal would not take away any abilities that the editors have now; it would do the opposite, giving some users extra capabilities, giving them more trust. So this should be a move in the direction that you would like, even though not all the way. One possible side effect: Once there are lots of coders editing the protected templates, this may lead to the idea that more templates need to be protected, since one of the reasons for not protecting them will have been eliminated. —Anne Delong (talk) 22:50, 11 September 2013 (UTC)[reply]

   My point is to give the right back to where it belongs. This is like taking my right away, then telling me things are improving because more people will be able to answer my requests to have work done for me by proxy. And I should be happy about this? How many years, how many edits does it take for someone to be trusted enough to edit the most visible article on the project? I'll answer for you. Zero, in both cases. Yet, I can't be trusted to edit a template? I'll tell you what will happen. This is passing with flying colors, 8:1 right now. A year from now, far more templates will be protected, and I will have even LESS privileges on the project to do the work I've done in the past. But that's ok, this is the project that ANYone can edit...so long as you're "TRUSTED". But I'm not trusted, because I'm just a lowly stupid editor who can barely ties his shoes. --Hammersoft (talk) 12:58, 12 September 2013 (UTC)[reply]

   An edit on an article can cause an error on an article. An error on a template can cause an error on several hundred thousand articles and present server issues. That is the reason for that difference. I don't disagree with you about the possibility of your second point and that should be actively fought against. SFB 21:10, 20 September 2013 (UTC)[reply]

4. Oppose I'm worried that having this available will lead to it being used when semi-protection would be more appropriate, which is contrary to the goal of letting more people edit more templates. I think a stronger guideline is needed for when each level of protection should be created before this becomes available. Jackmcbarn (talk) 12:33, 12 September 2013 (UTC)[reply]

   Jackmcbarn That's a valid point that was brought up during drafting, and probably should have been addressed in the RfC text initially. I've now added something about this above, under #Privilege. equazcion ^(talk) 12:50, 12 Sep 2013 (UTC)

   @Equazcion:I don't feel like including a paragraph saying "make sure this doesn't happen" will keep it from happening. I think a stronger solution is needed Jackmcbarn (talk) 17:35, 15 September 2013 (UTC)[reply]

5. I strongly support tool unbundling in general and as such I would prefer the implementation of a userright that would allow non-admins to edit any fully-protected page rather than just some. I'm not convinced that over-specialization like this is warranted: as I am sure that anyone seeking this userright would be held to high standards, I think that if someone is trusted to edit one type of protected page then they can be trusted to edit (or trusted to not edit) another. Without wanting to resort to hyperbole, I'd rather this not become a stepping stone to having multiple and confusing protection userrights for non-admins when one would do. I'm not convinced by the "problem" of single-purpose candidacies at RfA, either: they are not overwhelming the process nor are they a major burden. Acalamari 13:25, 13 September 2013 (UTC)[reply]

   Many people still seem uncomfortable with single-purpose RFAs though, enough that getting them to pass is hit-or-miss; and that's disregarding the fact that most avid coders have no interest in putting themselves through RFA, nor with its other associated tools. As proposals to unbundle the way you suggest have failed repeatedly, wouldn't it make some sense to make a concession and implement a next-best option that might finally get our avid coders working where they're needed? equazcion ^(talk) 15:05, 13 Sep 2013 (UTC)

   I don't know whether there's anything you could add to the proposal to address the specific point about it being "a stepping stone to having multiple and confusing protection userrights for non-admins". It's a valid concern, though IMO the technical element makes this a one-off situation. - Pointillist (talk) 16:27, 13 September 2013 (UTC)[reply]

   It's not entirely clear to me what would be so bad about further area-specific rights cropping up in the future, if it means more of the people who are good at something specific are allowed to do it, while also alleviating the concerns of those who would rather not give out far-reaching tools packages. I'm rather skeptical that "confusion" will ensue, nor that even if some people did end up confused when they looked into the various rights available on Wikipedia that that isn't something that could be dealt with rather easily. Furthermore, I'm of the opinion that as steps like this are taken, an actual unbundling could begin making more sense to more people down the line, and individual rights may start becoming combined. Either way, none of this can happen if we don't start actually implementing steps, choosing instead to demand that our many widely varying individual ideals are met fully. Everyone has their ideal of what Wikipedia should be, but making demands based on those ideals keeps us from progressing at all. equazcion ^(talk) 16:36, 13 Sep 2013 (UTC)

   Mmm, but then this RfC would have to be about unbundling in general rather than this specific case. There are special circumstances for template maintenance that are part of the reason the proposal is getting so much support. I'm not saying there would be anything necessarily "bad about further area-specific rights cropping up in the future", but of course other editors might be concerned about gradualism/thin end of the wedge etc. It's best to keep this RfC as narrow as possible, IMO. - Pointillist (talk) 16:55, 13 September 2013 (UTC)[reply]

   It could be that down the line unbundling may start making sense to people if several area-specific rights seem to entail similar virtues. That doesn't mean this RFC need be about unbundling. I don't know what will happen in the unforeseeable future nor is such forecasting a part of this proposal. It's just one possibility. What I do know is that those who want that to happen are not serving themselves by demanding that it happen now or else no arguably small part of it can, as the former has proven unlikely. equazcion ^(talk) 17:12, 13 Sep 2013 (UTC)

   Agree 100% - Pointillist (talk) 18:12, 13 September 2013 (UTC)[reply]

6. oppose per Hammersoft and Jackmcbarn. Also, guideline #1 for granting this "privilege" is near-absurd and would only drive new template editors away, and probably stems from Wikipedia's general paranoia and disregard for anonymity. — Lfdder (talk) 17:45, 13 September 2013 (UTC)[reply]

   As proposals such as these have generated resistance in the past from those concerned with such rights falling into unproven hands, the guidelines were written conservatively in the hopes of alleviating those concerns. Coming up with guidelines that will be more or less universally acceptable is a challenge that can yet be tackled in the future should this pass; and the guidelines are far from hard-and-fast rules. The granting administrators will use their own discretion in assessing whether an editor has proven themselves capable and trustworthy. equazcion ^(talk) 18:06, 13 Sep 2013 (UTC)

7. Oppose I don't see the need. Basically, I agree with Beeblebrox. If people want to argue like they did with the other six opposes, I rarely revisit !votes.--Wehwalt (talk) 00:03, 15 September 2013 (UTC)[reply]

   Just FYI, I didn't post arguments in those cases in order to garner responses from those who opposed; but rather to let onlookers know that there are counterpoints to the unique issues those opposers raised. You haven't done that, so I won't be posting an argument here. equazcion ^(talk) 00:22, 15 Sep 2013 (UTC)

8. Oppose: "While full protection is an ideal temporary solution for templates that have demonstrated a state of overwhelming controversy, it is less ideal as a permanent precautionary measure for articles. Many editors who have shown an aptitude for editing articles, and have earned the trust of the community in doing their work, may not necessarily be administrators, nor even be interested in becoming administrators.
   "Non-administrators do have the ability to request edits at fully-protected articles for administrators to enact on their behalf, but there is a significant shortage of administrators who have the time and necessary equanimity to do this reliably. Editors also tend to find this extra step more than a mere annoyance: Editing work is largely rewarding to linguistically-minded people in that they value the creative experience. Many end up choosing to avoid having to verbalize uncontroversial edit requests made to convince someone else to enact an edit on their behalf, by simply avoiding work on fully-protected articles altogether.
   "As there is currently no measure that would allow access only for trusted editors with article-editing know-how, some editors have resorted to applying for adminship..." Brycehughes (talk) 05:50, 15 September 2013 (UTC)[reply]
   • I understand the point you are making but the parallels are not the same. ( I do think that there should probably be a protected page editor right however, but that is not this RfC. ) Full protection is not a temporary solution for templates.... and permanent protection is not as common for articles. The page "Blue" doesn't get protected just because the color blue is used on a large number of pages; but for template space that alone would be a good reason for the page to be fully protected. There is a much larger pool of admins that will assist with protected articles—especially as such pages tend to be contested and on the watch list of active admins—while there are only three admins actively watching for edit requests to templates. A delay in making a fix to an article will leave just that article in a "imperfect" state for the time it makes for the edit request to be acted upon. A delay in making a fix to a high visibility template will leave a lot of pages broken. Also changes to templates might require changes to all the pages that use the template, which means that any overhead in the process can get magnified. PaleAqua (talk) 06:45, 15 September 2013 (UTC)[reply]

   It's not the number of protected templates vs. articles that matters; it's the frequency that they're edited—or, rather, have people wanting to edit them. Why do the technically-minded get a back door? Brycehughes (talk) 07:04, 15 September 2013 (UTC)[reply]

   It's not about whether or not people are technically minded. The point is that articles aren't protected "just as a precaution", whereas many templates are. To quote the protection policy "Pre-emptive full protection of articles is contrary to the open nature of Wikipedia." No one is arguing that we need to be as open with high-use templates because of the potential for mess. Yaris678 (talk) 07:52, 15 September 2013 (UTC)[reply]

   I don't see how the reason why a page or template gets protected has any bearing on whether or not there exists a genuine problem that needs to be solved for the good of the Wikipedia project. I do see how having templates preemptively protected might annoy a group of people who like to edit templates. Brycehughes (talk) 08:04, 15 September 2013 (UTC)[reply]

   If there was a load of pre-emptively protected articles, people would probably be arguing for a user right to edit those too. Yes, that argument would probably come from them being annoyed at not being able to edit the pre-emtively protected articles, but is that so bad? Surely not annoying users is a good thing. Yaris678 (talk) 09:34, 15 September 2013 (UTC)[reply]

   It's bad when it's the sole argument for creating yet another user right. How many are there now? 16? Everyone else has to WP:CHILL and wait for their edits to go through. I don't see why we need to make a special exception for template editors. Brycehughes (talk) 14:41, 15 September 2013 (UTC)[reply]

   It's not merely about annoyance, if you read the rationale both above and in the linked discussions; although for the sake of argument, if it's annoying enough that the people who can work on something stop working on it altogether, that could be reason enough. If articles were preemptively protected and required edit requests, and that caused all the skilled content contributors to stop contributing content, people would likely consider that reason to consider a change. In any case, to answer your "back door" comment, templates are full-protected because people without the necessary skills and responsibility can end up causing a lot of damage via a one-time mistake. All those various "oops" edits that occur in article space could cause massive problems if they occurred at high-use templates. That's why those who have been vetted as knowledgeable and responsible in this area are being proposed as receiving said permission. It's not about seeing technically-minded people as a higher class that deserves special treatment -- they're just uniquely suited to safely help out in this specific area. equazcion ^(talk) 14:59, 15 Sep 2013 (UTC)

   That doesn't make sense. According to the proposal, the right will allow editors to make "simple and generally uncontroversial edits to templates", while more "complex or controversial edits" will be subject to testing and consensus. What is the requisite skill level for making a simple edit? This isn't about creating a new tool that only the most "skilled" and "responsible" among us can employ immediately in those dreaded template-emergency situations—indeed, those situations are preempted by precautionary protection. Rather, it's about creating a new privilege for a group of people who have the wherewithal to lobby the Wikipedia community for their own user right. Brycehughes (talk) 15:35, 15 September 2013 (UTC)[reply]

   There's no requisite skill level for making a simple edit. There is a requisite skill level for determining which edits are simple, however. As for creating a new privilege for those who can, I'd say if you were familiar with the history you probably wouldn't be saying that. This has been a multi-year-long headache that failed many times over, and pretty much no one has had the lobbying strength to push through thus far. Those who would be getting the permission in question wouldn't have kept this up for this long just because they can, as so far, they decidedly can't. And if it makes any difference to anyone, I, the author of this proposal, do not plan on applying for the permission should it become a reality. In fact if this RFC closes as a pass, I'll likely be re-hanging my "retired" banner. equazcion ^(talk) 16:28, 15 Sep 2013 (UTC)

   If it were true that there was a requisite skill level for determining which template edits are simple, then all templates would need to be protected from editors who didn't have those skills. But they're not, because your statement is untrue. Regarding your multi-year long headache, how does that refute my point? Lobbying efforts for special privileges can't fail? They can't last for years? It has no bearing on the cost/benefit analysis before us, other than confirming that the issue has been correctly decided in the past. Brycehughes (talk) 17:07, 15 September 2013 (UTC)[reply]

   I bring up the history because you've assumed an ulterior motive. You say those who would get the permission are responsible for lobbying for it, and are doing so simply because they can, and because it would benefit them, so why wouldn't they. I'd contend that after the first try or two at getting something just 'cause they can, it would've seemed apparent that they can't. At this point it should be discernible that it's gone on this long because many people aside from those potential editors believe the encyclopedia needs this, and/or that it would at least be an improvement. Of course, the accusation that techies started this and should be blamed for incurring all this unwarranted support is not really something anyone would be able to prove either way. All I can do is tell you that I won't be getting the permission myself if this goes through, which I should hope at least shows my own intentions. I can also ask that you look at the potential net cost of this proposal versus its net gain, rather than attempting to assess everyone's motives. equazcion ^(talk) 17:28, 15 Sep 2013 (UTC)

   I haven't assumed an ulterior motive. I've assumed a motive in plain sight, as it also happens to be your premise. The proposal background clearly states that people who like to edit templates do not like to wait for their edits to be approved. By implementing this proposal, Wikipedia will make people who like to edit templates happy. Were I one of them, I would probably think this was a great idea too. But, in the bigger picture, I would also hope there'd be people outside of myself and my template-editor peers to zoom out and weigh the benefits of bestowing special privileges onto a certain group of editors against the cons of establishing yet another editor hierarchy as it affects the project at large. There are no accusations here, other than an attack on the weakness of the proposal. Brycehughes (talk) 17:55, 15 September 2013 (UTC)[reply]

   I forgot to answer your first point: "If it were true that there was a requisite skill level for determining which template edits are simple, then all templates would need to be protected from editors who didn't have those skills." -- Most templates aren't widespread enough that bad edits to them would cause significant issues. They're protected because they exist on many thousands of pages. It would take a requisite skill level to determine whether an edit is simple enough to be made without risk given the pervasiveness of the template. equazcion ^(talk) 17:45, 15 Sep 2013 (UTC)

   Then spend your template editing time editing the majority of templates that aren't widespread enough to pose this risk. For the templates that are permanently protected, make an edit request. Just like everyone else. The world won't end before you see your protected template edit go through. Brycehughes (talk) 18:00, 15 September 2013 (UTC)[reply]

   "Then spend your template editing time editing the majority of templates that aren't widespread enough to pose this risk." -- That's precisely what they do currently. And so, work on the widespread templates suffers. equazcion ^(talk) 18:04, 15 Sep 2013 (UTC)

   As it should, because they're high risk. Brycehughes (talk) 18:07, 15 September 2013 (UTC)[reply]

9. Oppose - Poorly thought-out proposal. The criteria for granting the user right are a horrible case of WP:CREEP and I also fail to see the point of it - from the three-template requirement this seems to be aimed at users maintaining templates across the whole site rather than specific ones relevant to their area, who will still have to use {{editprotected}}. If somebody's that interested in sitewide maintenance encourage them to run for adminship. If not, use sandboxes and {{editprotected}} like the rest of us. The main problem here isn't the lack of a userright, it's the overuse of preemptive protection. --W. D. Graham 08:45, 15 September 2013 (UTC)[reply]
10. Oppose-This could lead to a lot of abuse. The criteria to attain this status isn't stringent enough for the power to not be abused. Snood1205 (talk) 01:02, 16 September 2013 (UTC)[reply]
11. Oppose As an ad hoc "rule creep" -- we should then need a "ref fix flag", a "typo fix flag", a "personal attack deletion flag" etc. - I can think of a dozen or more special purpose flags which would then make sense. Absent a real reason for this addition, I oppose. Collect (talk) 13:20, 16 September 2013 (UTC)[reply]

    You are comparing apples to oranges here. One does not currently need administrative privileges to fix references, fix typos and delete personal attacks. However, one does need administrative privileges to edit fully protected templates. AutomaticStrikeout (₵) 17:10, 20 September 2013 (UTC)[reply]

12. Oppose its a good idea but I don't think this will go as expected. and it could cause some problems. A little stricter and a little clearer. we may have something good here until then I oppose. FockeWulf FW 190 (talk) 15:10, 16 September 2013 (UTC)[reply]
13. Oppose. I don't see why this is necessary and agree this would be too much fragmentation. If a user can be trusted to edit fully protected templates, surely that same user can be trusted with any admin task. If they don't want to perform any other admin tasks, there is no requirement that they do, so they can simply work only on templates if they so choose. We are all volunteers, after all. And if they don't want to be admins at all (or to go through the process), then they can continue working on templates in sandboxes and then submit requests for updates when done. Slightly inconvenient, perhaps, but hardly something that requires an implementation of a new right.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); September 16, 2013; 19:45 (UTC)
14. Oppose -- the ability for more technically-oriented people to edit protected templates is needed, but the solution is to let them be admins. Ëzhiki's argument just above is something I completely agree with. -- Michael Scott Cuthbert (talk) 03:23, 17 September 2013 (UTC)[reply]

    While some might believe that to be ideal, the current state of affairs precludes that as a viable solution. These editors predominately don't want to apply for adminship, and even for those editors that might, the general feelings in the community on whether or not to promote people who do apply for adminship for that single purpose alone are divided. The tools available to admins encompass a broad range of areas that many feel a potential admin should prove themselves knowledgable and capable of using for the most part, as well as, arguably, demonstrating a certain political stature. Many would like that or other ideals to win out, but a compromise may be the only practical solution available for the foreseeable future. equazcion ^(talk) 03:42, 17 Sep 2013 (UTC)

    I can very well understand one's unwillingness to go through an adminship application or editors' unwillingness to grant an admin bit for template work alone, but I still fail to see what's so impractical about editing the templates in a sandbox and then requesting an update when the work is done. I've done a fair share of template work myself, and whether one is an admin or not, highly visible templates which are protected should never be worked on live anyway. So in essence, the difference between an admin like me and a non-admin template worker is that I can post my work myself once I'm done while a non-admin would have to place a request and perhaps wait a couple days. I just don't see what's so problematic with this approach to require an implementation of a new right?—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); September 17, 2013; 13:52 (UTC)

    Trappist's answer to Question #8 provides a little insight there, as do many of the support comments above. The current system is inefficient and discourages techies from contributing. Edits should be able to be confirmed among peers who are actively involved or at least interested, rather than requiring the approval of some whose job it is to go around to various unrelated projects they aren't familiar with to try and evaluate whether an edit is sound. The nature of coding makes answering protected edit requests in those areas a substantially different and involved endeavor compared to protected article edits -- which is why there are practically no administrators who actually take it upon themselves to do it. I'd stay away from it myself were I an admin, even though I have the coding experience to be helpful -- It's just a headache-inducing undertaking to have to dive into projects you know nothing about, repeatedly, to try and untangle and decipher these changes and their ramifications (made more difficult by the fact that template code is more difficult to make organized and readable, without affecting functionality, than most of other programming languages; and the fact that, to my knowledge at least, there is no real development environment available to facilitate those investigations, beyond the plain old wiki edit box). In the end, though, even though it may be hard for you to see why the current system isn't working, the fact is that it isn't, as avid coders do tend to avoid work on high-use templates. This in itself is problematic, and if we can enact a change would change this, and would do so safely, then we should. equazcion ^(talk) 14:13, 17 Sep 2013 (UTC)

    Thanks for the explanation, I appreciate it, but I don't see the situation like that. It is indeed a lot of work to go through someone else's coding job and try to decipher it, but is it really necessary? Bugs are an inherent by-product of template work and may surface later even with the most diligent approach. I personally would approve any template change request as long as the sandbox contains examples of how the template being changed looks currently and how it would look/behave after the change. I may or may not ask for (or try out myself) additional test cases or clarifications if something looks not quite right, but as long as there are no visible problems and any major changes have a consensus, there is no need to dive deep into the code and try to parse it on the off-chance a bug has snuck in. And if I happen to approve a modification which leads to some overlooked serious problems, I'm prepared to roll it back (or see it rolled back by another admin) at the first sign of trouble. The job of an approving admin is not to make sure the change is flawless, it is to make sure that it is not malicious, is functional, and reflects the consensus of everybody involved. Some time commitment on the part of the reviewing admin is required, of course, but no more so than with any other protected edit request.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); September 17, 2013; 14:36 (UTC)

    Well, we could argue about how much need there is to make sure edits are sound, or what degree of confirmed soundness is required; but whichever way that discussion would go, I think we can agree that it's better if it's easier to catch more potential bugs earlier. Letting more of the more equipped people make those evaluations improves the situation. Is it necessary? I'm not sure what it means, really, when people say something isn't necessary and thus shouldn't be done. Many of the things you and I have come to rely on were the result of improvements that were not necessarily... well, not necessarily "necessary". And this would be an improvement, no matter how you look at it, even if there's some disagreement over degrees. There's also the issue of fixes needed sooner rather than later, which could be implemented more swiftly if more people in the know were both actively involved and had the required permission. The only real against argument (in relation to your comments) is the hierarchy confusion one, which I don't think actually translates into any practical issues -- though we'll probably have to agree to disagree over that. equazcion ^(talk) 14:55, 17 Sep 2013 (UTC)

    Well, I'm not trying to win you over to the dark side :), I'm simply trying to clarify my position to whoever else might be reading this, so it's perfectly OK that we disagree. What I meant by "necessary" is simply that one shouldn't hesitate to review a protected template edit request simply because they don't want to parse the code modifications. Making sure that there are no obvious problems (which can actually be done with minimal technical knowledge) should be sufficient. And if they can parse the modifications, that's just an added bonus. What you are trying to say (if I'm reading you correctly), that this is not a prevalent attitude among the reviewing admins, who prefer either to make sure everything is in order down to the most minute detail or not to bother with the review altogether (and the latter happens more often). I have no reason not to believe this (if this is what you are saying), but based on my experience, I haven't noticed it to be the case. Hence my oppose. Cheers,—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); September 17, 2013; 15:25 (UTC)

    Support #5 indicates that the prevailing practice among admins is to avoid reviewing altogether; and I further wouldn't necessarily chalk that up to a desire to understand minute details. "And if they can parse the modifications, that's just an added bonus." -- This proposal would make that "bonus" more widely available, in fact perhaps standard. equazcion ^(talk) 15:34, 17 Sep 2013 (UTC)

    Thanks for pointing that comment out; it's an enlightening one. However, one could equally argue that even if it takes a couple of weeks for the changes to be applied, it's still no big deal (and in fact it provides a cool-down period during which the template writer can look at his or her work afresh and perhaps see some problems which escaped their eyes first time round). On the other hand, for templates where applying a change quickly is crucial, one would think that the people interested in implementing it would actively reach out to some individual admin who shares their interest and is willing to help implement the change. At any rate, from what I've seen the unwillingness to implement the changes to protected templates stems more from the controversies often surrounding such changes rather than from the lack of technical expertise—a problem which the proposed flag is more likely to exacerbate rather than alleviate.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); September 17, 2013; 16:01 (UTC)

    I'll leave most of this alone as I think we've each laid out our feelings adequately enough. However you kinda tacked on something new at the end there that I think warrants addressing. It's not a refusal to implement changes that we're addressing, nor is that a prevailing issue. I'm assuming you mention this in response to my pointing out that you haven't made a practical argument against, but I have to call foul on that particular one, as it's a catch-all argument against many things. Disagreements will of course occur anywhere from time to time, but contention hasn't been the prevailing issue at high-use templates. It's the lack of fundamental participation, both by admins and coders, due to the inefficiency of the whole process. Controversial changes will require consensus to be established first, as stated in the proposal, or else the enacting editor's permission will be in jeopardy. equazcion ^(talk) 16:55, 17 Sep 2013 (UTC)

    You are right, my last bit wasn't particularly related to the proposal and describes a whole different aspect of the template coding process which is not quite relevant here (regardless of whether one agrees with it or not). I do stand with the rest of my arguments, however, since I'm hesitant to accept anecdotal evidence and conjecture in support. I do, of course, realize that my arguments may be seen as anecdotal as well, which is why a broader community input is beneficial. It looks that things are going towards supporting this proposal anyway. If my assessment turns out to be wrong and the new bit is going to bring nothing but benefits, so much the better. If my (and other opposing editors') assessment that the new bit would be problematic turns out to be right, then it can be rolled back fairly easily (I hope). Cheers,—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); September 17, 2013; 17:59 (UTC)

    Thanks for all the good and thoughtful comments to my Oppose vote -- it definitely appears that the proposal will pass, so it is good to know that those who support it have thought so deeply about the subject. I will keep the oppose here because I think that opening up adminship to get more contributors involved who have worked well on any aspect of the project is one of the most important changes that WP needs to make to keep up its energy; so definitely if that's not going to happen, I support this proposal, but I wish we could devote more effort to adding to the number of admins. This proposal will probably make that process even harder. -- Michael Scott Cuthbert (talk) 21:41, 18 September 2013 (UTC)[reply]

15. Oppose - Registered users should be the default editing circumstance for almost everything, and sadly this is one more move to show some elitism and assuming a lack of good faith on the part of those rank and file individuals (many such as myself who have been editing and participating on Wikipedia for many years) who need to be trusted. If anything, there should be evaluations about many templates as to if they really do need to be protected and why.... including on the "front page". If you want to change the criteria for a "trusted registered user", that is certainly a legitimate debate. In this context, however, I fail to see how merely semi-protecting a template is any worse than granting this "right" to hundreds or thousands of "trusted users". I also see this being a situation where many sorts of templates that at the moment wouldn't even be considered as something to be fully protected would then have that protection status added.... or that even further "levels" of protection might need to be created that still make those templates "admin edits only". This really is feature creep at its worst. --Robert Horning (talk) 19:21, 17 September 2013 (UTC)[reply]
16. I didn't think i'd revisit this RfC after commenting a couple of times, but i believe it is incumbent upon me to Oppose. As Robert Horning says or implies immediately above, the default position ought to be that regular, registered users can edit almost anything; if it's so fragile or important that they shouldn't be allowed to, we do have a process which allows them to show they have the community's trust ~ it's called RfA, and the one which was the proximate cause of this discussion has passed, showing that sufficient members of the community are prepared to trust someone to do what he says he'll do. I also think, as a couple of other users have mentioned, that this is a possible example of rule creep; or maybe of getting something (unbundling) in by a side door because the front door is closed. That previous sentence might be read to imply poor faith on the part of the filers or supporters; i had no intention of allowing that inference, and apologise for the poor wording. Cheers, Lindsay^Hello 17:27, 18 September 2013 (UTC) Edited to clarify intentions 18:18, 18 September 2013 (UTC)[reply]
17. I think this goes directly against founding principles. Read User:Jimbo_Wales/Statement_of_principles. The genie is already out of the bottle, so calling this a slippery slope would just be beating a dead horse. How's that for a mixed metaphor? Almost any level of hierarchy is bad for the project, including degrees of hierarchy that have been with us since 2003. Speaking as someone who has created and edited several templates, I understand the arguments both ways, but I'd prefer an openness in editing that immediately trashes hundreds of pages (and thus, is quickly noticed and fixed) to a closed system where the onus is on the community to determine who is trustworthy and who is not. Focus on the articles, not the article-writers.Imzogelmo (talk) 03:10, 19 September 2013 (UTC)[reply]
18. If the administrators really think this is a problem for them, I think the solution should be "reduce the number of protected templates" or "increase the number of administrators" (which might include reduce the requirements of administrators). We don't need another layer of rights McKay (talk) 20:20, 19 September 2013 (UTC)[reply]
19. I think there is definitely a problem here, but I don't think this proposal is the best way to address it. I find Imzogelmo's comment fairly persuasive; we do not need an additional layer of bureaucracy here. But more than that, I see two issues that should be addressed:
    (1) we should focus on ways to make it easier to edit templates, perhaps using some hybrid of Drafts and FlaggedRevs; and
    (2) we should focus on making page protection much more flexible (we currently have two hammers for every kind of nail and this isn't serving us well at all).
    Creating an additional protection level somewhat moves us closer to the second goal, but not without a lot of extra baggage. For any page, it should be possible to easily specify "you need more than X edits" or "you need to have been a registered user for longer than Y" in order to make an edit. This would allow us to stop fully protecting so many pages when semi-protection isn't adequate, in my opinion. --MZMcBride (talk) 22:12, 19 September 2013 (UTC)[reply]

    Those are lofty goals that may perhaps one day become a reality. As I've said before, there are solutions that some might call more ideal, but under the current circumstance it makes little sense to demand them and block anything else, while a less-than-perfect (depending on your perspective) solution is on the table that would still improve things. There's almost no chance of your suggestions happening in the foreseeable future, while this proposal could be implemented immediately. There's no "extra baggage" here beyond that which would come with your suggestions. In fact I think this proposal carries significantly less "baggage" than combining drafts, flagged revisions, and vast page protection options that would require significant software and procedural changes; even if those could result in a more powerful system. This is a user right, it's implemented without any new software coding, and is assigned and revoked without any significant process. equazcion ^(talk) 22:39, 19 Sep 2013 (UTC)

    Sure, we have to avoid making perfect the enemy of the done. It's a balancing act, it always is: you can accept a temporary fix and try to hope it won't become permanent or you can wait for a proper solution. One of the more painful consequences to accepting the temporary fix is that it discourages the development of a proper solution. This is one of the situations where I personally think the hack (read: quick fix) is doing more harm than good. The software should be better. I'd like it if the hundred-plus editors here would help make the software smarter. In addition to the two points raised in my comment, a third is the current inability to create arbitrary user groups through a user interface. Bureaucrats should be able to create local user groups with arbitrary user rights just as stewards can create global groups with arbitrary user rights. There are a lot of potential solutions here, but I don't think adding a protection level and a user group moves us forward in the direction I want to move. --MZMcBride (talk) 03:50, 20 September 2013 (UTC)[reply]

20. I just finished reading all this and need some time to digest it all; however, to oppose is my first, gut feeling on it. I do deeply agree with Acalamari's 5. I strongly support tool unbundling in general and as such I would prefer the implementation of a userright that would allow non-admins to edit any fully-protected page rather than just some. When an editor has performed many thousands of good and helpful improvements, adminship should become a given. At this point, though, it appears to me that the creation of another protection level is just a loose bandaid. And yet, why dishearten good template coders by the present, not-so-subtle system of making them feel untrusted? It's an open can of worms, truly, and I feel there are better ways to find a bigger can. – Paine Ellsworth ^CLIMAX! 17:26, 20 September 2013 (UTC)[reply]
21. If a template is so sensitive to damage that its default state must be fully-protected, it probably is a useful delay for changes to run through edit-protected and thus under multiple sets of eyes. Christopher Parham (talk) 22:55, 26 September 2013 (UTC)[reply]

1. I really want to support this but I think the guidelines for granting needs to be expanded. In my opinion, this userright ranks up there with edit filter in terms of potentially causing widespread damage to the site. In order for non-admins to become an edit filter manager, there needs to be a discussion first. I think that this userright should have a similar process to the way edit filter manager is granted. Elockid ^(Talk) 21:12, 27 September 2013 (UTC)[reply]

   That seems like a fair point, but can you point me to a description of the way edit filter manager is granted? I've wasted 20 minutes trying to find a summary of their process without success—I must be looking in the wrong place. Thanks - Pointillist (talk) 22:11, 27 September 2013 (UTC)[reply]

   There's a brief description of it at the end of the lead at WP:Edit filter. Elockid ^(Talk) 23:04, 27 September 2013 (UTC)[reply]

   While someone could vandalize a massive number of pages at once with this user right, the damage from that could be corrected very quickly. The edit filter could cause even more widespread problems, and there could be damage done that would be a lot harder to undo, and in some ways impossible to undo. Monty₈₄₅ 02:13, 28 September 2013 (UTC)[reply]

   Reverting the vandalized template is easy, yes. Finding the source of the problem, no. When a template vandal, User:Earth Exploding Live vandalized templates (they weren't protected but I'm just giving an example), it was very difficult for even the most seasoned vandal fighters to locate the source of the problem. With the edit filter, we can locate the problem pretty quickly. It's much easier to fix edit filter problems, I've dealt with both personally. Elockid ^(Talk) 02:20, 28 September 2013 (UTC)[reply]

   How do you undo the damage done when an edit filter blocks everyone on wikipedia from editing, discards the edits they tried to make, and gives them a warning about their misconduct. Sure, the edit filter was fixed within minutes, but that doesn't undo the damage from when it was active. And that was just from a blunder in a good faith edit (happened twice that I know of), not even someone deliberately abusing it. Monty₈₄₅ 02:31, 28 September 2013 (UTC)[reply]

   I can raise a similar argument. How do you undo the damage done to template where clicking anywhere on the page where that template is transcluded in leads you to a shock site (this has happened before)? Considering that it takes longer to locate the problem, IMO there's a much greater possibility of preventing good faith edits as a result. Not only are people prevented from editing the page but the template can be made to make it impossible to read. What if a template on the main page was vandalized? What I am saying here is that template vandalism can be just as hazardous or even more hazardous than the edit filter. You can't undo the consequences that resulted from both these cases. Our best option is to fix and prevent problem. Elockid ^(Talk) 04:21, 28 September 2013 (UTC)[reply]

   I'm not too concerned about vandalism with the criteria listed here (which can of course be tweaked later, btw). An applicant will have had to put in a fairly good deal of time and effort to meet them, without block-worthy behavior or 3RR violations in the past 6 months (which seems like a tall order of good behavior for a vandal), along with no suspicious behavior that would turn up during the investigation of those criteria (these criteria will require quite a bit more active investigation than those concerning most admin-assigned rights). If someone has committed that much time and effort to building a facade, chances are an added discussion requirement won't catch them either. Further, it seems like an unrealistically significant commitment for someone who'll be purposely damaging things, and I can't see it happening realistically -- vandals are generally drive-by. Finally, there won't be very many people with this right, and their contribs will be the first to get looked at if something starts breaking -- so if a problem is caused by a template editor, the culprit will be found and rolled back pretty quickly, and won't necessarily require much digging through transclusions to find.

   All of that having been said, nothing precludes discussion from occurring at WP:PERM, even though it generally doesn't for the rights currently in existence. Anyone concerned can watch the applications and comment. We could even have a waiting period to wait for comments, though it should be fairly short so this doesn't inch towards being "RfA lite", and because the right is easily revoked anyway. I see such things as logistics that can be addressed later though, and don't require codifying right now. equazcion� | 06:02, 28 Sep 2013 (UTC)

   The point I was making is that edit filter vandalism and template vandalism can be just as destructive or hazardous as each other. This is why I am advocating for a discussion first. Nothing similar to the easy come easy go process when applying for rights such as Rollbacker or Reviewer. There are even many cases where userrights were given too liberally as in not following the guidelines. And I'm not just talking about the ones in WP:PERM. The Reviewer right was given way too liberally without any form of discussion in almost all cases. Furthermore, if I remember correctly, there was a point where admins were giving the Autoreviewer right too liberally. Even with IP block exemption, admins have routinely not followed guidelines or protocol when granting the right and this is a right where the trust level needs to be similar to that of an admin. Like with what happened to Reviewer, the IP block exemption flag was given too liberally. I think this problem stems from the lack of discussions. If we have even a short discussion (maybe 3 days), we can have further assessment than just from one person which in many cases, it is. Elockid ^(Talk) 14:17, 28 September 2013 (UTC)[reply]

   @Elockid: Actually, in most cases it's easy to find the source of template vandalism if you know how. The usual way is to just use Special:RecentChangesLinked to get a list of recent changes to linked pages in the Template namespace. Or, if you want to get a little fancier, you could use this userscript. That doesn't always help (e.g. Talk:Human/Archive 33#Infobox with broken code, where someone changed one of the automatic taxobox templates in a way that wasn't obviously vandalism but caused other bits of taxobox to exceed template limits), but such situations are rare. Anomie⚔ 13:20, 28 September 2013 (UTC)[reply]

   But there's a problem. Most people don't know how to fix the problem as evident by the last template vandalism disaster. The community was unprepared last time and since this is not a common form of vandalism, I don't believe that the community as a whole this time. Elockid ^(Talk) 14:01, 28 September 2013 (UTC)[reply]

   IMO, the way to fix that is to make it easier for people to find instructions on how to do it. I'm not familiar with this "last template vandalism disaster" you're referring to, but perhaps the thing to do is find out where the people who couldn't find it looked for help and put instructions (or links to instructions) there.
   Also, BTW, somewhere above you were concerned about someone vandalizing a template that's on the main page, but do note that the main page is cascade-protected so the proposal here wouldn't let non-admins edit those templates. Anomie⚔ 15:09, 28 September 2013 (UTC)[reply]

   Here's an example thread at ANI and my talk page. I've also had users sending me emails per WP:BEANS. This spanned a few months. With regards to the main page, my main reason for bringing it up is that like edit filters disallowing good faith edits, template vandalism can also disallows good faith edits. Elockid ^(Talk) 19:29, 28 September 2013 (UTC)[reply]

2. As per Elockid. A great step in removing already heavy administrator workload but a potentially dangerous tool in wrong hands. - Jayadevp13 15:32, 9 October 2013 (UTC)[reply]
3. Neutral. About half a year ago, I had proposed that a similar right exist in this discussion. However, it seemed that my proposed discussion did not go anywhere, probably due to it being proposed at "closing time" for the Wikipedia talk:Protected Page Editor discussion, where I had posted the proposal. Glad to see that this proposal is getting a lot more attention than the one I tried to start did. However, with that being said (and after reading the proposal in its entirety), I do not agree with providing the permission to edit the Template:Editnotices/Page page or any of its subpages in its namespace as part of this right. I can see the edit notices getting either purposefully or accidentally vandalized as part of having this right. Putting up warnings for articles and other pages for readers to see has absolutely nothing to do with being a "template coder" and everything to do with making sure that everyone sees an important warning message. (However, one flaw in this proposal is not enough for me to "Oppose", but it is enough for me not to vote "Support.") Steel1943 (talk) 01:32, 13 October 2013 (UTC)[reply]

• I think those last three criteria for granting are a bit overly specific, I would make it a bit looser than that, but we can work that out. Also with Lua here now, we should probably include Module space into this. —TheDJ (talk • contribs) 10:58, 11 September 2013 (UTC)[reply]

Maybe the heading should be "Guidelines for granting", rather than "Criteria"? - Pointillist (talk) 11:02, 11 September 2013 (UTC)[reply]

I think modules are supposed to be included - is the wording unclear anywhere? — Mr. Stradivarius ^{♪ talk ♪} 11:08, 11 September 2013 (UTC)[reply]

TheDJ, Pointillist: Module space is already included here. As for the criteria, it's specific to alleviate concerns over the potential of this privilege to fall into unqualified hands. I felt there was a better shot at acceptance across the community if specifics were laid out. That said, the content of the section already has "guidelines" in bold, with mention that it's really at the administrator's discretion; but maybe I'll change the header as well. equazcion ^(talk) 11:15, 11 Sep 2013 (UTC)

You're doing a great job. I just thought that contrasting "Guidelines for granting" with "Criteria for revocation" might help with acceptance. - Pointillist (talk) 11:29, 11 September 2013 (UTC)[reply]

Thanks :) I made the header change, FYI. equazcion ^(talk) 11:38, 11 Sep 2013 (UTC)

• The last two criteria, IMO, are intended to ensure a editor is indeed learned in template editing... However, many of the editors who work with templates network together, and its possible for an editor to request coding changes on IRC, email, or user talk pages. These two should be discretionary. Perhaps the first four criteria should be closer to requirements, while the last two could be used as part of a larger list of skillsets for determining an editor's expertise. Coding in Lua is a greater indicator than use of the edit-protected template. - Floydian ^τ _¢ 11:53, 11 September 2013 (UTC)[reply]
  • I'm open to this and it seems people have thus far expressed a feeling that the criteria could use loosening. Stipulating that the final two criteria are more discretionary seems like a good idea, for the reasons you put forth. I'm not sure what exact textual changes to make yet -- As this is a meta issue we could discuss exact changes to employ on the talk page. equazcion ^(talk) 12:03, 11 Sep 2013 (UTC)
  • I still think that the last two guidelines are weak, but I've compromised. I've spent 14.7 years and made hundreds of template edits (mostly on a specialized wiki for an MMO I played + on wikipedia) and I still don't know all there is to know about templates. That being said, having all of this experience, I can pretty quickly look it up in the appropriate manual on MediaWiki wiki. I think that the current wording of the guidelines allows for consideration of edit requests anywhere, including but not limited to the template talk page, IRC, email, and user talk pages. Technical 13 (talk) 13:03, 11 September 2013 (UTC)[reply]
• Question: Whilst this is presumaby technicaly doable, do we have any idication from the developers that they have the time and inclination to actually modify the necessary bits to create the user right? Pedro :  Chat  11:56, 11 September 2013 (UTC)[reply]
  • The technical ramifications were explored thoroughly in the drafting talk page, now archived but linked on this talk page. On the developer side, this change would only require config changes, rather than new coding (a new user right + a new protection level). See here for a portion of that, in which User:Anomie dropped by and indicated a new protection level is viable if the community is for it. equazcion ^(talk) 12:00, 11 Sep 2013 (UTC)
    • Thanks Equazcion, I didn't see that link, appreciated. Pedro :  Chat  12:17, 11 September 2013 (UTC)[reply]
• (multiple ECs) Although i, in general, am not in favour of unbundling, i am not currently going to oppose. I do think, however, that the timing of this RfC is a little unfortunate, in view of the RfA running as it was started (yes, i'm aware that this particular RfA is part of the motivation for the RfC); it seems to me that if the Request is successful, as doesn't seem unlikely as i write this, that is a sign that the Community is more prepared to grant adminship for a single use than it was previously. That being the case, i'd not be in favour of the new usergroup being offered here. More generally, i'm not sure i understand why or where we would draw the lines of trust: If we trust someone to be able to edit templates through protection why wouldn't we trust him in other areas? Cheers, Lindsay^Hello 12:03, 11 September 2013 (UTC)[reply]

This proposal means a Template Editor candidate can be assessed using criteria that are much narrower and to some extent more objective than those in an RfA. There is also a far more credible mechanism for revocation. - Pointillist (talk) 13:04, 11 September 2013 (UTC)[reply]

Thanks, Pointillist ~ your last point there is probably the strongest reason i can see for supporting the proposal; i hadn't missed it, exactly, but my mind did gloss over it a bit. Cheers, Lindsay^Hello 15:22, 11 September 2013 (UTC)[reply]

Additionally, a general feeling was expressed even by supporters at the RfA that they were only supporting because there was no option such as the one described here. equazcion ^(talk) 13:11, 11 Sep 2013 (UTC)

• • Hello Lindsay! I appreciate your concerns and questions. Let's see what I can answer, and maybe others can back me up or offer more insight. The current RfA process isn't as much about technical ability and trust. It's a bureaucratic process that requires a wide array of abilities and commitments from having created multiple new articles and contributed to many administrator area discussions (AfD, RPP, and AIV to name a few) to having a good ability to converse and discuss with other editors under extreme circumstances (being the subject of PA or TROLLing for example) instead of just being able to step away. Moreover, my observation of the RfAs I've contributed to has been that it is very much more about a popularity contest than it is about technical skills and trustworthiness. This new proposed right is more along the lines of creating a usergroup that will allow our more technically inclined editors to be more productive in the specific areas that they are interested in based on their skillset. Technical 13 (talk) 13:43, 11 September 2013 (UTC)[reply]

Hi, Technical 13. I have to say that i completely disagree with one of your points (sorry!) ~ i think that RfA is very largely about trust, which is why i mentioned it earlier. We are giving a set of tools to a candidate based on whether or not we, as a community, trust him not to screw up or go crazy. Looking at their various abilities/experiences is just a means of evaluating their trustworthiness. That's why it seems to me that Trappist the monk and others have chosen to go along the best path in order to be more productive in the specific areas that they are interested in based on their skillset. Thus, from my perspective, this new userright is not necessary. But, we can agree to differ. Cheers, Lindsay^Hello 15:22, 11 September 2013 (UTC)[reply]

• Alternative implementation recommended Create a mechanism in the code so individuals can be bypass edit protection for specific pages or groups of pages, then for the English Wikipedia use this new mechanism to do what is suggested above. This implementation will give other Wikipedias, including non-Foundation projects using the software, the flexibility do do things like give "edit protected page" rights to curators of arbitrary articles or groups of articles and their associated pages, or provide similar features. As the English Wikipedia specifically does not allow "ownership" this would not be used for curating content or likely any other purpose in article-space in the English Wikipedia. davidwr/(talk)/(contribs) 17:03, 11 September 2013 (UTC)[reply]
  • This was discussed during the drafting stage of this proposal, but the developers indicated that it wasn't technically feasible. I'm assuming it can be done (from a software development standpoint it doesn't seem all that farfetched), but would require some substantial development and reworking of the software, so it would be far less likely to actually be implemented by the foundation should a proposal for it pass. equazcion ^(talk) 17:17, 11 Sep 2013 (UTC)
• Question: why are edit notices included in this? It's a completely different scope and skill set, isn't it? --Stfg (talk) 19:14, 11 September 2013 (UTC)[reply]

Response: Because per Wikipedia:EDITNOTICE, they are very simple templates. Hasteur (talk) 19:21, 11 September 2013 (UTC)[reply]

True, but none of the rationales for this proposal apply to editnotices. Just because they're in the Template namespace doesn't mean they should be lumped together with other templates. -- Ypnypn (talk) 19:25, 11 September 2013 (UTC)[reply]

(edit conflict) Scope is arguable, but it's not a different skill set. Edit notices entail the same type of coding, as they're merely banners made of wikicode. Aside from editors' own talk page edit notices, access to edit notices is locked from most users under a similar precautionary principle rather than reasons of controversy etc. They fall under the category of things our many avid coders could contribute substantially to, but are currently barred from unnecessarily. Also, access to edit them is already granted via another non-admin rights group, account creator. It seemed appropriate to include it here. equazcion ^(talk) 19:28, 11 Sep 2013 (UTC)

• Question - Unlike another proposed rights change under discussion lately, which would require editors to have a certain amount of experience before reviewing articles at Afc, this proposal gives more rights to some individuals. If 100 non-admins all speak in favour of this proposal, and no one opposed them, would they have the ability to implement this? Whose support is needed to create new user rights, and who would decide who gets them? —Anne Delong (talk) 23:06, 11 September 2013 (UTC)[reply]
  • Administrators are generally the ones who close proposals, meaning they provide the final assessment on whether or not a proposal has passed. As admins have the responsibility to disregard their personal feelings when doing so, and are elected largely based on their perceived ability to do so, it wouldn't and generally doesn't matter if everyone who supports a proposal are non-admins. New rights and protection levels are enacted by the Wikimedia Foundation's developers. When a community proposal that requires their action closes as successful, a request is put in to them. There have been instances where the Foundation chose to override the community and refused to enact a community-supported proposal, but that has been rare -- and during the drafting process there were at least two developers who commented on this one and seemed open to the idea if the community was. equazcion ^(talk) 23:14, 11 Sep 2013 (UTC)
  • PS. Several of the supporters on this page thus far are in fact administrators, in case that's relevant to your concern. equazcion ^(talk) 23:17, 11 Sep 2013 (UTC)

I think technically it could be implemented by sysops, (The ones who run the servers) as it would I think be only a change in a config file. Once the mechanics were implemented, the right would be granted by local admins in accordance with what ever guidelines the RFC Produces. Presumably, the protection level change to the new one would also be carried out by local admins. Note, that support for the proposal is actually higher amongst admins who have !voted then non-admins, so a refusal of admins to cooperate doesn't seem like it should be a problem. Monty₈₄₅ 23:26, 11 September 2013 (UTC)[reply]

^What he said :) Sysops and developers probably each have config access, and I'm not sure which would actually enact the initial change. It doesn't really matter. Either way (to answer your questions simply), barring the Foundation vetoing this, our admins would indeed be doing most of what needs to be done, as Monty says; which, if this passes, they would do, regardless of who voted. equazcion ^(talk) 23:39, 11 Sep 2013 (UTC)

Thanks to everyone who helped clarify this. This is the first time I've seen members of the community proposing to give themselves new rights, and I wanted to make sure it wasn't a pointless exercise. —Anne Delong (talk) 00:01, 12 September 2013 (UTC)[reply]

• That raises a question that hasn't really been addressed. If the proposal passes, should all fully protected templates be changed to the new template protection (possibly by an admin bot), should we try to review every fully protected template with an eye towards reduction (7k+ templates), or should they be reviewed and reduced on an as requested basis? Monty₈₄₅ 23:52, 11 September 2013 (UTC)[reply]
  • That question is better left for a subsequent discussion as it is kind of putting the cart in front of the horse in my opinion. Technical 13 (talk) 00:49, 12 September 2013 (UTC)[reply]
  • I imagine that one of those three options or some combination thereof would take place, though that's a logistic we can tackle when the time comes. Just a note though, the new protection level is intended to entirely replace full protection as the precautionary measure for high-risk templates, rather than only being applied to "reduce" the number of fully-protected templates. Full protection would be strictly reserved for extraordinary and temporary situations. equazcion ^(talk) 03:13, 12 Sep 2013 (UTC)

• Some participants will have noticed that I have voted Support. This may appear to be a volte-face; it is not, and it is without prejudice to any current RfAs. The RfC proposal is very specific and as worded, I do not consider it to be an unbundling per se of admins' tools. The threshold requirements are very precise and I don't think that applications for it would be abused by new and/or inexperienced users, or hat-collectors. I see it very much in a similar way as, just for example, File Mover. How this new 'right' could/would be technically implemented is beyond the scope of this RfC - Kudpung กุดผึ้ง (talk) 03:35, 12 September 2013 (UTC)[reply]

• I'm not really sure this changes much. If a template is already used on so many pages, I find it unlikely that there's going to be some error about it that has to be fixed, or anything the community collectively decides must be changed about it. If it ain't broke, don't fix it. LazyBastardGuy 04:15, 15 September 2013 (UTC)[reply]

• An interesting point of this un-bundling discussion is what the end result will mean to admins. Certainly our rollbackers are more able to fight vandalism by assuming that right from the previously-exclusive admin domain. Will the administrators eventually be the only Wikipedians to hold the ban hammer, once all other powers are eventually devolved? Will admins primarily be responsible for negotiating solutions between warring editors? I think this is a step in the right direction, as Wikipedia has grown to large and diverse for our admins to manage. Chris Troutman (talk) 18:36, 15 September 2013 (UTC)[reply]

There aren't many admin powers that can be unbundled without the need for an RfA-like scrutiny of the candidate's content contributions, experience, behavior and knowledge of policy. If "Wikipedia has grown to large and diverse for our admins to manage" then community-based solutions would be better than having new types of super user. I do agree that there are some interesting decisions ahead if we continue to see falling numbers of experienced editors and active administrators. For years we've assumed there would be an unlimited supply of admins to interpret our sometimes vague/contradictory precedents. A shortage of admins might force a re-examination of how Wikipedia works. That's not necessarily a bad thing. - Pointillist (talk) 22:21, 15 September 2013 (UTC)[reply]

I think the main admin powers that "must" (i.e. because the Foundation says so or they probably would say so if it became an issue) go through an RfA-like referrendum are those that give access to deleted material, those that affect user-rights, and those that affect which editors can change a page. Some admin powers go hand in hand with these and it wouldn't make sense to unbundle them except in extraordinary cases (e.g. the ability to delete pages or revisions might be granted to editors with access to subscription-only journal articles, but only for copyright reasons, and only with some level of accountability in place). Most other admin rights could, in theory, be unbundled by community consensus without the Foundation vetoing it. I don't think the Foundation will have any official comment about unbundling the right to edit protected pages, although individuals who happen to be Foundation employees, officers, or volunteers might give their opinions as individual editors. davidwr/(talk)/(contribs) 23:37, 15 September 2013 (UTC)[reply]

• Who will be granting this right? Rather than any admin granting this right, I would suggest that only those that have experience editing templates grant it. My specific point is the criteria of 150 edits to template namespace, this does not say whether they are good or bad edits, whether they are a lot of minor edits just to up their edit count, or major edits. One editor may make 10 minor edits whilst at the same time another might make one major edit. An admin needs to be able to tell whether the applicant understands what they are doing.Martin451 (talk) 18:05, 16 September 2013 (UTC)[reply]

• I'm not going to !vote here, as I see the need (I've made template edits on request, to templates I watch, which I didn't fully understand), but I'm not sure of the appropriate criteria. There needs to be some indication of trust, as editing a template which occurs in hundreds of thousands of articles can easily be disruptive, even if actually necessary. It would be a choice of a lesser disruption. — Arthur Rubin (talk) 23:49, 20 September 2013 (UTC)[reply]

This is an important question I'd like to raise (and it seems like a good point to introduce a section break here): Will such a user right allow these people permission to edit the fully protected Main page templates? For those unaware, almost all of the text seen on the Main page is from templates. As the most visible page on Wikipedia, the Main Page has historically been one of the first targets of vandalism by a compromised admin account. And, in fact, a few compromised admins were blocked and privileges revoked on grounds of site security (this has led to the creation of editnotices like Template:Editnotices/Page/Main Page, warning admins of this). If the answer is yes, I hope there is no similar incident. I'm not opposed to them helping out editing Template:In the news, Template:Did you know, and the other Main page templates, but they better have strong passwords and follow appropriate personal security practices like regular admins. Zzyzx11 (talk) 04:36, 12 September 2013 (UTC)[reply]

I think I can answer my own question: It depends on if there is also consensus to set them to the newly-created protection level, or leave them at the existing full protection. It also depends on what cascading protection does to such pages: will it cancel the newly-created protection level and automatically apply full-protection? Zzyzx11 (talk) 05:01, 12 September 2013 (UTC)[reply]

I can't speak for everyone, and I'm not seeking to answer this with any degree of finality; this is something that should probably be discussed, so I'm just contributing to that discussion. My own take on this is that we're vetting and trusting the people who get this right to handle it responsibly, and if anything, that means knowing that templates on the main page are to be handled with extra caution; that any changes involving code are to be sandboxed first, etc. As most of the people who end up with this right will know more about what they're doing with templates than the average admin (by mere virtue of the fact that they were vetted specifically for that purpose, and that most admins are not coders), the issue of compromised accounts is all that remains.

One could look at this as increasing the risk of compromised accounts being able to inflict damage, for the simple fact that there will be more accounts that could be compromised. The same would be true, then, if we added a lot of new admins. Each would be an equal risk [correction: not equal, as compromised admins can do much more harm], though a calculated one that we would be taking in exchange for a benefit. In fact we take a calculated risk whenever we appoint a new admin or grant other rights. I don't see any logical reason to treat template editors differently from admins when it comes to the measures taken in limiting the risk that their accounts might be compromised.

Compromised template editors, if those occur, would be handled in a manner similar to compromised admins -- the only difference being that template editors can have their right revoked much more easily, should it be deemed necessary. The eventual page for requesting this right should and will contain appropriate warnings and recommendations regarding security (and thanks for bringing up that excellent point).

I'm not fully versed in cascade protection but I'm thinking it will likely elevate the protections of child templates up the level of the parent. If the current practice is to cascade protect the main page itself at sysop level, that could mean template editors couldn't feasibly gain access to its templates. Depending on what the general feeling is regarding template editors editing main page templates, we could see if there are technical solutions that would allow it. equazcion ^(talk) 05:14, 12 Sep 2013 (UTC)

My understanding is that the cascading protection system will create a major technical hurdle to implementation. I'd say we should just leave this off the table for now, and come back to it at some point in the future, after the rest of template space is under the new system. Monty₈₄₅ 05:50, 12 September 2013 (UTC)[reply]

That's my understanding as well. ( Though if you follow through the examples of the config parameter, there might be a way to work around it by making allowing the new protection level to be used for cascading. ) Agreed, that what to do with these pages are probably better decided after there is a feeling about how the new permission works in practice assuming that it passes. PaleAqua (talk) 06:07, 12 September 2013 (UTC)[reply]

We can't allow the new protection level to be used with cascading, because that would allow editors with the new userright to protect pages as well as just being able to edit them. (You can protect a page just by transcluding it on a cascade-protected page.) It's probably best to leave editing the Main page templates to admins. However, there are a lot of templates that are cascade-protected that don't really have to be. For example, {{db-meta}} is cascade-protected, but really doesn't need it - I think semi-protection would be a better fit. For templates like these we can simply remove cascading protection to allow editors with the new user right to edit them. — Mr. Stradivarius ^{♪ talk ♪} 10:23, 12 September 2013 (UTC)[reply]

• I believe all of the pages on the main page are covered under cascading protection which granting permissions to isn't on this proposal after discussing this with developers saying that it wouldn't be feasible to implement for specific namespaces. The editors that drafted up this proposal wanted to make this as slimmed down as possible as a starting point so that the editors that would qualify for this right can get started. There were a few other things on the draft that got cut in this interest and may be brought up in a future RfC if this proposal passes. Thanks. Technical 13 (talk) 14:02, 12 September 2013 (UTC)[reply]
  • Agreed. After some thought and reading the responses here, it does appear the main page wouldn't be feasibly editable by the new user group without getting rid of its cascade protection, which should probably be left as is for the time being. If in the future it should be deemed necessary this can always be re-examined. equazcion ^(talk) 14:12, 12 Sep 2013 (UTC)

Cascade protection is a concern for me. The place where I want to work is cascade protected (Module:Citation/CS1). Policies and procedures defining Template editor user right need to have a mechanism that specifies how cascade protected pages are demoted to a protection level that allows template editor users to edit the pages.

—Trappist the monk (talk) 15:56, 12 September 2013 (UTC)[reply]

Module:Citation/CS1 could just be removed from Wikipedia:Cascade-protected items, and its protection level could be dropped. For anything used on "real" cascading-protection pages, like the Main Page, there's no possible way to edit those without having the ability to protect and unprotect pages. Jackmcbarn (talk) 16:10, 12 September 2013 (UTC)[reply]

I'm sure that you're right that these pages could just be removed from Wikipedia:Cascade-protected items. But who does that? How would I as a template editor user initiate the protection change? What are the policies and procedures that requesters and admins need to observe to implement a protection change. If these things aren't defined now, they need to be. They really goes hand-in-hand with the adoption of this RfC, don't they?

—Trappist the monk (talk) 16:46, 12 September 2013 (UTC)[reply]

I never realized cascading protection was such a mess. Was there ever a broadly participated discussion supporting how its being used both at Wikipedia:Cascade-protected items, and in the various user space versions of that? The use certainly isn't reflected at WP:CASCADE. I'd say sorting it out is probably beyond the scope of this RFC. Monty₈₄₅ 17:06, 12 September 2013 (UTC)[reply]

You just ask any admin to remove it from there, and hope they're willing to. So yes, it's a mess. Jackmcbarn (talk) 17:17, 12 September 2013 (UTC)[reply]

While there are several areas where cascade protection will currently prevent template editors from editing directly, the vast majority of high-risk templates don't fall under that category. With the resistance met in the past regarding a rights group such as this one, and how seemingly close we are to it gaining acceptance now, I don't think it's wise to demand that this be a perfect solution at this point in time. The issues posed by cascade protection can be addressed from a logistical standpoint later on in view of the fact that the community supports trusted template editors having access to high-risk templates -- something that will have been demonstrated already if this RFC passes. The procedures surrounding cascade protection weren't adopted with something such as this proposal in mind, and I'm fairly confident that with relatively minor procedural addendums it can be dealt with. equazcion ^(talk) 17:48, 12 Sep 2013 (UTC)

If their trusted they should be allowedWWE fan 4.0 (talk) 02:28, 16 September 2013 (UTC)[reply]

While the technical aspects of cascading protection make this more-or-less a moot point, I think we should still explicitly state: Actual full "sysop" protection will then be available as an extraordinary measure in the Template and Module namespaces, to temporarily disallow editing by anyone but administrators, should the need arise. All templates and modules transcluded to the Main Page will remain permanently fully protected. (proposed addition underlined). — PublicAmpers&^{(main account • talk • block)} 16:04, 12 September 2013 (UTC)[reply]

I'm wary of declaring that the main page will not be editable by the new rights group when the reasons that is currently the case are a bit muddy. It's at least due to a technical/logistical limitation, and if that changes at some point in the future, there's the question of whether it would still be be restricted on principle. I think it might be best to explain the issues surrounding the main page to anyone who might express concerns about it as they come, if they come. My humble opinion. equazcion ^(talk) 18:11, 12 Sep 2013 (UTC)

• The trouble I have with saying permanently is that the Main page is dynamic and constantly changing, so what is transcluded on it one day is not necessarily going to be the next day. Also, I'm thinking that adding something like that distracts the current question posed of "Should there be a new template_editor group to allow editors who demonstrate competence in those areas to edit non-cascading protected templates, modules, and editnotices without opening those conceivably higher risk areas to those that may wish to do harm to the encyclopedia?" If/When, this proposal passes, then it wouldn't be unreasonable to hash out extra privileges and/or restrictions in a future RfC. Technical 13 (talk) 18:39, 12 September 2013 (UTC)[reply]

I think this discussion affects enough editors that it would benefit from a watchlist notice. Do others think this is a good idea? — Mr. Stradivarius ^{♪ talk ♪} 12:46, 13 September 2013 (UTC)[reply]

Absolutely. equazcion ^(talk) 12:54, 13 Sep 2013 (UTC)

If only we had an administrator to do it! Oh wait... Yep! Technical 13 (talk) 13:53, 13 September 2013 (UTC)[reply]

I've added a suggestion to MediaWiki talk:Watchlist-details. I don't want to implement it myself, at least not right away, as I was involved in the drafting of the RfC. Maybe if there are no objections after a few days then I can add it. I want to give editors who watchlist that page a chance to comment on it first, though. — Mr. Stradivarius ^{♪ talk ♪} 14:22, 13 September 2013 (UTC)[reply]

Yes, please do it. —Anne Delong (talk) 14:53, 13 September 2013 (UTC)[reply]

Now added. — Mr. Stradivarius ^{♪ talk ♪} 23:13, 14 September 2013 (UTC)[reply]

I DONT KNOW WHAT ANY OF THIS MEANS BUT IT CAME up on my watchlist so I thought I'd tell you here. Thank you. New England Cop (talk) 01:58, 15 September 2013 (UTC)[reply]

I haven't !voted in this and don't intend to. I find the arguments of WDGraham, above quite convincing and if this RfC is unsuccessful then I think WDGraham's comments could inspire some alternative measures. Specifically:

• Is there any guidance on sandboxing for templates? If people knew the most efficient way of doing it they might be more easily persuaded. Perhaps we should write some. Or if there is already a really good essay (or similar) on this, perhaps it just needs a little advertising.
• What is the best way to reduce the amount of pre-emptive protection of templates? Are there currently some fully protected templates that should be semi or even not protected?

Yaris678 (talk) 09:48, 15 September 2013 (UTC)[reply]

To expand upon my comment about preemptive protection, a good example is Module:Citation/CS1, which was the template at the centre of the RfA which seems to have sparked this discussion. Yes, it's widely used, but it's an obscure subpage which isn't transcluded directly into articles - on average it gets less than 30 hits per day[2]. I don't think disruptive users are likely to find it and if they do it'll be at a manageable rate - and they'll be reverted before it propagates to articles. --W. D. Graham 10:18, 15 September 2013 (UTC)[reply]

Significant changes to critical templates are already sandboxed. The problems are, among other things, a lack of admins who know what they're doing enough to confirm and implement changes. There are quite literally almost none who actually handle the {{editprotected}} queue, and a couple who do it simply to help out since otherwise nothing would ever get done implement edits on blind faith that the coder knows what they're doing.

CS1 and other relatively lesser-known modules could actually be said to be more dangerous than the average high-use template, as since it's barely watched by anyone, and it's a low-level technical template, problems wouldn't be traced to it swiftly. In fact there was a time when deeply-transcluded and relatively unknown templates were nearly the only ones that got fully protected, for that reason.

We could debate the pervasiveness of the preemptive protection practice, but that's been done, as this isn't a new issue. This latest proposal was sparked by user Trappist and his CS1 work, but there is a long history of proposals to create trusted user groups that are allowed to edit "through protection". All have failed, primarily because they touched on the principle of "unbundling" administrative tools (so that a single administrative power can be assigned without assigning them all). This proposal to strictly limit the permission to template work where a proven need and aptitude is demonstrated comes out of the dust of those as an effort to cut through and around the everlasting controversy and drama surrounding "unbundling", and perhaps finally, after years of this, get our vast supply of good coders, who are willing and able to help, the access that would allow them to.

There are many alternatives that one could say are more ideal; the problem is getting them implemented in a divided community. Many of them have already been tried, discussed, debated, proposed. This is not a new issue. If this proposal can at least be a compromise, that many might not be enthralled with but could perhaps at least tolerate, maybe we can finally take an actual progressive step this time. equazcion ^(talk) 11:15, 15 Sep 2013 (UTC)

I may have said this somewhere else, but I do look at the edit-protected queue; text only changes are easy, if it looks uncontroversial, no problem. Likewise, if there is actually a discussion followed by consensus, I'm pretty willing to make the change (though I did get bit by that once, it was very widely discussed, clear consensus, and no one noticed the problem until after the edit), because at worst there was consensus in favor of trying what ever caused the problem. The problem is that most of the edits in the queue involve changes to relatively complex template code, most templates aren't coded to make it easy to follow the code structure, and when it comes to multiple nested templates, it can get very hard and/or take a lot of time to basically deconstruct the template to understand what the code is doing. Sandboxing is great for relatively simply templates, but the complex or nested ones can have so many usecases that even with sandboxing, it can be hard to evaluate whether anything will break. Now I don't fault those admins who take it on blind faith the requestor got it right, but I'm not comfortable doing that, and I think that is probably a major factor in the lack of active admins there. Monty₈₄₅ 05:05, 17 September 2013 (UTC)[reply]

I pass no judgment there. I've said before, it's merely a fact that needs stating (the fact that there are barely any admins who take on the protected edit queue -- but thanks for being one of the ones who does!). Coding edits aren't easy to evaluate even if one knows what they're doing, and if I were an admin, I'd probably stay away from the protected edit requests myself. Taking on a couple of scripts that you devote your efforts to is one thing. But this... It's not easy, nor fun, nor quick -- even if one knows what they're doing in general -- to evaluate several odd unrelated edits across all manner of different coding projects, one after the other. It's not efficient and shouldn't be necessary. equazcion ^(talk) 11:17, 17 Sep 2013 (UTC)

Replace the criteria for removal above with these general criteria:

1. The editor has been inactive for 12 months.
2. The editor was granted access to the tool in error.
3. The editor demonstrates a pattern of abusing the tool after repeated warnings.
4. The editor blatantly abuses the tool.

Number 2 is new, it's meant to cover cases where an administrator was deceived into granting access under false pretenses (e.g. editor had multiple accounts not disclosed to the granting admin, this was his "clean" one) as well as clerical errors that result in someone getting access when they shouldn't (e.g. a username-typo by the granting-admin).

Number 3 covers repeated, non-blatant vandalism, disruptive editing, using the tool to gain the upper hand in controversial situations, not using sufficient care, and just about any other mis-use of the tool that results in a warning followed by repeated mis-use.

Number 4 covers blatant mis-use, usually the kind that COULD get a block at any administrator's discretion. One strike and you are out.

Thoughts? davidwr/(talk)/(contribs) 00:36, 17 September 2013 (UTC)[reply]

#2 seems a little creepy, ie. excessively specific. On the extremely rare occasion that's bound to happen and is subsequently proved to be the case, I don't think there will be any doubt as to what action must be taken.

3 and 4, on the other hand, are a little too open to interpretation. "Abuse" does cover everything, but it does so by being anemic and ambiguous. It's like saying, "The permission can be revoked if used for a purpose that everyone agrees should warrant revocation". Given the history of these proposals, the criteria for removal need to reassure. Presenting more specifically what exactly will constitute abuse, I think, is paramount. equazcion ^(talk) 01:09, 17 Sep 2013 (UTC)

As an observation, the appointment process might be better modelled after the process for becoming a clerk. The clerk appointment system works extremely well, and very similar criteria seem to apply here, in that you want people who have been vetted by their peers.

I suggest the following procedure, based on the SPI Clerk process:

Any user in good standing can ask to be considered as a template editor. Template editors are initially accepted upon consensus of the current template editor membership, following a request to any template editor. If they do not have a proven track record of technical competence editing templates and/or modules, prospective template editors may be asked to serve a probationary period, typically lasting X months, during which time any edits must be approved by a full template editor. The template editors may then recommend full template editor status to the bureaucrats who will decide the matter.

I think that this addresses many of the concerns given by those who oppose the proposal as given. In particular, any talented coder can jump right in to the technical team, just like on any open source project.

Incidentally, at the risk of bikeshedding, can we think up a snappier name than "template editor"? How about "technician"? -- De Guerre (talk) 08:11, 18 September 2013 (UTC)[reply]

I'd be wary of creating a system where the current members decide on who to accept for membership. Both SPI and Arb clerks are supervised by those they clerk for, whereas the Template Editor cabal would be pretty much independent. The only place I can think of where such a system exists on wiki is with promotion to Crat, which is judged by other Crats, but its such a heavily participated discussion, and such a high support level required, that it largely eliminates the issue. Now something softer, like having a Template Editor noticeboard, (I know, too many noticeboards already) and holding a short discussion on requests for the right there, which would be open to anyone, but would be noticed and participated in primarily by template editors would be a more acceptable idea. As for the name, better it be self explanatory, no one is going to intuit that technician means editor of protected templates. Monty₈₄₅ 17:47, 18 September 2013 (UTC)[reply]

The thing I don't like about the current proposal is that any admin can make anyone a template editor, whether they have the skills or not. This is the rationale behind davidwr's suggestion #2. I only suggested a concrete procedure because it felt wrong to complain without proposing a fix. I'm not sold on it as a solution, but I think that the problem that both it and davidwr's proposal are trying to solve is a real problem. -- De Guerre (talk) 07:45, 19 September 2013 (UTC)[reply]

Handling specific permissions without a process is generally seen as safe since they can be revoked as easily as they're granted. Regarding Monty's musing of a "noticeboard" type of implementation, I was looking over WP:PERM, where requests for this permission are planned to go, and I don't see anything explicitly prohibiting outside comments there. I'd be hesitant to inadvertently encourage a voting environment, lest it become RfA-esque, but encouraging editors to assist purely in confirming that an applicant's prerequisite claims are accurate might be something to consider. equazcion ^(talk) 08:26, 19 Sep 2013 (UTC)

De Guerre, consider the edit filter manager right. While its assignable by admins, there are very few with the right, it is handed out very cautiously. Requests go the the edit filter talk page, sit for a period of time to allow for objections, and if I understand practice, often get cross posted to AN for a day before final granting. While the Template Editor right would not need to be as stringent, the practice there does provide an example of an alternative. Monty₈₄₅ 14:12, 19 September 2013 (UTC)[reply]

My similar fear is that the admins will simply deny all or most of the requests as untrustworthy or for some other reason so in the end it will just be a useless Role. This is about as good as we can get but its still not ideal. Ideally it would be for experienced editors to be given access to the Admin tools without all the gauntlet and drama. If they abused them then the tools can just be taken away again. But since the admin club will never allow that, the only thing we can do is to go through the extra trouble of creating a new user right because the vast majority of the admins who do have access to the protected templates don't know how they work. 138.162.8.57 (talk) 18:10, 24 September 2013 (UTC)[reply]

@138.162.8.57: I just saw your comments on the RfA talk page saying similar things. I don't know how much experience you have here (a CIDR range search counted ten thousand contributions from your 138.162.0.0/16) but in the RfA's I've attended it's often non-admins who are more cautious about promoting new admins, and that is partly because in the past it has taken months – and a lot of drama – to remove the tools when necessary. The good thing about the Template editor proposal is that it is suitable for people who don't want to be admins, and who might not have the necessary background and policy knowledge required. So if you haven't already supported the proposal, please do! thanks - Pointillist (talk) 21:12, 24 September 2013 (UTC)[reply]

What you describe, De Guerre, would likely encourage an exclusive club mentality. The suggestion to assign a "snappy" title alone is risky, as even an arguably humble-sounding one encourages an ironic sense of vanity. Combine that with a policy of only letting people in when they meet with the approval of the current members, and you have a recipe for accusations of agendas and elitism. Specific rights are traditionally assigned by administrators, with titles that are generally bland literal descriptions, and in practice I think that is the safest route. equazcion ^(talk) 02:35, 19 Sep 2013 (UTC)

• For the name bit, I have wondered if "template committer" might be a better name. This permission is similar to the commit bit in many open source projects, and by using the term committer it invokes the process model that is desired by this new process of changes being done in a branch ( sandboxes ) and then committed ( applied through page protection ) after ensuring ( consensus etc. ) that the changes are okay. It also avoids the connotation of the name "template editor" that other editors can't create or work on templates without this. PaleAqua (talk) 16:15, 19 September 2013 (UTC)[reply]
  • At the risk of starting to sound like a negative nancy... Template commiter might be more technically accurate, but it's also more esoteric -- ie. less intuitive to the community at large. I also personally feel "Template editor" has a particular "no big deal" connotation, as in, "I'm just an editor who happens to specialize in templates", rather than "I have a superpower" :) Just my opinion. If everyone else feels differently then of course the name could be changed. equazcion ^(talk) 19:13, 19 Sep 2013 (UTC)
• How about Template Coders or simply Coders? That's along the lines of what the watchlist notification for this page read.--Siddhartha Ghai (talk) 21:04, 21 September 2013 (UTC)[reply]
• I don't feel very strongly about the name, but "clerk" has some implications. Here at enwiki, clerks seem to be people who follow a process neutrally. Likewise, admins shouldn't use their powers to support their own point of view—lest they lost the confidence of the community. But I don't think we're expecting this sort of passive stance from potential template editors, are we? On the contrary, they'll be our usual type of contributor with the usual motivation to fix things. The only difference is that they have proved they have the [technical skills, experience, cautious temperament, etc] to handle templates that are extensively transcluded into articles. What we mean is "protected template editor". What's the best way to say that? - Pointillist (talk) 21:36, 24 September 2013 (UTC)[reply]
  • I think PaleAqua's "Template committer" suggestion is the most accurate while still being concise, if that's what we're going for. I'm still of the opinion that "Template editor" is accurate enough while also avoiding elitism nicely; but if there is to be a different name, Template committer has my vote among those mentioned thus far. equazcion� | 21:45, 24 Sep 2013 (UTC)

I found the proposal and all the reasons provided to be valid to create this new user right for experienced editors. But the one thing which I don't find much useful is the point number 5 under the Criteria for revocation which states that The editor has been inactive for 12 months. We also have other user rights like Rollback, Autopatrolled, Reviewer, File mover and many more except for Account creator, Administrators and Bureaucrats where these rights are not removed even if the said user has been inactive for 12 months or longer than that. Account creator is usually removed if the user is no longer involved in the ACC process or with the education program and stops their activity in these places. But that's a different thing. As this user right is related to editing Wikipedia, and if we can trust the editor not to misuse the template editor user right and they have used it constructively; I don't see the point of removing it after 1 year just because the respective user/editor is inactive. So why is it necessary to have it here ? TheGeneralUser (talk) 16:03, 2 October 2013 (UTC)[reply]

• I entirely agree with you, I think it was added as a general provision for similar reasons as why it is applied to administrators. I support the provision's removal at this time, but I think that adjustments such as these should be done in about six months at a follow up RfC to make this right work better for those with it. I think that waiting until we have about six months of data of how the right is used will go a long way in tweaking these things in a way that most everyone will feel comfortable. Technical 13 (talk) 16:16, 2 October 2013 (UTC)[reply]
• I disagree on general principles: All user rights that actually give you the ability to do something that you can't do manually should automatically be removed after a long period of inactivity, without prejudice for re-enabling upon request. Why? A long period of inactivity increases the chance that an account will be unknowingly compromised. Heck, I would even go so far as to have accounts that are inactive for over a year lose autoconfirmed status, just so if an account is compromised it can't immediately be used for abuse that requires autoconfirmed/confirmed status. I do agree with Technical 13 that the best time to discuss this will be a few months after it is implemented. I'm good with a 6-month wait and of course I'm fine if the community agrees to drop this requirement. davidwr/(talk)/(contribs) 21:33, 2 October 2013 (UTC)[reply]

I've read through this, and I think the definition of "template" is vague. (If I've missed a key sentence, please enlighten me : )

From a technical standpoint, am I correct to presume that template equals anything in template: space. And that it doesn't include anything else.

The reason I'm asking for specifics is, first, as I think we all know, most any page may be transcluded like a page in template space can be, and second: whether this involves mediawiki space in any way. - jc37 05:59, 3 October 2013 (UTC)[reply]

A "template" would be anything in the template namespace or the module namespace. The proposal is to make a new kind of protection that can only be applied in the template and module namespaces, and then to switch the protection on all existing protected templates and modules to the new type of protection. Then we would create a new user right that allows editors to edit pages protected with the new kind of protection. We are also proposing that this user right allows editors to bypass the title blacklist (in all namespaces), to give these editors the ability to create edit notices. User rights aren't limited by namespace, which is why we need the new type of protection and why we can't limit blacklist-bypassing to the template namespace. The proposal doesn't include the rights that would be necessary to edit the MediaWiki namespace. (Note that this is just my understanding - if I have any of the details wrong, feel free to correct me.) — Mr. Stradivarius ^{♪ talk ♪} 07:32, 3 October 2013 (UTC)[reply]

Essentially what Mr. Stradivarius said. The systematic change in protection would only occur for templates in the Template: namespace. If you're asking whether transcluded pages outside Template: space might be included, then I'd say they probably could be -- if they've been full-protected for the same reason, ie. due to a high transclusion rate that makes them high-risk. I'm not aware of any such pages currently, but if there are any -- and I think that would be pretty rare -- they could be similarly switched to the new protection level on a case-by-case basis. If you have any specific examples in mind it might be easier to answer this if we had a look at them. As for MediaWiki space, this proposal doesn't involve that at all. equazcion� | 10:56, 3 Oct 2013 (UTC)

Really, anything with enough transclusions to qualify for protection on that ground should probably be in template space already (with the possible exception of userboxes, but I don't know if any of them are protected anyway). Monty₈₄₅ 16:02, 8 October 2013 (UTC)[reply]

@Equazcion: I thought the idea was to include the Module: namespace as well. Or is there something I'm missing here? — Mr. Stradivarius on tour ^{♪ talk ♪} 06:49, 9 October 2013 (UTC)[reply]

Module namespace is indeed included, as are edit notices; I was just keeping it simple to answer Jc37's specific question about page transclusions :) equazcion� | 09:14, 9 Oct 2013 (UTC)

For anyone who might be interested : User:Equazcion/WikiTemplate UDL equazcion� | 03:46, 10 Oct 2013 (UTC)