Limites aux changements de configuration
Il ne s'agit pas d'une politique; on ne décrit ici que la pratique selon laquelle les administrateurs système gèrent les changements de configuration. |
Une communauté demande parfois un changement de configuration du wiki qui est techniquement possible à mettre en œuvre, mais qui est rejeté par les administrateurs système qui détiennent l'autorité ultime sur la configuration de MediaWiki.
Cette page sert à documenter la façon dont les administrateurs système réagissent habituellement à certains types de demandes et ce que la communauté peut attendre d'eux. En tant que tel, il n'est pas nécessaire de présenter tous les rejets des administrateurs système, seulement ceux qui seront vraisemblablement demandés à nouveau. Si vous pensez qu'une demande rejetée devrait (ou ne devrait pas) être répertoriée ici, veuillez mettre à jour ce tableau au besoin, même si vous n'êtes pas administrateur système. Si vous n'êtes pas certain, laissez un commentaire sur la page de discussion.
Changements interdits
Cette section regroupe les demandes qui seront rejetées d'office. Les administrateurs système interdisent ces modifications pour protéger les principes fondateurs de Wikimedia et les valeurs de base, ainsi que pour protéger l'intégrité des projets en général. Le département juridique de la Fondation Wikimedia interdit également certaines modifications pour des raisons juridiques.
| Type de demande | Exemple de demande | Motif | Remarques |
|---|---|---|---|
| Modifications rendant le wiki moins ouvert | Supprimer un billet des actions du journal | La transparence est un principe non négociable de MediaWiki. Les demandes de fonctionnalités sont recommandées si un journal gêne la communauté et que les fonctionnalités pour le filtrer n'existent pas encore. | Cela n'inclut pas le masquage par défaut d'un journal de Special:Log, mais seulement les cas où le journal n'existerait pas du tout. |
| Active le CAPTCHA de manière permanente pour toutes les modifications faites par les utilisateurs non confirmés | Cette configuration impose une restriction excessive aux nouveaux contributeurs, étant donné que les CAPTCHA sont là pour aider à lutter contre les abus et le vandalisme, et non pour servir à autre fin. Les administrateurs système ont estimé que cela était incompatible avec les valeurs fondamentales de Wikimedia et, en tant que tel, ont interdit ce changement. | Veuillez noter que c'est à propos de l'activation permanente du CAPTCHA pour toutes les modifications. Si votre wiki est victime d'abus ou de vandalisme soudain que vous n'arrivez pas à gérer, contactez immédiatement les administrateurs système. Ceci doit être considéré comme un rapport d'indicident de sécurité. Par conséquent veuillez utiliser le formulaire de rapport de sécurité. Cela créera une tâche qui sera visible au département Sécurité de la Fondation Wikimedia, ainsi qu'aux administrateurs de système concernés. Ils évalueront ensemble votre problème, décideront des restrictions potentielles et les mettront en œuvre. Il n'est pas nécessaire de proposer des solutions. | |
| Supprimer le droit d'édition d'un groupe d'utilisateurs | « Chacun a le droit de modifier » est un principe non négociable des projets Wikimedia. Supprimer complètement d'un groupe ses droits de modification ne sera pas autorisé. | 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. | |
| Modifications techniquement impossibles | Modifications du nommage des options de fuseau horaire | 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 | Permettre aux non administrateurs de voir le contenu supprimé | WMF Legal has barred non-admins not passing an RFA-comparable process from viewing deleted content; see Wikipedia:Viewing deleted content. | Creation of such a user group usually requires WMF Legal review. Les petits wikis risquent de ne jamais être autorisés à avoir de tels groupes utilisateur. |
| Permet aux non stewards de gérer les droits de vérification d'adresse IP et de masquage des modifications | 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. | |
| Ajouter les droits de masquage d'utilisateurs à ceux qui ne les ont pas | 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. | Pour chaque discussion de T320752, cela ne s'applique pas à editcontentmodel.
| |
| 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. En conséquence, il est nécessaire que seuls les bureaucrates ou les stewards réalisent cette tâche. | Wikis that currently don't have any bureaucrats and feel they are big enough to handle this themselves are recommended to elect bureaucrats instead. | |
| Permettre aux bureaucrates de supprimer les droits de bureaucrate. | Ceci dans le but de protéger la sécurité des projets. Parce que les privilèges des bureaucrates sont supérieurs à ceux des administrateurs, seuls les stewards ont le droit de faire cela. | 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. | |
| Modifications utilisant des technologies non supportées, ou qui en abusent de manière non recommandée | Installation d'extensions ou habillages peu maintenus | Certaines extensions sont actuellement installées dans certains wikis Wikimedia, mais ont des problèmes ou des bogues non résolus importants. Il est donc décidé de ne pas installer ces extensions sur d'autres wikis, bien que les installations existantes soient préservées. | Comprend actuellement : |
| Activer l'Editeur Visuel sur les pages de discussion | L'éditeur visuel n'est pas conçu pour supporter l'édition des pages de discussion. 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. | StructuredDiscussions implemented some VisualEditor features; another alternative is the New Discussion Tool. | |
| Modifier l'habillage par défaut sur tout wiki individuel. | Wikimedia doit avoir un aspect standardisé au travers de l'ensemble de ses projets. Il a été décidé que Vector resterait l'habillage par défaut sur tous les wikis Wikimedia. | 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". |
Changements devant satisfaire des critères spécifiques
| Type de demande | Motif |
|---|---|
| Téléversements de fichiers locaux | 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 uploaded.
Si votre projet ne peut pas accepter les médias non libres (sous un EDP), il est très peu probable que les téléversements de fichiers locaux soient autorisés. Les médias libres doivent être hébergés dans Wikimedia Commons à la place. Voir aussi : le contenu non libre. |
| Installer des extensions ou des habillages non encore présents sur au moins un projet Wikimedia | 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. Voir les étapes à suivre pour Ecrire une extension à déployer sur MediaWiki.org. |
Changements ayant des chances d'être refusés
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 de demande | Motif |
|---|---|
| Désactiver la création de page non autoconfirmée. | Cette configuration attribue une restriction non justifiée aux nouveaux contributeurs. 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. |
| Permet aux bureaucrates d'enlever les droits administrateur | Alors que les bureaucrates sur certains wikis peuvent retirer la mention de administrateur, sur la plupart des wikis il en est de la responsabilité des 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. |
| Groupes spéciaux des petits wikis | Les administrateurs système peuvent envisager la taille du wiki avant d'ajouter un groupe d'utilisateurs spécial. 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. |
Changements susceptibles d'être suspendus, mais non refusés
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 de demande | Motif |
|---|---|
| Modifier l'URL canonique d'un wiki | Voir aussi : les codes linguistiques spéciaux, Wiki-setup (rename) et phab:T172035 For several decades, some Wikimedia projects have been using canonical URLs which have problems like using the wrong language code or being otherwise confusing. As of January 2022, the process of renaming wikis and changing their URLs remains a severe technical challenge. So far, only the following wikis have ever been successfully renamed:
Actuellement les défis connus sont liés à Wikidata, Special:SiteMatrix, aux fonctions ContentTranslation, et aux journaux interwiki. |
Changements demandés par les administrateurs système, à leur propre initiative
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.