Requests for Comment/Global user rights

Global rights of Stewards and Sysadmins
I'm concerned that it appears Stewards and Sysadmins have the technical ability to evade/override local wiki restrictions. A couple examples of this include the global ability to view private abuse filters, edit the user interface, edit abuse filters, and perform basic sysop tasks without the sysop right.

Abuse filters are marked as private for a reason - which is that no one except local sysops/crats is supposed to be able to see them. Editing filters should never be done globally, as this would be interfearing with operations, period. Being able to edit the user interface isn't really appropriate either, as this should be left to the bureaucrats/founders of the local wiki.

In the event of cross-wiki vandalism, Stewards have the 'userrights' permission, which means that they can assign any local userright that they need temporarily in order to clean up the mess someone may have left behind. It's not really technically necessary to have this permission in addition to uneditable global group permissions that override (or at appear to be capable of overriding) local permissions and restrictions.

Proposal 1
The current global user groups will be left as is, with no changes whatsoever being made to them.

Comments
Per the reason for opening this RFC in the first place. Amanda (talk) 19:30, 29 December 2016 (UTC)

I think that the currently plan is a good idea as sysadmins can easily help users that request it with the rights. Sysadmins/Stewards will never intervene on local wikis except in the case of: cross-wiki vandalism, DMCA issues or if a user requests help from a sysadmin. Reception123 (talk) ( contribs  ) 14:04, 30 December 2016 (UTC)

(I want you to read the comment, so no templates are put.) We haven't used our permission from day 1 to view your wiki's contents unless you explicit consent for it, and we won't in the future. The permissions are there because it is ESSENTIAL to ensure the smooth operation of the service. If people want unlimited power for their wikis, I'm really afraid that I have to ask them to use their own resources. (Yes, this might be harsh.) PS: "Editing filters should never be done globally" -> during the time Orain was online, some global filters were active to prevent spams where everybody is not taking care of their wikis. &mdash; revi  17:36, 30 December 2016 (UTC) (Do not edit my comment in any way unless my explicit written permission is given. Period. Thank you. &mdash;  revi  10:07, 31 December 2016 (UTC))

Proposal 2
A new custom Miraheze extension will be developed, that allows global user groups to be edited locally on individual projects by non-Stewards, but yet does not destroy the entire global group elsewhere (I know this is complicated and likely won't happen for a while even if it were to pass).

Comments
I personally would not chose this route, mainly because of the complications and the time-consumming efforts. However, it would be one possible way to resolve the issue. Amanda (talk) 19:30, 29 December 2016 (UTC)

MT7 (talk) 04:30, 30 December 2016 (UTC)

There is already something in place. [\can't provide link to Phabricator as it's down]. Reception123 (talk) ( contribs  ) 14:04, 30 December 2016 (UTC)

Proposal 3
The global groups of Stewards and Sysadmins will be edited to remove any permissions that could be used on a local wiki that typically would require sysop, bureaucrat, or other elevated rights. This includes but is not limited to the rights listed in the introduction of this RFC.

Comments
I would be in favor of this, since Stewards have the ability to assign all local rights to themselves anyway. Amanda (talk) 19:30, 29 December 2016 (UTC)

Not for sysadmin. It may be redudant userright. MT7 (talk) 04:28, 30 December 2016 (UTC)

Per my comments above. As labster said in the initial Phabricator task, this could cause legal liability for Miraheze. Reception123 (talk) ( contribs  ) 14:04, 30 December 2016 (UTC)
 * Scratch that - this is now defined more clearly in proposal 6 below. These comments/votes are now invalid and should not be considered when closing this RFC. Amanda (talk) 03:28, 31 December 2016 (UTC)

Proposal 4
Both proposals 2 and 3 above will be implemented.

Comments
I personally think that this is a little too much. Amanda (talk) 19:43, 29 December 2016 (UTC)

Proposal 5
Proposal 1 will be implemented, but local communities will be allowed to create their own policies regarding the use of global user rights. These local policies would override global policies just on that one wiki, and Stewards and Sysadmins would be expected to act within the line of that local policy, even if it contradicts global ones. The exceptions would be legal issues or serious cross-wiki vandalism that has no other way to be cleaned up.

Comments
Wouldn't mind seeing this, but would prefer to see one of the other more straightforward proposals. Amanda (talk) 19:47, 29 December 2016 (UTC)
 * This is probably the most basic and feasible of the proposals involving change, so while it is not exactly completely straightforward, I'm going to support this one the strongest. Amanda (talk) 00:10, 30 December 2016 (UTC)
 * My current understanding of global permissions is that they are only used in two cases:
 * 1. There is consensus for the action on the local wiki,
 * 2. There is a technical/legal reason that supersedes any local policies (such as ToS 9).
 * No more, no less. Also, global policies are there to prevent abuse of the services at a local level, the abuse of which may result in termination of services under the new ToS. I don't think giving individuals the option to ignore these policies as they see fit is wise. Finally, the RfC we closed not to long ago decided the global scope of Stewards. This RfC would void that part of the RfC, and I sincerely doubt consensus has changed on in such a short period of time. -- Void  Whispers 04:57, 30 December 2016 (UTC)
 * I like this, so steward can't abuse on local wiki. MT7 (talk) 05:47, 30 December 2016 (UTC)
 * If the global policy is in the ToS or the Privacy policy no policy can override that. Reception123 (talk) ( contribs  ) 14:04, 30 December 2016 (UTC)

Proposal 6
Proposal 1 will be implemented, with some exceptions. Certain global rights that could almost never be used to "help" users will be removed from the global group. These rights are as follows (for both stewards and sysadmins):


 * The ability to view private abuse filters and view private abuse log entries. Private filters are supposed to be just that - private - visible to no one except people authorized by the local community.


 * The ability to unblock themselves. Stewards and sysadmins who contribute to a local project should be required to abide by local policy, and should not have the technical ability to evade sanctions should they fail to do so.


 * The ability to read, edit, move, etc globally. Per the same reason as unblockself, stewards and sysadmins should not be able to override local sanctions should they fail to comply with local policies.


 * The ability to disable global blocks locally. Stewards make global blocks to begin with, so they should not be able to decide which wikis (except Meta) they are not live on. This should be left to the local authorities.


 * The ability to nuke pages. This simply would not be helping anyone in any case.

Comments
I personally think that this is a fair compromise. Amanda (talk) 02:01, 31 December 2016 (UTC)
 * Okay so if a Steward is trying to enforce a global policy and local staff blocks them, what do we do? Just let the user ignore us? We barely use these rights, but there's occasionally a need for them. Not having them causes more issues than having them. -- Cheers, NDKilla ( Talk • Contribs ) 04:58, 31 December 2016 (UTC)
 * Unless a local wiki is blatantly violating Terms of Service, Privacy Policy, and/or Content Policy, there is nothing to enforce. Many local communities will have their own privacy and content polices anyway, so the biggest thing is Terms of Service. Unless this global policy is being obviously violated, stewards and sysadmins should be treated as regular users, and be subject to follow all local polices. Amanda (talk) 13:05, 31 December 2016 (UTC)
 * I also note that this only addresses bullets 2 and 3 of the initial proposal description. Amanda (talk) 13:07, 31 December 2016 (UTC)
 * In addition to what Borderman said below which I agree with, this also applies to nuke and abuse filters. If you make an abuse filter saying that technically prohibits stewards from performing action any local thing (if username == "NDKilla", disallow) should we not be able to delete or edit that filter just because you say it's 'private' for no reason? Many private filters have no private information or reason to be private other than the fact that being private means people who control spam bots can't see the filter which makes it harder to get around. Also Nuking probably isn't required but I believe I used it once on spiral.wiki (which we host) after there was a lot of spam there. Although we probably don't need to disable global blocks locally, it's related to global blocks thus we have it and really that one minor thing probably wont change, although it's the only thing I'd see changing at all. -- Cheers, NDKilla ( Talk • Contribs ) 20:41, 31 December 2016 (UTC)
 * I hear your point here, but I still disagree. As noted above, unless one of Miraheze's main global policies (TOS, Privacy, Content) is being violated, stewards/sysadmins should be treated as regular users. The only time technical actions outside of the local authorities should ever be taken is violations of global policy. Stewards and sysadmins that make standard contributions to local projects are not exempt from following and be disciplined for not following local rules, just because they have a global rule in the community (for example, this local policy is currently in effect on my wiki, and I'm sure other wiki founders have their own. Amanda (talk) 13:00, 1 January 2017 (UTC)
 * Stewards' scope of responsibility is part of a global policy even though it's not the ToS, Privacy, or Content policies. Have you noticed how there is no global sysop group? This is because of how rarely actual Stewards use sysop-like permissions. From the start I've wanted to just close this RfC because you appear to be rehashing the very recently closed policy on Stewards. Stewards aren't just Stewards or normal users, but they are both. Stewards can read and edit normal wikis as normal users. Stewards should not read the content on private wikis unless they have reason to believe something is happening there (such as looking at global accounts and seeing activity on private wikis). IMO Stewards rarely use these permissions so it shouldn't be a concern. They've been added as just part of the tool set and honestly I doubt you'll get as many users to comment successfully on any policy here as you would on the Steward policy. Since this RfC would directly affect that, you'd need the same number of users and ratio, and some of us have made our point clear elsewhere. Also system administrators probably won't have their global permissions changed because like it or not they will always keep the ability to edit their own global rights. It just makes things easier. System administrators have access to the technical back end and can do anything on the servers they deem technically nescesary and really have no obligation to explain their behavior. -- Cheers, NDKilla ( Talk • Contribs ) 17:17, 2 January 2017 (UTC)
 * I am doing my very best to be understanding, but I don't think anyone else (except for MT7) is understanding me. I totally get the fact that global groups are easier than manually assigning userrights when needed. However, what I don't think that others are getting is that my whole point here isn't to make life harder on staff members. My point is to prevent staff from saying "Oh, I'm in charge of Miraheze, so I don't have to follow local community policy and I can undo any sanctions local staff put on me for violating their polices". The above example is not acceptable for Stewards or sysadmins barring exceptional circumstances, and that's what I'm trying to avoid. Amanda (talk) 17:24, 2 January 2017 (UTC)

This whole page seems to be a reworking of previous similar RfC arguments. Whilst I believe Amanda makes some very interesting points above (and I do understand her point of view, mostly) I can't help but feel that there seems to be a desperate need to have all the control of a paid-for hosting service but without the costs that are usually incurred by having such freedoms with the MediaWiki software. Miraheze staff are not here to make a founder's life harder but it would appear that way if, at every turn, a founder is trying to change the way Miraheze is run in an attempt to get what the founder wants. It doesn't and shouldn't work that way otherwise Meta would be full of RfC's requesting all sorts of changes based on very specific and personal requirements. Every wiki in Miraheze must conform to global policies because these are in place to protect every founder, user and wiki that is encompassed by them. However, it should not be far from the realms of possibilities that policies and permissions could be open to change based on specific circumstances as Miraheze evolves over time. For the present though changing global rights and permissions to suit what an individual wants (based on the freedom of use expected with paid-for hosting) undermines what Miraheze is about. Blocking Miraheze staff seems somewhat counter productive. Both Void and NDkilla have made interesting points that pretty much make this RfC, at least for the time being anyway, untenable. Borderman  talk 16:12, 31 December 2016 (UTC)
 * Steward must read local policy. MT7 (talk) 17:44, 1 January 2017 (UTC)
 * Well, despite his lack of knowledge of English grammar, at least MT7 appears to be on my side. Amanda (talk) 20:16, 1 January 2017 (UTC)

Proposal 7
Proposal 1 will be implemented, but at the same time, a new custom MediaWiki feature for Miraheze will be added. This feature would allow local overrides to override global permissions. For example, if one of the global steward rights that is usually a sysop task is restricted to bureaucrats locally (via overrides in LocalWiki.php and/or LocalSettings.php), this override will prevent the steward from executing that action on that wiki. However, this would a per-wiki option, and not all wikis will have the same settings and some wikis could not even do this at all.

Comments
A lot of work, but it allows local freedom without destroying global configuration. Amanda (talk) 13:06, 1 January 2017 (UTC)