Limiti alle modifiche di configurazione

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 55% complete.
Other languages:
English • ‎Esperanto • ‎français • ‎italiano • ‎português • ‎ไทย • ‎中文

Talvolta una comunità richiede una modifica alla configurazione wiki che è tecnicamente fattibile da implementare, ma è respinta dagli amministratori di sistema, che hanno l'autorità definitiva sulla configurazione di MediaWiki.

Questa pagina serve a documentare come gli amministratori di sistema reagiscono a certi tipi di richieste e cosa deve aspettarsi la comunità da loro. In quanto tale, non necessità di raccogliere "tutti" i rifiuti da parte degli amministratori di sistema, solamente quelli che hanno probabilità di essere nuovamente richiesti. Se ritieni che una richiesta rifiutata dovrebbe (o non dovrebbe) essere elencata qui, per favore aggiorna la tabella ove opportuno, anche se non sei amministratore di sistema. Se non sei certo, lascia un commento nella pagina di discussione.

Modifiche vietate

Questa sezione elenca richieste che saranno declinate immediatamente. Gli amministratori di sistema vietano queste modifiche per tutelare i principi fondamentali e i valori centrali, oltre che proteggere l'integrità dei progetti in generale. Il dipartimento Legal della Wikimedia Foundation vieta inoltre alcune modifiche per ragioni legali.

Tipo di richiesta Esempio di richiesta Motivo Note
Modifiche che rendono la wiki meno aperta Rimuovere un registro dalle azioni registrate La trasparenza è un principio di MediaWiki non negoziabile. Se un registro infastidisce la comunità, è raccomandato effettuare una richiesta di nuove funzionalità per filtrarlo se già non è disponibile. Questo non includere nascondere automaticamente un registro da Speciale:Registri, ma solamente nel caso il registro non esista affatto.
Abilitare il CAPTCHA per tutte le modifiche degli utenti non confermati permanentemente Questa configurazione pone una eccessiva limitazione sui nuovi contributori, dato che i CAPTCHA contrastano gli abusi e i vandalismi, ma non servono ad altri scopi. Gli amministratori di sistema ritengono che ciò sia incompatibile con i valori centrali di Wikimedia, e in quanto tale, vietato questa modifica. Si noti che questa modifica riguarda l'abilitazione dei CAPTCHA per tutti gli edit in modo permanente. Se la wiki sta subendo abusi/vandalismi immediati e ingestibili si prega di contattare gli amministratori di sistema. Questo potrebbe essere considerato un problema di sicurezza. Come tale, si prega di compilare il modulo di sicurezza. Questo creerà un task visibile dal dipartimento di Sicurezza della Wikimedia Foundation, così come agli amministratori di sistema competenti. Insieme valuteranno il problema, decideranno le eventuali limitazioni e le implementeranno. Non è necessario suggerire alcuna soluzione.
Rimuovere l'accesso in scrittura a un gruppo utente "Chiunque può modificare" è un principi non negoziabili di progetti Wikimedia. La revoca totale dell'accesso in scrittura per qualunque gruppo utente non verrà abilitata. Revoche parziali dei privilegi di scrittura, come l'ACTRIAL su en.wiki, possono avvenire di volta in volta, ma questi casi sono estremamente rari e soggetti ad attenta riflessione. Vedi anche "Disabilitare la creazione di pagine per non autoconvalidati" sotto.
Modifiche che sono tecnicamente impossibili Modifiche alla denominazione delle opzioni del fuso orario MediaWiki utilizza il database dei fusi orari di PHP, basato sul Time Zone Database di IANA. Di conseguenza è tecnicamente e fisicamente impossibile cambiare le denominazioni di qualunque opzione del fuso orario. È solamente possibile cambiare quale fuso orario sia predefinito tramite la variabile $wgLocaltimezone.
Proposte di modifiche con problematiche di sicurezza e/o di responsabilità legali Consentire ai non amministratori di visualizzare elementi eliminati WMF Legal ha vietato ai non amministratori che non superano un processo analogo a RFA di visualizzare contenuto rimosso; vedi Wikipedia:Viewing deleted content La creazione di un tale gruppo utente richiede di solito la verifica di WMF Legal. Le piccole wiki possono vedersi rifiutate le richieste di approvazione tali gruppi utenti.
Consentire a non steward di gestire le assegnazioni dei permessi di CheckUser / Oversight Solo gli steward sono autorizzati a gestire questi gruppi altamente ristretti; le wiki locali non sono autorizzate a personalizzarli. CheckUser e oversight sono regolamentati da politiche globali; gli steward assicurano che tali politiche vengano correttamente applicate.
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.
Concedere agli Amministratori dell'interfaccia altri permessi 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.
Permettere ai burocrati di rimuovere i permessi di burocrate 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).
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.
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".

Modifiche che possono essere rifiutate

Questa sezione elenca modifiche che non sono necessariamente vietate, ma che possono essere rifiutate a meno che non siano presentati elementi particolari per convincere gli amministratori di sistema che le modifiche siano necessarie.

Tipo di richiesta Motivo
Disabilitare la creazione di pagine per non autoconvalidati 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.
Permettere ai burocrati di rimuovere i permessi di amministratore 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 made by the system administrators at their own discretion

As noted at Requesting wiki configuration changes, the ultimate authority on Wikimedia configuration lies with the system administrators, as only system administrators can edit it, and as such, are fully responsible for configuration. 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 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. Examples include (but are not limited to) exceptionally high levels of vandalism, other attempts to disrupt the Wikimedia movement and the like.

Measures can be both permanent and temporary, but temporary measures tend to be more frequent. System administrators do their best to limit temporary changes as much as possible (in both scope and duration), while still keeping the measures effective. Any measures may or may not be communicated to the community, as warranted by security implications.

Temporary measures can include (but are not 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 are not limited to) taking away certain abilities from administrators in favour of dedicated groups or deciding that two-factor authentication is mandated for a user group.