Requests for Comment/Global user rights

Status update January 4th, 2016: A Phabricator ticket has been filed here to review a MediaWiki extension that allows local management of user groups without destroying or otherwise interfearing with the global user groups. If it passes security review, this should solve the entire issue addressed in this RFC. Thank you for your consideration.

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Proposal 1 passes without any doubt. John (talk) 17:20, 6 January 2017 (UTC)

---

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

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

 Strong support 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. — 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. — revi 10:07, 31 December 2016 (UTC))

 Strong support I fail to see how this is an issue at all. Why are we wasting time with this? --Robkelk (talk) 14:34, 6 January 2017 (UTC)

@Robkelk: The issue is that stewards need to be subject to local wiki polices, and be subject to any sanctions for not following them. Stewards cannot say "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". That's the point of this RFC - to prevent the above from happening. --- DeltaQuad (talk contribs email), 14:59, 6 January 2017 (UTC)

 Strong support This is a non-issue that has been dragged out due to the results of the desires of one/two over an entire wiki farm. The fact that John is actively conceding on both Github and Phabricator and allowing one person to change Miraheze policy on the fly is an issue. LulzKiller (talk) 15:38, 6 January 2017 (UTC)

I am in no way conceding. In fact I am the only one who is keeping the spirit of Miraheze alive by ensuring the community driven aspect of the project is respected. There has been nothing that has been done that in any way that changes any policy on the fly. John (talk) 15:45, 6 January 2017 (UTC)

Explain these commits that DQ has been able to make that has sometimes affected global policy with absolutely 0 comment or rebute? I don't want to have to drag up the dictionary definition of conceding. LulzKiller (talk) 15:54, 6 January 2017 (UTC)

None affect global policy. All affect elementswiki only with exception to two. This follows good practice by not indefinitely blocking every IP that triggers a filter for ever which wasn't his idea - he just made the change. This corrects wording as stewards != staff and they aren't the ones that close wikis. Generic wording is best there anyway. John (talk) 16:00, 6 January 2017 (UTC)

With respect, John, the community has spoken, and are overwhelmingly against these changes and the users who wish to implement them. This matter has caused me grave concerns over the future of Miraheze the longer these parties are allowed to continue to cause conflict here, and unfortunately, the only one who has to make the call to end this turmoil is yourself, and I respectfully ask that you bow to community consensus that implores the relief as I have indicated. GethN7 (talk) 15:57, 6 January 2017 (UTC)

I am 100% against these changes suggested in this RfC. I am in no way in agreement with DQ. The parties at fault here is a continued disagreement between DQ and Labster and is the entire fuel of this fire. Attempts have been made to diffuse the situation though it always reignites because of Labster. John (talk) 16:00, 6 January 2017 (UTC)

I had elected to remain neutral in this dispute until I got here and saw the results for myself, and now I understand why Labster had a problem with this user, and now that I've personally witnessed the situation, I want it on record that if this continues, I will be entering into serious consultations with my colleagues about whether we wish to continue hosting ATT on Miraheze. I don't want to do that, up to this point, Miraheze has served us well, but this matter may force one of the parties involved to make a sacrifice, and I'd rather neither of us have to choose the most painful alternative to resolve this once and for all. GethN7 (talk) 16:06, 6 January 2017 (UTC)

Unfortunately there are only two forseeable solutions. ATTwiki respects the community-driven aspect of Miraheze or the person who made and gives up an extremely large portion of his time to Miraheze leaves. The former is easiest but if you all prefer a dictatorship, the latter can happen on the word. John (talk) 16:10, 6 January 2017 (UTC)

I see. Whatever anyone else who has any dealings with ATT wishes to do from this point on is up to them, I will merely try to support them however I can. As for Miraheze, I made my own personal position clear on this, my say is said. From this point on, whatever anyone at ATT wants in this matter, I will support, my personal opinions (save for any further support/oppose votes I render for my own personal reasons) aside. GethN7 (talk) 16:19, 6 January 2017 (UTC)

 Strong support - I see absolutely no reason to change our current policies. They have proven sensible and reasonable, and if it's not broke, why fix it? I also support LulzKiller's line of thought concerning this affair. GethN7 (talk) 15:44, 6 January 2017 (UTC)

 Strong support - Without choosing a side (yet) in the discussion between some other people and John, I can say I am in favor of proposal 1. Southparkfan (talk) 16:43, 6 January 2017 (UTC)

 Strong support - It ain't broke, don't fix it. -- Looney Toons (talk) 17:03, 6 January 2017 (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

 AbstainI 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)

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

 Comment: 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

 Support 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)

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

 Oppose 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 6 will be implemented.

Comments

 Oppose 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

 AbstainWouldn't mind seeing this, but would prefer to see one of the other more straightforward proposals. Amanda (talk) 19:47, 29 December 2016 (UTC)

 Strong support 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)

 Strong support I like this, so steward can't abuse on local wiki. MT7 (talk) 05:47, 30 December 2016 (UTC)

 Comment: 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

 Support 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 @NDKilla:, 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)

@Amanda: 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)

@NDKilla: 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)

(Reset indent) @DeltaQuad: I totally agree with you in that regard, it's unacceptable. The problem is that staff members don't really do this, and placing any technical restrictions on global groups doesn't help. If someone abuses the Steward toolset, they should not be a steward, so fix that. Don't try to fix one user by placing technical restrictions on a community role. You say you're not trying to make things harder for stewards or sysadmins but you're making it harder for both. If we remove many basic administrative permissions from the steward toolset, then they can't do their jobs (when needed) unless a sysadmin changes it, in which case a sysadmin (technical, not community role) has to decide if it's appropriate and acceptable to change the permissions. Personally (not even as someone with the rights) I say leave the toolset alone and just be sure the people with access are trusted. -- Cheers, NDKilla ^{( Talk • Contribs )} 17:30, 6 January 2017 (UTC)  Comment: 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 | contribs | email} 16:12, 31 December 2016 (UTC)

•  Support 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

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

 Abstain i like if bureaucrat have a steward right but only in local and can't block, lock and rename global. How do you think? So we can't connect with main wiki(meta). And I like if cu and Os have on local wiki with vote from people. H1 (talk) 07:15, 6 January 2017 (UTC)

Its already possiblsnto get CU and OS locally but you have to show a need for the rights and show that the wiki in question, with a sufficient community, trusts you not to abuse the rights. -- Cheers, NDKilla ^{( Talk • Contribs )} 17:33, 6 January 2017 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.