This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

As well as the template namespace, I think the module namespace ought to be included, as editing Lua modules requires a similar technical skillset to editing templates. In addition, there are a few other things we need to consider in the proposal. Should we allow editors with this userright to:

• edit .js pages belonging to other users? These are typically in the user namespace, but at the moment are only editable by admins.
• edit the MediaWiki namespace? Global .js scripts are housed here, and also quite a few of the MediaWiki messages need template coding skills to edit.
• edit cascade-protected pages? The most highly-transcluded templates are typically cascade-protected. E.g. the citation templates, WPBannerMeta, Infobox... all templates that could benefit from updates by knowledgeable template/module coders.
• create/edit pages blocked by the title blacklist? This is already part of the account creator right, and would enable users with this userright to create edit notices. I think it would also mean they were able to create accounts with names similar to existing ones, although I would have to check about the exact technical details.

Also, should the namespace limitation be enforced by technical means (e.g. no edit button for fully-protected user pages), or by social means (e.g. if the user edits a fully-protected user page, the right is removed)? Some of this may be able to happen on a purely technical level, but we may be able to be more flexible if we enforce some aspects by social means. Just some food for thought - there may be other things like this that we should consider as well. — Mr. Stradivarius ^{♪ talk ♪} 08:32, 10 September 2013 (UTC)

Is there often a need force edits to .js pages of other users due to some sort of pervasive technical problem or malicious intent? If not then perhaps this could be included on the provision that it be exercised only on the request of the user who owns the .js page, in a support capacity -- although I'm not sure how often even that needs to be done, and I'm wary of including any privileges here other than those absolutely necessary, to make the RfC as likely as possible to pass.

I'd be amenable to including MediaWiki namespace pages, as they seem to fall into the same category as templates -- interface-type elements that are fully protected as a precaution, and for which many non-admin editors' technical skills would be beneficial.

The edit notice restriction is something I think should be lifted for those with this userright, as it's relatively benign and already included with another non-admin rights group, and similarly falls into the category of precautionary protection for technical reasons. equazcion ^(talk) 08:48, 10 Sep 2013 (UTC)

I'm not familiar enough with cascade protection to comment on that. equazcion ^(talk) 08:49, 10 Sep 2013 (UTC)

I'm not sure if the RfC is as likely to pass if the userright might make it technically possible for these editors to edit Wikipedia: and article-space pages that have been temporarily full-protected for reasons of controversy; so I think the namspaces should be enforced by technical means. Requiring the assessment of editors on the basis of their ability to voluntarily keep from editing controversial protected pages in those spaces is something that comes more dangerously close to admin criteria, and I think we should try to keep away from that rat's nest. Just my humble opinion. equazcion ^(talk) 08:57, 10 Sep 2013 (UTC)

Agreed about the technical vs. social aspects. The more things are enforced technically, the easier it will be to hold editors accountable, and the more likely it will be to get the user right accepted. There isn't really anything mysterious about cascading protection. It's just like full protection, only it can be applied to many pages at once. Everything you need to know is at WP:CASCADE. The point is that it is technically possible to create a user right that allows editing of fully protected pages but disallows editing of cascade-protected pages, so we need to be clear about which one we want. — Mr. Stradivarius ^{♪ talk ♪} 10:31, 10 September 2013 (UTC)

Ah I see now about cascading protection. I personally think it should be included, but this could be one of the questions per the discussion below. equazcion ^(talk) 10:37, 10 Sep 2013 (UTC)

Editing of Cascade Protected items should be included since a lot of the templates are also cascade protected (at Wikipedia:Cascade-protected items) -- WOSlinker ( talk) 12:05, 10 September 2013 (UTC)

Should that question remain as a poll, or should we include cascading protection as one given aspect of the main proposal? My vote is for the latter. equazcion ^(talk) 12:08, 10 Sep 2013 (UTC)

• My thoughts about this since it will likely affect me as a non-admin template coder...
  • editusercss and edituserjs:
    • I've actually had at least one request for helping a user fix their common.js ( Theopolisme - example). In order to help him (he is now a proficient .js editor and I can probably request the page deleted, but I think I'll wait until after this RfC has closed), I had to create a mirror of his common.js page and clean out and fix it. I had him change their own .js to simply import the version in my userspace. This would have been so much easier if I could have just edited his common.js directly.
  • tboveride
    • This would be a better option than having to have the account creator userright "just" to edit editnotices (which has been a topic of discussion lately). I would support this.
  • editinterface
    • I've submitted my share of "editinterface" requests, and think this would be a fine addition to this proposal.
  • protect because editprotected doesn't apply to cascaded pages
    • I think this one might be a harder sell because it would effectively mean that the user could edit fully protected pages in "any" namespace and wouldn't be restricted to just technical (template: module: mediawiki:) namespaces. I would of course support it, but I don't think it would pass and I would hope its inclusion in the list of options would cause the whole proposal to fail. On the flip side, if you give the Negative Nancys one thing they can object to, everything else may pass. So, I leave it's inclusion up to one of you that is more familiar with how the minds of the majority of the contributors to RfCs work xD.
• And there you have it. My thoughts on the drafting of this RfC. Technical 13 ( talk) 12:45, 10 September 2013 (UTC)
  • I'm actually hoping that the right can be feasibly restricted to particular namespaces, given editprotected being enabled (along with whichever permission enables editing of cascade-protected pages). Technical enforcement of the main proposal's namespace restrictions sort of depends on this, right? equazcion ^(talk) 12:52, 10 Sep 2013 (UTC)
    • I don't think that it can at this time... It would require development of a new userright, that I'm not sure is technically feasible. As it happens, I'm quite familiar with many of the core developers from lurking and contributing to discussions on the multiple freenode IRC channels with them. I have already asked what userright would be required to edit cascade protected pages, which is how I learned it would require protect. I would be happy to ask any other questions and see if I can work with the developers to make it happen. Let me know (Please ping me with {{ U|Technical 13}} when responding to me to ensure the fastest response from me) Technical 13 ( talk) 14:10, 10 September 2013 (UTC)
      • Technical 13, if you could ask a dev to drop by and at least provide us with a brief comment on the feasibility of template-only editing through full protection (I think template-only is what this RfC will become), that would probably be of great help. Thanks! equazcion ^(talk) 14:17, 10 Sep 2013 (UTC)
        • Equazcion, I have done so and someone should be commenting shortly. Technical 13 ( talk) 14:45, 10 September 2013 (UTC)
          • Awesome, thanks! equazcion ^(talk) 14:54, 10 Sep 2013 (UTC)
• On the name space question, the problem with allowing interface editing, or even user .js and .css editing, is that the potential to do something really malicious there, and without getting into WP:BEANS, one could do some very bad things. As long as the right is limited to template space only, the worst someone acting in bad faith could do is vandalize a bunch of pages at once, but such vandalism would be easily reverted. As such, we could have much looser standards for granting a right that allows template only editing. I would avoid tboveride and protect for now. Better to get the basic right in place, and then discuss other things it may make sense to add, then risk distracting the initial discussion with them, and having no right at all. Monty ₈₄₅ 13:44, 10 September 2013 (UTC)
  • I understand your concern, but isn't the whole point of this that we trust these users to not do malicious things with the right, and if we do, we simply take it away (and ban/block if appropriate in situations where abuse like editing a user's .js to ... WP:BEANS) I actually think it is a very good format to break all of the specific parts of it into sections so the community can decide which sections make sense (I would even go so far as to say that making the creation of the usergroup is not optional, only what rights are given to the group are up for debate. I think there has been enough consensus in previous discussions to back this idea that there needs to be a new group, just the specifics need to be worked out.) Technical 13 ( talk) 14:10, 10 September 2013 (UTC)

• On the protect user right - I've just looked at the docs, and as you might expect from the name, this would allow users to protect and unprotect pages, as well as be able to edit cascade-protected pages. If protection and unprotection come into it then this proposal isn't very likely to pass, so we will probably be better off sticking to editprotected. Maybe the best way of doing things would be to re-examine how we're using cascade protection, rather than try and get the devs to add user rights which (I am guessing) will require non-trivial coding. — Mr. Stradivarius ^{♪ talk ♪} 14:45, 10 September 2013 (UTC)

• Without writing any new code, what could be done is to add a new level of page protection (adding something like $wgRestrictionLevels = array( '', 'autoconfirmed', 'tboverride', 'sysop' ); to the config; see mw:Manual:$wgRestrictionLevels for more details), and change all protected templates (manually or with a bot) to be at the tboverride protection level (or if bundling with tboverride is not wanted, you could replace that with any other permission or an entirely new one). Permissions to edit css, js, the MediaWiki namespace, and titleblacklisted pages can also similarly be done with no new code. Jackmcbarn ( talk) 17:02, 10 September 2013 (UTC)

Should we pose multiple questions here with separate support/oppose sections, for voting on things like whether to include MediaWiki namespace? How about alternative solutions? Or should we try to distill everything down to a single proposal that has the best shot at acceptance? equazcion ^(talk) 09:50, 10 Sep 2013 (UTC)

Multiple questions would be better. Previous "all-or-nothing" proposals have failed before because of the details of their implementation, so the best bet we have of finding a consensus is to give users a separate question for each aspect of the implementation. I suggest a structure like the following:

• A general question about the proposed userright, e.g. "Would you support, in principle, a user right that allowed users with technical expertise to edit pages that are fully protected for technical reasons? These include fully protected templates and modules, and possibly other kinds of page. This question is about the idea of having such a user right, not about its exact implementation details. Questions about the exact implementation details are included further down the page."

Next have a group of questions about the technical implementation:

• Question about template namespace, e.g. "Should editors with this user right be able to edit fully protected templates, not including templates protected with cascading protection?" Probably best to have a separate question about this, so that the discussion doesn't get caught up in philosophical debate that may be triggered by the first question.
• Question about module namespace, e.g. "Should editors with this user right be able to edit fully protected modules, not including modules protected with cascading protection?
• Question about pages protected with cascading protection.
• Question about User .js pages.
• Question about the MediaWiki namespace

After that we could have questions about things that would require social restrictions, for example:

• "Should editors with this right be able to answer protected edit requests for templates?"
• "Should editors with this right be able to edit templates that are fully protected due to an editing dispute?" (I've seen templates protected for this reason a couple of times)

There may be more questions like this that we can ask. It's probably best to keep the total number of questions down to less than ten, though, to avoid the effect of getting less answers to questions further down the page. — Mr. Stradivarius ^{♪ talk ♪} 10:17, 10 September 2013 (UTC)

Agreed, although I think we should still make some attempt to limit the complexity of questions. I think the more questions there are, the more likely it will be that the outcome of the RfC will be ascertained as unactionable and require further RfCs afterward (or are we proceeding with that eventuality as a given?) I'd limit the questions to the following:

• Should there be such a userright in principal, that allows template editing, including answering edit requests as well as uncontroversial edits at disputed templates?
• Should the right include module and MediaWiki namespaces?
• Should the right include other users' .js pages, with the restriction that they only be edited when users have requested help?
• Should the right include cascading protection?

That would be my take. equazcion ^(talk) 10:44, 10 Sep 2013 (UTC)

I added my version of the questions for now just to get that started, not stating anything with finality. More can be added based on how the discussion here progresses. equazcion ^(talk) 11:22, 10 Sep 2013 (UTC)

( edit conflict) We should very definitely have separate questions about the module namespace and the MediaWiki namespace. Including the module namespace is not likely to be controversial, but the MediaWiki namespace might well be, as it would allow editors to edit interface text such as the "Main page" on the top-left of every page. As for user .js pages, not all of them belong to an actual user (at least not directly). For example, we have User:Js, which houses things like user:js/ajaxPreview - it's really more of a makeshift JavaScript namespace than a user housing a few scripts they wrote. Also, we have scripts written by users who are inactive but that are still widely used; these still need maintenance in the event of MediaWiki software changes etc., but the original user isn't around to do anything about it. So we would need to drop the bit about users requesting help. Maybe a better wording would be something like "user scripts should not be edited against the user's wishes". In addition, cascading protection and fully-protected templates and modules are closely related, so I think it would make sense to ask the cascading protection question after the template and the module one. We can probably drop the question about answering protected edit requests and the one about editing disputed templates - they aren't crucial to the proposal, and users can always discuss them in a discussion section. — Mr. Stradivarius ^{♪ talk ♪} 11:23, 10 September 2013 (UTC)

I've made some changes based on these very helpful recommendations. Let me know if I missed something. equazcion ^(talk) 11:48, 10 Sep 2013 (UTC)

I think there should there be a Neutral, Comment, Discussion or the like subsection for each option in addition to Support and Oppose. PaleAqua ( talk) 14:55, 10 September 2013 (UTC)

I cut down the RfC to a single poll with Support, Oppose, and Discussion, as the general feeling on this page appears to be leaning towards leaving out MediaWiki and other more sensitive areas, at least from this RfC; and to possibly propose additions later on, should this be successful. equazcion ^(talk) 16:07, 10 Sep 2013 (UTC)

Looking at PaleAqua's comment at Wikipedia:Village pump (proposals)#New userright: Edit protected in Template namespace only, I can see that we've missed something very important. I think it will be essential to ask a question, or preferably questions, about what criteria the user right should be given out by. Different editors may have very different expectations here, so asking questions about the criteria will avoid users opposing the proposal if they don't like the ones that we choose. I think it would be best to have a different question about each individual criterion, i.e. one question about overall edit count, one question about edit count to template/module space, one question about the minimum time since last block, etc. — Mr. Stradivarius ^{♪ talk ♪} 11:32, 10 September 2013 (UTC)

I think that could make the page excessively complex. What sort of additional questions would there be? Could we maybe flesh out criteria in the drafting stage instead, based on people providing their opinions on this talk page? The criteria listed currently is just a result of my semi-arbitrary opinion off the top of my head. I'd invite all to propose tweaks or their versions of complete criteria, and hopefully we can come out with something likely to please? equazcion ^(talk) 11:58, 10 Sep 2013 (UTC)

I'm anticipating that this discussion will probably about as big as the last one. However you look at it, it's going to be complex, and editors are going to discuss all aspects of the user right somewhere or other on the page. I subscribe to the theory that in the end it is actually less complex to give editors a clear structure in which to discuss what they want to discuss. Also, for this kind of thing, you can spend a long time coming to a consensus on a draft wording, but in the end it will be the consensus in the RfC that matters. If you think about the mechanics of it, it is much more likely for a consensus to emerge if you allow editors to answer "500 edits", "1000 edits", or "2000 edits", rather than "oppose", "neutral" or "support". — Mr. Stradivarius ^{♪ talk ♪} 12:42, 10 September 2013 (UTC)

May also be wise to consider dropping the "MediaWiki namespace" option before it starts (in my opinion). -- WOSlinker ( talk) 12:50, 10 September 2013 (UTC)

• I think the current version of the criteria are too strict. I would reduce the account age to 3 months, and remove the explicit template edit count requirement. To start with, 6 months is generally the account age where editors start being acceptable at RFA, and by a year the account age is going to be mostly a non-issue there, I don't think we need to be as strict or stricter then the practical standards for full RFA. As for the edit count in template space, the quality and sort of edits matters more then the quantity. Further, the main reason for full protection in template space is protection against vandalism, not to stop good faith editors from making mistakes. In the other potentially included namespaces, mistakes could matter more, but I think we should focus on templates first. Monty ₈₄₅ 13:28, 10 September 2013 (UTC)
  • I'm perfectly open to easing the restrictions, but some food for thought: Seeing as gaining this user right would not entail a process nearly as rigorous as RfA, maybe the proposal has a better chance of acceptance if the criteria were stricter than those required for adminship? As for MediaWiki namespace and other areas, I would like to hear more input on whether to limit this RfC purely to template space. I too have a feeling people may be scared off by mention of allowing the other areas, even though on the flipside I think including them is not actually a problem and would be helpful. equazcion ^(talk) 13:36, 10 Sep 2013 (UTC)

I think that it should be made clear that anyone with this right (and admins too) should make changes in sandbox version first if they are making significant changes to any of the more complex templates, and should only be modifying the templates directly if they the changes are simple ones. -- WOSlinker ( talk) 11:34, 10 September 2013 (UTC)

I would be more restrictive than that and say that all changes to protected templates and modules need to be made first to the sandbox and then tested in a properly designed testcases page. It costs little to do these things and avoids the oops when all of the braces don't match.

I fully support this userright proposition. Where do I sign up?

— Trappist the monk ( talk) 11:42, 10 September 2013 (UTC)

I added something to the effect of WOSlinker's suggestion. I don't think it's necessary to stipulate every change must be sandboxed first. There are a multitude of simpler tweaks that carry a negligible risk of causing trouble, and requiring sandbox testing first for those would significantly cripple techies' enthusiasm for providing their expertise, I think. I don't think admins currently do this across the board either. equazcion ^(talk) 11:52, 10 Sep 2013 (UTC)

Currently the Revocation criteria seem overly broad... I propose the following changes

• The editor performed controversial edits without first determining consensus with respect to edits enabled by this userright
• The editor demonstrated negligence in performing a complex edit to a high-use, fully-protected template, without testing the edit from a sandbox first, that did or might have likely caused problems across a broad range of pages.
• The editor used the privilege to gain the upper hand in a dispute with respect to edits enabled by this userright
• The editor edited a fully-protected page whose protection had resulted from an edit war, in any capacity other than absolutely non-controversial maintenance with respect to edits enabled by this userright.
• The editor has been inactive for two years.

The purpose is to give a reasonable amount of protection to editors who have acquired this right to not have it taken away for causes unrelated to the editing of fully protected templates. Something similar to the "Do as I demand or I'm going to take your toy away" kind of veiled threat that I've seen some admins make and editors scream abuse over. Hasteur ( talk) 12:08, 10 September 2013 (UTC)

I added the suggestion for the first line. For the upper hand one, it seems like it might be conceivable that a user might edit a protected template to gain the upper hand at an article or other page not related to this userright, so I don't think it would be wise to make that change there. In the last instance, the line already states it only applies to "fully-protected page[s]", so I don't think it's necessary there -- but let me know if I'm missing something. equazcion ^(talk) 12:13, 10 Sep 2013 (UTC)

I've changed two years to 12 months so that it is not longer than WP:INACTIVITY -- WOSlinker ( talk) 12:16, 10 September 2013 (UTC)

Ah, ok. That sounds wise. equazcion ^(talk) 12:18, 10 Sep 2013 (UTC)

(RE to 12:13) The reason why I specified on point 4 is making sure that editing fully protected things besides a template don't get conflated with revoking the template-editor userright. Point 3 was duplicated, but better to be explictly proscriptive than let a cowboy admin make a decision that could reduce the community's confidence in the admin Hasteur ( talk) 13:01, 10 September 2013 (UTC)

This proposal is to restrict the userright to allow only the editing of pages in particular namespaces -- that is to say, we're hoping to technically restrict them, so that editing anything else that's fully protected would be impossible (such as an article). There's the possibility that a MediaWiki developer will come along and say such a restriction is not feasible (though I can't see why it would be) -- but if that happens, someone with this userright would not be permitted to edit anything fully-protected outside of these namespaces, so I'd say the right should still be revoked if they do. Unless I'm still not understanding what you mean. equazcion ^(talk) 13:13, 10 Sep 2013 (UTC)

• I'd replace criteria 2 with something more forgiving, such as: The editor demonstrated a pattern of failing to exercise sufficient care when editing protected templates, resulting in serious errors appearing on pages. We don't want to pull the right from one mistake, its a pattern of behavior we should be looking for as long as they are still acting in good faith. Probably get rid of criteria 1, as most of it is already covered by 3 and 4. If it stays, it should be modified to only apply if the editor should have known the edits would be controversial. Monty ₈₄₅ 13:36, 10 September 2013 (UTC)
  • I'll make the change on the negligence item. However I think an edit can be controversial without having resulted from an existing dispute, so I feel the first criterion should stay. Thoughts? equazcion ^(talk) 13:39, 10 Sep 2013 (UTC)
  • I have tweaked the first criterion per your suggestion though. equazcion ^(talk) 13:47, 10 Sep 2013 (UTC)

( edit conflict)The way I look at it, an admin considering an edit through protection in article space is on notice that there is a strong potential that any edit will be controversial, and that they need investigate to make sure a particular edit wont be before making it. That is on account of the fact that the vast majority of the time, an article space page is only fully protected because of an ongoing dispute or controversy. (There are a very few full protections as a result of really bad socking, but they are such a minority that the assumption protection is controversy based stands). That wont be the case in template space, where the vast majority of protection is a counter vandalism measure. While there are probably places an admin (or new right holder) should know an edit is going to be controversial, I think often it wont be known that the edit is controversial until after the fact, and that generally shouldn't be held against the person who made the edit in the first place. Monty ₈₄₅ 13:54, 10 September 2013 (UTC)

There are many potential blatantly controversial edits though. You could blank a template -- that would be more than foreseeably controversial. You could change "Please don't..." to "Please do...". These might go without saying, but I think it should be said nonetheless to prevent lawyering later on based on the wording of this page. Better safe than sorry, I suppose is what I'm saying. equazcion ^(talk) 13:59, 10 Sep 2013 (UTC)

Right, but that is why I think a should have known standard would make sense. Someone making either of those edits should have known they would be controversial. Its probably beyond AGF to assume that either was made in good faith. What I'm aiming the language at is someone who made an edit that they reasonably could have believed would be uncontroversial, but turns out not to have been. Monty ₈₄₅ 14:08, 10 September 2013 (UTC)

I added the word "obviously" to the criterion, see the current version. Do you think that's sufficient? equazcion ^(talk) 14:11, 10 Sep 2013 (UTC)

Ahh, that should be fine then. Monty ₈₄₅ 14:13, 10 September 2013 (UTC)

Should the userright proposed here be limited to editing full-protected templates alone, or should it include the possibility of allowing editing of the additional areas currently mentioned (MediaWiki, Lua modules, .js/.css)? While technical people might see the benefit to the added areas, we might see broader acceptance of this proposal if we forgo mention of those more sensitive areas. Please cast your vote. equazcion ^(talk) 13:51, 10 Sep 2013 (UTC)

It may be better to limit it to Template & Module namepaces to start with and then if that passes the vote, the others could be done in a separate Rfc. -- WOSlinker ( talk) 14:28, 10 September 2013 (UTC)

I agree, limit to template & module. Save the rest for a future RFC. User .js/.css in particular seems like it could be divisive and distracting to the rest of the RFC. PaleAqua ( talk) 14:50, 10 September 2013 (UTC)

( edit conflict) I'm inclined to agree. Limit it to template and module space, and to the editprotected user right. The problems with cascade protection can be solved by un-cascade-protecting things, rather than including the protect right in the proposal. Also, a word on the module namespace - although Lua may be a fully-fledged scripting language, you can't do any of the bad stuff that Monty 845 mentions above, because everything is sandboxed by the Scribunto extension. Any bad things you can do in the Module namespace you can also do with templates (although a lot slower). — Mr. Stradivarius ^{♪ talk ♪} 14:56, 10 September 2013 (UTC)

Based on the above as well as my agreement with the above, I've cut down the RfC to limit it to a simple question of template, editnotice, and module space. This can always be reversed if the tide turns. Thanks for the responses. equazcion ^(talk) 15:41, 10 Sep 2013 (UTC)

So, as promised I asked on #mediawiki on IRC and this was the conversation I had with MatmaRex:

... ... ...
[08:36] <T13|needsCoffee> I have a question. *dun dun duuunnnn* what is the userright that would be needed to be added to a usergroup to allow editing cascade protected pages?
...
[08:37] <MatmaRex> T13|needsCoffee: i think it's 'protect'
[08:37] <MatmaRex> T13|needsCoffee: but somebody was poking about that recently, so i'm not sure
...
[08:38] <T13|needsCoffee> So they would actually have to have the right that allows unprotection.  Thanks MatmaRex 
...
[08:39] <MatmaRex> T13|needsCoffee: yeah, since otherwise you could make a page protected by transcluding it on a cascade-protected one, without having the right to actually protect pages
...
[10:33] <T13|needsCoffee> MatmaRex, who would be the best developer to ask to comment on [[en:WT:Request for comment/Template editor userright]] about feasibility of template only editing through page protections?
[10:33] <T13|needsCoffee> @link
[10:33] <wm-bot> http://enwp.org/WT:Request_for_comment/Template_editor_userright
...
[10:35] <MatmaRex> T13|needsCoffee: that's a red link you've given me.
...
[10:37] <T13|needsCoffee> @link [[en:WT:Requests for comment/Template editor userright]]
[10:37] <wm-bot> http://enwp.org/WT:Requests_for_comment/Template_editor_userright
[10:37] <T13|needsCoffee> Missed an s
[10:37] <T13|needsCoffee> Need more coffee
...
[10:58] <T13|needsCoffee> MatmaRex: Any ideas?
...
[11:08] <MatmaRex> sorry T13|needsCoffee, was afk
...
[11:09] <MatmaRex> T13|needsCoffee: generally the rights for editing protected pages and actually protecting them are separate, except for the cascading thing you asked about earlier
...
[11:09] <T13|needsCoffee> Which is where the concern is.
[11:09] <MatmaRex> T13|needsCoffee: so this can be done by simply creating a new user group with a subset of sysop capabilities
...
[11:10] <MatmaRex> T13|needsCoffee: as for namespace-limited rights, that might also be doable with just configuration, but you'd have to jump through a few hoops
...
[11:10] <T13|needsCoffee> MatmaRex: Could you or another WMF representative comment on the RfC draft please? :)
[11:11] <MatmaRex> T13|needsCoffee: but frankly, if you ask me, you should probably just give the dude sysop rights in that case ;)
...
[11:11] <T13|needsCoffee> Ha.. feel free to add that comment as well. ;)
...
[11:12] <MatmaRex> T13|needsCoffee: we had some similar situations at pl.wp and IIRC they ended with the people being granted the rights
...
[11:13] <MatmaRex> T13|needsCoffee: i'm not sure if there is anybody in particular who could be asked about what you want there… maybe anomie, he was cleaning up some user-right stuff recently for OAuth integration
...
[11:13] <MatmaRex> T13|needsCoffee: (anomie = brad jorsch)
...
[11:13] <MatmaRex> T13|needsCoffee: let me look and see if namespace-based protection would be possible in the way you want
[11:14] <T13|needsCoffee> MatmaRex: if you have a few moments, could you add a new section to the bottom of the talk page with all that info?  I would very much appreciate that. :)
[11:15] <MatmaRex> !wg GroupPermissions
[11:15] <wm-bot> https://www.mediawiki.org/wiki/Manual:$wgGroupPermissions
[11:16] <MatmaRex> !wg NamespaceProtection
[11:16] <wm-bot> https://www.mediawiki.org/wiki/Manual:$wgNamespaceProtection
...
[11:20] <MatmaRex> T13|needsCoffee: you know what? i think that what you *really* want is a third protection level between autoconfirmed and sysop
[11:20] <MatmaRex> T13|needsCoffee: have you considered that?
[11:21] <MatmaRex> this is definitely possible and enabled on i think pl.wp and pt.wp
[11:22] <MatmaRex> at pl.wp the middle level is for "editors" (users who can review pages in the FlaggedRevs aka PendingChanges system), on en it could probably be for rollbackers or something (or a new group)
[11:22] <MatmaRex> most high-risk templates are protected to this level, only a handful of "perfect" ones like {{tl}} is fully protected
...
[11:23] <MatmaRex> T13|needsCoffee: i think that the feature as described in that RFC will be hard/impossible to implement
[11:23] <MatmaRex> feel free to quote all i said somewhere relevant, but note that i am not an expert on this ;)
... ... ...

So, perhaps a ping for anomie would be appropriate? Technical 13 ( talk) 16:17, 10 September 2013 (UTC)

Thanks so much, Technical 13 and MatmaRex. I hope we hear from him. Monty described an alternative on my talk page suggesting lowering high-risk templates to Pending Changes 2 level and granting PC2 to to the intended users -- or would that be the current Reviewer group already? I'm not all that well-versed in Proposed Changes... but I think granting the template editor group proposed here would need to entail more stringent criteria than those that have been used thus far in granting the Reviewer right, IMO. equazcion ^(talk) 16:27, 10 Sep 2013 (UTC)

That would be the current reviewer right. PC 1 allows any auto confirmed editor to edit the page, when an non-auto confirmed editor edits, it triggers PC, and a reviewer must then approve the change. With PC2, only reviewers (and other rights packages that include reviewer like admin) can edit without pending changes triggering and requiring approval. The previous version of the page is displayed for most (all?) viewers until the change is approved. Monty ₈₄₅ 16:44, 10 September 2013 (UTC)

Ah I see, thanks for that. Reviewer has been given out like candy though, so I think a new rights group would still be needed if we went that route. equazcion ^(talk) 16:47, 10 Sep 2013 (UTC)

There appears to be another problem, I just tested it, and transclusion appears to pull the latest version, ignoring pending changes. So even if we went with my proposed route, it would require that to be fixed by the devs. See Wikipedia:Pending changes/Testing/4 and User:Monty845/Sandbox3 where I transcluded the first page. The transcluded page has the removal of bolding from the first word pending, but it appears without approval when transcluded . Monty ₈₄₅ 16:50, 10 September 2013 (UTC)

As I understand it, there are other limitations with PC and templates. See the previous RfC. Specifically the concern brought up by User:Mr. Stradivarius about how the changes would be visible to logged in users. I also thought the PC was intentionally disabled for the template namespace, or is that still the case? PaleAqua ( talk) 16:59, 10 September 2013 (UTC)

I mentioned Monty's PC suggestion because of MatmaRex's suggestion of adding a protection level between autoconfirmed and sysop (in the IRC discussion above). They seemed to be describing almost the same thing, but PC2 seems to do a bunch things other than merely add a new mid-layer. We're probably best off with a new protection level and rights group to go with it -- unless it does turn out to be technically feasible that the editprotected permission can be restricted to particular namespaces for a particular rights group, in which case we just need that new rights group. If that makes any sense. equazcion ^(talk) 17:10, 10 Sep 2013 (UTC)

Yeah, sounds like that's the route of least resistance. Monty ₈₄₅ 17:19, 10 September 2013 (UTC)

I'm not entirely sure what the question here is, so I'll answer a few of them.

1. It's not possible to restrict a right to a particular namespace, so if you give someone editprotected then they can edit non-cascading sysop-level protections anywhere. It would be possible to add a new protection level that would only be applied to templates, if the community really wants such a thing.
2. As far as I understand Pending Changes/FlaggedRevs, there is a config flag to control whether the latest version of a template or the latest "approved" version of a template is transcluded. But I'm not familiar with exactly how it works or whether there are performance reasons for it to be set as it is here.
3. It's not possible to give someone the ability to edit cascade-protected pages without also giving them the ability to directly protect pages. The reason for this is simple: if someone can edit a cascade-protected page, they have a "back door" to protecting any other page by simply transcluding it onto a cascade-protected page.

HTH. BJorsch (WMF) ( talk) 19:13, 10 September 2013 (UTC)

And note that the additional protection level may run into resistance along the lines of WP:PEREN#Hierarchical structures. Anomie ⚔ 19:14, 10 September 2013 (UTC)

Thanks for the info, Brad. I think we're all prepared for the resistance this is bound to produce, although a multitude of comments at Wikipedia:Requests for adminship/Trappist the monk actually have me rather optimistic that general feelings are changing on this. It's good to know that this will be technically feasible with a new protection level. Thanks so much for your input! equazcion ^(talk) 19:18, 10 Sep 2013 (UTC)

In light of this, it might be best to give up on the idea of technically restricting the use of the user right on non-template/module namespaces. But that's not such a bad thing - we can just switch to a social restriction. I suggest we add some language to the effect that the user right will be removed if used to edit pages out of the template or module namespaces. That way we can use the editprotected right and avoid the need for the proposal to require any significant development time. — Mr. Stradivarius ^{♪ talk ♪} 22:02, 10 September 2013 (UTC)

The technical restriction appears to be feasible with the addition of a new protection level, which would primarily just be a config change, not requiring much if any development -- so I'm not sure I understand why you think it would be necessary to abandon hope of a technical restriction. equazcion ^(talk) 22:07, 10 Sep 2013 (UTC)

Because we would need to go through and change all fully-protected templates to use the new protection level instead. And because it would mean introducing two new things in the proposal, not just one, which I think would make it more likely to attract opposition. — Mr. Stradivarius ^{♪ talk ♪} 22:17, 10 September 2013 (UTC)

I think the security of a technical namespace restriction would trump the difficulty of adding the rights group and protection level (which again are just config changes), as well as the protection changes, which can be done via bot -- or in the worst case scenario, by request, the first time each page needs to be edited by a user with the right. Making the namespace a social restriction while users granted the right would have the technical ability to edit any namespace's fully-protected pages would be a relatively big put-off to the community, IMO. equazcion ^(talk) 22:25, 10 Sep 2013 (UTC)

Actually requiring a new protection level provides a couple benefits that might be useful in helping this to pass. One is that it could be applied to only a subset of the highly protected templates at start to allow for a trial run if people want to see how it works in practice. The second is that it leaves full-protection as a separate option. Templates that are currently protected just because they are heavily used could get the new level, but full-protection could still be used for template edit wars and the like. PaleAqua ( talk) 22:39, 10 September 2013 (UTC)

That's a good point about still allowing full protection for edit wars, that the new rights group wouldn't be able to edit. I didn't think of that. I should probably add something about that to the RfC. equazcion ^(talk) 22:43, 10 Sep 2013 (UTC)

...and done :) Thanks PaleAqua. equazcion ^(talk) 23:05, 10 Sep 2013 (UTC)

Just spitballing a couple ideas here and I realize the more this does the less likely it is to succeed but there are 4 potential things that would be useful to haev in this and I know at least 2 are already mentioned.

1. Edit protected templates in the template namespace
2. Edit protected Modules in the Module namespace
3. Potentially be able to modify the Mediawiki namespace
4. Allow the user to pull in more than 25000 articles from AWB

I'm not sure if #3 is realistic but it seems like several of the folks who would get this also know how to do at least some of the changes to that namespace as well. Additionally, The 4th one is more of just a nice to have and is pretty benign but is currently restricted to admins. There was some talk about adding it to Rollbacker or Filemover but that fizzled out. It might also be beneficial to call this something more like Technical author or something if we end up adding more than just template namespace. Kumioko ( talk) 19:34, 10 September 2013 (UTC)

I would love to add all of this and more. Originally we had MediaWiki space and js/css pages in the draft as well, but the general feeling has been to limit the focus to templates/modules/editnotices for the time being, and other permissions can be proposed for addition later if this passes. The major hurtle will be getting, well, something to pass first, and we're all wary of getting greedy :) equazcion ^(talk) 19:40, 10 Sep 2013 (UTC)

Yeah I think there will be enough trouble with getting anything to pass around here...even gas. :-) For what its worth I like the idea of an interim editor between autoconfirmed and Admin too. Kumioko ( talk) 19:52, 10 September 2013 (UTC)

I don't think this really is a interim editor between auto-confirmed and admin, or even an admin in training, or any of the other various pre-admin stepping stones that have been suggested several times in the past. This userright is for a very specific and real issue, that of maintaining and assisting the maintenance of highly visible templates. This is more a branch akin to reviewer but for templates, but without the technical problems related to using pending changes for templates, and with a different, criteria for who can get the right. The people best suited to this role are often not the people that would be interested in hat collection, being admin or any of the like. I fear framing this as some sort of sub-admin, apprentice admin, or the like is the easiest way for this to get derailed into the no-consensus zone. PaleAqua ( talk) 00:05, 11 September 2013 (UTC)

^Agreed on all fronts. I'm not sure if Kumioko actually meant the word "interim" in the literal sense of something that comes in anticipation of something else down the line, but in any event we should probably keep a distance from anything that could be construed as such. This is a specific user right for those who do a specific type of work here, akin to Autoreviewer, File mover, etc. and shouldn't be confused with a semi-admin role. equazcion ^(talk) 00:20, 11 Sep 2013 (UTC)

Your right I agree this is not a pre admin role and I didn't mean to infer it was...I just meant that I support the idea of an interim level between peaseant and Lord. :-) Kumioko ( talk) 00:50, 11 September 2013 (UTC)

IMO, let's get the foot in the door before we start asking for "above and beyond" requests. Hasteur ( talk) 20:01, 10 September 2013 (UTC)

As far as I'm concerned this is ready for public consumption, but I've been wrong before (also been impatient before). Please have a look through the current draft and speak if you have any thoughts on changes that might increase chances of pushing this through. If there are no significant issues raised for 12 hours or so, I'm going to archive this talk page and start advertising links. Thanks, and thanks to everyone for your help and insights thus far! equazcion ^(talk) 19:37, 10 Sep 2013 (UTC)

The technical means of accomplishing it may deserve higher visibility then just being in that foot note. That would make it easier to address any concerns about creating a new protection level for template space, by both assuring that it wont migrate to article space, and that it will only be used in place for full protection, not be used to expand the protection of template space. Monty ₈₄₅ 19:42, 10 September 2013 (UTC)

Okay, I moved the explanation out of the footnote and into the main text. equazcion ^(talk) 19:50, 10 Sep 2013 (UTC)

• I think the last two Criteria for granting are too weak. Propose increasing the threshold to:
  • The editor should have worked on the sandbox version of at least three protected templates.
  • The editor should have used the {{ editprotected}} template at least ten times to successfully request edits to fully-protected templates.

I actually think that 5-8 and 20-25 are more appropriate, but I'll go low here... I also think there should be another note say that edits to the MediaWiki: namespace and user .js/.css should be kept for a future RfC if this one is to pass. I feel that otherwise, the discussion will quickly get off-topic asking "what about" those things. Technical 13 ( talk) 20:02, 10 September 2013 (UTC)

I increased the the sandbox requirement to three, and the protected edit count to five. Ten seems high -- there might be some personal feelings involved here, as I don't remember exactly but I think I myself might not qualify for the ten protected edits :) Even though I've made some rather substantial contributions with my sub-ten protected edits. Does anyone else feel it should be as high as ten? equazcion ^(talk) 20:11, 10 Sep 2013 (UTC)

Remember though that this is in addition to 200+ template space edits plus the discretion of the assigning administrator, who will presumably be judging the contributions in a weighted fashion, ie. they will assess whether the person knows what he's doing based on more than just numbers. equazcion ^(talk) 20:20, 10 Sep 2013 (UTC)

Yeah, that was why my proposal above was conservative. I know that I've personally had single templates that I've had five or ten successful {{ editprotected}} requests on. Technical 13 ( talk) 21:08, 10 September 2013 (UTC)

• I think it is ready... Do it! * T13|needsCoffee is quivering in anticipation. Technical 13 ( talk) 00:16, 11 September 2013 (UTC)
• Please don't take this live until after the RFA it refers to finishes. It isn't long to wait, but otherwise it could disrupt, or even be seen as promoting an RFA. Ϣere SpielChequers 00:34, 11 September 2013 (UTC)

  Seconded on waiting for the RfA to finish. PaleAqua ( talk) 00:40, 11 September 2013 (UTC)

  ( edit conflict) 6 days? That's quite a bit longer than I'd like to wait. I'm not sure how it could be seen as promoting the RFA, other than it containing a link to it -- it actually seeks to prevent such RFAs from even starting in the future. Who knows, maybe this will conclude with overwhelming support before the RFA finishes, and everyone at the RFA will switch to Oppose because the new userright will be available for the candidate instead :) Only those editors dead-set on assuming bad faith will think this is an attempt at promoting the RFA; I can't realistically see many of those appearing or get taken seriously. I understand the concern but I don't think it's all that warranted. I'll likely risk taking this live by tomorrow morning, give or take. equazcion ^(talk) 00:42, 11 Sep 2013 (UTC)

  I further think it'll be beneficial to capitalize on the feelings presented predominately at RFA, that unbundling would be the best accommodation for that candidate. Waiting will just provide time for people to forget about that. It helps to have a good current example fresh in people's minds. equazcion ^(talk) 00:45, 11 Sep 2013 (UTC)

  I'd rather not wait until the RfA finishes as well. That being said, I think we probably reword the link to said RfA. " Trappist the monk's current request for adminship" may be construed as non-neutral. That being said, I think that removing the work "current" and using the abbreviation should be fine " Trappist the monk's RfA". Small thing, but don't want it to interfere or cause a distraction. If the RfA finished before the RfC (which I expect it will), then the word "current" would be inaccurate and a reason to cause a distraction for those looking to distract. Technical 13 ( talk) 01:05, 11 September 2013 (UTC)

  You may have a point, and I tweaked the link wording as suggested. equazcion ^(talk) 01:09, 11 Sep 2013 (UTC)

Should closers be found before this is opened? PaleAqua ( talk) 02:02, 11 September 2013 (UTC)

A closer isn't designated prior to opening an RFC in my experience, though it's been a while since I made an RFC. Is that what's generally done now? equazcion ^(talk) 02:15, 11 Sep 2013 (UTC)

Its been done for a number of major RFCs that were anticipated to be controversial recently, personally I'm not a fan of the practice. It hasn't been an issue yet, but one of these days its gonna blow up over the selection. Monty ₈₄₅ 02:26, 11 September 2013 (UTC)

Hmm. I don't think it's necessary. This particular proposal will come down more to numbers than a judgment of rationales, and if the outcome ends up being so close that it would've mattered who was closing, it probably shouldn't pass anyway. PS. I'm moving this page to Requests for comment/Template editor user right, with two separate words -- I previously thought the single-word techie term "userright" was more widely used, but now I'm thinking the other way will read better. equazcion ^(talk) 09:51, 11 Sep 2013 (UTC)