Limiti alle modifiche di configurazione
Questa non è una politica; descrive solamente la pratica di come gli amministratori di sistema gestiscono le modifiche di configurazione. |
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 Gruppi utente 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. | |
| Aggiungere diritto di nascondere un utente a non oversighter | In base alla linea guida, è compito degli oversighter nascondere elementi al pubblico. Gli oversighter firmano accordi di riservatezza e sono legalmente obbligati a mantenere le informazioni private, mentre ciò non è vero per amministratori e altri ruoli. | ||
| Concedere agli Amministratori dell'interfaccia altri permessi | Lo scopo degli amministratori dell'interfaccia è rendere pochi utenti in grado di effettuare modifiche alle pagine CSS e JS. Garantire altri diritti a questo gruppo potrebbe incoraggiare le wiki a concedere questo ruolo per fini differenti. | Per discussion in T320752, this does not apply to editcontentmodel.
| |
| Permettere agli amministratori di concedere diritti per bot, amministratore o amministratore dell'interfaccia | Rifiutata poiché concedere e rimuovere tali flag è un compito dei burocrati dove presenti o degli steward. Gli amministratori dell'interfaccia hanno inoltre permessi molto delicati (di modificare pagine CSS e JS) e le richieste devono essere attentamente valutate. Per questo è necessario che solamente burocrati e steward gestiscano il compito. | Wiki che non hanno al momento burocrati e ritengono di essere abbastanza grandi da gestirsi da sole sono raccomandante ad eleggere burocrati. | |
| Permettere ai burocrati di rimuovere i permessi di burocrate | Questo è per proteggere l'incolumità dei progetti. Dato che i permessi di burocrate sono più elevati di quelli degli amministratori, solamente gli steward sono autorizzati a farlo. | In tutte le wiki private i burocrati possono rimuovere lo status di burocrate, ma ciò poiché le wiki private sono gestite da gruppi dedicati e servono a speciali scopi di manutenzione che ad ospitare contenuti. | |
| Modifiche per usare tecnologie non supportate o abusarne in modi non supportati. | Installazione di estensioni/temi che non sono ben mantenuti | Alcune estensioni sono attualmente installate in alcune wiki Wikimedia, ma hanno problemi irrisolti o bug rilevanti. Per questo motivo si è deciso di non installare tali estensioni su ulteriori wiki, sebbene le installazioni esistenti verrano preservate. | Al momento includono: |
| Abilitare il VisualEditor nelle pagine di discussione | L'editor visuale non è realizzato per supportare la modifica di pagine di discussione. Perciò abilitare l'editor visuale in un namespace di pagine di discussione è destinato a non funzionare sempre come atteso dalla comunità. Per evitare agli sviluppatori segnalazioni di bug su qualcosa che non dovrebbe funzionare fin dall'inizio, è stato vietato abilitare il Visual Editor nelle pagine di discussione. | StructuredDiscussions implemented some VisualEditor features; another alternative is the New Discussion Tool. | |
| Cambiare il tema predefinito su una specifica wiki | Wikimedia dovrebbe avere un aspetto generalmente uniforme attraverso tutti i nostri progetti. È stato deciso che Vector rimarrà il tema predefinito su tutte le wiki Wikimedia a meno che non venga presa la decisione di cambiarlo globalmente. | Cambiare il tema predefinito di tutte le wiki Wikimedia non è certamente proibito, ma potrebbe essere estremamente difficile da effettuare e verrebbe gestito centralmente. Non solo ciò richiederebbe il consulto di tutte le comunità coinvolte prima di prendere tale decisione, ma è inoltre richiesto uno sforzo massiccio per effettuare tutte le modifiche necessarie "dietro le quinte". |
Modifiche che richiedono il rispetto di precisi criteri
| Tipo di richiesta | Motivo |
|---|---|
| Caricamento di file locali | Secondo la licensing policy di Wikimedia, tutti i progetti dovrebbero ospitare solamente contenuti sotto licenza libera. In determinate circostanze, un progetto può adottare una Exemption Doctrine Policy (EDP), che definisce (in conformità sia con le leggi degli Stati Uniti che dei paesi presso cui il contenuto del progetto è maggiormente consultato) quando è possibile caricare materiale protetto da copyright.
Se il tuo progetto non può accettare contenuti multimediali non liberi (sotto una EDP), è estremamente improbabile che venga abilitato il caricamento di file locali. Contenuti multimediali liberi dovrebbero preferibilmente andare su Wikimedia Commons. See also: Non-free content. |
| Installare estensioni/temi che non sono già stati installati in almeno uno dei progetti Wikimedia | Per proteggere la sicurezza dell'infrastruttura Wikimedia, tutte le estensioni, temi e altri componenti eseguiti devono passare controlli di sicurezza, performance e altro. Estensioni che non sono già installate su almeno uno dei progetti Wikimedia non saranno considerati per l'installazione finché non superano tali controlli. See Writing an extension for deployment on MediaWiki.org for required steps. |
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 | Questa configurazione pone un'eccessiva limitazione ai nuovi contributori. Gli amministratori di sistema si opporranno a tale richiesta a meno che la wiki in questione (1) sia preparata a gestire le bozze in maniera tempestiva, (2) abbia una comunità molto sviluppata dal punto di vista di redazione e di amministrazione e (3) si sia accertato un consenso eccezionalmente ampio per la modifica. I primi due punti possono essere esaminati facendo ricorso alle dimensioni della wiki: il numero di contributori attivi, amministratori, burocrati e altri funzionari deve essere simile alle "grandi wiki", altrimenti è necessario fornire un'ottima spiegazione sul motivo per cui la richiesta dovrebbe essere accettata. Il terzo punto può essere soddisfatto da una partecipata RFC nella wiki, la cui chiusura permetta all'amministratore di esporre il consenso nel task Phabricator specifico; se il consenso non sembra particolarmente forte (nota che potrebbero non esserci amministratori in grado di leggere la lingua locale del wiki), l'amministratore dovrà esporre per quale motivo dovrebbe essere considerato sufficientemente ampio. |
| Permettere ai burocrati di rimuovere i permessi di amministratore | Sebbene in alcune wiki i burocrati possano rimuovere il flag di amministratore, nella maggior parte delle wiki ciò è responsabilità degli steward. Affinché tali richieste possano essere accettate, la wiki deve essere grande - con diversi burocrati attivi - e deve essere in grado di dimostrare una reale necessità per la modifica. Nelle wiki più piccole questa abilità è soggetta ad abuso da parte dei burocrati nel desiderio di usurpare il potere della comunità di decidere sui problemi relativi all'amministrazione. |
| Gruppi speciali sulle piccole wiki | Gli amministratori di sistema potrebbero considerare la dimensione delle wiki prima di aggiungere uno speciale gruppo utenti. Tali richieste talvolta sembrano motivate dal mero desiderio di avere qualcosa che le grandi wiki non hanno, piuttosto che da una reale necessità. Per esempio, ai membri del gruppo rollback è dato accesso ad uno strumento che permette loro di effettuare con un click la stessa operazione che i semplici utenti possono fare in una serie di passaggi (annullare molteplici modifiche da uno stesso utento); nelle piccole wiki a basso traffico, questo incremento della velocità potrebbe non essere necessario e deve essere pesato contro il potenziale abuso. Inoltre talvolta sono effettuate richieste per creare un gruppo personalizzato che può essere implementato tramite un gruppo utenti già esistente (come gli autoverificati). Nell'interesse della gestibilità, gli amministratori possono non creare un nuovo gruppo se è possibile trovare un approccio alternativo. |
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.
| Tipo di richiesta | Motivo |
|---|---|
| Change the canonical URL of a wiki | See also: Special language codes, Wiki-setup (rename) and 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:
Currently the known challenges are related to Wikidata, Special:SiteMatrix, ContentTranslation functions, and interwiki logs. |
Modifiche effettuate dagli amministratori di sistema a propria discrezione
Come evidenziato in Richiesta di modifiche alla configurazione wiki, l'autorità finale sulla configurazione di Wikimedia risiede negli amministratori di sistema, dato che solo gli amministratori di sistema possono cambiarla e perciò sono pienamente responsabili per la configurazione. Pertanto gli amministratori di sistema possono non solo rifiutare richieste, ma anche modificare la configurazione autonomamente. Questa sezione si propone di spiegare e documentare perché ciò possa accadere, ma dato che il mondo può essere difficile da prevedere, non è (e non potrà essere) completa in nessun modo. In questa sezione le "modifiche effettuate dagli amministratori di sistema" verranno chiamati "provvedimenti" per semplicità.
I provvedimenti sono presi principalmente per proteggere la sicurezza dell'infrastruttura Wikimedia, ma sono infrequenti, e possono avvenire anche per altre ragioni. Le altre ragioni non sono menzionate qui poiché sarebbe complicato prevederle. Esempi includono (ma non sono limitati a) livelli eccezionalmente elevati di vandalismo, altri tentativi di disturbare il movimento Wikimedia e simili.
I provvedimenti possono essere sia permanenti che temporanei, ma quest'ultimi tendono ad essere più frequenti. Gli amministratori di sistema fanno il loro meglio per limitare cambiamenti temporanei per quanto possibile (sia per portata che per durata), pur mantenendo i provvedimenti efficaci. Ogni provvedimento può o non può essere comunicato alla comunità, se giustificato da implicazioni per la sicurezza.
Provvedimenti temporanei possono includere (ma non essere limitati a) la riduzione del numero di utenze create da un indirizzo IP, la richiesta di CAPTCHA per tutte le modifiche e simili. Provvedimenti permanenti possono includere (ma non essere limitati a) rimuovere certe competenze agli amministratori a beneficio di gruppi dedicati o stabilire che l'autenticazione a due fattori è obbligatoria per un gruppo utente.