Wikipedia talk:Requests for comment/MediaWiki editor

Page contents not supported in other languages.
Source: Wikipedia, the free encyclopedia.

What would you think about ...

... the possibility of a new user right being created called "MediaWiki editor"? Given that it's purpose is basically self-explanatory due to its name, what do you think? (Oh, and obviously, there's a good reason why this should not be bundled with with the template editor right, but having that right could be a prerequisite to getting this one, if created.) Steel1943 (talk) 16:01, 27 June 2014 (UTC)[reply]

  • @Steel: I assume this would have the editinterface, edituserjs, and editusercss at very least in it? Might it also include protect which would be required to edit cascade protected pages (since it seems unlikely that Bugzilla:54081 is going anywhere anytime soon) and/or apihighlimits to allow more efficient script processing? I do believe that userright would be the last step of the puzzle for tools I would need to do most of my work without having to run through an RfA (I really don't want to have to do that all that much). My greatest concern with attempting to get something like this to achieve a community consensus is that there will be a lot of neigh-sayers that are just worried about "hat collectors" and the like. I would be happy to work with you and whomever else may be interested (Equazcion and Trappist the monk: come to mind) on developing such a proposal. — {{U|Technical 13}} (e • t • c) 16:40, 27 June 2014 (UTC)[reply]
(
talk) 20:01, 28 June 2014 (UTC)[reply
]
  • Jim, that's a global right, not a local one, and it is temporary. What Steel is proposing is a local, more permanent version of that. — {{U|Technical 13}} (e • t • c) 20:18, 28 June 2014 (UTC)[reply
    ]
Hmm. I support this proposal. Did he proposed it anywhere??
talk) 20:22, 28 June 2014 (UTC)[reply
]
Some people don't like those templates. 20:58, 28 June 2014 (UTC)

Okay, some specifics of what I have in mind as "maybe" a good idea to propose this as...

As for potential first candidates for this usergroup, I'm thinking

Helder.wiki, Cyberpower678, Kephir:, and myself to name a few... — {{U|Technical 13}} (e • t • c) 21:56, 28 June 2014 (UTC)[reply
]

(
open channel) 22:04, 28 June 2014 (UTC)[reply
]
A few notes from a technical standpoint: I see no reason why this should include apihighlimits, autopatrol, autoreview, rollback, or suppressredirect. None of these are necessary to make edits to any sort of protected pages. I also don't see why it needs to involve the edit filter or importing. Further, the current autochecked group is useless because its only permission is also part of autoconfirmed, and as written, the new group wouldn't remove the need for the reviewer group. Jackmcbarn (talk) 22:09, 28 June 2014 (UTC)[reply]
  • Jack, I've struck the things you mention that I can't argue a specific use for except to reduce the number of user groups these users would need to be in. apihighlimits would improve processing speeds of userscripts that don't have a hard coded limit set on them and would be very useful for getting information from the API (a list of user skin pages using a userscript that may be retired or moved or something of that nature). suppressredirect is included in the same global package and I'm assuming it's there because it's not a good idea to leave "that" kind of redirect when moving a javascript or css page. As far as AbuseFilter goes, I would consider that part of the "interface" package and being able to easily import gadgets or scripts from another site (like meta) seems like it may be handy from time to time. Due to the sensitivity of both of those, and the non-persistent need, they would be add only when needed for a specific task and then remove yourself type deals (which is basically my understanding of how most administrators do it). I would think such a userright would also have the same basic "this right will be removed if" as administrator. — {{U|Technical 13}} (e • t • c) 22:26, 28 June 2014 (UTC)[reply]
I agree with Jack, but I am honored that you would pick me as candidate for this right. :-)—
ChatOnline 22:29, 28 June 2014 (UTC)[reply
]
  • Cyberpower678, yours is one of the users I frequently see requesting changes to MediaWiki pages, so it only makes sense... ;) — {{U|Technical 13}} (e • t • c) 22:43, 28 June 2014 (UTC)[reply]

Steel1943's response, and proposal

Wow, I'm late for the party. I don't understand why this discussion has turned this way. Anyways, from the list above made by Technical 13, the following should NOT be part of this new user right:

  • apihighlimits (Per Jackmcbarn's description of the right and that it automatically grants the supressredirect right)
  • autopatrol
  • autoreview
  • editprotected
  • editsemiprotected
  • protect
  • suppressredirect
  • templateeditor

(I see that "autopartol" and "autoreview" were already crossed off, but I'm crossing them off again to show that I agree.) When I mentioned this proposal, my idea was, and still is, to allow an editor to edit pages in the MediaWiki namespace, and that is all. First off, this right should not allow an editor to edit a semi-protected or protected page; we already has permissions for that, one being confirmed or autoconfirmed, and the other one is being an administrator. We should in no way be editing a fully protected page unless we are administrators, which is not the purpose behind this proposal. However, I do agree that this right should allow the editor to bypass cascading protection (but NOT full protection). Also, since this would be a separate right that would be added on TOP of Template editor, that right should not be bundled with this one. Essentially, think of this right as another name: Template Editor II. It's purpose would be to add the following permissions on top of the template editor right:

  • What this user right would allow editors to do:
  • Allow editing in the MediaWiki namespace
  • Allow editing on pages that the editusercss and edituserjs rights provide
  • Allow editing cascade-protected pages. (Note: this permission would NOT allow editing pages with full or permanent protection. Since the cascading protection is in place to protect Wikipedia from having a crucial system-required page disrupted, those pertain to this right. In addition, administrators would have to be aware of this right's existence to ensure that cascade-protected pages that should not be edited by editors with this right are out under permanent or full protection.)

...And that is all this right would provide. It's not to bundle more existing tools/rights with it, but to provide the access for trusted editors who understand the functionality of Wikipedia "behind the scenes" to provide assistance. (So, no bundling

Importers
' permissions with this right; they are separate rights for a reason, and should remain that way.) I may start writing a rough draft for this proposal in the near future, but here would be a rough standard for granting and revoking this right:

  • Granting
  1. Editor already has the template editor user right
  2. Editor has requested (insert amount here) successful edit requests combined on the talk pages of MediaWiki pages and cascade-protected pages subpages in the User: namespace that end with .css or .js
  3. (No more criteria needed: the criteria for granting Template Editor addresses the rest of the concerns with this right)
  • Revoking
  1. Editor has their Template Editor right revoked
  2. Editor makes edits on cascade-protected pages subpages in the User: namespace that end with .css or .js and/or MediaWiki pages to bring themselves in the upper hand in a dispute, or to cause vandalism
  3. Please refer to the criteria for revoking Template Editor for the rest of the criteria (such as inactivity for a year, etc.)

In fact, this might as well act as a rough draft for the proposal. Also, Technical 13, I do not understand the purpose of the editinterface or tboverride permissions; what are those used for? Steel1943 (talk) 00:19, 29 June 2014 (UTC)[reply]

To be able to edit cascade-protected pages, you absolutely need both editprotected and protect. Cascading protection is a strictly higher level of protection than full protection, and to edit the former, you must also be able to edit the latter. There's no way around it. Editinterface is what allows editing the MediaWiki namespace, and tboverride is what allows editing things on the titleblacklist (like editnotices). Jackmcbarn (talk) 00:22, 29 June 2014 (UTC)[reply]
@Jackmcbarn: I strongly disagree. A page can have cascading protection on it without full protection, and vice versa. The distinction between the two needs to remain in place to allow administrators to enforce page protections. An editor who is granted this right to edit MediaWiki and cascade-protected pages has no business having permission to edit articles or other non-template or non-MediaWiki pages that are fully protected due to content disputes, edit wars, or persistent vandalism. (P.S. Thanks for the clarification on those two rights I asked about above; editinterface is clearly needed, and tboverride seems necessary as well.) Steel1943 (talk) 00:36, 29 June 2014 (UTC)[reply]
@Steel1943: What I said isn't a policy or opinion issue. It's the way the software works. There's not really room to disagree. Jackmcbarn (talk) 00:37, 29 June 2014 (UTC)[reply]
@Jackmcbarn: Then, how is the "software" able for me, as a "template editor", to be able to edit a page that has template protection and no cascading protection, but NOT able to edit a page with template protection AND cascading protection? (Technical 13 may recall this instance: this happened with Template:Notice a few months ago.) Steel1943 (talk) 00:45, 29 June 2014 (UTC)[reply]
The software is hardcoded that any page with cascading protection requires the "protect" right to edit, plus whatever right is needed to edit the page that the cascading protection came from. Jackmcbarn (talk) 01:09, 29 June 2014 (UTC)[reply]

T13's TL;DR response section

Tracked in Phabricator
Task T56081

Okay, so apparently, there is some confusion about what technically something of this nature would require... So, let's break it down...

  • apihighlimits
    • allows user to use higher limits for API queries
    • This allows people to access 5000 entries from the API per query instead of the normal 500.
  • editinterface
  • editprotected
    • allows to edit protected pages (without cascading protection).
    • It's included with the global version of this usergroup because it is needed to edit cascading protected pages per Jackmcbarn's comment above...
  • editsemiprotected
    • allows to edit semiprotected pages (without cascading protection).
    • It's included with the global version of this usergroup because it is needed to edit cascading protected pages per Jackmcbarn's comment above...
  • editusercss
    • allows editing *.css subpages of any user.
  • edituserjs
    • allows editing *.js subpages of any user.
    • Would be needed to work on things like User:Theopolisme/afch-rewrite.js for example (Theopolisme I expect will confirm that would be okay with him based on our discussions via email)
  • protect
    • allows locking a page to prevent edits and moves, and editing or moving locked pages. Is required to edit pages with cascading full protection.
  • suppressredirect
    • Allows moving a page without automatically creating a redirect.
    • As I explained above, this would be useful for moving JavaScripts that should never have a wiki #REDIRECTFooBar.js left behind but instead should be importScript('FooBar.js'); for a "redirect".
      • MediaWiki doesn't create redirects when moving JS pages anymore. See
        Helder.wiki 14:16, 3 July 2014 (UTC)[reply
        ]
  • tboverride
    • This is needed to be able to save things with certain "bad" words, and is already part of the templateeditor package.
  • templateeditor
    • There is no reason to not include this into a "Template editor II"/"Interface editor" usergroup This will eliminate the need for users to have "both" userrights since this one would not be obtainable or keepable without the other, it only makes sense to roll it in and have the user only have one (if we are going to propose something like this, we really need to make it as hat collector unfriendly as possible and make it clear that it is so or there will be too many opposes on the grounds that "it's just another hat").

People in this usergroup are most likely to be creating quite a few new pages, this is why I suggested that the autopatrolled group be included. There is no reason to leave all kinds of system message pages and other technical stuff that only the technically minded (the ones most likely to be in this group and very few admins) would be able to figure out and mark as patrolled all over the place.

The reason I'm suggesting rolling the reviewer, rollbacker, and template editor groups into this group is that it will reduce the number of groups the user is in most of the time, kill most of the hat appeal (especially if it is an RfX process as I suggested above), and allow the users in the group to have a more streamlined wgUserGroups array for testings userscripts and gadgets properly without having to have a dozen different accounts with various right groups. I'd venture to say that most of our current template editors, already have these other rights, or are certainly eligible for them anyways.

Finally, allowing these users to add/remove themselves to the importer and abusefilter groups. The reason I would find Importer useful, is these editors are likely to develop (at least in part) new gadgets and userscripts on testwiki: or one of the other similar "development" sites (there are a few others like beta). As such, it would just make it that much easier on these users to be able to allow them to just import their tested version from those other development projects to enwp when they are done, otherwise they have to request an admin to import it for them or copy and paste and loose the edit history (which I find distasteful and would make it more difficult for another technically minded editor to debug an issue that arose later on especially if the original creator has retired or died or something. As for the AbuseFilter group, less than 200 out of almost 1500 administrators have put themselves in this group, and of those, a fair number have been inactive for quite some time. The editors that would be in this proposed group, are the ones that can figure out regular expressions and understand variables and conditional testing. These are the users most likely to fix and make useful additions to our edit filters, and being able to add/remove themselves as a need arises seems logical to me. These two groups would not be rolled in to this user group, but accessible as needed.

Now, a couple replies to stuff in the Steel re section... Okay, for the granting and revoking sections:

Granting
  1. Yes
  2. Should make it a little more broad to include usercss/js page requests and requests made directly on an administrators talk page (for example this batch request of 36 MW: pages).
Revoking
  • Yes to all

I hope this helps clarify some things and we can decide how we want to proceed. :) — {{U|Technical 13}} (e • t • c) 02:03, 29 June 2014 (UTC)[reply]

I'm having a trouble @T13, I think this user right must be given out only by a community discussion something similar to RfA. This is needed because this right will have most of the admin tools. And community must trust the user, since they are going to make changes on stuffs which are used by 1000's of users and any wrong change will effect everyone. This right is not similar to other primary rights like requesting rollback or Template editor. So, request should be made on the same we do when requesting for adminship. Opinions??
talk) 07:35, 29 June 2014 (UTC)[reply
]
  • I entirely agree that this should be given out as the result of an RfX style process. I tried to make that clear above.

Giving a user the editinterface right allows them to impersonate anyone by editing MediaWiki:Common.js, while by being granted edituserjs they can do so by editing their /common.js or /skin.js (which can be much more stealthy). So we might as well be handing out full sysop rights instead of this Template Editor 2: Electric Boogaloo. — Keφr 09:42, 29 June 2014 (UTC)[reply]

  1. editinterface
  2. edituserjs
  3. editusercss
From what I am understanding above, these three permissions would allow only the functions that I desired this right to have when I initiated this question/proposal on Technical 13's talk page. All of the other permissions that have been proposed at some point would unbundle tools that should be exclusive to administrators, and since there is currently technically no way to unbundle them without allowing the editor to have some of the permissions that should be exclusive to administrators (Example: allowing the editor to edit cascade-protected pages would require the protect and/or editprotected rights), they should not be included as part of this proposal. I should be "adjusting" my above proposal shortly. Steel1943 (talk) 14:51, 29 June 2014 (UTC)[reply]
  • Steel, I can all but guarantee a proposal to grant just those three rights in a new group will be shot down as a result of anti-hat collection people. It would be much better to propose to simply add those three rights to the existing  Template editor group. — {{U|Technical 13}} (e • t • c) 14:55, 29 June 2014 (UTC)[reply]
  • Technical 13, what you might find odd is that I would be opposed to adding the user rights onto the existing Template Editor group. You may find this odd or even understand this, but this new group of user rights I'm proposing for non-admin use ... I don't even want them. I don't trust myself to edit any of the MediaWiki pages, or to edit other users .css or .js pages. I feel that, at least for me, it should be a separate right that I can prove to the community (or just one administrator) that I have a purpose to have based on a set of criteria ... that I obviously cannot meet right now, but an editor like you definitely (or other MediaWiki regulars that have been part of this discussion) could. However, with what you said, this proposal could be "split up", so to speak:
  1. The first proposal could ask the community if the three user rights proposed above could be handed to non-administrators in trusted situations
  2. If the previous proposal passes, the second proposal would ask the community if these user right should be set up in a new user group (Template Editor II, MediaWiki Editor, etc.) or added into the currently-existing Template Editor group.
I get how acquiring community and administrator approval to allow these user rights may be a difficult task, but I, for one, can see the usefulness of a non-administrator having the access to these three user rights, given that there are several editors who have substantial beneficial knowledge that can assist with editing these pages that some administrators do not. Steel1943 (talk) 15:15, 29 June 2014 (UTC)[reply]
There's a lot of interface pages that use templates to do all of their work (like MediaWiki:Protectedpagetext). Without being able to edit full-protected (and cascade-protected) pages, your ability to edit the interface is really limited. Jackmcbarn (talk) 15:57, 30 June 2014 (UTC)[reply]
At this point, the only way I would support an option to allow this new "user group" to include editing any type of protected pages is if ... the user right to able to edit fully protected and cascade protected pages can be separated in some fashion. An idea that I have would be to separate the user rights that allow editing fully-protected pages and cascade-protected pages. That option my be possible by someone creating a Bugzilla bug to separate the two functions. Of course, both of those functions would then, by default, be part of the administrator user group, and whatever other groups have permission to edit both fully-protected and cascade-protected pages. If this is possible, that would be amazing ... considering that I will never support this new user group being allowed to edit fully-protected pages. Steel1943 (talk) 20:21, 30 June 2014 (UTC)[reply]
  • Steel, T56081 basically proposes this. Comments from more people requesting this would certainly grease the wheel by becoming more and more squeeky... — {{U|Technical 13}} (e • t • c) 20:54, 30 June 2014 (UTC)[reply]
  • Ah-ha! Thanks for clarifying that! I wasn't sure what that bug was for. I'll start commenting on it soon. Steel1943 (talk) 21:00, 30 June 2014 (UTC)[reply]
Even if we had that option, what namespaces would we set it on? Jackmcbarn (talk) 21:03, 30 June 2014 (UTC)[reply]
  • Template, Module, MediaWiki, and User perhaps (technical spaces that would be affected by TEs)? That is certainly something I'd enjoy discussing more. — {{U|Technical 13}} (e • t • c) 21:16, 30 June 2014 (UTC)[reply]
Setting them on Template and Module would make just about all cascading protection worthless everywhere. Jackmcbarn (talk) 21:19, 30 June 2014 (UTC)[reply]
  • They would still be cascade protected and non-editable for everyone that currently can't edit them except the 187  Template editors. — {{U|Technical 13}} (e • t • c) 21:24, 30 June 2014 (UTC)[reply]
If that were what would happen, that would be fine, but that's not what would happen. Jackmcbarn (talk) 21:25, 30 June 2014 (UTC)[reply]
  • That is all the ticket on Bugzilla asks for. Offer a way to exempt TEs to cascade protection in select namespaces. — {{U|Technical 13}} (e • t • c) 21:27, 30 June 2014 (UTC)[reply]
Once again, thanks for clarifying. What you have stated would be a disaster, if allowed by default (allowing TEs to edit cascade-protected pages in certain namespaces.) I don't want permission to edit cascade-protected pages, and I'm a TE. I may sound like a broken record with this next statement, but here goes; the only way I can see this working is to unbundle the user rights that allow editing on fully-protected pages and cascade-protected pages into two separate user rights: one that allows editing a fully protected page, and one that allows editing a cascade-protected page. My best analogy that I can think about to illustrate is to compare levels of protection on pages to blood types: cascading-protection, in this example, would be the Rh antigen (+ or -, equivalent to a "yes/no") and all other levels of protection being the ABO antigen. So, with my analogy, AB would represent "full or permanent protection", and + will represent "has cascading protection". (I lost my entire example after trying to assemble the following table.) Anyways, here would be the examples of when an editor could edit a page if the user rights to edit fully protected pages and cascade protected pages were separated:
When CAN an editor edit the page?
Editor has no protected page editing privilegesEditor can edit fully protected pagesEditor can edit cascading-protected pagesEditor can edit both fully protected and cascading-protected pages
Page has no edit protectionYESYESYESYES
Page has full protectionnoYESnoYES
Page has cascading protectionnonoYESYES
Page has both full protection and cascading protectionnononoYES
The purpose behind this idea is to separate the protection that protects pages that would "break Wikipedia" if changed incorrectly (cascading-protection) from the pages that are protected to prevent recent or long-standing content disputes, vandalism, or a recent secluded edit that caused a lot of issues on the site (full protection). To allow this new, possible user group the ability to edit cascading pages and NOT fully protected pages would satisfy its proposed purpose: to allow editors to assist with the "technical gears" behind how Wikipedia works ... technically. Steel1943 (talk) 22:40, 30 June 2014 (UTC)[reply]
Now I see the core of the issue. There are no pages that would fall under "Page has cascading protection", and never will be. All of them that you think fall under that category actually fall under "Page has both full protection and cascading protection". This is because cascading protection isn't its own form of protection. Rather, it's a form of regular protection. There are five different edit protection levels a page can have on Wikipedia:
  • No protection
  • Semi protection
  • Template protection
  • Full protection
  • Full protection that cascades
Does this make sense? Jackmcbarn (talk) 23:11, 30 June 2014 (UTC)[reply]
@
WP:CASC, which itself has cascading-protection, ironically. However, I would believe that the Wikimedia software is programmed in the way you have stated; that's why if that is the case, if the user right that allows editing fully protected pages and cascade-protected pages can somehow be split, all of my personal concerns would be resolved. Steel1943 (talk) 23:29, 30 June 2014 (UTC)[reply
]
Since cascading protection is full protection, File:Padlock-red.svg has full protection (since it inherits cascading protection) even though full protection isn't set in its individual settings. Jackmcbarn (talk) 23:56, 30 June 2014 (UTC)[reply]
Also, keep in mind the difference between pages that are the root of cascading protection, and pages that inherit it. When a page is being protected, a checkbox "Protect pages included in this page (cascading protection)" is available that allows it to be set as a cascading root. You can see a list of all of the cascading-protection roots on Wikipedia at [1]. And it's not "ironic" that
WP:CASC is cascade-protected; if it weren't, then transcluding pages from it would have no effect at all. Jackmcbarn (talk) 00:02, 1 July 2014 (UTC)[reply
]
(edit conflict) @Jackmcbarn: I understand that, but that still brings back to my point; since this page has two separate "protection tags" (one for move protection, and one for cascading protection), there must be a way to split the user right that governs the cascading protection from full protection and the rest of the protections (move protection, template protection, etc.) Steel1943 (talk) 00:08, 1 July 2014 (UTC)[reply]
You can't split cascading protection rights from full protection rights because cascading protection is full protection. All cascading-protection means is "full-protect this page, and full-protect all of the pages that this page directly or indirectly uses". Jackmcbarn (talk) 00:10, 1 July 2014 (UTC)[reply]
Also, the reason that the protect right is always needed to edit cascading-protected pages is that if you add a transclusion to any cascade-protected page, whatever page you transcluded instantly becomes protected as well. Jackmcbarn (talk) 00:12, 1 July 2014 (UTC)[reply]
(edit conflict) I understand the "text" may say that, but that doesn't necessarily mean that is technically correct. Here are a few more examples if why I think there can be a way to differentiate the fully-protected pages from the cascade-protected pages:
  1. When attempting to edit a cascade-protected page with no other protection, the editor is presented an editnotice letting them know that they cannot edit the page when they go to the edit screen via the "Edit" tab at the top of the page. On a fully-protected page, the "Edit" tab is replaced with a "View Source" tab, and the editnotice that appears at the top of the screen is worded differently.
  2. On my previous example of Template:Notice, when the page had template protection and cascading protection, after I clicked the "Edit" tab, I could not edit the page, and the background to the syntax was white. On most examples of when a template editor edits a page with template protection, the background of the syntax is pink/red.
There are aspects of the software that can differentiate the cascading protection from other protections in several ways. So, since there are some real-life examples of how the software differentiates these protections, how do we get started on creating a bug to apply the fact that differentiating aspects exist, and apply that to when an editor can/cannot edit a page with cascading protection? Steel1943 (talk) 00:22, 1 July 2014 (UTC)[reply]
Pages that are "only" cascade-protected have an "edit" tab at first simply because it takes a (relatively) long time to check whether a page inherits cascading protection, so the software doesn't do that unless you're actually trying to edit it. (It also skips a lot of other checks like titleblacklist there.) For your second point, what you saw is exactly what would happen for any other fully protected page, so I'm not sure what you're trying to say. Jackmcbarn (talk) 00:28, 1 July 2014 (UTC)[reply]
@Jackmcbarn: I just had an epiphany while I was thinking these past few minutes ... a question/understanding that would basically end this entire conversation for me, at this point. Earlier, you were talking about protection levels. Let's say a page is tagged with both semi-protection and has cascade protection. Let's say the first 4 levels you mentioned are option 1, and cascading protection (level 5) is option 2. If "option 2" is activated (cascading-protection), does that make the software completely override what is chosen in "option 1", with the exceptions of the cosmetic things (seeing the small lock pics on the screen, tab name changes, etc) and whatever "drop-down" choices are selected that anyone with the protect user right can see/select (ex. Administrators)? Steel1943 (talk) 01:09, 1 July 2014 (UTC)[reply]
I'm not sure whether you mean "root" cascading protection or inherited cascading protection, so here's the answer for both cases. It's impossible for a page to have root cascading protection and semi-protection at the same time (i.e., you can't check the cascading box and pick semi on the protection screen). It is possible for a page to have inherited cascading protection (which is what happens when you transclude it at
WP:CASC, Main Page, or any other cascading-protected page) and semi-protection at the same time, though. In this case, the cascading protection does indeed "win" as far as required permissions are concerned. Jackmcbarn (talk) 01:15, 1 July 2014 (UTC)[reply
]
Clarification: Neither restriction actually "wins". You need the permissions to edit through both restrictions in order to edit the page. This is a moot point here, though, since our protection levels are strictly hierarchical. Jackmcbarn (talk) 01:21, 1 July 2014 (UTC)[reply]
...And we're back to the point I made earlier; "both restrictions" makes me think there is some way to unbundle the user right to edit cascading protected pages from the user rights that allow editing pages with other protections. Oh well, I'm confused, and I don't think it's going to get better for a while. At this point, I think that this proposal should stick with just the three user rights that I suggested, and then at a later time, if the page protection editing user right issue gets resolved, and this proposal passes, we can have another RFC to add it to this user group later. Steel1943 (talk) 01:34, 1 July 2014 (UTC)[reply]
There are two rights required to edit a cascading-protected page. The first one is the right required to edit whatever the root page is. This is currently editprotected (i.e. full protection) for all pages here. This could theoretically be worked around, although it would require a lot of work and complexity. The second one is the "protect" right. This one is set in stone and can't be changed. Jackmcbarn (talk) 01:40, 1 July 2014 (UTC)[reply]
The key to understanding "both restrictions" is that it means two separate checks, not two separate sets of rights. Jackmcbarn (talk) 01:41, 1 July 2014 (UTC)[reply]

Will a screenshot help clear it up? — {{U|Technical 13}} (e • t • c) 01:42, 1 July 2014 (UTC)[reply]

I can't support this being implemented. For those who really have the need, there is m:Global interface editor anyway, because the people who have this are usually the only ones needing to make adjustments to the interface because they are doing it across many wikis.. I also don't see a need demonstrated here; quite frankly, this just seems like hats hats hats. There's enough admins around who have the needed technical expertise - it's not like the template namespace where there is such a large code base to maintain. --Rschen7754 08:28, 1 July 2014 (UTC)[reply]

@Rschen7754: After I learned about the existence of the global Interface Editor user group recently (in fact, during this discussion), I started thinking along the same lines. Besides your concerns, I now feel as though in order to accomplish the original goal of my proposal would require a LOT of changes with the background functions of Wikimedia in general, such as finding a way to unbundle cascading-protection from the other protections. Also, the global user right, from my understanding, exists so that the editor who is presented that right can make the adjustments to every Wikimedia site after a change is agreed to via consensus, probably on the main Wikimedia site someplace. At this point, I don't even believe I can support my own proposal. Steel1943 (talk) 13:13, 1 July 2014 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Requests_for_comment/MediaWiki_editor&oldid=1137448959"