Discussioni progetto:Coordinamento/Pagine d'aiuto/Commissione di Arbitraggio

Richieste di valutazione di violazioni dell'UCoC

Secondo me, manca un caso, che suggerirei di aggiungere:

• Nel caso l'intervento sia richiesto dalla comunità per risolvere una procedura di problematicità, tramite l'apposizione del template {{Richiesta VAR}} nella pagina di servizio in cui si discute della problematicità. In tal caso, la "controparte" è implicitamente l'utenza verso cui è stata aperta la procedura.

Torna? --SuperSpritz^{l'adminalcolico} 18:03, 27 mar 2024 (CET)

direi "l'utenza o le utenze", non è detto che non ci sia un gruppo di utenti (non necessariamente sock o meatpuppet) che stiano operando in squadra. -- .mau. ✉ 19:18, 27 mar 2024 (CET)

Sì, hai ragione.--SuperSpritz^{l'adminalcolico} 19:59, 27 mar 2024 (CET)

Impegno della Comunità

Obiettivo dell'ArbCom dovrebbe essere anche quello di occuparsi di attività, come le segnalazioni di problematicità, che «dragano risorse dal nostro compito (scrivere un'enciclopedia)» (cit.) e per ottenere ciò mettiamo su un sistema che impegnerà la Comunità in elezioni per 8 settimane l'anno, se non ci sono "suppletive".
Siamo sicuri che ci serva una sovrastruttura come questa? --Antonio1952 (msg) 21:59, 28 mar 2024 (CET)

[@ Antonio1952] L'ArbCom non si deve occupare genericamente di "tutte" le segnalazioni di problematicità, che continueranno a essere gestite come sono adesso. Può però essere chiamato a dare una posizione finale in quei casi (abbastanza rari) in cui una procedura di problematicità ordinaria non riesce a trovare un WP:CONSENSO chiaro o si trascina talmente a lungo da finire in uno stallo. E l'impegno delle elezioni è lo stesso che c'è ogni volta che viene eletto un admin: al singolo utente, non è che porta via "otto settimane piene": porta via il tempo di esprimere un suo commento sul candidato e, se ha i requisiti di voto, il tempo per votare. Non mi sembra si possa parlare di "dragare risorse". Per il resto, c'è anche WMF che sta incoraggiando i vari progetti a dotarsi di questa struttura come parte dell'implementazione dell'UCoC e serve comunque per gestire anche le revisioni dei blocchi dati in seguito a procedura comunitaria, come spiegato da .mau. al Bar. Serve eccome. --SuperSpritz^{l'adminalcolico} 08:44, 29 mar 2024 (CET)

Sinteticamente.

Dalle discussioni pregresse avevo capito che per adempiere alle regole dell'UCoC non era necessario un ArbCom ma sarebbe bastato introdurre la possibilità di "Richiesta di revoca" che abbiamo appena introdotto. Peraltro, si era scelto di rifarsi al modello di es.wiki proprio perché non ha un ArbCom.

Le UP che si trascinano nel tempo sono, come dici, abbastanza rare e comunque, se non si trova un consenso, vuol dire che la problematicità in esame non è poi così evidente per cui la soluzione logica dovrebbe essere un "non luogo a procedere".

Le votazioni non fanno perdere tempo alla Comunità se chi vota lo fa a prescindere. Se invece, come è giusto che sia, prima di votare si legge la presentazione del candidato, i commenti alla candidatura nonché i commenti in fase di votazione, allora il tempo si perde, eccome. --Antonio1952 (msg) 21:53, 2 apr 2024 (CEST)

ML o VRTS e richiesta chiarimento

Dato che ci devono essere discussioni interne, meglio creare una nuova ML, così i membri dell'ArbCom possono ricevere e commentare casi internamente, rispetto all'avere un indirizzo mail @wikimedia (VRTS). Inoltre andrebbe imho chiarito il significato di edit non automatici/automatizzati. --Superpes15^(talk) 15:17, 1 apr 2024 (CEST)

[@ Superpes15] servirebbe comunque un indirizzo e-mail del tipo arbcom-it@wikimedia.org (che rimane distinto da VRTS) per consentire comunque a utenti esterni all'ArbCom di comunicare con esso? Ho visto su Meta che tutti gli ArbCom attualmente in forza hanno un indirizzo di contatto di questo tipo. Edit non automatici/automatizzati sono gli edit che avvengono tramite i nuovi tool, del tipo "collegamenti suggeriti" eccetera. Credo siano già etichettati in qualche modo.--SuperSpritz^{l'adminalcolico} 18:43, 1 apr 2024 (CEST)

[@ Superspritz] L'indirizzo dovrebbe essere arbcom-it@lists.wikimedia.org o arbcom-itwiki@lists.wikimedia.org (indirizzo di ML), VRTS è più indicato per comunicazioni interno-esterno che interne con qualche nota privata (tipo per oversight), invece la ML permette entrambi ed è molto più indicata per il lavoro che deve fare l'ArbCom così come qualsiasi altra commissione, infatti credo che tutti gli ArbCom usino email tipo @lists.wikimedia.org e non @wikimedia.org, a memoria solo enwiki aveva una coda VRTS per l'ArbCom, ma è stata chiusa e comunque lì l'ArbCom ha anche altre funzioni! --Superpes15^(talk) 14:51, 2 apr 2024 (CEST)

[@ Superpes15] ho controllato, a parte en.wiki e ru.wiki effettivamente tutti gli ArbCom usano una mailing list del tipo arbcom-xx@lists.wikimedia.org dove xx è il codice della lingua, nel nostro caso "it". Forse conviene già correggere la pagina di bozza.--SuperSpritz^{l'adminalcolico} 17:25, 2 apr 2024 (CEST)

[@ Superspritz] Perfetto, grazie, ora va benissimo, quando arriverà l'ora mi occuperò della parte relativa alla creazione della ML (tutti gli ArbCom eletti saranno owner, in modo che chiunque possa approvare le mail esterne che arrivano) :) --Superpes15^(talk) 17:32, 2 apr 2024 (CEST)

Chiarimento su uno dei requisiti

[@ .mau.] ho una domanda in merito a un punto relativo ai requisiti per la candidabilità: si parla di "non essere soggetto a divieti di partecipazione agli eventi di Wikimedia Foundation, Wikimedia Italia o Wikimedia CH". Sarebbe l'equivalente del requisito per U4C "non avere un divieto di partecipazione agli eventi attivo nell'ultimo anno"? Forse converrebbe allineare la descrizione presente nella bozza proposta a quella dell'U4C che non richiede di specificare il dettaglio dei vari chapter. Che ne pensi? --SuperSpritz^{l'adminalcolico} 18:59, 1 apr 2024 (CEST)

sì, pensavo a una localizzazione che però non ha senso, visto che WMI e WMCH non hanno a che fare con Wikipedia a differenza di WMF. Provo a modificare. -- .mau. ✉ 13:09, 2 apr 2024 (CEST)

Segnalo pure che gli ambiti di competenza escludono la "giurisdizione su azioni ufficiali di Wikimedia Italia e Wikimedia CH o dei loro staff": perché limitare il discorso a WMI e WMCH? --Argeste ^soffia 17:26, 4 apr 2024 (CEST)

Per silenzio-assenso in bozza ho generalizzato, estendendo la cosa a qualunque chapter (e qualunque usergroup). --Argeste ^soffia 17:46, 10 apr 2024 (CEST)

Aspetti operativi

1. Non mi è chiara la necessità di una doppia data annuale di elezioni visto che il mandato dura un anno. Se serve a sopperire le carenze dovute a dimissioni o revoche, allora non capisco la necessità di elezioni suppletive che, se non mi sono perso qualcosa, nessuna delle altre wiki prevede.
2. Normalmente i requisiti per la candidabilità sono più restrittivi o al massimo uguali a quelli per poter votare. In altre parole, chi può essere eletto può anche votare. I requisiti proposti non lo garantiscono. Infatti, un utente potrebbe essere registrato da 1 anno ed aver fatto 150 edit a trimestre oppure 600 edit nei primi 3 trimestri e, in entrambi i casi, essere candidabile ma non poter votare. IMHO, i requisiti vanno uniformati.
3. Se WMF Legal impone criteri simili a quelli per diventare sysop, allora la soglia minima di voti favorevoli per noi non può essere 15 (che mi pare basso a prescindere) ma deve essere pari al ns. Quorum.
4. Non mi è chiaro cosa succede se in una tornata elettorale ci sono più candidati rispetto ai posti disponibili: viene eletto chi ha ottenuto il maggior numero di voti favorevoli o chi ha il miglior quoziente favorevoli/(favorevoli + contrari)?

--Antonio1952 (msg) 22:47, 2 apr 2024 (CEST)

Per precisare, i criteri simili a un'elezione da sysop valgono solo se c'è la possibilità di vedere i contributi cancellati, come è stato indicato qui. C'è una piccola crono della questione qui. A livello tecnico, quando aggiungiamo questo diritto a un gruppo utente, controlliamo se il gruppo utente sia assegnato tramite una procedura simile a una RfA, altrimenti non si può aggiungere, come imposto anche dai SysAdmins. Invece c'è un quorum di almeno 25-30 voti favorevoli in caso di assegnazione di flag avanzati come il CU! Nel nostro caso io pure suggerirei di attenerci al quorum, come già detto sopra, fermo restando che il risultato non deve incidere sul valore del quorum come avviene con le altre elezioni. --Superpes15^(talk) 23:16, 2 apr 2024 (CEST)

m2c sui punti sollevati da Antonio1952:

1. In effetti è vero: la frequenza di voto potrebbe essere allineata alla durata del mandato. Comunque non colgo i vantaggi di una votazione unica. Con due sessioni di votazione all'anno c'è più garanzia che l'ArbCom non si rinnovi tutto insieme (salvo rielezioni), e questo IMHO favorisce una più naturale trasmissione delle prassi operative: se è vero che non è il caso di assumere che le singole decisioni dell'ArbCom facciano giurisprudenza, vincolando in tal modo anche le decisioni future, sicuramente il lavoro può giovarsi dell'esperienza acquisita, che non è sempre facilmente veicolabile mediante linee guida o pagine di aiuto strutturate. Inoltre, più lungo è l'intervallo fra una votazione e l'altra più cresce l'esigenza di elezioni suppletive e più si complica la gestione degli scorci di mandato rispetto ai "periodi sabbatici" (che peraltro finirebbero per essere raddoppiati)
2. Uniformare i requisiti di voto ha senso, soprattutto in termini di semplificazione, e fra i due requisiti mi piacciono più quelli proposti per votare (oltretutto, replicando quelli di Meta non sono neppure una scelta arbitraria). Peraltro, così facendo ci priveremmo della possibilità di eleggere arbitro un utente stimato che per qualche motivo sia stato poco presente nei mesi che precedono il voto (magari perché si è fratturato una mano o è stato impegnato in una missione scientifica in Amazzonia); questo sarebbe una perdita netta per la Comunità, mentre non lo è inibire a quello stesso utente - stimato o meno che sia - la possibilità di votare (a meno di voler pensare che il modo di votare degli utenti che si sono recentemente assentati sia intrinsecamente diverso da quello "medio" degli altri votanti: ma se fosse così si aprirebbero altre domande...). Valutiamo serenamente cos'è meglio fare.
3. Premesso che non so quali siano le richieste di WMF Legal, anche per me una soglia minima di votanti pari a 15 (la bozza dice votanti totali fra favorevoli, contrari e astenuti: quindi non solo favorevoli come per i sysop) è troppo bassa. La aumenterei portandola anche a 25-30, ma senza raggiungere quella per i sysop per un motivo semplice: gli utenti hanno abitualmente a che fare con gli amministratori (nelle cancellazioni, nelle PDC, in WP:RA, etc.) e sono propensi a farsi un'idea e votare, ma ragionevolmente avranno molto meno a che fare con l'ArbCom e quindi la partecipazione al voto potrebbe risentirne.
4. Ma ricordo male o si è stabilito di avere un arbocom a composizione variabile, in modo che possa essere eletto ogni candidato che abbia maturato sufficiente consenso? Io preferisco questa composizione a quella a numero fisso, perché assicura maggiore "diversity" (fra persone che comunque godono della fiducia comunitaria), inibisce il voto strategico per fazioni contrapposte e stimola la partecipazione allargata (se vanno in riconferma tot arbitri che stimo, in caso di ArbCom a numero fisso la mia eventuale candidatura sarebbe in qualche modo a loro contrapposta, per cui potrei avere imbarazzo di farla o semplicemente timore a confrontarmi con loro sul piano elettorale; questo non va bene, IMHO, perché a lungo andare aumenta il rischio di autoreferenzialità dell'ArbCom). --Argeste ^soffia 14:42, 3 apr 2024 (CEST)

[@ Antonio1952] La bozza propone un numero minimo di componenti ma non fissa un "numero massimo di posti disponibili", come fatto notare anche da @Argeste: quindi, io interpreto che se si presentano in 9, mettiamo, e sono eletti tutti e 9, saranno tutti e 9 operativi nell'ArbCom. Come fatto notare da Argeste, questo consente di avere un ArbCom a composizione variabile. Se la comunità ha dato il suo consenso a un candidato, perché farlo "aspettare un turno" solo perché "tutte le sedie disponibili sono occupate", come nel famoso gioco delle sedie musicali? Meglio non porre nessun limite superiore (e questo elimina alla radice il possibile problema da te sollevato). I requisiti di voto, da quanto ho visto, sono stati copiati da quelli previsti per alti ArbCom e per U4C: servono per garantire che chi vota sia una utenza presente nel progetto e non sia un "dormiente" che compare solo al momento della votazione. Idem per i candidati: dovendo valutare operati e dinamiche, è meglio che si tratti di utenze che sono presenti e "aggiornate" su come sta andando il progetto. Altro punto: "criteri simili" non vuol dire "criteri uguali" perché le dinamiche anche di partecipazione tra tipi di elezione diverse possono essere differenti, specie in presenza di requisiti di voto più stringenti (per inciso: anche secondo me sarebbe più semplice uniformarli e anche secondo me i criteri di Meta sono più attuali rispetto a quelli in vigore da noi al momento). Ti faccio anche notare un altro punto, relativo alle elezioni per admin: i requisiti per candidarsi prevedono di essere utenze autoverificate, ma questo non comporta che possono votare solo gli autoverificati, quindi l'omogeneità tra "requisiti di candidatura" e "requisiti di voto" c'è già adesso solo fino a un certo punto. Detto questo, anche secondo me potrebbe essere ragionevole alzare il numero minimo di votanti (dalla nota in bozza, ho visto che il "15" è uscito come calcolo di media rispetto agli altri ArbCom, se ci fai caso nella maggior parte delle wiki, 8 su 11 se conto gli ArbCom elencati su Meta, non è richiesto nemmeno un quorum minimo di votanti per l'ArbCom, per inciso; però alzare a 20-25 potrebbe anche starci).--SuperSpritz^{l'adminalcolico} 15:42, 3 apr 2024 (CEST)

• Punto 2: @Superspritz, è normale che i requisiti di candidabilità siano più restrittivi rispetto a quelli di voto per cui avviene che un deputato trentenne possa votare per eleggere il presidente della Repubblica ma non possa essere candidato/eletto a tale carica; similmente un utente non autoverificato può votare per l'elezione di un sysopo ma non si può candidare a tale incarico. Io avevo fatto notare che, con i criteri proposti, può succedere il contrario e cioè che un utente possa candidarsi senza aver soddisfatto i requisiti necessari per poter votare.
• Punto 3-4: Il combinato disposto del numero illimitato di eleggibili, del basso quorum e dell'efficacia anche dei voti astenuti comporta che possono bastare 4 voti favorevoli, 1 contrario e 10 astenuti per essere eletti (al limite anche 1 favorevole e 14 astenuti).

--Antonio1952 (msg) 23:23, 3 apr 2024 (CEST)

[@ Antonio1952] il numero minimo di votanti si può alzare, il quorum però resterebbe dell'80% dei favorevoli. Facendo brain storming, mi verrebbe da dire che per evitare i casi limite da te descritti, un'alternativa drastica potrebbe essere escludere gli astenuti dal computo dei votanti, che equivale a non prevedere proprio o ignorare in toto il voto di astensione. Oppure, dato un numero di votanti minimo pari a 15 (ma per me sarebbe meglio alzare a 25), richiedere di ottenere almeno "X" voti favorevoli sul totale dei votanti per considerare valida l'elezione, fermo restando il quorum generale dell'80%; questo sarebbe più simile al sistema che usiamo adesso per gli admin, dove serve comunque un numero minimo di "sì" ed eviterebbe gli scenari limite da te individuati. Ci sarebbe anche una quarta possibile soluzione: non avendo pregressi per poter calcolare un "quorum minimo dinamico di voti favorevoli" come si fa adesso per l'elezione degli admin, si potrebbe pensare di adottare il sistema a "quorum minimo di voti favorevoli fisso" per le prime tornate di elezioni per poi passare, una volta che ci sia una "base storica", a un sistema simile a quello usato per gli admin, legato anche al livello di partecipazione complessivo (nota: in alcune wiki, non è previsto nemmeno un numero minimo di votanti e il quorum di eleggibilità è il 50%+1 dei voti, quindi molto più "lasco" di quanto si sta discutendo qui).--SuperSpritz^{l'adminalcolico} 23:43, 3 apr 2024 (CEST)

Sull'ultima questione, io sarei per l'ultima soluzione proposta da [@ Superspritz]: un numero fisso per le prime tornate, per poi passare a un valore calcolato in modo analogo a quanto facciamo per le elezioni degli admin--Parma1983 23:46, 3 apr 2024 (CEST)

D'accordo con quanto scritto qui su da Parma1983. Dopo la prima tornata di votazioni, si può passare al numero variabile.

Riguardo al numero dei componenti dell'ArbCom, gli organismi di tutte le altre wiki hanno un numero fisso di componenti per cui non mi sembra praticabile l'ipotesi che si vorrebbe portare avanti qui.

Sempre a proposito di altre wiki, nessuna prevede l'obbligo di motivare il voto contrario e anzi alcune, tra cui la francese che si era detto di prendere come modello, addirittura vietano i commenti. --Antonio1952 (msg) 12:12, 4 apr 2024 (CEST)

[@ Antonio1952] in realtà en.wiki ha un numero massimo di componenti (15) ma non un numero fisso, nemmeno cz.wiki non ha un numero fisso ("number of seats varies with the number of active users"), la stessa fr.wiki ne elegge "cinque per volta" ma non stabilisce nel suo regolamento un numero massimo di componenti. Quindi, non è che proprio tutte le wiki hanno un numero fisso (nl.wiki ha un numero massimo di 7 ma in questo momento ci sono solo 4 arbitri, per esempio). Comunque nulla vieta, dopo un'eventuale partenza dell'ArbCom, di fissare in corso d'opera eventuali "tetti", dato che non sappiamo ancora quanto sarà "affollata" la fase di candidatura; più facile, in questa fase, stabilire un minimo, per il massimo o fisso si può vedere in seguito.--SuperSpritz^{l'adminalcolico} 12:43, 4 apr 2024 (CEST)

Hai ragione, sono stato impreciso: dovevo scrivere che tutte hanno un numero "massimo".

Ciò doverosamente premesso, segnalo che qui leggo che fr.wiki ha 10 membri eletti in due tornate, a marzo e a settembre, e durano in carica un anno; in ogni tornata vengono eletti 5 membri.

Cz.wiki ha un numero massimo di arbitri che può variare in base al numero degli utenti attivi secondo questa fantastica formula $\left\lfloor {\frac {1}{2}}+{\sqrt {23+{\frac {n}{15}}}}\right\rfloor$ ma certamente non in base a quanti utenti si sono candidati. --Antonio1952 (msg) 13:12, 4 apr 2024 (CEST)

Da dove diavolo abbiano tirato fuori questa formula, come facciano a stabilire il valore di $n$="active users" (diverso da "registered users") e come definiscano "active" lo sanno solo loro...--SuperSpritz^{l'adminalcolico} 13:16, 4 apr 2024 (CEST)

È peggio perché sono gli utenti molto attivi e cioè gli utenti attivi con più di 100 modifiche. Forse li conteranno prima di ogni elezione! --Antonio1952 (msg) 15:06, 4 apr 2024 (CEST)

Mi piace!!! Adottiamolo anche da noi!!! Ovviamente, [@ Antonio1952], ti offri tu per fare il calcolo a ogni elezione, vero? O:)--Parma1983 15:14, 4 apr 2024 (CEST)

Per la serie: l'ArbCom non ci ruberà tempo alla scrittura dell'Enciclopedia! --Antonio1952 (msg) 15:27, 4 apr 2024 (CEST)

La proposta di partire senza un valore massimo non è proponibile perché per ora non c'è ancora consenso a non introdurlo, dopo ci vorrebbe un consenso più forte per modificarlo. --Antonio1952 (msg) 15:17, 4 apr 2024 (CEST)

Proprio da miglior risultato funzionale con il minore sforzo possibile". --Torque (scrivimi!) 15:23, 4 apr 2024 (CEST)

[× Conflitto di modifiche] [@ Antonio1952] Al momento però l'unico utente che ha mosso una obiezione su questo aspetto sei tu... Ad ogni modo, vedendo che il numero massimo previsto tra le varie wiki è 15 membri, si potrebbe partire con qualcosa del tipo "è composto da almeno 7 arbitri e al massimo da 15", però poi bisogna stabilire con che criterio si escludono gli arbitri "extra massimo", se dovesse capitare. Sulla base del numero di voti, eleggendo solo quelli più votati? Questo diverrebbe un punto in più su cui stabilire un consenso iniziale.--SuperSpritz^{l'adminalcolico} 15:26, 4 apr 2024 (CEST)

Non entro nel merito del dibattito. Solo per info, segnalo l'esistenza della parola magica (aiuto:parole magiche) {{NUMEROUTENTIATTIVI}} per contare gli attivi. Al momento sono 7 859. —Super • nabla^🪰 15:28, 4 apr 2024 (CEST)

Immagino che non fosse stato pensato un numero massimo per evitare competizioni tra i vari aspiranti al ruolo. Personalmente non credo che saranno in tantissimi a candidarsi, se non forse la prima volta, anche perché non mi aspetto una mole di lavoro tale da giustificare la presenza di tanti membri nella commissione. Il massimo di 15 membri mi pare comunque possa andare bene e secondo me difficilmente lo supereremmo nelle candidature, ma, nel caso, si potrebbe pensare di escludere chi raggiungesse il minor valore nella differenza tra i voti favorevoli e i voti contrari--Parma1983 15:29, 4 apr 2024 (CEST)

@Super nabla, quel numero è presente anche nella Pagina principale ma comprende tutti quelli che hanno fatto 1 edit negli ultimi 30 giorni, non solo quelli che ne hanno fatto almeno 100. --Antonio1952 (msg) 15:47, 4 apr 2024 (CEST)

Con i 7686 "utenti attivi" di SuperNabla la "formula ceca" dà un massimo di 23 arbitri. Con la stessa formula il tetto a 7 arbitri (che è il minimo cui ci stiamo orientando) corrisponde a 390 utenti attivi, il tetto a 15 arbitri equivale a circa 2800 utenti attivi.

Ad ogni modo non colgo proprio alcun vantaggio a fissare un tetto al numero di arbitri, quale che sia: né di tipo procedurale (perché richiede di inventare un metodo di ordinamento dei candidati, mette in crisi il concetto di elezioni suppletive, senza che sia eliminata la loro necessità), né di tipo pratico (qualunque sia la dimensione dell'ArbCom, il numero di arbitri designati per affrontare ciascun "caso" andrebbe determinato e potrebbe essere sempre pari a 3 o 5; l'esperienza di altre wiki come ad es. quella francofona mostra che il rischio non è tanto l'abbondanza di arbitri ma la loro penuria), né di tipo concettuale (più largo è l'arbcom meno gli arbitri si sentono investiti della missione di mettere a posto it.wp bypassando la comunità, e questo secondo me è una garanzia per tutti ed è anche il motivo per cui l'idea dell'arbcom in passato era stata accantonata). --Argeste ^soffia 15:50, 4 apr 2024 (CEST)

@Argeste, la formula si riferisce ad utenti con almeno 100 edit, quindi un sottoinsieme degli "utenti attivi" (per i cechi sono 106 su 2426). --Antonio1952 (msg) 16:08, 4 apr 2024 (CEST)

Francamente non vedo la necessità di un tetto massimo. Negli Arbcom à la en.wiki la necessità nasce dall'avere un collegio funzionante, cosa impedita naturalmente da un numero eccessivo di arbitri. Ma se adottiamo il modello di fr.wiki con un collegio a composizione variabile, a che serve un tetto massimo, scusate? Più arbitri in circolazione significa maggiore rotazione, minore potere in capo al singolo arbitro, maggiore condivisione delle decisioni e delle prassi, insomma meglio sarà. Che bisogno abbiamo di creare burocrazia inutile con la creazione di "ideonei non beneficiari" come nei concorsi italiani?

Teniamo conto tra l'altro che la natura delle elezioni se si fissa un tetto massimo cambia profondamente. Si passerebbe infatti ad elezioni competitive, in cui si affronteranno vari sostenitori di uno o dell'altro candidato. Insomma, si vanno a creare naturalmente dei partiti wikipediani. A me non sembra affatto una direzione desiderabile. Per rispondere alla preoccupazione di Antonio di arbitri eletti con un consenso ridotto, credo sia molto meglio ragionare su alti quorum di voti favorevoli (40-50? Parlo di numeri assoluti ovviamente) ----Friniate^Arengo 17:10, 4 apr 2024 (CEST)

[@ Antonio1952] questo fa sì che attualmente l'arbcom dei cechi conta fino a 5 arbitri. è un numero bassissimo che non è compatibile con l'idea che chi valuta le singole richieste debba essere un collegio ristretto, anonimo e senza conflitto di interessi perché la composizione minima di questo collegio ristretto è di 3 arbitri e i due restanti non in tutti i casi possono bastare ad assicurare assenza di COI e anonimato. Siamo certi che invece i cechi non prevedano che ogni caso sia valutato dal plenum del loro arbcom? e comunque, che succede se il plenum è in numero pari? Tutti questi casi sono risolvibili ma aggiungendo artifici ad artifici rispetto allo "schema .mau", che già non è semplicissimo e che eviterei di ingarbugliare più del necessario. E invece la tua proposta di fissare un tetto massimo mi suona un po' troppo vicina all'avvitamento burocratico.

Sul resto quoto Friniate (anche se continua a conflittarmi). --Argeste ^soffia 17:13, 4 apr 2024 (CEST)

Anche secondo me è meglio non specificare un numero massimo. 7 arbitri minimi servono a garantire la funzionalità dell'organo, creando un tetto il rischio maggiore, a parte la ulteriore complicazione delle linee guida, sarebbe la probabile competizione tra utenti, di cui non abbiamo bisogno. --Hominis Scrivimi 01:18, 5 apr 2024 (CEST)

Numero di componenti

Per i motivi espressi nella sezione precedente (e che condivido) le linee guida non stabiliscono un numero fisso di arbitri, ma si limitano a indicare il numero minimo, che è quello necessario ad assicurare la funzionalità all'organo. Il presupposto è che se il numero di arbitri sceglie sotto la soglia minima, l'ArbCom non possa funzionare bene.

In bozza leggo: "è composta da almeno 7 membri" e, più avanti, "indice un'elezione straordinaria quando ritiene che il numero di arbitri sia insufficiente a garantirne il regolare funzionamento". Seguono due questioni:

1. Ci sono ragioni che sconsigliano di fissare a 7 il numero minimo di arbitri, oppure possiamo mantenere questo numero lasciando decadere le ipotesi di un minimo di 9 o 11 componenti? Io direi che con 3 arbitri, +1 uno per assicurare l'anonimato al collegio di arbitri designati, più altre due-tre riserve disponibili in caso di questioni che vedano direttamente coinvolto qualche arbitro tanto da decretarne l'incompatibilità, siamo a posto. Per cui non vedo il motivo di prevedere un minimo più alto di 7 (un ArbCom numeroso è meglio di uno piccolo, ma finché un ArbCom piccolo è in grado di funzionare va sempre preferito a nessun ArbCom)
2. La scelta di indire un'elezione straordinaria è demandata all'ArbCom stesso, e questo vale - stando a quello che leggo in bozza - anche qualora i componenti siano meno del minimo. Confermiamo questa impostazione o vogliamo introdurre un automatismo? Ndel complesso, ritengo si possa evitare di irrigidire il sistema: supponiamo che 2-3 settimane prima dell'elezione regolare si dimetta un arbitro e il numero di quelli in carica sia uno meno del minimo. In circostanze siffatte costringere a un'elezione straordinaria può essere poco opportuno, visto che per un periodo breve l'ArbCom è comunque in grado di funzionare ad es. con 6 arbitri anziché 7. --Argeste ^soffia 16:49, 3 apr 2024 (CEST)

Commento brevemente per punti:

1. Io terrei il minimo a 7.
2. No, non imporrei automatismi, per non vincolare troppo il funzionamento dell'ArbCom (in certi momenti potrebbe ad esempio funzionare senza problemi anche con meno membri attivi)--Parma1983 17:00, 3 apr 2024 (CEST)

• Come Parma, anche io terrei il minimo a 7 e lascerei anche io che sia l'ArbCom a decidere se, nel caso finisse "sotto quota minima", può ancora funzionare oppure no, in base anche a WP:BUON SENSO.--SuperSpritz^{l'adminalcolico} 17:23, 3 apr 2024 (CEST)

• 7 mi sembra un numero ragionevole, ne ridotto ne eccessivo, per i motivi sopra argomentati da Argeste. Non trovo che i casi in cui dovrebbero intervenire siano frequentissimi, ma all'occorenza il numero potrà essere ridiscusso e aumentato in futuro. --Torque (scrivimi!) 12:31, 4 apr 2024 (CEST)

Bene, grazie: visto che una decisione serve (e che comunque stiamo ragionando in bozza), riporto 7 ritenendo non necessario tenere traccia della possibilità di ripensarci. --Argeste ^soffia 13:44, 4 apr 2024 (CEST)

Firma nelle comunicazioni dell'ArbCom

Intanto grazie a .mau. per la pagina che mi sembra molto ben fatta, chapeau. C'è una cosa che non mi è chiara. Qui e lì si usa l'espressione «a firma "Commissione di Arbitraggio"» per le comunicazioni pubbliche dell'ArbCom. L'idea è che di volta in volta un membro dell'ArbCom scelto come portavoce pubblichi nella pagina di servizio dedicata utilizzando la sua utenza e lo faccia a nome di tutti oppure che ci sia una sorta di utenza condivisa? Se è un utenza membro dell'ArbCom a scrivere a nome di tutti, deve essere uno dei designati (per lo specifico caso)? L'idea, se ho capito bene, è che i membri dell'ArbCom siano noti, ma non siano noti quelli appartenenti al sottoinsieme dei membri chiamati a decidere su un singolo caso. Se è vero (cioè se ho capito bene), non è meglio che le comunicazioni le pubblichi (con la sua utenza) un membro non designato, cioè uno di quelli che non partecipa alla decisione finale (punto 3 della sezione "Processo di analisi")? --Amarvudol (msg) 18:25, 3 apr 2024 (CEST)

Credo ci siano dei tool che consentono di inserire tale tipo di comunicazione (se non vado errato, qualche amministratore dell'interfaccia potrebbe esser più preciso di me), qualcosa di analogo ai tool che si usano per esempio per le revisioni delle bozze ma che consentono di mettere una "firma" di questo tipo.--SuperSpritz^{l'adminalcolico} 18:29, 3 apr 2024 (CEST)

Aggiustamento dei requisiti

Come fatto giustamente notare da [@ Antonio1952], i requisiti per essere candidati in almeno un punto sembrano essere più "laschi" rispetto ai requisiti richiesti per poter votare. Proporrei quindi di aggiustare questo punto:

• essere registrato su Wikipedia in lingua italiana da almeno 365 giorni alla data della candidatura e avere un'attività di almeno 600 contributi validi e non automatici/automatizzati su Wikipedia in lingua italiana nei 365 giorni precedenti la data di candidatura

per allinearlo ai requisiti Meta per gli steward, aggiungendo la parte in corsivo:

• essere registrato su Wikipedia in lingua italiana da almeno 365 giorni alla data della candidatura e avere un'attività di almeno 600 contributi validi e non automatici/automatizzati su Wikipedia in lingua italiana nei 365 giorni precedenti la data di candidatura di cui almeno 50 eseguiti nei sei mesi precedenti la data di candidatura

Pareri? --SuperSpritz^{l'adminalcolico} 14:58, 4 apr 2024 (CEST)

Ovviamente Favorevole anche se sostituirei "365 giorni" con 1 anno per tener conto che ci sono gli anni bisestili. --Antonio1952 (msg) 15:30, 4 apr 2024 (CEST)

Favorevole--Parma1983 15:31, 4 apr 2024 (CEST)

[@ Antonio1952] "un anno" è ambiguo; potrebbe essere interpretato come "l'anno di calendario precedente (1º gennaio-31 dicembre)" e non come i "365 giorni precedenti la data della candidatura". "365 giorni" indica un intervallo temporale fisso che non tiene conto del posizionamento rispetto al calendario, se non come puro "conto alla rovescia", esattamente come i "trenta giorni" (per esempio per le bozze abbandonate o dall'avvio di una procedura di cancellazione) non tengono conto della durata dello specifico mese in corso. Da un punto di vista di riferimento temporale, è più preciso e in qualche modo assoluto (vale qualsiasi sia il calendario adottato).--SuperSpritz^{l'adminalcolico} 16:22, 4 apr 2024 (CEST)

Nella versione di Antonio (da un anno vs. da 365 giorni) io non ravviso ambiguità.

Però se dobbiamo adeguarci ai requisiti per l'elettorato attivo tanto vale uniformare in toto, incluso il criterio dei "600 edit raggiunti tre mesi prima" --Argeste ^soffia 17:24, 4 apr 2024 (CEST)

Favorevole --ʍayßɛ⁷⁵ 17:25, 4 apr 2024 (CEST)

@Superspritz, vedo che ti sei convinto da solo. --Antonio1952 (msg) 00:07, 5 apr 2024 (CEST)

Ho modificato la formulazione dei requisiti per la candidatura perché equivocabile e l'ho uniformata a quella dei requisiti di voto.

In dettaglio, ho sostituito la frase "600 contributi ... raggiunti nei tre mesi precedenti la data di candidatura" con "600 contributi ... raggiunti tre mesi prima della data di candidatura".

Poi, se vogliamo uniformare ancora di più, sostituirei data di candidatura e data di inizio della votazione con data di avvio della sessione di elezione cioè il primo giorno della 4 settimane di durata dell'intero meccanismo. --Antonio1952 (msg) 18:12, 5 apr 2024 (CEST)

Sono favorevole all'ulteriore aggistamento unificatore proposto da Antonio1952. --Argeste ^soffia 02:40, 6 apr 2024 (CEST)

giurisdizione

Il paragrafo "ambito di competenza" mi sembra parzialmete contraddittorio laddove dice dapprima che l'Arbcom non ha giusdizione su comportamenti esterni a it.wiki e poi dice che invece ce l'ha. Si noti che le enforcement guidelines dell'Ucoc invece prevedono esplicitamente che vadano perseguite le "off-wiki" violations (Reports shall be capable of covering UCoC violations, whether they happen online, offline, in a space hosted by a third party, or a mix of spaces ), non solo come aggravante come pare dire la nostra bozza, ma da subito. La nostra bozza mi sembra quindi al momento in parziale violazione delle linee guida globali. Pertanto toglierei semplicemente il punto 4 e riformulerei la parte sotto in "La Commissione di Arbitraggio è competente anche sulle violazioni dell'Ucoc generate da comportamenti esterni a Wikipedia in lingua italiana, se questi hanno o possono avere un impatto o conseguenze negative su Wikipedia in lingua italiana o sui suoi contributori." ----Friniate^Arengo 18:10, 4 apr 2024 (CEST)

In effetti il punto 4 è in contraddizione con quanto prevede UCoC e anche con la frase immediatamente successiva. Favorevole nel rimuoverlo. Non sarebbe addirittura il caso di spostare questa frase nella sezione "Funzioni" oppure basta la precisazione nell'ambito?--SuperSpritz^{l'adminalcolico} 18:13, 4 apr 2024 (CEST)

Più che propriamente "perseguire" le violazioni off-wiki l'ArbCom - e non solo quello visto che l'UCoC impegna tutti - ne tiene conto e ne prende atto ai fini delle proprie determinazioni nei termini, come ben detto sopra, in cui queste abbiano avuto o possano avere impatto su it-wiki e sui suoi partecipanti. Ove peraltro condotte gravi vengano direttamente segnalate, con le opportune garanzie di riservatezza, all'ArbCom questo potrà disporre il blocco dell'utente autore della violazione (e di tali risultanze, auspicabilmente, si dovrebbe tenere conto a livello globale Wiki).--TrinacrianGolem (msg) 20:12, 7 apr 2024 (CEST)

La sezione "Giurisdizione" in realtà dice più ciò di cui l'ArbCom non si occupa (i tre punti elenco) che ciò di cui si occupa (solo l'ultima frase). Concordo quindi con l'idea di razionalizzare la sezione in relazione con la precedente, includendo le "violazioni dell'UCoC generate da comportamenti esterni" a it.wiki ma con impatto su di essa, fra le funzioni dell'Arbcom, e trasformando quindi ciò che resta di "Giurisdizione" (termine che non mi convince appieno) in una sottosezione se non nella prosecuzione della sezione precedente. --Argeste ^soffia 23:49, 7 apr 2024 (CEST)

Commissione arbitrale, non d'arbitraggio

"Arbitraggio" ha un significato specifico in italiano, diverso da arbitrato. In particolare, l'arbitraggio non è un metodo di soluzione delle controversie, ma di determinazione dell'oggetto del contratto. Questa commissione dovrebbe quindi chiamarsi "Commissione Arbitrale", a meno di non cercare soluzioni più fantasiose e sorprendenti, nel qual caso avrei dei suggerimenti da fare ;-). --151.68.69.63 (msg) 10:03, 6 apr 2024 (CEST)

Anche io avrei un suggerimento da fare: tradurre il nome usato per questo organismo nelle altre wiki, per esempio "Comité d'arbitrage", "Arbitration Committee" ecc. ecc. Ci sono altre cose ben più serie su cui discutere su questo argomento che non inventarsi un nome diverso da tutte le altre wiki basandosi su definizioni leguleie da codice civile che non si applicano a Wikipedia (che è una enciclopedia). Per le sorprese: Pasqua, per quest'anno, è già passata.--SuperSpritz^{l'adminalcolico} 14:44, 6 apr 2024 (CEST)

Visti tutti gli aspetti da definire, anche a me sembra intempestivo occuparsi adesso del nome. Ad ogni modo, visto che l'acronimo "WP:CdA" suona molto male, se vogliamo salvare l'abbreviazione "WP:ArbCom" allora meglio avere due sole parole come in "commissione arbitrale" (in sigla, anche WP:CA). --Argeste ^soffia 23:41, 7 apr 2024 (CEST)

PS: Approfitto per plaudere alla proposta di "commissione" anziché "comitato" che potrebbe parimenti ingenerare confusione.

Procedimenti: Punti da chiarire su "chi può ricorrere all'ArbCom"

Nella bozza proposta non sono chiari due punti chiave, anche se uno è implicito nella descrizione delle funzioni e competenze: chi può ricorrere all'ArbCom? I punti riguardano utenze non registrate IP anonimi) e utenze terze. Io proporrei quanto segue:

1. Per le utenze non registrate, va tenuto presente che i blocchi per procedure comunitarie vengono emessi solo nei confronti di utenze registrate; gli utenti anonimi ossia gli IP non si possono comunque bloccare indefinitamente e in ogni caso le procedure comunitarie non si aprono nei confronti di IP. Proporrei quindi di allinearci a quanto fa l'ArbCom di de.wiki, de:Wikipedia:Schiedsgericht/Regeln#Stellen einer Anfrage che dice esplicitamente quanto segue:

(DE)

«Anfragen an das Schiedsgericht können grundsätzlich nur von angemeldeten Benutzerinnen oder Benutzern gestellt werden»

(IT)

«Le richieste al tribunale arbitrale possono essere presentate solo dagli utenti registrati»

(de:Wikipedia:Schiedsgericht/Regeln#Stellen einer Anfrage)

2. Per le utenze terze: non consentire che, viste le funzioni previste per l'ArbCom, possa fare ricorso una utenza non direttamente coinvolta. Sarebbe inoltre opportuno far osservare, magari con una nota, che per quanto riguarda le violazioni dell'UCoC, le policy già in forza su it.wiki consentono già adesso segnalazioni da parte di utenze sia terze che non registrate (es. vandalismi in corso, segnalazioni di copyviol, richieste di pareri sui comportamenti, segnalazioni di problematicità), il che è conforme a quanto prescrive l'UCoC che richiede che in generale queste violazioni possano essere segnalate anche da utenze non direttamente coinvolte, mentre per quanto riguarda gli ArbCom e gli appelli consente che siano i singoli progetti a stabilire i "paletti" per i ricorsi (vedi linee guida). Si potrebbe eventualmente ammettere come unico caso di segnalazione ammissibile da parte di utenze terze, purché registrate (e non bloccate?), di eventuali comportamenti off-wiki non conformi a UCoC (tramite mail all'ArbCom?) e che possano arrecare potenziali danni a utenti attivi o al progetto.

Mi sembra sia un chiarimento essenziale, che oltretutto è perfettamente coerente con i punti riportati nel paragrafo "Funzioni". Pareri? --SuperSpritz^{l'adminalcolico} 17:39, 7 apr 2024 (CEST)

Concordo su entrambi i punti. Per quanto riguarda gli IP l'esclusione mi pare pacifica (e per gli eventuali casi di errore esistono già rimedi). Per i registrati, vista la natura di ArbCom, il coinvolgimento dell'utenza deve essere condizione di procedibilità (anzi, dove un'utenza terza e non coinvolta adisse impropriamente l'ArbCom, fermi restando i casi di sockpuppetting con il relativo accertamento, andrebbe valutato ed eventualmente sanzionato l'abuso di pagina di servizio). Abbiamo già sufficienti strumenti (UP, RdP, pagine di segnalazione ed in ultimo anche il canale delle mail dirette agli admin) per quei casi in cui un'utenza terza si trovi a segnalare violazioni UCoC. Sull'ultimo punto - quello relativo a condotte off-wiki lesive del progetto e/o degli utenti - dovremmo IMHO definire una policy apposita, fermo restando che - ove segnalate in riferimento a controversie sottoposte all'ArbCom - andrebbero portate comunque a conoscenza dello stesso ArbCom. Tale policy sarebbe utile anche nella considerazione della "delicatezza" e della potenziale violazione della privacy delle utenze che siano, in ipotesi, oggetto di doxing ed altre condotte gravi, onde evitare di aggravare gli effetti della violazione per un verso e, per l'altro, garantire l'irrogazione delle necessarie sanzioni nei confronti di chi si sia reso autore di tali condotte.--TrinacrianGolem (msg) 18:22, 7 apr 2024 (CEST)

Mah, non vedo perché complicarci la vita sinceramente, come sottolinei, Ucoc prevede che le segnalazioni di violazioni possano essere fatte anche da terzi, mi sembra un avvitamento burocratico senza particolari vantaggi permettere di accedere alle UP ma non all'Arbcom. Diverso è il caso dei ricorsi su cui concordo (e che sarebbe coerente col meccanismo di revisione dei blocchi che prevede anch'esso che possano intervenire solo i diretti interessati). ----Friniate^Arengo 21:43, 7 apr 2024 (CEST)

[@ Friniate] In realtà non è proprio così; probabilmente la bozza va riorganizzata per esplicitare meglio il tutto. Qua si sta parlando di "ricorsi contro i blocchi", che già adesso non sono previsti da parte di utenze terze. Per segnalazioni che sono di carattere pubblico, ossia non coinvolgono particolari aspetti di privacy o di riservatezza, già adesso i terzi possono segnalare violazioni dell'UCoC tramite le procedure già esistenti. E anche la comunità può richiedere in modo esplicito l'intervento dell'ArbCom (è il caso descritto come "procedure di UP in cui la comunità rimane in qualche modo in stallo", in tal caso l'esito della procedura di UP può essere, per consenso comunitario, chiedere l'intervento dell'ArbCom come escalation per casi particolarmente spinosi) e anche qua la procedura potrebbe essere stata iniziata tranquillamente da una utenza "terza". Quello che è già presente in bozza, ma forse non è molto chiaro, è che è prevista (nel paragrafo "Richieste di valutazione di violazioni dell'UCoC") la possibilità di contattare in modo riservato l'ArbCom via e-mail se ci sono coinvolti aspetti relativi a specifici problemi di riservatezza, privacy eccetera. Questo può farlo chiunque (purché sia una utenza registrata e non bloccata, direi: se è bloccata, deve prima fare appello di sblocco), anche un terzo. Ma non si tratta di un "ricorso" quanto di un "segnalare all'ArbCom". Magari questo punto non è descritto in modo chiaro, senza aggiungere nulla a quanto già presente adesso ma riorganizzando meglio i contenuti, dovrebbe tornare tutto.--SuperSpritz^{l'adminalcolico} 23:21, 7 apr 2024 (CEST)

Ah ok, avevo capito male allora. Sì, credo che vada scritto meglio il paragrafo sulle funzioni allora. ----Friniate^Arengo 23:29, 7 apr 2024 (CEST)

Quorum per la validità dell'elezione

La versione proposta prevede che ciascuna votazione sia valida se sono stati espressi "almeno 15 voti validi, astenuti compresi".
Come già scritto anche da altri utenti, mi sembra una soglia molto bassa oltre che illogica, visto che gli astenuti non vengono computati quando si calcola la percentuale dei voti favorevoli.
La proposta è quindi quella di utilizzare un sistema analogo a quello che regola le votazioni dei sysop e cioè stabilire che:

«una votazione ha esito positivo se gli utenti favorevoli sono in numero maggiore o uguale al "quorum richiesto" e almeno pari all'80% dei partecipanti complessivi alla votazione al netto degli astenuti (ossia considerando solo favorevoli e contrari)».

Per tener conto della paventata possibilità che le elezioni dell'ArbCom suscitino meno interesse di quelle dei sysop e quindi vedano una partecipazione ridotta di utenti, il "quorum richiesto" potrebbe venir calcolato di volta in volta come si fa per quello dei sysop ma tenendo conto solo delle votazioni relative all'ArbCom. La formula potrebbe essere questa: $Q=\left\lfloor {\frac {4}{5}}\cdot {\frac {x_{1}+x_{2}+x_{3}+x_{4}+x_{5}+x_{6}+x_{7}+x_{8}}{8}}\right\rfloor =\left\lfloor {\frac {1}{10}}\sum _{i=1}^{8}x_{i}\right\rfloor$

dove $x_{i}$ è il numero degli utenti favorevoli e contrari in ciascuna delle ultime otto votazioni ArbCom conclusesi con esito positivo. Le otto votazioni sarebbero quelle più recenti in ordine di momento di avvio (giorno/ora/minuto) e, a parità, in ordine di momento di presentazione della candidatura (giorno/ora/minuto).
N.B.: Ho modificato il coefficiente iniziale da 2/3 a 4/5 perché nelle votazioni per l'ArbCom la percentuale minima dei voti favorevoli è sempre e solo dell'80% (per i sysop scende ai 2/3 in caso di votazione di riconferma).
Per la prima sessione di votazioni, ritenendo che l'effetto novità porterà comunque ad un'elevata partecipazione al voto, penso che si possa partire dal quorum attualmente in vigore per i sysop e cioè 48. --Antonio1952 (msg) 23:03, 7 apr 2024 (CEST)

Sul metodo di calcolo del quorum per le sessioni a regime, il sistema variabile adottato per gli admin mi pare valido. Per la prima (e le due successive, in modo da dare il tempo di stabilizzarsi meglio alle procedure), il numero di 15 mi pare decisamente basso, ma 48 un po' troppo alto. Terrei un valore prudenziale di 35 o al massimo 40--Parma1983 02:01, 8 apr 2024 (CEST)

Concordo anche io che a regime la formula proposta da [@ Antonio1952] vada più che bene. Per le prime elezioni però anche a me il quorum attuale per gli amministratori sembra troppo alto. Non sono sicuro del cosiddetto "effetto novità", anche perché si sta trattando di una materia e di un organismo abbastanza complesso e onestamente non saprei quantificare con quale "affluenza" verranno accolte le prime candidature. Concordo anche che il "15" attualmente indicato è, viceversa, troppo basso e vedrei meglio un valore prudenziale di 30 o 35 votanti. Proporrei di utilizzare la formula proposta da Antonio a partire dalla terza tornata di elezioni, utilizzando per i dati "mancanti" e fino a raggiungimento del "regime", il valore di quorum fisso usato per le prime due elezioni.--SuperSpritz^{l'adminalcolico} 15:55, 8 apr 2024 (CEST)

@Superspritz, pensi che dopo due tornate non si riescano a raggiungere 8 votazioni valide per cui ci sarà necessità di integrare con un numero fisso? O ho interpretato male io la tua ultima frase? --Antonio1952 (msg) 16:23, 8 apr 2024 (CEST)

Forse ho interpretato male io il meccanismo, se tu stavi considerando il numero di singole votazioni andate a buon fine, allora in effetti la formula potrebbe andare a regime già dalla seconda tornata. --SuperSpritz^{l'adminalcolico} 16:50, 8 apr 2024 (CEST)

Servono 8 votazioni perché il calcolo possa essere effettuato, perciò non si può escludere che possa teoricamente partire già dalla seconda sessione. Tuttavia, secondo me i dati iniziali potrebbero risultare sballati (ad esempio, molto alti o molto bassi), perciò aspetterei comunque una sessione in più per far partire il calcolo a regime--Parma1983 16:54, 8 apr 2024 (CEST)

Forse, anche dalla prima votazione, basta mettere $x_{1}=...=x_{8}=30$ (se si vuole 30 come quorum), poi i $x_{i}$ assumeranno il valore storico via via che si vota. --Amarvudol (msg) 17:36, 8 apr 2024 (CEST)

@Amarvudol, se non ho capito male, in ciascuna sessione di voto, le votazioni partono dopo che, alla fine della seconda settimana dedicata alla discussione delle singole candidature, il candidato accetta. Presumo quindi che verranno avviate nel giro di 1/2 giorni al massimo e quindi tutte prima che se ne sia conclusa qualcuna. --Antonio1952 (msg) 18:47, 8 apr 2024 (CEST)

Sì, in ogni sessione tutte le elezioni si svolgono in parallelo e in contemporanea.--SuperSpritz^{l'adminalcolico} 18:51, 8 apr 2024 (CEST)

Mozione d'ordine! :)
Procediamo per step. Prima stabiliamo i valori desiderati in termini di partecipanti assoluti e percentuale di favorevoli e poi eventualmente definiamo formule che siano in grado di generare i valori desiderati lasciandoli però fluttuare in funzione della maggiore o minore partecipazione/ampiezza della comunità, etc. Non mi sembra utile partire dalle formule se siamo già consapevoli che i valori desiderati non sono quelli in bozza.

Al momento, la bozza prevede che il candidato venga eletto se contemporaneamente:

1. votano almeno 15 utenti
2. i favorevoli sono l'80% dei voti espressi (al netto degli astenuti).

Sul punto 1, mi pare che ci sia già consenso per alzare la soglia attuale. Propongo pertanto di modificarla come segue: "almeno 25 voti a favore". Posso procedere? --Argeste ^soffia 20:54, 8 apr 2024 (CEST)

• 25 è troppo basso. Finora, oltre al mio 48, si sono espressi Parma1983 con 35/40, Superspritz con 30/35, Amarvudol con 30 (se si interpreta l'esempio fatto come desiderata) e, analogamente, tu con 25. La media fa 34,6 che, arrotondato per difetto, come si fa per l'altro quorum, diventa 34. --Antonio1952 (msg) 21:47, 8 apr 2024 (CEST)

  (f.c.) 25 al netto di contrari e astensioni non corrisponde a 25 totali, ma a una trentina di voti. --Argeste ^soffia 22:26, 8 apr 2024 (CEST)

  (f.c) Quelli del quorum sysop sono sempre stati solo voti favorevoli e così è riportato nella mia proposta postata all'inizio di questo thread. --Antonio1952 (msg) 22:37, 8 apr 2024 (CEST)

  15 sembrano davvero pochi, ma arrivare sopra i 45 al contrario sembra eccessivo… mi allineerei pure io attorno a 30 --Torque (scrivimi!) 22:10, 8 apr 2024 (CEST)

  25 favorevoli come proposto da Argeste mi sembra un numero ragionevole --Hominis Scrivimi 22:35, 8 apr 2024 (CEST)

  Facendo i conti, 25 favorevoli con un "quorum" all'80% richiederebbe 32 votanti in tutto per candidato nel caso di "elezione al pelo", come fatto notare da Argeste. A me andrebbe bene anche questa soglia per iniziare (25 favorevoli), anche se più bassa rispetto ai 30 di cui parlavo prima. Se si tiene in conto l'ipotesi di qualche voto contrario o astenuto, alla fine non mi sembra un numero poi così basso; personalmente mi aspetto meno partecipazione rispetto alle elezioni dei sysop, proprio perché un ArbCom per sua natura si "interfaccia meno" con gli altri utenti su base quotidiana e forse per la maggior parte della comunità potrebbe essere percepito come "entità distante". Non vedo grossi problemi a partire "cautelativi" senza mettere asticelle troppo alte. Mettere in piedi tutta una macchina per fare l'ArbCom per poi rischiare di dire "scusate, non se ne fa niente" perché non si raggiunge la "soglia di voti" perché abbiamo messo un asticella troppo ottimistica non sarebbe proprio il massimo. Per iniziare, 25 sembra anche a me un buon compromesso di partenza. Se poi la partecipazione è più massiccia del previsto, subentra sempre la formula proposta da Antonio a riequilibrare il tutto, evitando il rischio di rimanere con soglie troppo basse vita natural durante.--SuperSpritz^{l'adminalcolico} 23:13, 8 apr 2024 (CEST)

  La mia impressione è che, nonostante la rilevanza dell'argomento alla maggior parte della comunità, più interessata all'enciclopedia che a cavillosità pseudoleguleie, tutto questo interessi poco, per cui temo che le prime votazioni non avranno una grande affluenza, spero di sbagliarmi. Quindi ritengo che la soglia di 25 favorevoli sia un buon inizio, viceversa sposterei il quorum da 4/5 a 2/3 (ossia 66.6% , magari arrotondato 70%) perché mi sembra uno di quei casi in cui sia molto facile trovare chi si diverte a sparare pallini col Flobert, giusto per il gusto di farlo. --Bramfab (msg) 10:13, 9 apr 2024 (CEST)

  Più che per lo scopo indicato sopra, secondo me abbassare il quorum a 2/3 sarebbe più utile principalmente per incoraggiare le candidature di utenze non admin, che potrebbero essere "intimorite" dal dover ricevere una soglia di gradimento molto elevata e tirarsi indietro nel timore di non farcela.--SuperSpritz^{l'adminalcolico} 10:41, 9 apr 2024 (CEST)

Per me 25-30 è un buon punto di partenza. Sperando che non sia troppo se queste elezioni non susciteranno interesse. --Amarvudol (msg) 11:17, 9 apr 2024 (CEST)

Visto che siamo nell'ambito di "predizioni", io invece sono convinto che ci sarà una corsa a diventare ArbCom sia da parte dei sysop che degli altri utenti.

Poi, visto che quando un utente qualsiasi si candida per il ruolo di sysop affronta il rischio di una percentuale dell'80%, non vedo perché la stessa percentuale debba dissuaderlo dal candidarsi ArbCom né vedo incrementi nel pericolo di "impallinamento" considerando che, al momento, i requisiti di voto sono più restrittivi di quelli sui sysop. --Antonio1952 (msg) 14:20, 9 apr 2024 (CEST)

Sono d'accordo con alcuni dei commentatori precedenti: se si innalza la partecipazione minima (che serve solo a tutelare dal rischio che qualcuno venga eletto solo a causa della "distrazione" della comunità: ma la periodicità delle cadenze elettorali dovrebbe di per sé scongiurare questa eventualità), la percentuale di gradimento può benissimo essere portata dall'80% ai 2/3, sebbene inferiore quella adottata per eleggere i sysop. Anzi, proprio perché i sysop possono agire autonomamente mentre gli arbitri operano collegialmente, sarebbe auspicabile favorire un po' di diversity fra gli eletti: l'abbassamento della percentuale di gradimento va in questa direzione. --Argeste ^soffia 14:39, 9 apr 2024 (CEST)

Certamente l'abbassamento del quorum richiesto dovrebbe anche invogliare una rosa più vasta di candidature. Sulla corsa per diventare ArbCom ho qualche dubbio: non vedo particolari emozioni e corse per "posizioni" superiori a quelle di Admin, se ci sarà ben venga, aumenterà la scelta. --Bramfab (msg) 15:48, 9 apr 2024 (CEST)

Anche per me 15 è troppo basso, come dicevo sopra arriverei a 40-50 circa (avevo fatto anche un calcolo un po' così: quattro quinti dell'attuale quorum degli admin ci porta a 38 che mi pare un buon compromesso). ----Friniate^Arengo 11:26, 10 apr 2024 (CEST)

Valutazione dell'ammissibilità (Fase 1) e procedimento accelerato

Il procedimento standard di valutazione delle richieste pervenute prevede tre fasi, la prima delle quali è definita "Valutazione dell'accettabilità della richiesta".

Ho modificato il testo descrittivo sostituendo "può decidere a sua totale discrezione se accettare o rifiutare di procedere con l'analisi, sulla base della validità attribuita alle motivazioni espresse" con "può decidere a sua totale discrezione se accettare o rifiutare di procedere con l'analisi, sulla base della compatibilità della richiesta con le funzioni e le competenze della Commissione e dell'ammissibilità delle motivazioni espresse".

Ritengo infatti che questa prima fase la Commissione non debba entrare nel merito, altrimenti essa rischierebbe di duplicare le fasi 2 e 3 ("Discussione e analisi della richiesta" e "Decisione finale"). Sarei quasi per enfatizzare il concetto precisandolo in qualche modo, ad es. "sommaria ammissibilità delle motivazioni espresse" (ma cerchiamo un'espressione più felice). --Argeste ^soffia 01:51, 8 apr 2024 (CEST)

Favorevole al testo già modificato, anche senza enfatizzazione :D--Parma1983 02:11, 8 apr 2024 (CEST)

Procedimento accelerato

Prima ancora di descrivere il processo di analisi articolato tre fasi, nella sezione "forme di procedure" è indicata la possibilità di non seguire questo "procedimento standard" (NB: processo, procedimento o procedura? scegliamo un termine univoco?) e adottare un "procedimento accelerato".

Non è chiarito come la Commissione decida quale procedimento adottare, né chi sia chiamato a partecipare alla fase di votazione interna (tutti gli arbitri o solo quelli designati ad hoc?). Faccio presente che non avrebbe molto senso far decidere al 'plenum' i casi banali e a una sottocommissione i casi spinosi.

Per sciogliere la contraddizione ravviso le seguenti possibilità:

1. abolire il procedimento accelerato
2. prevederlo nell'ambito della fase 1 del procedimento standard, in cui cioè tutti gli arbitri possono decidere di dare torto o ragione all'appellante (ma in tal caso devono potersi esprimere non solo con favorevole, contrario o neutrale all'ammissibilità della richiesta)
3. prevederlo solo a valle della designazione degli arbitri in modo che la fase 2 ("discussione e analisi") eviti la richiesta di pareri e commenti (in tal caso essa consterebbe nella mera designazione degli arbitri) e si giunga subito alla fase 3 ("decisione finale", sempre appannaggio dei soli arbitri designati).

--Argeste ^soffia 01:51, 8 apr 2024 (CEST) PS: a latere: è possibile demandare la designazione degli arbitri a una fase ad hoc del procedimento standard, compresa fra la "valutazione iniziale" e la "discussione"?

A una prima lettura, l'avevo inteso come l'opzione 3 (ossia che si saltasse la fase 2), perciò sarei per tale possibilità (ammesso che non si voglia propendere per l'abolizione del procedimento accelerato, su cui non sarei eventualmente contrario). Sono invece contrario all'opzione 2--Parma1983 02:11, 8 apr 2024 (CEST)

Per quanto riguarda il procedimento accelerato, io tenderei a vederlo come utilizzabile per colmare un punto su cui, per ora, la comunità non ha dato consenso, ossia la retroattività per quanto riguarda la revisione di blocchi di lunga durata. Questo per un motivo molto semplice: se si apre alla "retroattività" fino a una data X da stabilire, più è lontana temporalmente l'azione o la situazione che ha portato al blocco, più elevata è la probabilità che gli utenti che erano intervenuti all'epoca non siano più attivi sul progetto e non possano quindi esporre una loro posizione in merito. In tal caso, sulla base di quanto disponibile negli archivi di discussione, l'ArbCom potrebbe decidere, una volta definiti gli arbitri designati, quindi secondo l'opzione "3", di passare subito alla decisione finale (che sarebbe comunque non ulteriormente appellabile, essendo l'ArbCom "di ultima istanza"), se valuta che non ci sia la possibilità di una discussione in cui poter chiedere in modo bilanciato i pareri delle parti coinvolte all'epoca. --SuperSpritz^{l'adminalcolico} 16:19, 8 apr 2024 (CEST)

Aggiustamento del paragrafo "Funzioni"

[@ Friniate, Argeste] Tenendo conto di quanto emerso nelle due discussioni precedenti (discussione "Giurisdizione" e discussione "Procedimenti: Punti da chiarire su 'chi può ricorrere all'ArbCom'"), ho accorpato nella bozza le due sezioni originarie "Funzioni" e "Ambito di competenza" in un unico paragrafo "Funzioni", dove è stato esplicitato meglio:

• che l'ArbCom può intervenire sia su segnalazione che su richiesta della comunità, in quest'ultimo caso solo previo consenso comunitario
• che ha competenza anche sui comportamenti off-wiki contrari all'UCoC se pregiudizievoli o dannosi nei confronti del progetto o di altri utenti attivi nel progetto, intervenendo sempre su segnalazione

Se il testo risultante non fosse ancora sufficientemente chiaro o necessitasse di essere "limato", ben vengano i commenti.--SuperSpritz^{l'adminalcolico} 16:07, 8 apr 2024 (CEST)

Grazie, ieri ho fatto (dimenticandomi di segnalarlo qua) un po' di riscrittura della sezione con lo scopo di renderla più chiara. Le uniche modifica che mi sembrano di qualche rilievo sono:

• indicare fra le casistiche escluse quelle che riguardano, più in generale, i livelli di accesso degli utenti (e non solo sysop e CU), scelta peraltro del tutto in linea con l'esclusione di ciò che non abbia attinenza con l'applicazione dell'UCoC
• generalizzare il riferimento a WMI e WMCI, includendovi qualunque chapter e qualunque user group alla luce della natura linguistica e non geografica del progetto

Come al solito, se qualcosa non è condivisibile, be bold. --Argeste ^soffia 12:57, 10 apr 2024 (CEST)

Quorum per la validità dell'elezione / 2 (taglio tecnico)

Cercando di mettere insieme i vari pareri e di raggiungere una soluzione di compromesso, provo a formulare una possibile soluzione per questo punto:

1. Il quorum (numero di voti favorevoli minimo per ritenere valida un'elezione) viene calcolato con la formula proposta da [@ Antonio1952], quindi varia nel tempo a seconda del livello di partecipazione effettiva. Ogni singola elezione andata a buon fine concorre alla formula di calcolo del quorum (quindi: se nella prima sessione dovessero candidarsi 10 utenti e ne venissero eletti 8, la formula andrebbe subito a regime già dalla seconda sessione).
2. Il numero di voti favorevoli deve essere almeno 2/3 dei voti validi, contati solo su favorevoli e contrari (al netto quindi degli astenuti)
3. Clausola transitoria: per la prima sessione di elezione o comunque per le prime 8 elezioni valide, si assume un valore di quorum fisso pari a 30 votanti, come compromesso iniziale tra il numero minimo proposto nella discussione (25) e quello massimo (48) risultante utilizzando per la formula di Antonio le ultime otto elezioni ad amministratore valide.

Il valore di "30" tenta di conciliare sia la posizione "prudenziale" di chi teme una partecipazione significativamente più bassa rispetto a quella delle elezioni ad amministratore che la posizione di chi ritiene che "25" sia una soglia comunque troppo bassa. Questo valore inoltre è più vicino alla media aritmetica calcolata da Antonio (34) risultante tra la proposta minima (25) e l'attuale quorum per l'elezione ad amministratore (48). Non va dimenticato che comunque questo valore verrà in ogni caso aggiustato sulla base della effettiva partecipazione, per cui già fin dalle primissime elezioni potrebbe essere modificato. I 2/3 rispetto all'80% discendono dalla considerazione di favorire le candidature di utenze non admin, ponendo una soglia più bassa che possa incoraggiare una candidatura con criteri più "abbordabili". Pareri in merito? --SuperSpritz^{l'adminalcolico} 17:13, 10 apr 2024 (CEST)

Favorevole --Bramfab (msg) 17:44, 10 apr 2024 (CEST)

• 3. Vada a denti stretti per il 30. Evidenzio che il passaggio da 30 al variabile non può essere fatto, per ovvi motivi, in corso di sessione ma deve essere fatto nella sessione di voto successiva a quella in cui si supera il numero di 8 votazioni valide. In altre parole, se nella 1ª sessione vengono eletti 7 ArbCom, tutte le votazioni della 2ª sessione (regolare o suppletiva) dovranno avere ancora il quorum di 30.
• 2. Rimango contrario ad abbassare la percentuale di voti favorevoli ai 2/3. Come ho scritto sopra, un qualsiasi utente che si assoggetta alla votazione per diventare sysop sa di dover correre (cit.) per superare l'80%, non capisco perché questa stessa soglia dovrebbe demotivarlo dal proporsi come ArbCom. L'unica motivazione che vedo per usare i 2/3 è l'esatto opposto di quella proposta e cioè tende a favorire l'elezione dei sysop. Infatti c'è il rischio - concreto e direi inevitabile - che un sysop possa essersi fatti dei nemici che gli voterebbero contro (che poi è il motivo per cui nelle votazioni di riconferma la soglia percentuale passa dai 4/5 ai 2/3).

--Antonio1952 (msg) 18:15, 10 apr 2024 (CEST)

[@ Antonio1952] Perché sysop e arbitri sono due funzioni radicalmente diverse che non si possono equiparare 1:1. La valutazione di un candidato sysop si può fare sulla base di come fa patrolling eccetera e comunque con un determinato livello di visibilità da parte della comunità. Un arbitro non si elegge su queste basi ma principalmente sul suo livello di equilibrio e di capacità di intervento moderato, nonché sulla sua conoscenza delle policy. Sono fattori che sono molto meno visibili da parte della comunità e su cui è anche per certi versi più sfumato dare una valutazione ed è anche il motivo per cui non è affatto automatico che il livello di partecipazione sia confrontabile con quello per le elezioni da admin. E potrebbe essere perfino più difficile arrivare a quel fatidico "80%".--SuperSpritz^{l'adminalcolico} 18:23, 10 apr 2024 (CEST)

Favorevole sul "gradimento minimo" dei 2/3, al netto degli astenuti.

Favorevole anche sulla partecipazione minima di 30 come compromesso fra i "numeri" proposti. Ma ragioniamo quindi su 30 votanti qualunque sia il voto espresso o di 30 favorevoli?

Contrario al criterio proposto da Antonio1952 per la modulazione nel tempo della soglia di partecipazione minima. Il criterio della partecipazione minima risponde al solo obiettivo di evitare "votazioni passate sottogamba", mentre la comunità è distratta. Per i sysop, questa eventualità sussiste (quantomeno in teoria) perché le elezioni possono partire in un qualunque istante. Per gli arbitri stiamo immaginando finestre temporali fisse (e collocate strategicamente lontane dalle vacanze estive e invernali) nelle quali per cui più elezioni avvengono contemporaneamente. Ciò implica che il mancato raggiungimento della soglia di partecipazione minima possa avvenire:

• per una singola votazione fra le tante che si svolgono contemporaneamente: ma perché? perché il candidato è ignoto ai più ma, ciò nonostante, in pochi assumono l'onere dell'inopportunità di eleggere arbitro uno "sconosciuto"? mi sembra difficile: in questi casi si vota contro o ci si astiene, ma da come stiamo impostando la soglia, sia i voti contrari sia le astensioni contribuiscono al raggiungimento della soglia di partecipazione minima, cosicché questa soglia non è utile a tagliare i candidati carneadi.
• per tutte le votazioni che si svolgono contemporaneamente: in questo caso il fenomeno potrebbe spiegarsi con un repentino calo strutturale dell'interesse della comunità rispetto all'ArbCom, e avrebbe l'effetto di "mandare deserta" l'elezione di tutti nuovi arbitri. Ma in tal caso basterebbe che il fenomeno si ripetesse per due elezioni consecutive (ossia, basterebbe che dopo un calo repentino la partecipazione resti stabilmente bassa oppure non aumenti abbastanza tornando sui livelli originari) per azzerare il numero di arbitri e quindi portare alla sospensione dell'istituto dell'ArbCom.

Solo apparentemente questo è un esito possibile, da limitarsi ad accettare a malincuore. A ben guardare, però, esso potrebbe essere dovuto a un fenomeno distorsivo. Immaginiamo (caso A) che in sede di prima applicazione (ossia nella prima sessione di voto) la partecipazione sia appena sufficiente; il ricalcolo della soglia minima, valida per la seconda sessione di voto, tiene conto di questa partecipazione modesta e porta la nuova soglia, poniamo sempre a 30 votanti; se la seconda sessione mantiene la stessa partecipazione, le votazioni sono valide. Immaginiamo ora (caso B) che in sede di prima applicazione la partecipazione sia alta e la soglia salga a 50; se nella seconda sessione la partecipazione non è altrettanto alta e, anzi se è identica a quella prevista per la seconda sessione nel caso A (per cui l'avevamo ritenuta sufficiente), adesso le elezioni non risulterebbero più valide. Questa cosa è IMHO palesemente insensata.

Aggiungo - ma rispetto al problema precedente è solo un elemento ulteriore - che la formula si basa sulle "ultime 8 elezioni" ma in caso di N elezioni contestuali con N>8 (risultato possibile e anzi auspicato, visto che l'ArbCom richiede minimo 7 arbitri) non è possibile identificare quali tali "ultime 8 elezioni" siano: da un lato dovremmo inventarci un criterio per aggirare questo ostacolo computazionale, dall'altro dover ragionare a "pacchetti di elezioni" (che essendo svolte contemporaneamente ricevono presumibilmente un'analoga partecipazione e comunque sono influenzate dai medesimi fattori esterni) fa venire meno il senso della media mobile, che punta a evitare cambiamenti troppo repentini delle soglie di partecipazione richieste.

Per questo motivo la mia idea è tenere fissa la soglia minima di partecipazione o, al limite, parametrizzarla in funzione della "attuale dimensione della comunità" (utenti attivi?) e non delle votazioni pregresse. --Argeste ^soffia 18:30, 10 apr 2024 (CEST)

Devo sinceramente ammettere che inizialmente ero d'accordo su tutti i tre punti, ma poi ho letto le motivazioni di Argeste e mi trovano d'accordo: l'effettuare elezioni in predeterminate finestre temporali, e il fatto che tuttora molti utenti non sysop seppur validissimi potrebbero essere del tutto sconosciuti ad alcuni (io tuttora ne scopro di nuovi ogni tanto), IMHO determinano la non necessità di ricalcolare una soglia minima di votanti ogni volta, ma potrebbe rimanere a 30 (voti favorevoli e contrari, l'astenuto di per sè non giudica o non è in grado di farlo) o giù di lì. In ogni caso capisco che serva una mediazione tra le varie opinioni, quindi non intendo oppormi e voto Favorevole. --ʍayßɛ⁷⁵ 07:58, 11 apr 2024 (CEST)

• Favorevole, anch'io mi terrei su un minimo di 30 voti, i 2/3 forse è troppo bassa come soglia ma la abbasserei un po' dall'80% al 70 o 75% massimo. Concordo che non sono esattamente la stessa cosa admin e arbitri, che vengono eletti in due periodi precisi dell'anno e le funzioni di arbitro (requisito principale è l'equilibrio, la neutralità, vedere Superspritz sopra) le eserciteranno solo nei casi in cui l'arbcom dovrebbe intervenire, che non capita certo tutti i giorni.--Kirk Dimmi! 08:56, 11 apr 2024 (CEST)
• D'accordo con Argeste sulle criticità della soglia mobile, ma allora 30 diventa poco, soprattutto se abbassiamo il quorum ai due terzi. Perché l'Arbcom funzioni dev'essere costituito da gente di specchiata fiducia comunitaria. Quindi la scelta è tra alto quorum assoluto e basso quorum percentuale oppure basso quorum assoluto e alto quorum percentuale. Quindi 30 ok col 75-80% di favorevoli, altrimenti alzerei ancora un poco il quorum assoluto.--Friniate^Arengo 21:58, 11 apr 2024 (CEST)
• Visti gli effettivi problemi evidenziati sulla soglia mobile, la soluzione potrebbe essere non tanto guardare alle ultime 8 singole elezioni, ma alle ultime 3(?) sessioni, calcolando per ciascuna la media dei voti delle singole elezioni. In tal modo si terrebbe meglio conto delle variazioni nel tempo della partecipazione--Parma1983 23:43, 11 apr 2024 (CEST)

  (f.c.) in effetti sarebbe già meglio. --Argeste ^soffia 16:17, 12 apr 2024 (CEST)

• Per il quorum mi trovo in generale d'accordo con Parma1983. Prefereriei un quorum mobile, magari con una percentuale di favorevoli alta tipo 80%. Il quorum fisso non tiene conto della partecipazione al progetto e può comportare, a seconda dei casi, sia soglie troppo alte che soglie troppo basse. --Vesparello (🛵) 09:16, 12 apr 2024 (CEST)
• È possibile - e forse anche probabile - che nella prima sessione di voto ci sia una grande partecipazione e poi, nelle successive, l'interesse scemi o addirittura crolli (dalle mie parti il fenomeno è detto Scrusciu ri scupa nova, alias rumore di scopa nuova) ma, d'altro canto, nessuno può garantire che questo crollo di interesse non scenda sistematicamente sotto 30.

Ora, se il crollo di interesse è repentino né la soglia di 30 né la soglia variabile posso porvi rimedio; invece se l'interesse scema gradualmente, la soglia variabile è, per sua natura, in grado di seguire il fenomeno.

Ciò premesso, riprendendo la prima proposta fatta da Parma1983 (16:54, 8 apr 2024), proporrei di non utilizzare per il calcolo della media mobile tutte le votazioni della prima sessione e di far partire il quorum variabile, dalla sessione successiva a quella in cui si raggiunge un numero minimo di 8 votazioni utili al calcolo del quorum. Ad esempio, se nella seconda sessione ci saranno 8 o più eletti, il quorum variabile partirà dalla terza sessione; se invece nella seconda sessione ci saranno non più di sette eletti, allora bisognerà attendere le votazioni della terza sessione e il quorum variabile partirà con la quarta sessione.

Infine, ricordo che nelle elezioni dei sysop il quorum si basa solo sui voti favorevoli, quindi escludendo i voti contrari e, a maggior ragione, gli astenuti. --Antonio1952 (msg) 22:08, 12 apr 2024 (CEST)

[@ Antonio1952] C'è però in effetti un problema in questo calcolo, a cui prima non avevo pensato: nelle elezioni i membri vengono eletti tutti contemporaneamente, perciò è impossibile individuare gli ultimi 8. Ad esempio, infatti, se in due sessioni consecutive A e B si hanno 7 eletti, avresti tutti i 7 dell'ultima sessione B, mentre non sarebbe possibile individuare l'ottavo tra i 7 eletti nella sessione A. Lo stesso discorso varrebbe se nell'ultima sessione gli eletti fossero più di 8: in tal caso, non si saprebbe come selezionare gli 8 su cui calcolare il quorum. Per questo avevo poi pensato di valutare i valori di 3(?) ultime sessioni, calcolando per ciascuna una media--Parma1983 22:56, 12 apr 2024 (CEST)

La linea guida proposta dice: «Al termine della settimana, sulla base dei pareri espressi il candidato dichiara se accetta o no di proseguire con la fase di votazione» quindi la votazione può partire solo dopo l'accettazione del candidato e, essendo improbabile che le accettazioni avvengano contemporaneamente, le votazioni verranno avviate in tempi diversi.

La mia proposta iniziale (23:03, 7 apr 2024) era di considerare "le più recenti in ordine di momento di avvio (giorno/ora/minuto); poi, a parità di momento, si può scegliere:

• il momento di presentazione della candidatura (sempre giorno/ora/minuto);
• il momento di accettazione della candidatura (sempre giorno/ora/minuto);
• il codice "oldid" di creazione della pagina di votazione se non si voterà per tutti nella stessa pagina, tipo Wikioscar.

Possiamo anche pensare di fare la media delle ultime 2 o 3 sessioni di votazioni ma bisognerebbe fare una media ponderata per evitare che una sessione con 10/15 elezioni pesi quanto quella con 2/3 elezioni.

In ogni caso, ritengo che il dilemma da sciogliere prioritariamente sia se avere a regime un quorum fisso o uno variabile.

Personalmente sono per il quorum variabile, quale che sia il metodo di calcolo. --Antonio1952 (msg) 15:05, 13 apr 2024 (CEST)

Se non ho inteso male io, le procedure verrebbero comunque avviate in contemporanea, indipendentemente dal momento dell'accettazione, ma ne chiedo conferma a [@ .mau.] e anche a [@ Superspritz], che mi pare conosca meglio l'organizzazione degli altri ArbCom. In ogni caso, io preferirei il quorum variabile, anche perché, nel caso l'interesse col tempo calasse, rischieremmo di trovarci con l'impossibilità di eleggere qualcuno--Parma1983 15:12, 13 apr 2024 (CEST)

[@ Parma1983] Sì, le procedure sarebbero in contemporanea e si chiudono in contemporanea, come avviene in tutti gli ArbCom e come avverrà anche per U4C. Se iniziamo a fare i conti su ore minuti e secondi non ne usciamo più. Anche perché se un candidato aspetta troppo, non si può dilazionare l'intera procedura, a meno che non si cambi la procedura stessa, nel senso che il candidato si presenta, la comunità fa le sue domande senza esprimere pareri (come avviene per U4C), poi si va comunque al voto tutti insieme per tutti i candidati, salvo rinunce esplicite da parte del candidato stesso. Questo consentirebbe di snellire anche la procedura, senza avere un filtro iniziale oppure lasciando che la comunità esprima i suoi pareri personali ma in forma non vincolante per il candidato. In tal modo, il quorum mobile si potrebbe calcolare sulla base della partecipazione media alle ultime due o tre elezioni (non andrei troppo in là nel tempo, essendo due sessioni fisse semestrali e non una sequenza continua come nel caso degli amministratori).--SuperSpritz^{l'adminalcolico} 18:39, 13 apr 2024 (CEST)

[@ Superspritz] Ok, quindi si potrebbe considerare implicitamente accettata la candidatura, salvo esplicita rinuncia da effettuarsi in qualsiasi momento, anche a elezione già avviata. Sì, potrebbe funzionare per semplificare la procedura.

Per quanto riguarda il quorum, sì, avevo infatti pensato alla media delle ultime 3 sessioni e non di più, per avere un quadro sufficientemente variegato--Parma1983 19:40, 13 apr 2024 (CEST)

con due sessioni l'anno io farei media su quattro sessioni (due anni), comprese quelle dove eventualmente non è stato raggiungo alcun quorum. -- .mau. ✉ 22:29, 13 apr 2024 (CEST)

(conflittato) Se le votazioni partono tutte insieme, per come è scritta adesso la linea guida, bisogna inserire un termine perentorio, finita la settimana di discussione, entro cui la candidatura va accettata oppure decade automaticamente.

Se invece, come ventilato da chi mi precede, la discussione diventerà solo un pourparler, allora va bene la tempistica attualmente proposta.

A me 3 sessioni sembrano troppe ma per cominciare può andare anche bene; eventualmente, si potranno ridurre a 2 in seguito. La formula del quorum diventerebbe

$Q_{AC}=\left\lfloor {\frac {4}{5\cdot N}}\sum _{i=1}^{N}x_{i}\right\rfloor$ dove $N$ è il numero totale di votazioni ArbCom delle ultime tre sessioni di voto che si sono concluse con esito positivo e $x_{i}$ è il numero degli utenti favorevoli e contrari in ciascuna delle predette N votazioni. --Antonio1952 (msg) 22:32, 13 apr 2024 (CEST)

Ok, secondo me così dovrebbe funzionare. Fare previsioni ora non è semplice, ma se a regime venissero eletti in ogni sezione circa 3-4 componenti, la media si calcolerebbe su poco più di 10 elezioni--Parma1983 23:55, 13 apr 2024 (CEST)

[@ Antonio1952] Io direi che se si deve fissare un termine perentorio, non è per "accettare" la candidatura ma semmai per ritirarla; se uno si candida e non si ritira esplicitamente, si va al voto. Come avviene adesso per U4C, steward eccetera. Solo così tutte le elezioni di una sessione si possono sincronizzare.--SuperSpritz^{l'adminalcolico} 00:02, 14 apr 2024 (CEST)

L'idea della media mobile calcolata non in base alle ultime N elezioni ma delle ultime X sessioni (con X pari a 2 o 3) mi convince. Viste le elezioni straordinarie, potremmo considerare non il numero delle sessioni ma il periodo, ad es. le sessioni dell'ultimo anno (significherebbe le ultime 2 sessioni ordinarie e tutte quelle straordinare occorse nel frattempo)? Ad ogni modo come .mau. non vedo vantaggi a escludere le elezioni prive di quorum.

Sulla accettazione/rinuncia, anche per me sarebbe molto meglio prevedere che debba essere esplicitata la rinuncia e non l'accettazione. Però oggi prevediamo che in caso di pareri largamente contrari alla candidatura non si voti: come possiamo formulare la cosa? --Argeste ^soffia 00:31, 14 apr 2024 (CEST)

Scusate eh, ma non possiamo semplicemente contare le elezioni individuali per ogni singolo arbitro, anche se contemporanee? ----Friniate^Arengo 00:32, 14 apr 2024 (CEST)

[@ Friniate] Il calcolo è in realtà molto semplice: sommi tutti i valori delle N elezioni che si sono svolte nelle ultime 3(?) sessioni, dividi il totale per N e ne prendi i 4/5--Parma1983 00:48, 14 apr 2024 (CEST)

Ah ok, avevo capito male allora, pardon. ----Friniate^Arengo 00:50, 14 apr 2024 (CEST)

Calcolare il quorum in base alle ultime 3 sessioni mi sembra un buon modo per ovviare alle problematiche emerse. Non ho però capito se per il calcolo della media si tengano in considerazione solo le elezioni valide (ovvero quelle che abbiano raggiunto il quorum), oppure sia valide che non. Per quanto riguarda l'inizio delle elezioni, farle partire separatamente mi sembra una complicazione non necessaria; si potrebbero considerare indicativamente 6 giorni per i commenti della comunità, e il 7º lasciarlo per un eventuale rifiuto nel caso in cui non emerga un consenso uniforme. Infatti è molto improbabile che i commenti della comunità arrivino tutti nelle ultime 24h, quindi si potrebbe coniugare la necessità di far esprimere gli utenti, con quella di dar tempo al candidato di rifiutare, con quella di far partire le elezioni ad un termine prestabilito (ovvero la fine dei 7 gg). Mi sembra ragionevole far partire automaticamente la votazione in caso di non-rifiuto del candidato, l'accettazione sarebbe sottintesa --Hominis Scrivimi 01:04, 14 apr 2024 (CEST)

[@ Argeste] Infatti, dopo aver sistemato questa cosa del quorum, va aggiustata un po' anche la procedura di candidatura/elezione. Descritta così, ci sono altre cose che non vanno bene, per esempio: se uno si candida nell'ultimo giorno utile, eviterebbe la settimana di "domande dalla comunità". Non va bene. Secondo me, sarebbe preferibile una formula del tipo "fase di candidatura in due settimane: la prima per proporre le candidature, poi stop; la comunità può proporre domande fin da subito e per tutta la settimana successiva alla candidatura, anche per dare tempo ai candidati di rispondere; allo scadere delle due settimane, vanno alle elezioni tutti i candidati che non hanno ritirato esplicitamente la candidatura". Senza "approvazione preventiva vincolante": magari nelle due settimane possono essere espressi anche pareri contrari da parte di chi interviene, ma va tenuto presente che poi non tutti quelli che intervengono in questa fase hanno diritto di voto. Ma questo è un altro punto, che andrà discusso in separato thread, non in questo che è focalizzato sul quorum. --SuperSpritz^{l'adminalcolico} 01:06, 14 apr 2024 (CEST)

Quagliamo?

A questo punto della discussione, direi che si possono tirare le somme per una formulazione condivisa finale. Tirando le somme da quanto emerso sopra, la proposta è questa:

• Il quorum per l'elezione degli arbitri viene calcolato in base alla partecipazione (media) nelle ultime 3 sessioni di voto, tenendo conto solo delle elezioni valide ("che hanno avuto esito positivo", come indicato da [@ Antonio1952] nella sua ultima formula) con la formula "pesata" proposta sempre da Antonio1952
• Per le prime sessioni di elezione, in via transitoria prima che si possa applicare la formula, si utilizza un quorum fisso per l'elezione che richiede almeno 30 voti favorevoli e che i voti favorevoli siano almeno il 75% dei voti ricevuti, al netto degli astenuti (=gli astenuti non contano)

Per agevolare il calcolo, converrà fare in modo che le votazioni nelle sessioni siano sincronizzate: questo è il prossimo (e si spera ultimo) punto chiave da discutere, ossia "come aggiustare la procedura di candidatura ed elezione" alla luce delle incongruenze che sono state fatte notare sopra. Ma intanto chiudiamo il punto del quorum. Pareri sulla proposta di formulazione finale? --SuperSpritz^{l'adminalcolico} 11:01, 14 apr 2024 (CEST)

• Favorevole anche se rimango perplesso per il 30, sia pure limitato alle prime 3 sessioni di voto. --Antonio1952 (msg) 11:58, 14 apr 2024 (CEST)

Favorevole. Solo due aspetti minori: (1) ultime tre sessioni significa ultime tre sessioni ordinarie e in aggiunta tutte quelle straordinarie successive alla prima delle tre, vero? (2) escludere le elezioni non valide (sotto quorum oppure con esito negativo) che vantaggi arreca? --Argeste ^soffia 18:24, 14 apr 2024 (CEST)

[@ Argeste] (1) sì, corretto (2) mi sa che la proposta di Antonio è ricalcata sul calcolo del quorum mobile per gli admin, che tiene conto solo delle elezioni valide. Per me si potrebbe anche tenere il conto della media secca dei partecipanti al netto degli astenuti, indipendentemente dal risultato del voto, non vedo particolari vantaggi nel considerare solo le elezioni valide. Tenendo conto che comunque la formula non scatterebbe nelle prime sessioni di voto, abbiamo tempo per definire anche più in là questo dettaglio, una volta approvato il meccanismo generale e l'introduzione di un quorum mobile.--SuperSpritz^{l'adminalcolico} 18:28, 14 apr 2024 (CEST)

• Favorevole Il quorum di 30 per le prime 3 elezioni può pure per qualcuno essere opinabile ma non ritengo essere una questione fondamentale.--Vesparello (🛵) 21:27, 14 apr 2024 (CEST)
• Favorevole nel complesso direi che possa andar bene--Parma1983 21:30, 14 apr 2024 (CEST)
• Favorevole --Friniate^Arengo 22:13, 14 apr 2024 (CEST)

Favorevole--TrinacrianGolem (msg) 22:36, 14 apr 2024 (CEST)

• Favorevole--Hominis Scrivimi 23:29, 14 apr 2024 (CEST)
• Favorevole nel complesso. Sono già state spese molte energie! --Torque (scrivimi!) 07:23, 15 apr 2024 (CEST)
• Favorevole la perfezione non esiste, comunque ottimo lavoro... --torsolo 07:50, 15 apr 2024 (CEST)
• Favorevole --ʍayßɛ⁷⁵ 07:52, 15 apr 2024 (CEST)
• Favorevole Le cose si possono migliorare, importante è iniziare. --Ilario (msg) 09:41, 15 apr 2024 (CEST)
• Favorevole tanto le regole non sono scolpite nella pietra. -- .mau. ✉ 11:23, 15 apr 2024 (CEST)

OK, visto che il consenso finalmente si è consolidato, procedo ad aggiornare il testo della pagina di descrizione. Grazie a tutti per gli interventi.--SuperSpritz^{l'adminalcolico} 11:25, 15 apr 2024 (CEST)

Io avevo inteso che la percentuale del 75% si applicasse, al pari del quorum di 30, solo per la fase transitoria, ovvero le prime tre sessioni di voto, mentre a regime si dovesse applicare la percentuale dell'80% così come previsto nella formula (4/5+N).
Superspritz invece aveva inteso proporre il 75% come valido sempre.
A questo punto credo che sia opportuno sentire il parere di chi, qui sopra, si è espresso a favore della proposta e cioè [@ Argeste, Vesparello, Parma1983, Friniate, TrinacrianGolem, Hominisque] [@ Torque, Torsolo, Maybe75, Ilario, .mau.] --Antonio1952 (msg) 00:21, 16 apr 2024 (CEST)

[@ Antonio1952] Una nota: per l'elezione degli admin, la percentuale minima di favorevoli è dell'80% dei votanti ma il fattore usato per il calcolo del quorum sulla base dei votanti nelle ultime elezioni valide è 2/3, non 4/5: il "peso" usato nella media mobile per determinare la soglia minima di votanti a favore non riflette la percentuale dell'80%. I due pesi sono scollegati.--SuperSpritz^{l'adminalcolico} 00:25, 16 apr 2024 (CEST)

Avevo appena risposto da [@ Antonio1952], avendo la sua PU tra gli OS :D

Comunque, come scrivevo nella sua talk, il valore del 75% per me si applicava alla percentuale di favorevoli e non al fattore moltiplicativo del calcolo della media per il quorum, esattamente come avviene per gli admin (in quel caso, 80% di favorevoli e i 2/3 per il calcolo del quorum)--Parma1983 00:29, 16 apr 2024 (CEST)

Come avevo scritto sopra (23:03, 7 apr 2024), ritengo che nel caso dei sysop si sia voluto tener conto, in via cautelativa, della percentuale minima di favorevoli richiesta nelle votazioni per la riconferma (appunto 2/3).

Comunque, giusto per non disperderci, la domanda è: volete una percentuale dell'80% a regime ridotta nella fase transitoria al 75% oppure una percentuale fissa sempre al 75%? --Antonio1952 (msg) 00:44, 16 apr 2024 (CEST)

[@ Antonio1952] Inizialmente ero più per l'80%, ma ragionandoci su mi va bene anche il 75%, che, con la conclusione della discussione, ormai consideravo come assodato--Parma1983 00:50, 16 apr 2024 (CEST)

Abbiamo stabilito di considerare un fattore di partecipazione (all'inizio 30 favorevoli, poi la formula che si basa sui precedenti) e uno di gradimento (la percentuale di favorevoli sui votanti che si esprimono). IMHO questi due fattori sono scorrelati: per la partecipazione, considerare all'inizio i 30 è necessario non essendoci i precedenti cui rifarsi; per il gradimento invece IMHO si può fissare dall'inizio la percentuale valida anche a regime. Superspritz ha citato la soglia dei gradimento al 75% solo nel secondo punto elenco (quello riferito al transitorio), ma io ho inteso che si sia semplicemente espresso in modo infelice, al punto che neppure l'ho fatto notare. D'altra parte non mi pare che, Antonio a parte, vi fosse consenso per tenere a regime la soglia di gradimento all'80%. Io ero per il 67-70% ma 75% mi sembra un buon compromesso

Piuttosto, ripensandoci, la formula che ora è in bozza genera un effetto spiacevole: se tutte le prime elezioni sono poco partecipate e i candidati poco graditi, cosicché ad es. ci sono 30 favorevoli (soglia minima di partecipazione) e 10 contrari (in modo che il rapporto tra favorevoli e somma di favorevoli e contrari sia al minimo, ossia al 75%), quando si va a regime accade che la soglia minima di partecipazione diventi l'80% della media tra favorevoli e contrari (media che è 40), ossia 32 favorevoli (e fino a 10 contrari): questo salto non ha senso!

Ugualmente non ha senso il fatto che se invece le prime elezioni sono poco partecipate e i candidati graditissimi (ossia se i 30 favorevoli non si contrappone alcun contrario), quando si va a regime la soglia minima di partecipazione diventa l'80% di 30 votanti, ossia 24 favorevoli (e fino a 8 contrari). Qual è la ratio di adottare formule che prevedano una soglia di minima partecipazione che risenta del gradimento (percentuale di favorevoli sul totale di favorevoli e contrari) avuto dei candidati precedenti?

Confermerei la previsione, ma credo che a linee guida approvate potremo semplificare ancora. --Argeste ^soffia 01:06, 16 apr 2024 (CEST)

(f.c.) @Argeste, è ovvio che, se la percentuale a regime sarà del 75%, bisognerà adeguare coerentemente la formula e quindi passare da 4/(5*N) a 3/(4*N).

Il coefficiente nel calcolo del quorum e la percentuale minima di favorevoli devono essere collegati; se il coefficiente è più alto si crea l'effetto distorsivo che segnalavi tu, se è più basso comporta un inutile abbassamento del quorum. Questo è valido anche nel caso dell'elezione dei sysop (e qui rispondo anche a @Parma1983).

Infatti, per i sysop ci sono due percentuali minime, una dell'$80\%$ per l'elezione e una del $66,{\bar {6}}\%$ per le votazioni di riconferma; la formula per il calcolo del quorum, che – ricordo - è valida per entrambe le tipologie di votazione, è scritta in modo da non creare distorsioni.

Ad esempio, se la media dei votanti (favorevoli + contrari) nelle precedenti votazioni è stata di 30 (poco importa se siano 30 favorevoli e 0 contrari o 24 favorevoli e 6 contrari), il quorum successivo sarà pari a 20 (=2/3*30). In questo modo, ipotizzando che ci siano sempre 30 votanti, nel caso di votazioni di riconferma, i 20 voti favorevoli minimi coincidono con la prevista percentuale minima dei 2/3.

In questo caso, avendo una sola percentuale di voti, il coefficiente deve essere 3/4, se la percentuale dei voti è il 75%, o 4/5, ove fosse dell'80%. --Antonio1952 (msg) 15:11, 16 apr 2024 (CEST)

Come scrivevo da Antonio, in considerazione del fatto che la formula di calcolo del quorum per le elezioni degli admin dimostra di funzionare bene da anni e che i due valori (percentuale di favorevoli per l'elezione e fattore moltiplicativo della media dei favorevoli e contrari nelle ultime N elezioni per il quorum) sono tra loro scollegati, io abbasserei i 4/5 della formula ai 2/3, esattamente come avviene per gli admin--Parma1983 01:38, 16 apr 2024 (CEST)

Per me percentuale e quorum sono due cose scollegate. La percentuale è e rimane la stessa perché mi rappresenta il gradimento minimo del candidato. Il quorum serve invece a determinare se e quanto è conosciuto il candidato nella comunità ma questo è legato alla partecipazione. Questo secondo parametro si può conscere soltanto con lo storico e fissarlo a 30 per le prime tre elezioni semplificherebbe la vita. Si potrebbe invece pensare di avere un passaggio morbido dal quorum fisso di 30 a quello variabile calcolato Q secondo la formula. Chiedo scusa se scriverò le formule tipo Excel, sono da cellulare e scriverle in formato grafico appropriato risulta un po' difficile. L'idea potrebbe essere la seguente:

• prima votazione quorum =30
• seconda votazione quorum =20+(Q/3) dove Q è il quorum calcolato sulla prima votazione
• terza votazione quorum =10+(Q*2/3) dove Q è il quorum calcolato sulle prima e seconda votazioni
• quarta votazione quorum =Q

In questo modo si eviterebbe un possibile scalino brusco nel quorum tra terza e quarta votazione. Comunque non la vedo come cosa fondamentale e sarei comunque d'accordo anche a lasciare le cose come stanno col passaggio brusco da 30 a calcolato tra la terza e la quarta votazione.--Vesparello (🛵) 05:03, 16 apr 2024 (CEST)

Io ho espresso il mio voto favorevole sia al quorum 30 delle prime 3 votazioni che al 75% dei voti favorevoli necessari per l'elezione. --ʍayßɛ⁷⁵ 07:14, 16 apr 2024 (CEST)

posto che questo punto potrebbe esser eventualmente da calibrare in futuro (30 mi sembra comunque un numero accettabile come partenza), concordo con chi mi precede... --torsolo 08:22, 16 apr 2024 (CEST)

Quoto Vespanello, ma anche per me non è un fatto fondamentale.

Quoto più forte Parma: parametrare la partecipazione all'80% (4/5) della partecipazione media precedente (come nella formula ora in bozza) significa ammettere una banda di oscillazione dei votanti sensibilmente ridotta rispetto a quella ammessa alle elezioni degli admin, per le quali la formula analoga calcola il quorum in ragione del 67% (2/3) della partecipazione media precedente. --Argeste ^soffia 10:16, 16 apr 2024 (CEST)

Idem come Parma, anch'io ero per l'80 ma il 75 mi è parso un buon compromesso. ----Friniate^Arengo 21:10, 16 apr 2024 (CEST)

75% per me va bene sempre. -- .mau. ✉ 09:12, 17 apr 2024 (CEST)

Concordo con vesparello sulla parte del quorum e percentuale; secondo me si può fare a meno di modulare il quorum fra la terza e quarta tornata di elezioni, si complica inutilmente la situazione. Pure io avevo sottinteso che il 75% si continuasse ad applicare anche una volta preso il via il sistema; favorevole ad abbassare il quorum da 4/5 a 2/3--Hominis Scrivimi 00:34, 18 apr 2024 (CEST)

[← Rientro] Vista l'"interpretazione autentica" della percentuale del 75% anche a regime, ho modificato, per logica matematica, anche la formula per il calcolo del quorum. --Antonio1952 (msg) 21:32, 22 apr 2024 (CEST)

Aggiustamento della fase di candidatura/accettazione

Riprendo su thread separato il punto emerso durante la discussione sul quorum. La procedura di candidatura descritta nella bozza proposta presenta almeno due punti critici che secondo me vanno aggiustati:

• Con la procedura descritta, con le domande della comunità ristrette alla sola prima settimana, quella della presentazione delle candidatura, una utenza potrebbe scegliere di proporsi/farsi proporre all'ultimo momento utile, eludendo così la fase delle domande. Chiaramente, sarebbe un WP:GIOCARE che non deporrebbe a favore della candidatura, ma sarebbe tecnicamente lecito e consentito e comunque creerebbe una situazione di disparità tra i candidati
• La procedura descritta prevede che, alla fine della seconda settimana, ogni candidato dica esplicitamente se accetta o meno di proseguire nell'elezione. Questo comporta una serie di problemi collaterali, primo tra tutti il fatto che è pressoché sicuro che non tutti si esprimeranno nello stesso momento e ci sarebbero quindi degli "sfasamenti" potenziali nell'inizio delle votazioni.

Tutto questo rende questa prima fase pre-voto, secondo me, farraginosa e poco utile. Proporrei quindi una modifica di questa prima fase in una direzione semplificata, come segue:

• Prima settimana: come adesso, riservata per la presentazione delle candidature. Dopo i primi sette giorni, non si può presentare più nessuno
• In contemporanea, e per la durata di due settimane, la comunità può porre domande a tutti i candidati. Questo fa sì che anche chi si candida all'ultimo momento può essere sottoposto a domande da parte della comunità per almeno una settimana, evitando così il primo problema della potenziale "elusione" di questa fase. Nota: per "comunità" si intendono le sole utenze registrate, che sono anche le sole che possono ricorrere alla Commissione: gli interventi da parte di utenze non registrate (IP) non sono ammessi.
• Ai candidati non è più richiesta l'accettazione esplicita di proseguire alla fase di voto. Semmai, un candidato può ritirare esplicitamente la propria candidatura prima dell'inizio delle due settimane di votazione. Chi non lo facesse prima di tale termine, passa automaticamente alla fase di votazione (che inizierebbe e terminerebbe nello stesso istante per tutti)
• Durante le due settimane di domande, la comunità può anche esprimere un proprio gradimento sul candidato (tipo Favorevole, Contrario ecc.) senza che questo abbia un carattere vincolante per il candidato (esempio estremo: se la comunità si esprime con una valanga di Contrario ma il candidato non ritira la sua candidatura, si va comunque al voto, che sarà quel che sarà).

Alla luce di quanto sopra, il "diagramma temporale" diventerebbe quindi questo:

Anche visivamente, è decisamente più semplice e snello rispetto al diagramma attuale. Pareri in merito? --SuperSpritz^{l'adminalcolico} 12:10, 15 apr 2024 (CEST)

• Favorevole Sì, direi che tutto il sistema così possa funzionare bene--Parma1983 14:27, 15 apr 2024 (CEST)
• Favorevole --ʍayßɛ⁷⁵ 17:05, 15 apr 2024 (CEST)
• Favorevole -- --Sannita - L'admin (a piede) libero 17:58, 15 apr 2024 (CEST)
• Favorevole. Propongo di snellire il passaggio su chi è legittimato a porre domande, adottando la formulazione vigente su Meta per le elezioni dell'U4C, secondo cui "Eligible voters can ask questions to candidates", ossia: "hanno facoltà di porre domande i (soli) utenti che possono votare". In effetti il diritto di farsi tutelare dall'ArbCom (riconosciuto a tutti gli utenti registrati) non prevede necessariamente la sensibilità richiesta per contribuire costruttivamente al processo di individuazione dei singoli arbitri. E se non fosse così, allora non avrebbe senso circoscrivere la facoltà di votare --Argeste ^soffia 18:27, 15 apr 2024 (CEST)
• Incerto/a Io vedo ancora due criticità. La prima è l'inizio delle domande a candidature aperte che mette su un piano di disparità chi si propone (o viene proposto) all'inizio della settimana, senza domande sul piatto e chi si propone alla fine della settimana con alcune domande e già alcune risposte date. Potrebbe per questo motivo esserci un'alta concentrazione di candidature all'ultimo minuto. Vedrei quindi più opportuna la fase delle domande iniziare dopo la chiusura delle candidature. La seconda sono le domande poste in prossimità dello scadere del tempo che consentirebbero la risposta solo ad alcuni candidati. Infatti chi è qui non è attivo 24/7 e a qualcuno potrebbe passare la domanda dell'ultimo minuto. Per ovviare a questo andrebbero distinti due periodi distinti, uno per le domande e uno per le risposte, che cominciano insieme ma col primo che termina qualche giorno prima del secondo. --Vesparello (🛵) 05:31, 16 apr 2024 (CEST)

  [@ Vesparello] un'altra possibilità potrebbe essere il sistema "alla fr.wiki", dove domande (e risposte) sono possibili per tutte e quattro le settimane, durante le votazioni comprese. Oppure fare iniziare le domande, come dici tu, subito dopo la fine delle candidature ma farle durare fino alla fine delle votazioni. In questo modo, non ci sarebbe alcun reale vantaggio nel "candidarsi all'ultimo minuto" e ogni candidato avrebbe tutto il tempo a disposizione per poter rispondere.--SuperSpritz^{l'adminalcolico} 13:14, 16 apr 2024 (CEST)

È molto simile alla mia proposta, anche fare come dici [@ Superspritz], di iniziare le domande subito dopo la fine delle candidature e farle durare fino alla fine delle votazioni, secondo me va benissimo. --Vesparello (🛵) 13:46, 16 apr 2024 (CEST)

Domanda tecnica: Pensiamo di avere per ogni candidato due pagine, una di domande/risposte ed eventuale apprezzamento e una per votare, o solo una dove si fa tutto? --Antonio1952 (msg) 15:26, 16 apr 2024 (CEST)

(f.c.) Dove andrebbero in tal caso le domande rivolte a tutti i candidati? --Argeste ^soffia 16:49, 16 apr 2024 (CEST)

Non vedo grosse differenze tra le due soluzioni. Solo una pagina dove si fa tutto sarebbe più comodo, anche per archiviare. Due pagine separate sarebbe più simile a quanto si fa per gli admin, su questo punto personalmente sono neutrale.--SuperSpritz^{l'adminalcolico} 16:33, 16 apr 2024 (CEST)

[← Rientro] Tenendo conto delle osservazioni emerse sopra (limitare anche la fase di domande/pareri ai soli utenti con diritto di voto e riorganizzare il periodo di domande/pareri), il nuovo diagramma temporale aggiornato diventerebbe questo, ancora più semplice rispetto al precedente:

Torna a tutti? --SuperSpritz^{l'adminalcolico} 16:44, 16 apr 2024 (CEST)

• In tutta sincerità, non mi convince immensamente il fatto che si possano fare le domande ai candidati fino all'ultimo giorno della votazione, ma se agli altri sta bene non mi oppongo--Parma1983 16:53, 16 apr 2024 (CEST)

  In effetti rientra dalla finestra il problema di un candidato che "non riesce a rispondere a domande dell'ultimo minuto". Anche [@ Vesparello], rileggendo bene sopra, suggeriva che il periodo delle domande si chiudesse prima del periodo delle risposte. Potrebbe esser ragionevole ridurre il periodo delle domande da tre a due settimane, terminandole con la prima settimana di votazione. In tal caso i candidati avrebbero una settimana di tempo per rispondere alle domande "in extremis" del periodo utile.--SuperSpritz^{l'adminalcolico} 19:53, 16 apr 2024 (CEST)

  [@ Superspritz] Ottimo, grazie, così secondo me funzionerebbe bene, anche per tener conto dell'eventualità che un candidato non riuscisse a collegarsi negli ultimissimi giorni di votazione e dunque a rispondere--Parma1983 19:57, 16 apr 2024 (CEST)

[← Rientro] Ecco il diagramma temporale aggiustato secondo questa proposta.

[@ Vesparello] (ma non solo), va bene?--SuperSpritz^{l'adminalcolico} 20:02, 16 apr 2024 (CEST)

• Favorevole--Parma1983 20:06, 16 apr 2024 (CEST)
• Contrario a non consentire le domande da parte di utenti registrati anche se non elettori visto che, nelle candidature dei sysop, ammettiamo anche gli IP e Contrario a sovrapporre la fase delle domande (e quindi ad incentivare le discussioni) durante la fase di voto. Sono quindi favorevole alla prima versione proposta da Superspritz. Se un candidato non rispondesse o eludesse una mia domanda, io gli darei un voto contrario motivandolo con la sua risposta insoddisfacente. --Antonio1952 (msg) 22:34, 16 apr 2024 (CEST)
• Contrario Terminerei le domande un minuto prima dell'inizio votazione, mi spiace per ritardatari nel porle o nel candidarsi (ma Wiki significa veloce), ma solitamente ovunque in fase di votazione: les jeux sont faits, rien ne va plus, non è più tempo di parole, ma di fare la conta. --Bramfab (msg) 23:09, 16 apr 2024 (CEST)
• Favorevole su tutto. Restringere i commenti agli utenti con diritto di voto assicura che la discussione non venga manipolata (anche da utenze multiple) e la visione comune su un candidato non venga distorta. L'ArbCom è (sarà) qualcosa di abbastanza delicato ed è necessario avere le conoscenze opportune anche per esprimere pareri in queste fasi; difficilmente un utente che non rispetta i requisiti avrà qualcosa da dire in buona fede in questa sede. --valcio ••• 08:58, 17 apr 2024 (CEST)
• sul senso della restrizione ai soli aventi requisiti di voto, l'ho proposto oltre che pen analogia a U4c (è vero che per i sysop prevediamo altro ma solo perché quando fu definita quella procedura non si siamo posti esplicitamente il problema, salvo poi intervenire a posteriori in caso di trolling) anche per le considerazioni di Valcio. Quanto alla tempistica per le domande, Incerto/a, ma tendente al contrario, sulla proposta ultima di Superpritz per i motivi già espressi da Antonio1952 e Bramfab: IMHO anche nel caso di candidature in extremis basta la settimana successiva (la seconda della procedura di voto) a scongiurare il rischio che qualcuno si candidi all'ultimo minuto per evitarle. Mi sfugge anche il beneficio di non consentirle già dalla candidatura ma solo a partire dalla seconda settimana. Quanto alle risposte, un candidato può darle IMHO anche dopo la chiusura della finestra per fare domande. --Argeste ^soffia 10:03, 17 apr 2024 (CEST)

[← Rientro] Tenendo conto dei pareri degli incerti/contrari sulla durata del periodo delle domande/risposte, mi sembra che questo diagramma temporale tenga conto di tutto.

Per quanto riguarda "chi può porre le domande": confrontando mele con mele, ossia ArbCom con ArbCom/U4C, la restrizione ai soli "eligible voters" è allineata a quanto previsto su Meta per U4C (e non solo: è già in vigore anche per gli steward).--SuperSpritz^{l'adminalcolico} 11:03, 17 apr 2024 (CEST)

• Favorevole alla proposta qui sopra. --Argeste ^soffia 11:43, 17 apr 2024 (CEST)
• Ok, con le ultime correzioni mi pare in effetti possa funzionare ancora meglio, quindi sono Favorevole--Parma1983 15:01, 17 apr 2024 (CEST)
• Favorevole --Friniate^Arengo 23:08, 17 apr 2024 (CEST)
• Favorevole--☠︎Quinlan83☠︎^{(𝖄𝖔𝖚 𝖙𝖆𝖑𝖐𝖎𝖓' 𝖙𝖔 𝖒𝖊?)} 23:48, 17 apr 2024 (CEST)
• direi di esplicitare nel grafico che la seconda settimana può essere usata, oltre che per fare domande, anche per esprimere commenti di gradimento/non gradimento. Comunque favorevole --Hominis Scrivimi 00:34, 18 apr 2024 (CEST)
• +1 ok agli ultimi aggiustamenti--valcio ••• 08:24, 18 apr 2024 (CEST)
• Pure io * Favorevole--I Need Fresh Blood_{corrispondenze V"V} 10:24, 18 apr 2024 (CEST)
• Favorevole--Vesparello (🛵) 11:54, 18 apr 2024 (CEST)
• Commento: a questo punto aggiorno la pagina di descrizione, visto che il consenso mi sembra assodato.--SuperSpritz^{l'adminalcolico} 12:08, 18 apr 2024 (CEST)
• Favorevole --Torque (scrivimi!) 15:11, 18 apr 2024 (CEST)

Ultime rifiniture (e il nome)

Ho riletto tutta la procedura, corretto dettagli minori e provato a renderla più scorrevole (qui prima e dopo la cura).

Riprendo il tema del nome che non ricordo bene chi aveva sollevato: "Commissione di Arbitraggio" è impreciso, "Commissione di arbitrato" sarebbe già meglio, ma suona male in italiano. Proporrei pertanto "Commissione degli Arbitri" (WP:CdA? umph!) o "Commissione Arbitrale". Io preferisco l'ultima ipotesi. --Argeste ^soffia 01:18, 18 apr 2024 (CEST)

• Direi "Commissione Arbitrale" anch'io--Parma1983 01:24, 18 apr 2024 (CEST)
• +1 Commissione Arbitrale--valcio ••• 08:22, 18 apr 2024 (CEST)
• +1 Commissione Arbitrale--I Need Fresh Blood_{corrispondenze V"V} 10:25, 18 apr 2024 (CEST)
• +1 Commissione Arbitrale --Vesparello (🛵) 11:55, 18 apr 2024 (CEST)
• +1 Commissione Arbitrale.--SuperSpritz^{l'adminalcolico} 12:00, 18 apr 2024 (CEST)
• +1 Commissione Arbitrale. Non ricordo dove era stato detto ma sarebbe anche la traduzione più corretta. --Torque (scrivimi!) 15:13, 18 apr 2024 (CEST)

  Era stato fatto presente da un IP qui. Anch'io Favorevole a Commissione Arbitrale. --PandeF (msg) 15:37, 18 apr 2024 (CEST)

• +1 Commissione Arbitrale.--ʍayßɛ⁷⁵ 15:39, 18 apr 2024 (CEST)
• Commissione arbitrale. --Amarvudol (msg) 16:33, 18 apr 2024 (CEST)
• OK per Commissione arbitrale. "Arbitrale" non dovrebbe andare in minuscolo? --Antonio1952 (msg) 18:25, 18 apr 2024 (CEST)

Last but not least: retroattività

Ci sarebbe un ultimo punto, secondo me importante da mettere in chiaro. La Commissione Arbitrale nasce come strumento di segnalazione e di ultima istanza in merito all'applicazione e alla violazione dell'UCoC. Ma non c'è nessun cenno, né implicito né esplicito, in merito a segnalazioni di violazioni di UCoC relative a eventi passati, né c'è, come nel caso delle revisioni del blocco, una affermazione esplicita in merito alla possibilità o meno di richieste retroattive verso l'ArbCom. Ossia manca questo punto: qual è il limite temporale a partire dal quale si possono considerare situazioni segnalabili all'ArbCom? Visto che questa Commissione nasce in funzione dell'UCoC, la mia proposta è la seguente:

• Possono essere avanzate anche segnalazioni relative a situazioni precedenti l'esordio della Commissione Arbitrale, purché tutti i fatti e le azioni relative alla segnalazione si siano verificati interamente dopo il 17 febbraio 2021

Perché il 17 febbraio 2021? Perché questa è la data di pubblicazione ufficiale dell'UCoC su WMF. Quindi, è solo a partire da tale data che l'ArbCom ha un riferimento ufficiale e globale a cui far capo per la sua funzione istituzionale. Se serve per applicare UCoC, non ha senso chiederne l'intervento per situazioni relative a un tempo in cui UCoC non era ancora in forza. Chiaramente, richieste relative a fatti passati devono essere comunque legate ad aspetti di scarso o mancato rispetto dell'UCoC, questo per impedire che ArbCom diventi un generico "sportello ricorsi" per qualsiasi azione, es. blocco, assegnato a partire dalla data suddetta. Anche nel caso del pregresso, la casistica rimane sempre quella (e l'onere di evidenziare le eventuali carenze nell'applicazione di UCoC per cui si richiede l'intervento dell'ArbCom rimane sempre e comunque a carico della parte richiedente). Pareri? --SuperSpritz^{l'adminalcolico} 16:44, 18 apr 2024 (CEST)

• Sì, mi pare ragionevole consentire di ricorrere all'ArbCom per fatti avvenuti dall'entrata in vigore dell'UCOC (ovviamente alle stesse condizioni attuali), perciò sono Favorevole alla proposta--Parma1983 17:05, 18 apr 2024 (CEST)
• Favorevole --Friniate^Arengo 17:09, 18 apr 2024 (CEST)
• +1, ma aggiungerei anche ; in caso contrario, la Commissione valuterà a sua discrezione l'ammissibilità della segnalazione. Certamente non si può richiedere agli arbitri di giudicare situazioni complesse di decenni fa, ma potrebbero esserci casi più semplici dove potrebbe essere opportuno un intervento --valcio ••• 20:57, 18 apr 2024 (CEST)
• Favorevole così come enunciato da Superspritz--I Need Fresh Blood_{corrispondenze V"V} 21:59, 18 apr 2024 (CEST)
• Favorevole se… ero partito da un’idea personale abbastanza ampia, ma la spiegazione iniziale di SuperSpritz é coerente e impeccabile! Sarei quindi d’accordo con quanto proposto da Valcio: così come detto ma con la possibilità di valutare a propria discrezione la possibilità di accettare anche delle eccezioni. --Torque (scrivimi!) 23:41, 18 apr 2024 (CEST)
• Favorevole... un punto fermo ci deve essere anche per non rivangare questioni ormai cristallizzate... --torsolo 07:59, 19 apr 2024 (CEST)
• Favorevole se le segnalazioni precedenti all UCoC venissero accettate e valutate a discrezione della commissione come ha detto valcio, a maggior ragione questioni di anni fa che non hanno avuto modo di essere risolte meritano essere districate da un organo che finalmente abbiamo --Luix710 (msg) 10:06, 19 apr 2024 (CEST)

• Commento: Mettendo insieme quanto emerso, il paragrafo "Retroattività" potrebbe essere quindi formulabile come segue:

Possono essere avanzate anche segnalazioni relative a casi precedenti l'attivazione della Commissione arbitrale, purché tutti i fatti e le azioni relative alla segnalazione si siano verificati interamente dopo il 17 febbraio 2021.^{[nota documentale con il link alla crono su WMF]}

Per segnalazioni relative a casi precedenti tale data, la Commissione si riserva il diritto di valutare a propria totale e inappellabile discrezione l'eventuale ammissibilità.

Torna? --SuperSpritz^{l'adminalcolico} 12:07, 19 apr 2024 (CEST)

• Favorevole Nel merito, ma non del tutto nella forma. Anche perché andrebbe spiegato quali possono essere motivi validi, o codificati o attraverso esempi, per cui la commissione può prendere in considerazioni vecchi casi. Messo così come adesso, sembra una pura arbitrarietà. --Vesparello (🛵) 13:16, 19 apr 2024 (CEST)
• Commento: concordo con vesparello e per trasparenza è giusto stilare dei motivi per cui una richiesta non sia ammissibile, altrimenti la mia idea sarebbe quella di applicare l'UCoC retroattivamente, così avremmo un modo semplice per valutare senza ingegnarci troppo --Luix710 (msg) 13:25, 19 apr 2024 (CEST)

  A WP:BUON SENSO, verrebbe da dire solo quelli per cui c'è continuità nell'attuale UCoC - è sempre il problema che se il quadro di riferimento dell'epoca era diverso da quello attuale, "retrocedere" e far valere regole che all'epoca non erano previste se addirittura non in contrasto con quanto prevedevano le policy del tempo, per forza di cose richiede una valutazione caso per caso. Non è "arbitarietà", infatti si parla di "valutare", non di "decidere". Gli esempi non si possono "inventare" così su due piedi e faccio presente che, su materie così delicate, stiamo parlando di tutte situazioni uniche e una diversa dall'altra, che vanno valutate per il contesto in cui si sono svolte, eccetera eccetera. Come non esiste un "modello standard di procedura di problematicità" non si può pretendere che esista un "modello standard di caso pre-UCoC accettabile da un ArbCom" (siamo in piena WP:ANALOGIA). Senza dimenticare che c'è sempre chi prende "esempio" per "norma che vale per tutti i casi anche vagamente analoghi" o chi vorrebbe "esempi di tutti i casi possibili". Del resto, se si accetta il principio generale che anche per i casi UCoC l'ArbCom decide se ammettere o meno, perché per i casi vecchi, in cui farebbe la stessa cosa, si vede dell'"arbitrarietà"? --SuperSpritz^{l'adminalcolico} 13:28, 19 apr 2024 (CEST)

  l'ucoc però è stato approvato in via globale, e quelle policy che un tempo erano valide oggi sarebbero oggettivamente errate. se riscontriamo che un utente è stato bannato per un comportamento oggi passibile dal codice ma non da una norma locale non più in vigore si creerebbe una situazione paradossale: teniamo bannato a vita un utente oggi de facto innocente? se quest'organo deve nascere per dare seconde possibilità ove doveroso mi sembra giusto applicarlo per tutti --Luix710 (msg) 13:35, 19 apr 2024 (CEST)

  Chi ha detto che le policy locali non sono più valide? Ucoc fissa uno standard minimo, ma è detto ovunque che poi chiaramente ogni comunità può fissare proprie linee guida aggiuntive. ----Friniate^Arengo 13:41, 19 apr 2024 (CEST)

  parlavo di casi di policy che sono cambiate nel tempo, forse non avevo specificato --Luix710 (msg) 13:42, 19 apr 2024 (CEST)

  Dal 2021 ad oggi non mi risulta sia cambiato chissà che in termini di policy sul comportamento degli utenti. ----Friniate^Arengo 13:45, 19 apr 2024 (CEST)

  Io concordo con la retroattività ordinaria al 17 febbraio 2021. Della retroattività prima di quella data non mi importa tanto, se c'è o non c'è per me non fa differenza ma una spiegazione, almeno minima per cui l'ArbCom possa prendere in considerazione particolari casi avvenuti prima deve essere data. Altrimenti c'è il rischio che la commissione venga intasata di richieste fatte sulla base di questa deroga. Per questo motivo ritengo che delle limitazioni devono essere fatte prima di invocare l'intervento dell'ArbCom. Poi, se non si ritiene che questo sia un rischio, bene così, infatti, mi sono trovato d'accordo sulla sostanza della retroattività, della data fissa e delle possibili (poche) eccezioni.--Vesparello (🛵) 14:39, 19 apr 2024 (CEST)

  Chiaro. Anche se sembra scontato, mi sembra ovvio che una richiesta relativa a un caso del 2010 non avrebbe alcuna speranza di accoglienza. Un margine potrebbe esserci al più per situazioni a cavallo del 2021, dato che le policy erano sostanzialmente simili a quelli attuali: ma si dovrebbe trattare di situazioni particolarmente gravi di violazione dell'UCoC o di quello che oggi chiameremmo così. Si potrebbe anche mettere, sempre per i casi pre-2021, qualche altro paletto del tipo "una condizione è che tutte le parti coinvolte e non bloccate/bannate dal progetto siano ancora tutte attive al momento della segnalazione", che avrebbe un senso per poter garantire sia una "memoria storica" sia che tutte le parti in causa possano dire la loro, se necessario. Richiedere all'ArbCom valutazioni che potrebbero esser fatte solo sulla base di crono e diff e relative interpretazioni, senza poter sentire i diretti interessati, avrebbe poco senso. --SuperSpritz^{l'adminalcolico} 14:50, 19 apr 2024 (CEST)

Commissione arbitrale: approviamo?

La discussione lunga e approfondita (e grazie a tutti gli intervenuti per il loro contributo costruttivo) ha portato alla fine a dare una fisionomia praticamente completa a quello che è il regolamento della Commissione arbitrale (funzioni, durata del mandato, eleggibilità e requisiti per votare, impegni e vincoli eccetera). Forse ci sono ancora degli aspetti minori da "limare" ma nulla che sia bloccante perché si possa non solo considerare di promuovere l'attuale bozza a una pagina di policy a pieno titolo, ossia Wikipedia:Commissione arbitrale (se lo vedete in blu, è solo perché ora ridirige alla bozza sotto Progetto:Coordinamento) ma, se la comunità darà il suo WP:CONSENSO, anche considerare di indire la prima sessione di elezione della Commissione (verrebbe a puntino il mese di maggio), che non sarebbe distante dal periodo canonico (aprile) indicato nella bozza. Sempre in caso ci sia consenso, dovranno poi esser chiamate in causa altre figure tecniche (in primis, amministratori dell'interfaccia e burocrati, suppongo) per l'attivazione della mailing list e della wiki dedicata, per il NDA, per la creazione dei template e delle pagine di servizio pubbliche su it.wiki eccetera - tutte cose che si possono fare in tempi (si spera) relativamente brevi. Pareri in merito?--SuperSpritz^{l'adminalcolico} 19:12, 23 apr 2024 (CEST)

• Favorevole. Allo scopo di poter rendere subito operativo l'ArbCom una volta che sia stato accertato il consenso, lavorare subito alle funzioni tecniche (per chi possa e sappia farlo) IMHO male non fa. --Argeste ^soffia 19:21, 23 apr 2024 (CEST) PS: credo che occorra segnalare al bar: faccio io

  Concordo --I Need Fresh Blood_{corrispondenze V"V} 19:44, 23 apr 2024 (CEST)

  [@ Argeste] Per attivare il gruppo utente ArbCom basta creare un semplice task che posso aprire e gestire al volo da solo in pochissimi minuti, poi considerando che si può fare il deploy solo nei giorni lavorativi da lunedì a giovedì non c'è alcun problema, la ML la faccio creare altrettanto al volo ed è tutto pronto in realtà! Quindi direi che con il tempo ci siamo pienamente, se per voi va bene, visto che c'è ormai un certo consenso, prossima settimana farò tutto e intanto attendiamo altri pareri, così all'inizio di maggio si è già pronti. Verrà creato anche un account wiki a nome dell'ArbCom (non utilizzabile da nessuno) con il precipuo scopo di far inviare gli appelli dagli account loggati (così da avere conferma del possesso dell'account per il quale si fa l'appello). Intanto, quello che serve davvero, è lavorare sull'inizio delle elezioni, visto che comunque un gruppo utente vuoto e una ML vuota serve a poco e in realtà si potrebbero anche attivare dopo, ma soprattutto bisogna lavorare sulle questioni di itwiki (tipo pagine di servizio o se servono dei template particolari ecc) :D --Superpes15^(talk) 10:55, 27 apr 2024 (CEST)

• Favorevole--Parma1983 20:04, 23 apr 2024 (CEST)

• Consento

  --Bramfab (msg) 20:43, 23 apr 2024 (CEST)

• Favorevole--Sannita - L'admin (a piede) libero 20:41, 23 apr 2024 (CEST)
• Favorevole --Friniate^Arengo 21:20, 23 apr 2024 (CEST)
• Favorevole per tutte le ragioni già espresse da me e dagli altri --valcio ••• 21:40, 23 apr 2024 (CEST)
• Favorevole Accendiamola, anche se non ho partecipato ho seguito. --ValterVB (msg) 21:56, 23 apr 2024 (CEST)
• Favorevole avanti tutta! --Torque (scrivimi!) 22:16, 23 apr 2024 (CEST)
• Favorevole --ʍayßɛ⁷⁵ 07:06, 24 apr 2024 (CEST)
• Favorevole nella speranza che non debba lavorare troppo... --torsolo 08:12, 24 apr 2024 (CEST)
• Favorevole Come [@ ValterVB], ho seguito la proficua discussione ed è il momento di andare avanti.--PandeF (msg) 10:36, 24 apr 2024 (CEST)
• Favorevole - --Klaudio (parla) 12:28, 24 apr 2024 (CEST)
• Favorevole E grazie a tutti coloro che ci hanno lavorato. --Amarvudol (msg) 13:20, 24 apr 2024 (CEST)
• Favorevole --Luix710 (msg) 18:51, 24 apr 2024 (CEST)
• Favorevole come Amarvudol --actor𝄡musicus 𝆓 espr. 20:16, 24 apr 2024 (CEST)
• Favorevole --Antonio1952 (msg) 22:05, 24 apr 2024 (CEST)
• Favorevole sia all'approvazione che all'indizione di elezioni per maggio. Confidando che la spesa valga l'impresa, ma si vedrà solo col tempo. --Hominis Scrivimi 22:26, 24 apr 2024 (CEST)
• Favorevole --Buggia 11:59, 25 apr 2024 (CEST)
• Favorevole --Vesparello (🛵) 19:15, 25 apr 2024 (CEST)
• Favorevole--Aplasia 21:12, 25 apr 2024 (CEST)
• Favorevole --Kirk Dimmi! 21:59, 25 apr 2024 (CEST)
• Favorevole -- .mau. ✉ 11:25, 26 apr 2024 (CEST)
• Favorevole — $ZandDev ↩ 13:59, 26 apr 2024 (CEST)
• Favorevole --Ombra 07:17, 27 apr 2024 (CEST)
• Commento:  La wiki dedicata mi pare molto molto molto più che esagerata, la mailing list è più che sufficiente per questo compito, l'NDA se non ci sono in mezzo dati CU e OS o altri dati privati non serve a nulla (vedete l'arbcom di nlwiki per esempio), ma se è un requisito in più che si è scelto di rendere obbligatorio per chi vuole entrare nell'ArbCom, chiarisco che non ha minimamente senso e non può avere alcun effetto, visto che non utilizzando i dati sensibili CU/OS nessuno sarebbe vincolato da esso, quindi per me è assolutamente inutile e, anzi, forza utenti a vincolarsi legalmente con WMF senza che ce ne sia motivo e senza che WMF fornisca alcuno strumento coperto dal NDA. Ammetto che ci sono alcuni punti che mi lasciano perplesso ma se iniziamo a discuterne non se ne esce. Se chiariamo che è una policy che si può aggiornare sempre e migliorare allora mi ci trovo pienamente! Fatemi inoltre sapere quali diritti utente dovrà avere chi entrerà in questo gruppo (ragionando anche nell'ottica che ci saranno degli utenti non admin), sicuramente visualizzare i contenuti e il testo cancellato (che non richiede un NDA) e immagino i filtri antiabusi privati, e poi? Io metterei la possibilità di attivare l'autenticazione a due fattori e la ricerca nelle pagine cancellate! Sbloccare/bloccare serve? Serve altro? Visto che non ci sono diritti privati di CU e OS l'appartenenza al gruppo sarebbe gestibile interamente dai burocrati (che possono anche rimuovere oltre che aggiungere)! --Superpes15^(talk) 10:28, 27 apr 2024 (CEST)

  [@ Superpes15] Chiaramente le policy dell'ArbCom, come tutte le policy di Wikipedia, non sono scolpite nella pietra e sono suscettibili di aggiornamenti in corso d'opera, anche sulla base dell'esperienza del funzionamento e della verifica sul campo delle effettive necessità (del tipo: se qualcosa non dovesse servire o non dovesse andar bene, si può sempre togliere o modificare opportunamente). L'NDA discende dal fatto che i membri dell'ArbCom devono poter vedere anche eventuali revdel oscurati, quindi ci sono dei diritti OS in ballo, ma ma anche dal fatto che l'ArbCom potrebbe esser chiamato a valutare anche sulla base di elementi off-wiki, come per esempio mail eccetera, se queste rientrano fra le violazioni dell'UCoC (per esempio, minacce o insulti inviati con la funzione "Invia e-mail a questo utente" che però è a tutti gli effetti uno scambio privato e non pubblico), e chiaramente questo andrebbe fatto su canali riservati. In tal caso un NDA è una forma di garanzia di riservatezza. La wikina dedicata è una cosa che hanno gran parte degli ArbCom (come del resto abbiamo le wiki dedicate per sysop e CU) e serve per ospitare le discussioni interne all'ArbCom stesso che sono al tempo stesso riservate (vedi votazione sui singoli casi, da qualche parte andrà tenuta registrata) ma anche eventualmente tracciabili e rese visibili a WMF o un U4C se lo dovesse richiedere (e concordo con l'obbligo di 2FA). Da un punto di vista di privilegi, sono richieste le possibilità di vedere i revdel, come detto, e i contenuti cancellati (voci cancellate ecc.): ma questi diritti credo siano gestiti dai burocrati, visto che gli admin ce li hanno "di serie". --SuperSpritz^{l'adminalcolico} 11:52, 27 apr 2024 (CEST)