Limites à des changements de configuration

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
This page is a translated version of the page Limits to configuration changes and the translation is 11% complete.
Other languages:
Bahasa Indonesia • ‎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.

Prohibited changes

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.

Type of request Example request Reason Notes
Changes that make the wiki less open Remove a log from logged actions Transparency is a non-negotiable principle of MediaWiki. Feature requests are recommended 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.
Enable CAPTCHA for all edits of non-confirmed users permanently 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.
Supprimer le droit d'édition d'un groupe d'utilisateurs "Anyone can edit" is a non-negotiable principle of Wikimedia projects. Full revocation of editing permissions from any user group will not be enabled. Partial revocation of editing privileges, like enwiki's ACTRIAL, can happen from time to time, but those cases are extremely rare and are subject to careful consideration. See also "Disable non-autoconfirmed page creation" below.
Changes that are technically impossible Changes to the naming of timezone options 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.
Proposed changes with security and/or legal liability issues Allow non-admins to view deleted stuff 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.
Allow non-stewards to manage CheckUser/Oversight permissions 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.
Add hideuser right to non-oversighters 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.
Grant Interface admins other permissions 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.
Allow administrators to grant bot, administrator or interface admin rights 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.
Allow bureaucrats to remove bureaucrat rights 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.
Changes to use unsupported technologies, or abuse them in unsupported ways Installation of extensions/skins that are not well maintained 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.

Currently includes:

Enable VisualEditor on talk pages 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.
Uninstall 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 to use it anymore. To avoid future problems, Flow was uninstalled in March 2018 from all wikis where it had zero topics (see phab:T188812).
Changing the default skin on any individual wiki 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".

Changes that need to meet specific criteria

Type of request Reason
Local file uploads According to Wikimedia's licensing policy, all projects are expected to host only content under a Free Content License. In limited circumstances, a project may adopt an Exemption Doctrine Policy (EDP), which defines (in accordance with both United States law as well as the law of countries where the project content is predominantly accessed) when copyrighted materials can be updated.

If your project may not accept non-free media (under an EDP), it is highly unlikely local file uploads will be enabled. Free media should go to Wikimedia Commons instead. See also: Non-free content.

Installing extensions/skins that aren't already installed on at least one Wikimedia project 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. To future requests of this: you should also create a task to request security reviewing of the extension.

Changes that are likely to be declined

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.

Type of request Reason
Disable non-autoconfirmed page creation This configuration places an undue restriction on new contributors. Sysadmins will resist such a request unless the wiki in question (1) is prepared to handle drafts in a timely manner, (2) has a well developed editing and administrative community, and (3) has established an unusually broad consensus for the change. The first two points can be addressed by appealing to the wiki's size: the number of active editors, sysops, bureaucrats, and other functionaries should be similar to "big wikis", otherwise a very good explanation will need to be given as to why the request should be accepted. The third point can be satisfied by a carefully discussed on-wiki RFC, with the closing administrator explaining the consensus in the relevant Phabricator task; if the consensus does not look particularly strong on its face (note that there may not be any sysadmins who are able to read the local language of the wiki), the admin will have to explain why it nonetheless should be considered sufficiently broad.
Allow bureaucrats to remove administrator permissions While bureaucrats on some wikis can revoke the administrator flag, at most wikis this is the responsibility 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.
Special groups on small wikis 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 that are likely to be stalled, though not declined

This section lists changes that are of course not be declined per consensus, but due to very high technical matters, they won't be handled shortly.

Type of request Reason
Change the canonical URL of a wiki See also: Special language codes, phab:tag/Wiki-setup_(rename) and phab:T172035

For several decades, some Wikimedia projects are using the canonical URLs which don't feel better, such as wrong language code or confusing means. As of Feb 2021, these works are meeting several technical challenges, and before this time point, only a maximum of five wikis were renamed: Wikimedia Pennsylvania (changed to ), Wikimedia Affiliation Committee private wiki (changed to ), Wikimedia Eesti (changed to ), Belarusian (Taraškievica) Wikipedia (changed to ) and Wikimedia Foundation Governance Wiki (changed to ). Currently the known challenges are Wikidata-related, Special:SiteMatrix, ContentTranslation functions, and the related interwiki logs of any renamed wikis.

Changes made by the system administrators at their own discretion

Comme indiqué à Demander des modifications de la configuration d'un wiki, l'autorité ultime en matière de configuration de Wikimedia appartient aux administrateurs système, car seuls ces derniers peuvent la modifier et, à ce titre, sont entièrement responsables de la configuration. Ainsi, les administrateurs du système peuvent non seulement rejeter les demandes, mais aussi modifier la configuration de leur propre chef. Cette section vise à expliquer et à documenter les raisons pour lesquelles cela pourrait se produire, mais étant donné que le monde peut être difficile à prévoir, elle n'est (et ne peut être) en aucun cas complète. Dans cette section, les "modifications apportées par les administrateurs du système" sont appelées "mesures" pour des raisons de simplicité.

Les mesures sont le plus souvent prises pour protéger la sécurité de l'infrastructure de Wikimedia, mais il arrive rarement qu'elles soient prises pour d'autres raisons. Les autres raisons ne sont pas mentionnées ici, car il est difficile de les prévoir. Les exemples incluent (mais ne sont pas limités à) des niveaux exceptionnellement élevés de vandalisme, d'autres tentatives pour perturber le mouvement Wikimedia et autres.

Les mesures peuvent être à la fois permanentes et temporaires, mais les mesures temporaires ont tendance à être plus fréquentes. Les administrateurs système font de leur mieux pour limiter autant que possible les modifications temporaires (tant en termes de portée que de durée), tout en maintenant l'efficacité des mesures. Toute mesure peut être communiquée ou non à la communauté, en fonction des implications en matière de sécurité.

Les mesures temporaires peuvent inclure (mais ne sont pas limitées à) la diminution de la limite de comptes créés à partir d'une adresse IP, l'exigence de CAPTCHAs pour toutes les modifications et autres. Les mesures permanentes peuvent inclure (mais ne sont pas limitées à) retirer certaines capacités aux administrateurs en faveur de groupes dédiés ou décider que l'authentification à deux facteurs est obligatoire pour un groupe d'utilisateurs.