Talk:Limits to configuration changes

Technocracy

Shouldn't this be at Technocracy? Who is to say "community consensus" means decisions by people who aren't sysadmins? There is a developer community too, and usually no one on-wiki bothers to ask them what they think, despite the fact that they have to do the work of implementing technical changes. Steven Walling (talk) 23:50, 15 September 2011 (UTC)

I don't think many people would interpret "community consensus" as anything but the most obvious sense of the phrase, but I don't have any objection to this page being moved to a better title.

These cases are specifically cases where there wasn't any real technical challenge that was unresolved. These requests could have been implemented with current technology, they simply weren't due community consensus (of the local projects) being ignored by system administrators.

System administrators and developers should weigh in on discussions like everyone else. And in some cases, it makes sense for individuals to place a higher value on their comments and votes. But I don't think many people would advocate a system that these (rare) cases demonstrate. I don't think many people favor a technocracy. --MZMcBride 02:56, 17 September 2011 (UTC)

Many people probably don't think much about what role "non-editing" groups should play in decisions, and are a bit shocked when they find out otherwise. Most members of the active editing community would expect that WMF, the devs, etc. will a) get involved in early discussions and b) implement the community decisions. The devs and WMF hear about these proposals via the same mechanisms as everyone else. The proposal at bugzilla:30208 has been raised almost every month at irc office hours; before, during and after. It has also been proposed on the strategy wiki, and discussed in March and May. The WMF have been invited to become involved in the formation of the proposal and consensus processes. Technical problems and resourcing issues are problems which should send proposals back to the drawing board. However that is not the case in the items listed on this page. These are political/ideology decisions being made by devs and WMF. Personally I think devs need a veto against the community consensus, but it should be limited to non-technical reasons, and the WMF should have a veto which is broad, but limited in a few ways to prevent them stonewalling the community entirely/indefinitely (e.g. the veto might be time limited to three months). John Vandenberg 04:43, 17 September 2011 (UTC)

Non-editing groups should realize that they are eminently replaceable and act accordingly. The technical talent we have is not special, after reading several interviews I can only assume that most of the foundation staff knows far less about Wikipedia than average user; it is the community of volunteers that is really our only valuble asset and should be heeded accordingly. The foundation was created because part time volunteers can't deal with legal issues or maintain servers very well, not to think for themselves. Extransit 02:46, 27 September 2011 (UTC)

You can assume lots of things. That doesn't make them true. ^demon 14:08, 27 September 2011 (UTC)

I think someone needs to check hisself before he wrecks hisself.--Jorm (WMF) 18:52, 27 September 2011 (UTC)

Are you being serious? Werdna 08:22, 27 September 2011 (UTC)

Global community

The title is quite POV or the content is not suitable for it: all the currently (three) listed requests were not only very controversial (which means consensus might be difficult to understand), but also affecting aspects shared by all the Wikimedia projects, which would require a broader consensus. Global community consensus (or lack of it) shouldn't be ignored. --Nemo 00:46, 16 September 2011 (UTC)

The title isn't great. It's a wiki and there's a move tab. :-) The community consensus in these cases was fairly clear. It usually is, particularly when it's quantifiable. I don't see how raising the autoconfirmed threshold on the English Wikipedia requires a "broader consensus." Among whom? Wiki projects are largely sovereign on issues like this. You really think the people at Swahili Wikinews need to have input as to whether it's 4 days or 7 days to edit certain pages on the English Wikipedia? I don't understand this. --MZMcBride 02:56, 17 September 2011 (UTC)

Regarding the title, this topic might fit within the movement roles work.

The only reason these are controversial is because they are community consensus on English Wikipedia, and the WMF has a large stake in anything to do with English Wikipedia. Other wikis dont have this problem. e.g. Arabic Wikipedia and several others have 50 edits for autoconfirmed. Farsi Wikipedia can easily have configuration changes for trial periods (see bugzilla:27195). WMF is really only impacted if the public and press don't like a change to the configuration of English Wikipedia. The flip-side is that Jimmy/WMF can force change without community consensus like they did during the w:Wikipedia biography controversy, and it was a lot of work to turn off Pending Changes after the trial. John Vandenberg 05:04, 17 September 2011 (UTC)

Yes, as I said on bugzilla I think that there are limits to what local consensus can change, because Wikipedia (as the other Wikimedia projects) is still a unified project, with language editions and local differences which can be important but will have some limit. There are some changes that would change how Wikipedia can be defined and described, especially if they're applied to the English Wikipedia (because all kinds of media often copy English ones, to start with), and can't be decided by the local community alone.

Some "technical" configurations are in fact implicit global policies, even if they're not written in a recognized Meta page or WMF board resolution and they have some flexibility. Everyone seems to agree that no Wikimedia project is allowed to restrict anonymous users from editing, for instance. Restricting createpage right to autoconfirmed is less clear an issue, but it makes sense to imagine that it falls in this category. With regard to the other examples: yes, I think that restricting page creation to registered users in a panic has been an error and that those limits for autoconfirmed status are absurd and should have been discussed more; but this proves only that the WMF can be wrong and that it cares less about small wikis and their errors (what a surprise!), not that we're all bound to make more and more bigger errors.

Finally, based on this comment I propose Limits to configuration changes as title for now; everyone is free to move again, naturally. --Nemo 12:56, 17 September 2011 (UTC)

I like the new title. Is there a Wikipedia page like oldwikisource:WS:COORD, which is a table of differences between the language subdomains of Wikisource? John Vandenberg 13:27, 17 September 2011 (UTC)

I don't think so, but it would certainly be interesting. --MZMcBride 14:31, 17 September 2011 (UTC)

We have some such pages in Category:Wikimedia projects coordination, we certainly need more. Nemo 09:30, 3 October 2011 (UTC)

Nemo: I think the new title is better. Not perfect, but better. Thanks. :-)

Regarding when it's okay to say no, I can certainly agree that there are defining principles that can't be ignored when implementing configuration changes. First and foremost, the code has to be secure, scalable, and sane. Beyond that, it has to fit in to Wikimedia's core values. Proposals to allow inline images from anywhere on the web would be problematic. A proposal to lock down the site from anonymous editors would be (and has been) problematic.

Sometimes developers/system administrators have a tendency to simply "hold out" on certain changes. For years, |link= wasn't allowed in image syntax because of largely imaginary copyright/attribution concerns. Eventually hacks were created using ImageMap and other tools and finally the syntax was implemented by Tim Starling. This isn't quite a configuration change, so it wouldn't be listed on this page, but it is a demonstration of a similar (if not the same) underlying problem, I think. --MZMcBride 14:31, 17 September 2011 (UTC)

Just noting

I'd like to list the following config changes that enwiki filed that have been done. 12190, 13498, 13890, 14075, 16552--that was just skimming Site Requests for comments that contained 'en.wikipedia.org', there's plenty more. That's also not counting the many dozens of feature requests that have originated from enwiki and been implemented. ^demon 14:04, 27 September 2011 (UTC)

w:Man bites dog (journalism) --MZMcBride 17:14, 7 October 2011 (UTC)

Added similar one from id.wp

http://meta.wikimedia.org/w/index.php?title=Limits_to_configuration_changes&diff=2963100&oldid=2937267 Bennylin 05:43, 5 October 2011 (UTC)

The community, God love it, is *frequently* on crack, and needs to be told "just no." David Gerard

If he'll spew crap like that, I'm going to be very blunt and tell David Gerard that he should stop doing PCP; the fact that we can produce evidence to back our position up and they can't should demonstrate that we actually know what we're doing and they don't but think they do. The Blade of the Northern Lights (話して下さい) 20:30, 6 October 2011 (UTC)

Disconnection from stewards overseeing

Meta used to be the only project where bureaucrats were allowed to remove sysop and bureaucrat rights, a quite obvious exception given the tight connection between the Meta community and stewards. Lately, for unknown reasons, some projects are being allowed to disconnect themselves from the stewards' (loose) overseeing of such deflags. There's no need to discuss here how useful such an overseeing is: but I think that, if projects are allowed to request so-called "super bureaucrats", there must be a global discussion to decide which projects can request it, we can't just proceed randomly or allow everyone to opt-out. (My personal opinion is that no project should be allowed to do so; even Meta could live without it.) What's the way to proceed, a RfC? Note that this question is prompted by the observation of a peak of such requests, the next one being fr.wiki in two weeks from now. Nemo 13:25, 23 February 2012 (UTC)

I agree, specially on the part that projects (included meta) could live without this and that no project should be allowed to do so. It breaks the beneficious external oversight and it even breaks more the central rights log, which for years used to be the place to look for rights removals at any project. —Marco Aurelio (Nihil Prius Fide) 16:58, 6 March 2012 (UTC)

Note: there's a list on Bureaucrat#Removing access. I've not verified its completeness and accuracy, but apparently several mistakes happened about such special permissions given to bureaucrats. Nemo 10:42, 12 March 2012 (UTC)

Cf. Bug 35258 – Allow bureaucrats to remove sysop rights on fr.wikipedia. Nemo 12:05, 16 March 2012 (UTC)

I agree as well, administrators shouldn't be locally removeable, especially on wikis with only one or two (active) crats. And of course, removing crat flag locally is an absolut "no-go"! a×p_de^Hello! 13:03, 16 March 2012 (UTC)

I disagree. A bit of an explanation : I'm a bureaucrat on fr.wp (so yes, kinda biaised), and we just concluded a RfC there which showed overwhelming support (82% is good, right ?) for this right (desysop) to be given to all bureaucrats. The rationale being that :

• It makes it unnecessarily difficult for sysop to request the removal of their rights (some don't speek inglishe, some don't want to go outside fr.wp for something they feel don't concern anyone outside fr.wp - example : fr:User:Aristote2, who asked the bureaucrats for the removal of his sysop rights)
• It doesn't prevent abuse, but makes it harder for the people concerned to complain (example : User:Hégésippe Cormier, who briefly lost his sysop rights due to the haste of user:Yann - a steward). Again, it makes it difficult for someone who's not good in English to complain - where, to who, how ?
• It makes it harder for the local community to see the user changes. What MarcoAurelio see as a disadvantage (breaking the central rights log), many if not all on fr.wp saw as an advantage : finally, we could see the removal of the sysop rights on the same log as the granting of such rights. We see block and unblock, protect and unprotect, delete and undelete on the same logs, right ? Why not addition and removal of the sysop rights, like for the botflag ? Many find that counterintuitive.
• It's more "paperwork" (and it's not so rare : with the removal of the rights for inactivity on fr.wp, the occasional temporary sysop, and the wikibreaks, that's about one or two a month).

Now, I'm not saying it should be given to any wiki, with no oversight by anybody and all, but there are 8 bureaucrats and nearly 200 sysops on fr.wp. Any "abuse" would be reported to meta within a day at most (within an hour, more probably). And any right with legal consequences (i.e., checkuser and oversight rights) remains under the control of the steward, and rightly so.

en.wp has been granted this technical possibility over 6 months ago : why block it for fr.wp while there is further discussion about it here ? If the discussion on meta concludes to the removal of this possibility for all wikis, so be it, but I find it unfair for fr.wp that our request to bugzilla should be blocked due to circumstantial distrust. Esprit Fugace (talk) 18:03, 16 March 2012 (UTC)

Your points are useful and well-known, but do not bring water to your conclusion. If there's some difficulty of interaction with stewards, this is the real problem, not who holds the rights; you don't seem to have considered any other option. Also, if even big wikis like fr.wiki have sysops who don't know about the stewards and so on, I can't imagine how confusing the system can be for small wikis: both categories would deserve an improvement, which doesn't come from raising walls.

The discussion on this page is only about the fact that some criteria are needed; yes, so far we've not had any clear rule, but very few wikis requested an exception, while currently this is becoming a problem. I'm not saying that en.wiki or fr.wiki shouldn't have this right, but this should be considered in perspective and globally. What you've said above would be best put in an RfC to discuss the matter: just add why other options are not considered viable and on what basis fr.wiki should be allowed an exception (with clear criteria), and you're done, making a good service to all other wikis. Stewards will love to know how to serve wikis better, I'm sure. Cheers, Nemo 18:34, 16 March 2012 (UTC)

Then why don't you try launching such a RfC ? You're the one who wants a change to what's been done 'till now... Esprit Fugace (talk) 18:42, 16 March 2012 (UTC)

I don't think so. The exceptions are exceptions. Had I to open an RfC, I'd just explain why there's no reason to remove flags locally and the RfC would start with the proposal of removing such a permission from all wikis. You know why you want this, I don't. If you start the RfC, we can focus it on what's the perceived need and how to achieve it. Nemo 20:36, 16 March 2012 (UTC)

If i remember it well, stewards were create to respond to the need of bureaucratic task for small wiki and then their roles were expanded. Removing rights was a bureaucratic task long time ago, isn't it ? I don't think that adding rights could be done by bureaucrat and now then couldn't remove it, and a majority of user think so on WP:FR. The only reason is to have a "power separation". It could be normal but that not the thinking of french community. The execption on WP:EN could also be done for WP:FR. Nobody ask to give the right to remove right for all bureaucrats on all communities the hindi case show that isn't a good idea. A counterpart to this request is to give to steward more time to respond to other communities, it's nbot bad ? So please simply accept this request. It would not be burried in the marble, if anything goes wrong a roollback could be done... --Gdgourou (talk) 23:49, 17 March 2012 (UTC)

You don't remember well. See Wikipedia power structure for some history. Nemo 22:27, 18 March 2012 (UTC)

Here is a list of open requests to make this change:

• bug 33879 ro.wp
• bug 35258 fr.wp

Just for the sake of tracking. At this point, someone with an opinion should probably make an RfC. ST47 (talk) 07:03, 18 March 2012 (UTC)

I believe that any project should be allowed to remove the admin flags locally. There is really no need to wait for a steward to do this. The reason this popped up is some abuse that took place on hi.wp, so you just jumped to the conclusion that this could happen anywhere, which is false. But even if some 'crat would decide to revoke all the sysops, this could easily be reverted by stewards. The real problem on hi.wiki seemed to be the deletion of many articles, but this is totally unrelated to the problem of sysop revocation, and if anything, an argument in favour of the break-up from stewards. Any sysop could decide to provoke chaos by running a robot which deletes pages, and having a local bureaucrat to revoke the sysop's rights would make it much easier to stop this.

I see this issue as an unneeded control that the Foundation has on the individual projects; from the moment a project had a bureaucrat appointed, the steward should become only a back-up method of appointing and revoking user rights.--Strainu (talk) 11:22, 18 March 2012 (UTC)

I find this all a bit perplexing; a rogue bureaucrat removing userrights wrongly is a very rare scenario, and the argument that stewards are available 24/7 to deal with userrights issues applies to that rare scenario too - so it's illogical to insist that stewards must handle desysopping. Handing out userrights is far more dangerous, and we allow that locally. So if a community (on a wiki large enough that "community" is a meangful term) wants local desysopping, let 'em have it. Anyway, the argument about stewards "overseeing" seems to imply a rather different relationship between stewards and large projects than we are familiar with. Rd232 (talk) 12:51, 20 March 2012 (UTC)

Desysop is not done locally to prevent the most severe wheel warring, it's very simple. Local deflag puts some sysops above others in conflicts about sysops, it's self-evident. And it's the same reason why sysop have unblockself right by default. Nemo 18:27, 22 March 2012 (UTC)

Desysop is not done locally to prevent the most severe wheel warring - that seems desperate, frankly. Wheelwars between bureaucrats over whether someone should be desysopped or not? Just doesn't seem likely. And aren't people always saying that stewards are available 24/7? Why doesn't that apply to removing bits from warring or rogue bureaucrats? Rd232 (talk) 18:03, 23 March 2012 (UTC)

Desperate, really? Where do you live? I've already seen it happening, and very recently. So you don't agree that the technical parity among sysops is one of the main characteristics of MediaWiki (defaults) and Wikimedia projects? Looks really weird, especially for you. Nemo 13:55, 24 March 2012 (UTC)

? Sysops are not bureaucrats. We're talking about giving bureaucrats the right to desysop (on projects that want it). And you didn't answer my question. Rd232 (talk) 21:00, 24 March 2012 (UTC)

Bureaucrats are usually also sysops. Super-bureaucrats become super-sysops because they have the technical ability to desysop the others and win any wheel-war. One doesn't need to actually use such a power to impose it. Your question isn't relevant: blatant abuse is not the point (that can be easily spotted and reverted), the point is the change in the "power structure", which might be harmless or even beneficial, but needs discussion and some criteria. Nemo 21:46, 24 March 2012 (UTC)

they have the technical ability to desysop the others and win any wheel-war - desysopping is a radical measure; a user desysopped without good cause will complain about it, and the bureaucrat may lose their bit. A bureaucrat must know that desysopping to end a wheel-war can only be a temporary measure, if the desysopping is not justified. needs discussion and some criteria - that's up to the local community, isn't it? The only caveat I would accept is that for wikis so small that "the community" is very small or non-existent, then a request to enable local desysopping might be denied. Rd232 (talk) 10:58, 25 March 2012 (UTC)

Per Nemo above, completly. That just happened recently, some months ago, in my (former) homewiki. Emergency desysop had to be requested as blocks to other admins and users started going on. Better that I don't guess what would have happened if the ability to desysop were given to those people, given that administrators there are given bureaucrat access too by default; and that threats to desysop were made. —Marco Aurelio (Nihil Prius Fide) 17:29, 24 March 2012 (UTC)

"Better that I don't guess what would have happened if the ability to desysop were given to those people" - then some people might have been desysopped. Boo hoo (it's eminently fixable). But anyway, the right to desysop is not to be given to bureaucrats on every project; it's to be given to bureaucrats on projects that have community consensus for it. Rd232 (talk) 21:00, 24 March 2012 (UTC)

Doesn't change the point. The point is that there's a reason not to deflag locally, although one can disagree, and that it's not a characteristic which can be dropped without some criteria. Nemo 21:46, 24 March 2012 (UTC)

Date column

I think it would be useful to add a date column, for when the initial request was made based on apparent project consensus. For configuration changes which were rejected on many wikis, the date of the first would be the most useful, but hopefully additional dates for the other projects can be added without breaking the sortability of the table. John Vandenberg (talk) 06:29, 24 August 2014 (UTC)

Rewrite of this page

Hello, I've drafted an update at Limits to configuration changes/Update 2019, to make this more informing. Currently, this page is not maintained by system administrators on regular basis, and it has a list of requests that were declined, but the selection is not made using any specific criteria.

My new page tries to document type of requests that will be declined, or are likely to be declined, or are impossible to do rather, which means some of the requests listed now aren't included in my new page. Mostly, it's because a) I don't deem them to be relevant b) are included in another type of request.

I'd appreciate your comments on this. Thank you, --Martin Urbanec (talk) 23:57, 29 August 2019 (UTC)

No comments yet, but I've started to "copy edit" and further wikify the page. Please check that I have not changed the meaning (in a negative way) anywhere. - dcljr (talk) 00:27, 30 August 2019 (UTC)

Thanks, it's an early draft, so it probably needs this to be done. Will have a look later! --Martin Urbanec (talk) 00:38, 30 August 2019 (UTC)

@Dcljr: Quickly looked earlier today (the thanks were used to indicate "LGTM at first glance"), did a full review now. Your changes seem okay to me (mostly), thank you for doing them. However, there are few things I would like to discuss.

• Adding links doesn't seem to change the meaning, IMO.
• Ad »I assume this should actually say "Wikimedia"«) I actually meant MediaWiki, not Wikimedia, but I understand why you raised you that up, thank you. While it is also a non-negotiable principle of Wikimedia (=the movement), it is also a non-negotionable principle of MediaWiki (=the software), since MediaWiki developer community wouldn't agree to make it significantly less transparent in some way. Not sure what is the best here, this is here merely to explain what I intended.

Feel free to reply in-text and/or copy my signature into my message, if you find it useful --Martin Urbanec (talk) 18:48, 30 August 2019 (UTC)

There is a fine line between documenting what happened and writing in a prescriptive way. I think the proposed text mixes the two things too much. Nemo 10:57, 30 August 2019 (UTC)

Could you elaborate? My intention is to not document "what happened", but "predict what would happen/should happen/will happen". The former is mostly useless, that is already in Phabricator, filterable easily by task status, and it doesn't make much sense to have a list of tags in Phabricator, while [1] generates that automatically. My point is that Phabricator is place for documenting what happened, and why, not Meta. Meta is place for documenting community-facing stuff, such as reasons to decline task, in general, rather than when speaking of a particular request. --Martin Urbanec (talk) 16:38, 30 August 2019 (UTC)

A by default skin change was refused, and it doesn't appear in your update. I think it is an important point, as any small project may want to ask for the same option to make their project more visible and distinct. Please consider a more detail sentence about this point. Noé (talk) 12:13, 30 August 2019 (UTC)

Thank you, Noé. To be honest, I was thinking about falling this under "Installing extensions/skins that aren't installed at at least one Wikimedia project". Granted, this might not be so obvious. Also, it also may not fall into it at all, since phab:T217883 might be created after Timeless was deployed, at which point, it would make sense to list it separately. I'll do that soon, please let me know what do you think once I do so. --Martin Urbanec (talk) 18:35, 30 August 2019 (UTC)

@Nemo bis: This is exactly what I meant above. This page, in its current state, is not clear enough even to one of the few of system administrators who is active at site requests (me), and as such, I should know much of the content anyway. Given I seem to fail to interpret the content (which is really not-that-clear to me), rewrite is likely necessary. Might choose the wrong approeach or wording, through. As said above, I'd appreciate your comments. --Martin Urbanec (talk) 18:35, 30 August 2019 (UTC)

@Noé: Done. Let me know. --Martin Urbanec (talk) 18:38, 30 August 2019 (UTC)

@Martin Urbanec: Thanks for the addition. I think one of the key point was also that the devteam wouldn't support a skin used only on one project, cause it cost a lot for them. Money was important in this refusal, I think.Noé (talk) 08:23, 2 September 2019 (UTC)

@Martin Urbanec: Regarding links, I have not finished wikifying the text, but I've already linked the same terms multiple times (e.g., "stewards"). Although this would be a no-no in a Wikipedia article of the same length, I feel like the nature of the page calls for more "convenience links" rather than fewer. I've probably gone a bit overboard, though, so you or others may want to delink certain things. Also, there are usually multiple targets that could be used (e.g., here at Meta, at MediaWiki.org, at the English Wikipedia…), and I have not always searched for the absolute best target for every link. As for the MediaWiki/Wikimedia confusion discussed above, I see your point—plus, I found the link used in the corresponding entry in the current version of the page, so I used that to link the phrase "principle of MediaWiki". Regarding your comment, "and/or copy my signature into my message", I'm not sure what you mean by that. On a possibly related note, though: I boldly changed the "lead section" to be from a third-person perspective (e.g., "initially written by Martin Urbanec") rather than first-person. I figured you were going to remove that bit, anyway, when/if your new version was accepted. It just seemed a bit weird to have a sig on a page that was supposed to eventually become a content page. Finally, regarding my "copy edits" (ugh… I prefer "copyedits"), you will notice that I became progressively more bold as I went along. (!) The last entry in the last table, for example, is almost completely rewritten from what you provided. You (and others) definitely should make sure I have not introduced any false, misleading, or irrelevant statements (especially since I am not a sysadmin, developer, steward, or admin). I plan to finish adding links on the various technical terms (no doubt making various small changes at the same time), and then you (all) can do whatever you want with it. [grin] - dcljr (talk) 15:26, 31 August 2019 (UTC)

Thank you. I originally thought you were going to reply under my message, or inside my own comment, to make things more understanable. At that point, it would be needed to make it clear what was written by you and what was written by me. Thanks for doing the rewrites/copy edits, I don't need to write the best text, I more wanted to start a discussion than to write new version of this page, if no word I wrote would be used, but this page would be more informative, I would still be happy. As such, I have no problems with edits beyond copyediting, as long as the edits doesn't introduce any "false rejections/information by system administrators". Speaking of which, your edits look good to me. I have a few things to mention, but that shall be interpreted as having a matter to discuss, not introducing false information in any mean. Please interpret "missing section in my comment" as "looks good to me".

Intro text rewrite) LGTM

Disable non-autoconfirmed page creation) LGTM

While bureaucrats on some wikis can "desysop" administrators in "Allow bureaucrats to remove administrator permissions") While this wording isn't incorrect, I believe one page should use one level of formality. Since you increased that in the other entries, I believe "can revoke the administrator flag" is better. Changed.

"Special groups on small wikis") I have the feeling it moves from the sounding I intended to have there. I'm not sure about your opinion through, so I'm bringing it up rather than editing again. Precisely, it is about "must be weighed against the potential for abuse". It is more about manageability (and about protecting project's best interest, sometimes, against the will of such project) than about abuse. Any idea how to re-rewrite this part?

Thanks for reminding me I have to fill the CAPTCHA request. Going to do so now. --Martin Urbanec (talk) 20:39, 31 August 2019 (UTC)

The "potential for abuse" part was mostly just me assuming that that was the main issue. Not sure how to rephrase it. Not having any experience with maintaining the configuration files, I guess I don't really understand the "manageability" issues invoved in giving a small wiki what other, larger wikis have. Creating new groups and rights, yes, I see why that could become unmanageable, but expanding existing groups and rights to other wikis? Why is that a manageability issue (or, for that matter, a "best interest" issue)? (I only ask because knowing this might suggest a better wording to me. I'm not trying to get into a debate…) - dcljr (talk) 08:11, 2 September 2019 (UTC)

I totally understand why you ask, not trying to indicate anything bad. Groups are often only inspired by a bigger wiki, they often have similar, but not same, subset of rights. For instance, group engineer at cswiki doesn't allow members to delete pages, while might somewhere else. The manageability issue is mistaking custom groups by built-in groups, as-in "it is here since xxwiki was born, so it is probably default and we might not be able to change that". Custom groups should require certain level of processes, and thus, community big enough to develope them. I don't have problems with both a dedicated rollbacker group and autopatrolled being able to rollback, it just should be decision of more broad community than three people, to avoid issues I tried to describe. Hope that makes the problem more clear. Thanks for your help, --Martin Urbanec (talk) 08:20, 2 September 2019 (UTC)

More concrete example: cswiki community is opposed to non-admins being able to (un)delete, even if only for "maintenance". Ruwiki has a closer group, being able to delete (and probably close AfDs or something). None of those is bad, just requires some discussion. That's what I meant. --Martin Urbanec (talk) 08:22, 2 September 2019 (UTC)

I see… I'll have to think about this. (Or maybe another sysadmin will chime in, and let me off the hook. [wink]) - dcljr (talk) 08:56, 2 September 2019 (UTC)

"Just" thinking is fine :-). If you have any ideas how to improve that, or a feel it's better to rewrite that from scratch, I can do so and it can help us thinking what's the best. --Martin Urbanec (talk) 11:43, 2 September 2019 (UTC)

Any other suggestions I forgot to incorporate? If not, I plan on switching the two pages soon. --Martin Urbanec (talk) 16:19, 7 January 2020 (UTC)

Vagueness

For example,

• Should we have a precise description of "RFA-comparable process"?
• If a wiki have created a "deleter" user group, should admins be able to assign them?

--GZWDer (talk) 09:45, 26 March 2020 (UTC).

Merge "Changes that need to meet specific criteria" and "Changes that are likely to be declined" sections or not?

@Martin Urbanec: IMHO, I don't really understand what are the differents between two sections, both sections describe site configuration requests that may be rejected or approved under different panoramas. So I would merge two sections to be "Changes that are likely to be rejected, unless meet specific criterias". Anyone against so? Liuxinyu970226 (talk) 04:26, 17 January 2022 (UTC)

IMO "Changes that are likely to be declined" may have a much higher standard. "Disable non-autoconfirmed page creation" seems much harder to be accepted than "Local file uploads" 94rain ^Talk 00:41, 2 December 2023 (UTC)

@94rain And how are "Local file uploads" and "Installing extensions/skins that aren't already installed on at least one Wikimedia project" not likely to be declined? Liuxinyu970226 (talk) 03:28, 22 December 2023 (UTC)

@Liuxinyu970226 Uploads are enabled by default on wikimedia sites. For "Installing extensions/skins that aren't already installed on at least one Wikimedia project", it's definitely possible. A series of steps need to be completed though (example task). 94rain ^Talk 03:42, 22 December 2023 (UTC)

#Prohibited changes Allow bureaucrats to remove bureaucrat rights

Shouldn't it be contrary to Bureaucrat#Removing_access, where there are some non-private wikis that bureaucrats can remove bureaucrat rights? -- 94rain ^Talk 00:40, 2 December 2023 (UTC)

It's not. It's clear an exception to the norm and marked as such with a reason. – Ammarpad (talk) 04:50, 3 December 2023 (UTC)

I couldn't find any discussions saying that it's prohibited. phab:T107661 allowed 'crat on ptwiki (not a private or fishbowl wiki) to remove themselves with no controversy on phab. I feel there should be a condition to be met. It seems more more accurate to move it to #Changes that are likely to be declined --94rain ^Talk 05:23, 3 December 2023 (UTC)

As you noted there are 3 regular content projects where this applies (of hundreds). Feel free to add a note that limited exceptions apply and link to that other page. — xaosflux ^Talk 20:38, 3 December 2023 (UTC)

Add "Install extensions for per-page or per-namespace read restrictions" to Prohibited changes

Suggested addition to "Proposed changes with security and/or legal liability issues" in Prohibited changes:

• Example Request: Install extensions for per-page or per-namespace read restrictions
• Reason: MediaWiki was never written with regards to per-page or per-namespace read restrictions and there are probably a lot of ways those restrictions can be theoretically (or practically) bypassed.
• Notes: See T299546 when a request for installing lockdown extension was declined and a security vulnerability found in MediaWiki that effectively allowed everyone to read any pages on (some) private wikis.

94rain ^Talk 07:21, 6 December 2023 (UTC)

 Oppose Such thing affects just bugs to fix, not really benefit for limiting. Liuxinyu970226 (talk) 02:18, 6 January 2024 (UTC)