This page is a translated version of the page Limits to configuration changes and the translation is 48% complete.
Other languages:
English • ‎Esperanto • ‎français • ‎italiano • ‎português • ‎ไทย • ‎中文

Sometimes a community demands a wiki configuration change that is technically feasible to implement, but is rejected by the system administrators, who hold the ultimate authority over MediaWiki configuration.

This page serves to document how system administrators usually react to certain types of requests, and what the community should expect from them. As such, it doesn't need to contain all rejections from system administrators, just ones that are likely to be requested again. If you feel that a rejected request should (or should not) be listed here, please update this table as appropriate, even if you're not a system administrator. If you're not sure, leave a comment on the talk page.


This section lists requests that will be declined right away. System administrators prohibit these changes to protect Wikimedia's founding principles and core values, as well as to protect the integrity of the projects in general. Wikimedia Foundation's Legal department also prohibits some changes for legal reasons.

請求類型 範例請求 原因 注释
降低維基開放程度的更改 操作日誌移除其中一種日誌 Transparency is a non-negotiable principle of MediaWiki. Feature requests are recommeneded if a log is bothering the community and features to filter it out don't exist yet. This doesn't include hiding a log by default from Special:Log, but only cases when the log would not exist at all.
對非確認使用者的所有編輯永久啟用驗證碼 This configuration places an undue restriction on new contributors, given CAPTCHAs are here to help with abuse and vandalism, not to serve any other purpose. System administrators deemed that this is incompatible with Wikimedia core values, and as such, prohibited this change. Please note this is about enabling CAPTCHA for all edits permanently. If your wiki is experiencing an immediate and unmanageable abuse/vandalism, please do reach out to the system administrators. This would be considered as a security incident report. As such, please use security report form. This will create a task to be visible to Wikimedia Foundation Security department, as well as relevant system administrators. They will jointly assess your issue, decide on potential restrictions and implement them. You do not need to recommend any solutions.
技術上不可能達成的更改 更改時區選項的名稱 MediaWiki uses the PHP timezone database, which uses the IANA Time Zone Database. As such, it is technically and physically impossible to change the names of any timezone options. It's only possible to change which timezone is the default in your wiki via the $wgLocaltimezone variable.
涉及安全和法律責任問題的提議更改 允許非管理員檢視已刪除的內容 WMF Legal banned non-admins not passing RFA-comparable process from viewing deleted content; see Wikipedia:Viewing deleted content. Creation of such a user group usually require WMF Legal review. Small wikis will not likely be allowed to have such user groups.
允許非監管員管理使用者查核員監督員權限 Only stewards are allowed to manage those highly restricted groups; local wikis are not allowed to customize this. CheckUsers and oversights are governed by global policies; stewards will ensure that the policies are correctly enforced.
非監管員群組加入隱藏用戶名權限 By policy, it is the task of oversighters to hide things from the public. Oversighters sign confidentiality agreements and are legally required to keep the information private, while this is not true of administrators and others.
授予介面管理員其他權限 The purpose of interface admins is to make fewer users able to edit CSS and JS pages. Granting other rights to this group may encourage wikis to grant this right when their intention is different.
允許管理員授予機器人管理員介面管理員權限 Rejected because granting and removing those flags is a task for bureaucrats where present, or stewards. Interface administrators also have highly sensitive permissions (to edit CSS and JS pages) and requests for granting must be carefully considered. As such, it is necessary that only bureaucrats or stewards handle this task. Wikis that currently don't have any bureaucrats and feel they are big enough to handle this themselves are recommended to elect bureaucrats instead.
允許行政員移除行政員權限 This is to protect the safety of the projects. Since bureaucrat permissions are higher than those of administrators, only stewards are allowed to do this. Bureaucrats on all private wikis can remove bureaucrat status, but that's because private wikis are managed by dedicated groups and serve special support purposes rather than host content.
更改是要使用不受支援的技術或以不受支援的方式濫用它們 安裝沒有妥善維護的擴充功能/外觀 Some extensions are currently installed in some Wikimedia wikis, but have significant unresolved problems or bugs. So it is decided not to install these extensions to further wikis, though existing installations will be preserved. 目前包括:
在討論頁啟用視覺化編輯 The visual editor is not built to support editing talk pages. As such, enabling the visual editor in a talk page namespace is likely to not always work as expected by the community. To save developers from bug reports about something that's not supposed to work in the first place, enabling VisualEditor on talk pages has been prohibited.
解除安裝Flow Uninstalling Flow (now known as Structured Discussions) is a hard task, given how complex Flow is. For this reason, requests to do so will be declined. Wikis can request that Flow be set to "read only" if they don't want use it anymore. To avoid future problems, Flow was uninstalled in March 2018 from all wikis where it had zero topics (see phab:T188812).
安裝尚未在至少一個維基媒體項目上安裝的擴充功能或外觀 To protect the security of the Wikimedia infrastructure, all extensions, skins and other components running in it must pass security, performance and other reviews. Extensions that are not already installed on at least one Wikimedia project won't be considered for installation until they pass such reviews.
更改任何單個維基上的預設外觀 Wikimedia should have a standardized look globally across all our projects. It has been decided that Vector will remain the default skin on all Wikimedia wikis unless the decision is made to change this globally. Changing the default skin on all Wikimedia wikis is certainly not prohibited, but would be extremely difficult to accomplish, and would be centrally led. Not only would this require consultation with all affected communities before such a decision could be made, but a massive effort would also be required to make all the necessary changes "behind the scenes".


This section lists changes that are not strictly prohibited, but are likely to be declined unless special evidence can be presented to convince system administrators that the changes are necessary.

請求類型 原因
禁止非自動確認使用者建立頁面 此配置對新的貢獻者施以不適當的限制,系統管理員會拒絕這類請求,除非維基能處理以下問題:(1) 已經準備好能夠及時處理草稿。(2) 有完善的編輯和管理社群。(3) 已對該更改建立非常廣泛的共識。前兩點可以透過維基的大小來確認:活躍使用者、管理員、行政員及其他工作人員的數量應該與「大維基」相近,否則就應該對該請求被接受的原因給出一個好的解釋。第三點可以透過在維基上的意見徵求中經過仔細地討論來滿足,並由總結的管理員在Phabricator上的相關任務中的解釋共識。如果共識看起來並不特別強烈(請注意可能沒有系統管理員能夠理解該本地維基的語言),管理員就必須解釋該共識為何能視為足夠廣泛的共識。
允許行政員移除管理員權限 While bureaucrats on some wikis can revoke the administrator flag, at most wikis this is the responsibilty of stewards. In order for this kind of request to be accepted, the wiki should be large—with multiple active bureaucrats—and be able to demonstrate a real need for the change. In smaller wikis this ability is prone to abuse by bureaucrats wishing to usurp the power of the community to decide on issues of adminship.
小維基的特殊使用者群組 System administrators may consider wiki size before adding a special user group. Such requests sometimes seem to be motivated by the mere desire to have something that bigger wikis have rather than an actual need. For example, members of the rollbacker group are given a tool that allows them to do with one click the same thing ordinary users can do in a series of steps (revert multiple edits by the same user); in small, low-traffic wikis this speed increase may not be necessary and must be weighed against the potential for abuse. Also, sometimes requests to create a custom group can instead be implemented with an existing user group (such as autopatrolled). In the interest of manageability, sysadmins will not create a new group if an alternative approach can be found.

Changes made by the system administrators at their own discretion

As said at Requesting wiki configuration changes, the ultimate authority on Wikimedia configuration lies with the system administrators. This is because only system administrators can edit it, and as such, are fully responsible for it, and because no one can be made fully responsible for something without also granting full authority over the same something. As such, system administrators can not only reject requests, but also change configuration on their own. This section aims to explain and document why this might happen, but given the world can be hard to predict, it isn't (and can't be) complete by any means. In this section, "changes made by the system administrators" are called "measures" for the purpose of simplicity.

Measures can be both permanent and temporary, althrough temporary ones tend to be more frequent. System administrators do their best to limit temporary as much as possible, while still keeping the measures effective. Especially temporary changes can be communicated with the community in full, meaning the community would recieve overall explanation that explains why the measure was taken without going into technical details, partially, meaning the community would be informed that a measure was taken, but not why, or not at all, while the community won't recieve any information. Same as with duration, system administrators do their best to give less information only when it is necessary, but given the nature of the measures, they also err on the side of caution to protect the security of Wikimedia infrastructure. As such, system administrators might decide to not inform community, or to give little information, when it later shows it wasn't necessary. While this should happen as infrequently as possible, it can happen, and cannot be prevented.

Measures are mostly taken to protect the security of the Wikimedia infrastructure, but infrequently, can happen for other reasons as well. The other reasons aren't mentioned here, because it is hard to predict them, and this section is (as of 2019) relatively new, as it was written in late 2019. As time goes, technical community members (who may or may not be system administrators) will do their best to update this section. Examples of cases warranting taking measures can include exceptionally high level of vandalism, other attempts to disrupt Wikimedia movement and the like.

Temporary measures can include (but aren't limited to) decreasing the limit of accounts created from one IP address, requiring CAPTCHAs for all edits and the like. Permanent measures can include (but not limited to) taking away certain ability from administrators in favour of dedicated group or deciding that two factor authentication is mandated to be in a user group.