Wikipédia Discussão:Eliminadores

Para encontro futuro das discussões sobre a implementação deste estatuto: Wikipedia:Esplanada/propostas/Criação de grupo de usuários com acesso à eliminação de páginas (21mai2010) e Wikipedia:Tentativa de consenso/Estatuto de eliminador.--Lépton 14h58min de 16 de agosto de 2010 (UTC)

Aviso formal, com ligações para as regras e políticas

Se administrador recebe um aviso na discussão com todas as regras que ele obrigatoriamente deve conhecer, por que o mesmo não acontece com os eliminadores? Só um "parabéns" não é o bastante, tem gente por aí apagando página e deixando pra trás todos os redirects e afluentes, eliminando imagem e deixando ligação no verbete... assim não dá, se é pra fazer que faça direito. --viniciusmc (discussão) 03h13min de 6 de setembro de 2010 (UTC)

Vinicius, por favor, caso identifique falhas no procedimento de algum elimin, dirija-se a discussão do café e exponha. Tenho certeza que todos estamos interessados em acertar. Obrigado. Fra Amats, ELM ^disputatio 03h22min de 6 de setembro de 2010 (UTC)

Também estou certo disso, mas a questão aqui é voltada em primeiro lugar não aos eliminadores, mas aos responsáveis por conceder a ferramenta a eles. Além do mais, em caso de dúvidas um aviso formal só viria a facilitar as coisas. --viniciusmc (discussão) 03h33min de 6 de setembro de 2010 (UTC)

[Ver]

Eliminador proteger páginas vandalizadas

Ver também: Wikipédia:Usuários

Estou propondo que os usuários WP:Eliminadores possam proteger páginas que são vandalizadas constantemente. Acho que isso seria uma boa, já que tem páginas que são vandalizadas constantemente e os pedidos ficam mofando por dias e dias.... O que acham? Vitor Mazuco^Msg 01h33min de 28 de junho de 2013 (UTC)

Sinto falta de uma tabela comparativa com as funções administrativas, o que cada um pode ou não pode fazer, marcados com Sim e Não sabe? Facilitaria bastante para a comunidade. Constatei algo estranho: por que existem tão poucos interwikis em WP:Eliminadores? Vulcan (discussão) 05h39min de 28 de junho de 2013 (UTC)

Achei a tabela, está em Wikipédia:Usuários#Tabela, vou analisar com calma. Vulcan (discussão) 05h45min de 28 de junho de 2013 (UTC)

Isso foi discutido e rejeitado há seis meses e aqui estamos novamente. Alguma coisa mudou de lá pra cá? Surgiu algum motivo que impeça os eliminadores de se candidatarem a administradores? Se isso for aprovado, um eliminador que for reversor poderá proteger, apagar e eliminar. Se pelo menos houvesse um simples motivo pra que eles não se candidatassem a administrador, tudo bem, mas não há. Mais um pouco e pedem pra renomear usuários também.—T_ele^s«fale comigo» 07h04min de 28 de junho de 2013 (UTC)

O único motivo é: existe o estatuto de eliminador. Se ele não existir(ver seção abaixo) todos eles virariam administradores, e nada impediria eles de focar apenas em eliminação se assim desejarem. Vulcan (discussão) 07h46min de 28 de junho de 2013 (UTC)

Não faz sentido. Se o estatuto de eliminador não existir, os eliminadores deixam de ser eliminadores. Onde está escrito que eles passam a ser administradores? Não existir eliminadores seria mais um motivo pra os atuais se candidatarem a administrador.—T_ele^s«fale comigo» 07h52min de 28 de junho de 2013 (UTC)

Sim não está escrito em nenhum lugar, é uma ideia, promover eles, mas atropela as regras, eu sei. Precisa ver se todos cumprem os requisitos, Citação: Wikipédia:Administradores escreveu: «2.000 edições no domínio principal e uma conta com seis meses de registro"»(além de precisar do crivo da comunidade, o que somando tudo é uma exigência extremamente alta e desnecessária, podia afrouxar isso como fazem outras wikis), Citação: Wikipédia:Eliminadores escreveu: «possuir 1.000 edições no domínio principal e ter uma conta com seis meses de registro.», assumindo que conheçam as regras são 1000 edições no domínio principal que separam um do outro. E entendo seu ponto de vista que eles que deveriam se eleger e não remover o estatuto e automaticamente promovê-los a adms. Talvez a ideia de promover automaticamente não seja a melhor por passar por cima das regras atuais de tornar-se administrador e deveríamos focar apenas em extinguir o estatuto de Eliminador, e aí quem quiser ser administrador que se candidate. Vulcan (discussão) 13h13min de 28 de junho de 2013 (UTC)

Como foi discutido recentemente, recuso-me a participar dessa discussão. Há muitos problemas por aqui e poderíamos estar tratando de outros ao invés de nos repetirmos nos mesmos.--Mister Sanderson (discussão) 23h54min de 27 de julho de 2013 (UTC)

Adaptado de Wikipédia:Usuários, atualmente as diferenças entre eles são:

O que um Eliminador não pode fazer mas um Administrador pode:

ver registros de filtros de edições detalhados ver filtros de edições consultar API em lotes de 5.000. editar páginas semi-protegidas bloquear um endereço IP, uma gama de IPs ou um usuário registrado. impedir um usuário de enviar emails editar o domínio MediaWiki. editar páginas totalmente protegidas. editar as subpáginas .css or .js de outros usuários. ser imune a bloqueios aplicados ao seu IP ou faixa de IPs. marcar reversões como as edições de bot mover páginas com suas subpáginas proteger e desproteger páginas. reverter edições usando o botão "voltar".(rollback, igual a Reversores) ver uma lista de páginas que ninguém vigia. altegrar os grupos de outro usuário. (+/− reversor,+/− autorrevisor+/−  isento de bloqueio)

Tabela completa dos Direitos de acesso

Permitido Herdado automaticamente Herdado por política Limitado por política         Privilégios comuns Privilégio Todos Registrado (Auto)confirmado Autorrevisor Reversor Eliminador Robos Administrador Outros Ver o registo de edições (abusefilter-log)                 Ver filtros de edições (abusefilter-view)                 Fundir as suas contas (centralauth-merge)                 Criar novas contas de utilizador (createaccount)                 Editar as suas próprias preferências (editmyoptions)                 Editar os seus dados privados (por exemplo, endereço de correio eletrónico, nome real) e pedir mensagens de correio para reinício da palavra-passe (editmyprivateinfo)                 Editar a sua lista de páginas vigiadas (note que algumas ações continuarão a adicionar páginas, mesmo sem ter este direito) (editmywatchlist)                 Ocultar tópicos e mensagens de conversas estruturadas (flow-hide)                 Criar URL curtos (urlshortener-create-url)                 Ver os seus próprios dados privados (ex.: endereço de correio eletrónico, nome real) (viewmyprivateinfo)                 Ver a sua lista de páginas vigiadas (viewmywatchlist)                 Usar a interface de teste do redimensionamento VIPS Special:VipsTest (vipsscaler-test)                 Criar páginas (que não sejam páginas de discussão) (createpage)                 Criar páginas de discussão (createtalk)                 Editar páginas (edit)                 Ler páginas (read)                 Usar a API de escrita (writeapi)                 Aplicar etiquetas juntamente com as alterações (applychangetags)               Adicionar ou remover etiquetas arbitrárias em revisões e entradas de registo individuais (changetags)               Editar os seus próprios ficheiros CSS de utilizador (editmyusercss)               Editar os seus próprios ficheiros JavaScript de utilizador (editmyuserjs)               Editar os ficheiros JSON do próprio utilizador (editmyuserjson)               Marcar como encerrados tópicos de conversas estruturadas (flow-lock)               Marcar edições como menores (minoredit)               Gerir concessões de permissões OAuth (mwoauthmanagemygrants)               Purgar a cache de uma página (purge)               Sobrescrever um ficheiro existente carregado pelo mesmo utilizador (reupload-own)               Enviar e-mails a outros utilizadores (sendemail)               Ver o registo da lista de barramento de spam (spamblacklistlog)               Ver entradas de registo do filtro de edições detalhadas (abusefilter-log-detail)           Não ser afetado pelos limites de frequência de edição baseados em endereços IP (autoconfirmed)             Editar páginas protegidas com "Permitir apenas utilizadores autoconfirmados" (editsemiprotected)             Editar mensagens de outros utilizadores nas conversas estruturadas (flow-edit-post)           Mover páginas (move)         Mover categorias (move-categorypages)           Marcar edições de outros utilizadores como patrulhadas (patrol)           Sobrescrever um ficheiro existente (reupload)           Executar ações despoletadoras do captcha sem ter de passar pelo captcha (skipcaptcha)             Reiniciar vídeos falhados ou transcodificados para serem novamente inseridos na fila de tarefas. (transcode-reset)           Carregar ficheiros (upload)           Gravar livros como página comunitária (collectionsaveascommunitypage)           Gravar livros como página de utilizador (collectionsaveasuserpage)           Ter edições automaticamente marcadas como patrulhadas (autopatrol)         Burocratas Editar páginas protegidas com "Permitir apenas autorrevisores" (editautoreviewprotected)         Burocratas Mover ficheiros (movefile)       Mostrar entradas de registo de filtros de abuso marcados como privados (abusefilter-log-private)     Bloquear ou desbloquear a capacidade de edição de outros utilizadores (block)     Reverter rapidamente as edições do último utilizador que editou uma página em particular (rollback)     Ver uma lista de páginas não vigiadas (unwatchedpages)     Pesquisar páginas eliminadas (browsearchive)     Eliminar páginas (delete)     Ver entradas de histórico eliminadas, sem o texto associado (deletedhistory)     Ver texto eliminado e mudanças entre revisões eliminadas (deletedtext)     Mover páginas raiz de utilizadores (move-rootuserpages)     Burocratas Eliminar páginas em massa (nuke)     Ativar autenticação de dois fatores (oathauth-enable)     Burocratas Verificador Supervisor Adm. de Interface Importador Não criar um redirecionamento do nome antigo quando uma página é movida (suppressredirect)       Restaurar uma página (undelete)     Usar limites superiores nas consultas (queries) via API (apihighlimits)     Não desencadear o aviso de mensagens novas ao fazer edições menores a páginas de discussão (nominornewtalk)   Não afetado pelos limites de velocidade de operação (noratelimit)     Criadores de contas Burocratas Steward Ser tratado como um processo automatizado (bot)   Pseudorobô Modificar filtros de edições (abusefilter-modify)   Modificar filtros de edições com ações restritas (abusefilter-modify-restricted)   Ver filtros de abuso marcados como privados (abusefilter-view-private)   Impedir um utilizador de enviar e-mails (blockemail)   Eliminar etiquetas da base de dados (deletechangetags)   Eliminar e restaurar entradas específicas de registos (deletelogentry)   Supervisor Eliminar e restaurar edições específicas de páginas (deleterevision)   Supervisor Editar o modelo de conteúdo de uma página (editcontentmodel)   Editar a interface de utilizador (editinterface)   Adm. de Interface Editar páginas protegidas (sem proteção em cascata) (editprotected)   Editar JSON global do site (editsitejson)   Adm. de Interface Editar os ficheiros JSON de outros utilizadores (edituserjson)   Adm. de Interface Eliminar tópicos e mensagens das conversas estruturadas (flow-delete)   Desativar bloqueios globais localmente (globalblock-whitelist)   Importar páginas de outras wikis (import)   Importador Contornar bloqueios de IP, bloqueios automáticos e bloqueios de gamas de IP (ipblock-exempt)   Isento de bloqueio de IP Criar e (des)ativar etiquetas (managechangetags)   Marcar edições revertidas como edições de robô (markbotedits)   Enviar uma mensagem para vários utilizadores ao mesmo tempo (massmessage)   Fundir o histórico de edições de páginas (mergehistory)   Mover páginas com as suas subpáginas (move-subpages)   Contornar as verificações de semelhança de nomes (spoofing) (override-antispoof)   Burocratas Modificar níveis de proteção e editar páginas protegidas (protect)   Sobrescrever localmente ficheiros no repositório partilhado de imagens (reupload-shared)   Definir mentor do utilizador (setmentor)   Contornar a lista de títulos e nomes de utilizador interditos (tboverride)   Ver o registo da lista de títulos interditos (titleblacklistlog)   Ver informação sobre a atividade atual de transcodificação (transcode-status)   Privilégios específicos Privilégio Estatuto específico Ver dados privados no registo de abusos (abusefilter-privatedetails) Verificador Ver o registo de consultas dos detalhes privados do filtro de abusos (abusefilter-privatedetails-log) Verificar os endereços IP e outras informações de um utilizador (checkuser) Ver o registo das verificações de utilizadores (checkuser-log) Ver entradas ocultadas do registo de abusos (abusefilter-hidden-log) Supervisor Ocultar entradas do filtro de abusos (abusefilter-hide-log) Suprimir tópicos e mensagens das conversas estruturadas (flow-suppress) Bloquear ou desbloquear um nome de utilizador, escondendo-o ou deixando de escondê-lo do público (hideuser) Ver registos privados (suppressionlog) Ver, ocultar e restaurar revisões de páginas específicas para qualquer utilizador (suppressrevision) Ver revisões ocultas para qualquer utilizador (viewsuppressed) Editar CSS global do site (editsitecss) Adm. de Interface Editar JavaScript global do site (editsitejs) Editar os ficheiros CSS de outros utilizadores (editusercss) Editar os ficheiros JS de outros utilizadores (edituserjs) Contornar bloqueio automátido de nós de saída TOR (torunblocked) Isento de bloqueio de IP Importar páginas de um ficheiro xml (importupload) Importador Criar espaços de conversas estruturadas em qualquer local (flow-create-board) FlowBot Eliminar páginas com histórico grande (bigdelete) Steward Privilégios de mudanças de grupos Privilégio Estatuto específico Pode adicionar e remover grupos: Reversores, Eliminadores, Autorrevisores, Editores da interface, Pseudorrobôs, Criadores de contas, Administradores, Administradores da interface, Burocratas, Robôs, Utilizadores confirmados Burocratas Pode adicionar e remover grupos: Reversores, Autorrevisores, Utilizadores confirmados, Criadores de contas, Pseudorrobôs, Isentos de bloqueio de IP Administrador Remover a própria conta do grupo: Pseudorrobôs Pseudorobô Editar todos os privilégios de utilizador (userrights) Steward

Concordo com a proposta do Mazuco. É o ideal. Mar França (discussão) 20h36min de 28 de junho de 2013 (UTC)

Promover eliminadores

Citação: WP:Eliminadores escreveu: «Há atualmente 16 eliminadores na Wikipédia lusófona. Juntamente com os administradores, constituem um total de 67 usuários com esta permissão."»

Update: nem precisa analisar com calma, pelo que vi lá e li em WP:Eliminadores ... por que não desativam esse estatuto que poucas wikis usam e promovem todos os eliminadores a administradores? Vulcan (discussão) 06h12min de 28 de junho de 2013 (UTC)

Comentário Aliás, por que o comentário do usuário GRS73 D​ C​ E​ F Citação: Discordo, quem quer acesso a lixo eliminado se candidate a administração, a criação deste grupo é um incentivo ao atual ócio administrativo. Fabiano msg 21h31min de 27 de maio de 2010 (UTC) foi ignorado e seguiram adiante e mesmo assim criaram o estatuto de eliminador? Isso viola nossas políticas. Vulcan (discussão) 06h24min de 28 de junho de 2013 (UTC)

• Respondendo a perqunta; por que eliminar páginas é diferente das demais funções de administração. Para eliminar uma página basta que esta se enquadre nas regras de ER, ESR ou que a PE tenha como resultado a eliminação. Basta clicar em um botão e pronto. Para bloquear, proteger, desproteger, suprimir edições tem que ter capacidade de análise (embora alguns que tem o estatuto de administrador tenham grande dificuldade de fazer). A pouco tempo tínhamos um eliminador que aplicava resultados de acordo com sua posição "inclusionista", o que levou a um pedido de remoção de seu estatuto e a exemplo dos políticos brasileiros renunciou antes deste ser concluído; imagine se fosse administrador. Na atual lista de 21 temos ausentes, que receberiam a função de administrador apenas para ter mais um estatuto sem uso. Qual a vantagem que o projeto recebe em troca? Ter mais nomes na lista de administradores? Este projeto precisa de menos listas e mais atividade prática. E sobre minha posição na época da criação, continua a mesma. Sou totalmente contra esta praga de novos estatutos, hoje a primeira coisa que usuários fazem antes de qualquer coisa é desejar um. Chega a ser cômico, mas como não tenho estatuto de autorrevisor (por que não quero), não posso mover páginas protegidas para usuários registrados, tenho que pedir que alguém mova para mim. Estou aqui desde maio de 2006 e até hoje ninguém conseguiu me explicar o fascínio dos estatutos (ajuda em um projeto voluntário? Desculpe, mas esta eu não acredito). Fabiano ^msg 06h47min de 28 de junho de 2013 (UTC)

E não seria melhor desativar esse estatuto de eliminador? Pois se desativar e promover os eliminadores a administradores e eles continuarem apenas eliminando no pior dos casos eis o que acontecerá: os eliminadores seriam administradores que estariam focados em eliminação. Ou seja, não há prejuízo algum(e se houver abuso é só remover o estatuto), os administradores tem várias opções do que fazer e escolhem quais desejam fazer, não precisa fatiar o trabalho em 200 estatutos, só burocratiza a coisa quando eles querem fazer outras tarefas, e se um eliminador quiser algum dia fazer outra tarefa como proteger uma página por exemplo ele poderá fazer, isso ajuda a desafogar as páginas de pedidos e também aliviar os administradores que estão sobrecarregados. Vulcan (discussão) 07h27min de 28 de junho de 2013 (UTC)

Concordo Eliminador e administrador são funções diferentes. O eliminador tem o privilégio de mexer "à vontade" com as páginas, já o administrador tem o privilégio extra de mexer "à vontade" com os próprios usuários. Não faz sentido dar a um editor o poder de eliminar uma página, mas não dar o poder de proteger a página contra IPs. Albmont (discussão) 11h15min de 28 de junho de 2013 (UTC)

Claro, as páginas q são vandalizadas a toda hora não _{"não" escrito por acidente, conforme abaixo} é preciso pedir "pelo amor de deus" pra proteger. Vitor Mazuco^Msg 11h38min de 28 de junho de 2013 (UTC)

Não? Pela minha experiência, não só é preciso pedir pelo amor de deus como ainda prometer pagar o dízimo para o administrador. E quando protegem, é por um dia ou uma semana, para páginas que são vandalizadas todo mês durante anos. Albmont (discussão) 11h58min de 28 de junho de 2013 (UTC)

É sim Albmont. Errei ali. Vitor Mazuco^Msg 16h25min de 28 de junho de 2013 (UTC)

• Pessoalmente, não quero nem nunca quis ter acesso a ferramentas administrativas. Acho que actualmente, os utilizadores que possuem esse estatuto desempenham o seu papel razoavelmente (WTF?... pronto, alguns...). Não acho que seja solução, acabar com o cargo de eliminador. Como disse na minha proposta anterior, à semelhança do que ocorre nos bloqueios feitos por reversores, os eliminadores também podiam ter acesso restrito à protecção de páginas que são forçosamente vandalizadas, para não só agilizar o trabalho dos administradores mas também para proteger o histórico dos artigos. VítoR™  • (D) 13h21min de 28 de junho de 2013 (UTC)

E mais, proteger uma página vandalizada não requer muito esforço para compreender, é praticamente um trabalho robô. Vitor Mazuco^Msg 14h46min de 28 de junho de 2013 (UTC)

Como eu já disse 10100 vezes, era para ser um trabalho mais robótico. Página vandalizada -> proteção automática. Não sei porque é preciso verificar o histórico, analisar a quantidade de vandalismos, etc. Para mim, isto se chama masoquismo. Albmont (discussão) 17h52min de 28 de junho de 2013 (UTC)

Fazer como nessa proteção? A página foi vandalizada uma vez e tem cerca de 25 acessos/dia mas como é página de Ajuda tudo bem. Agora se aplicar isso para artigo vai trancar dezenas de milhares de artigos por mês, aí vai ser uma gritaria geral dos defensores dos IPs, eu sei que resolve mas acho difícil de se aplicar na prática por causa da polêmica envolvida, então nem adianta muito ficar repetindo zilhões de vezes essa ideia. Vulcan (discussão) 18h12min de 28 de junho de 2013 (UTC)

Adianta sim, foi por ficarmos repetindo WP:V, WP:V, WP:V, que cada vez mais tem editores que levam WP:V à sério, e tentam evitar transformar a Wikipédia em um grande blogue. Albmont (discussão) 18h35min de 28 de junho de 2013 (UTC)

Ideia para facilitar a proteção Adicionar ao santo gadget FastButtons a possibilidade de pedir proteção Wikipédia:Pedidos/Proteção de forma mais automatizada. Clicar em um botão Solicitar proteção da página e um pop-up surgir com a mensagem que está no topo da Wikipédia:Pedidos/Proteção(aquela caixa rosa no topo) e depois um botão Solicitar proteção para confirmar. Vulcan (discussão) 20h26min de 2 de julho de 2013 (UTC)

Páginas com mais de 10 reversões nos últimos 30 dias (reversões identificadas pelo sumário). Se isso ajudar posso fazer uma ferramenta para gerar isso automaticamente. ^Danilo.mac_(discussão) 21h57min de 28 de julho de 2013 (UTC)

Muito bom, Danilo! Acho que ajuda sim.—T_ele^s«fale comigo» 00h01min de 29 de julho de 2013 (UTC)

[Ver]

Desativar o estatuto de Eliminador

Ver também: Wikipédia:Pedidos de administração/doc, Wikipédia:Esplanada/propostas/Eliminador proteger páginas vandalizadas (27jun2013) e Wikipédia:Esplanada/geral/Eliminaram os eliminadores? (26jun2013)

O que um Eliminador não pode fazer mas um Administrador pode:

ver registros de filtros de edições detalhados ver filtros de edições consultar API em lotes de 5.000. editar páginas semi-protegidas bloquear um endereço IP, uma gama de IPs ou um usuário registrado. impedir um usuário de enviar emails editar o domínio MediaWiki. editar páginas totalmente protegidas. editar as subpáginas .css or .js de outros usuários. ser imune a bloqueios aplicados ao seu IP ou faixa de IPs. marcar reversões como as edições de bot mover páginas com suas subpáginas proteger e desproteger páginas. reverter edições usando o botão "voltar".(rollback, igual a Reversores) ver uma lista de páginas que ninguém vigia. altegrar os grupos de outro usuário. (+/− reversor,+/− autorrevisor+/−  isento de bloqueio) Opinar como administrador em discussões de bloqueio, contando no quórum para qualquer tomada de decisão

Tabela completa dos Direitos de acesso

Permitido Herdado automaticamente Herdado por política Limitado por política         Privilégios comuns Privilégio Todos Registrado (Auto)confirmado Autorrevisor Reversor Eliminador Robos Administrador Outros Ver o registo de edições (abusefilter-log)                 Ver filtros de edições (abusefilter-view)                 Fundir as suas contas (centralauth-merge)                 Criar novas contas de utilizador (createaccount)                 Editar as suas próprias preferências (editmyoptions)                 Editar os seus dados privados (por exemplo, endereço de correio eletrónico, nome real) e pedir mensagens de correio para reinício da palavra-passe (editmyprivateinfo)                 Editar a sua lista de páginas vigiadas (note que algumas ações continuarão a adicionar páginas, mesmo sem ter este direito) (editmywatchlist)                 Ocultar tópicos e mensagens de conversas estruturadas (flow-hide)                 Criar URL curtos (urlshortener-create-url)                 Ver os seus próprios dados privados (ex.: endereço de correio eletrónico, nome real) (viewmyprivateinfo)                 Ver a sua lista de páginas vigiadas (viewmywatchlist)                 Usar a interface de teste do redimensionamento VIPS Special:VipsTest (vipsscaler-test)                 Criar páginas (que não sejam páginas de discussão) (createpage)                 Criar páginas de discussão (createtalk)                 Editar páginas (edit)                 Ler páginas (read)                 Usar a API de escrita (writeapi)                 Aplicar etiquetas juntamente com as alterações (applychangetags)               Adicionar ou remover etiquetas arbitrárias em revisões e entradas de registo individuais (changetags)               Editar os seus próprios ficheiros CSS de utilizador (editmyusercss)               Editar os seus próprios ficheiros JavaScript de utilizador (editmyuserjs)               Editar os ficheiros JSON do próprio utilizador (editmyuserjson)               Marcar como encerrados tópicos de conversas estruturadas (flow-lock)               Marcar edições como menores (minoredit)               Gerir concessões de permissões OAuth (mwoauthmanagemygrants)               Purgar a cache de uma página (purge)               Sobrescrever um ficheiro existente carregado pelo mesmo utilizador (reupload-own)               Enviar e-mails a outros utilizadores (sendemail)               Ver o registo da lista de barramento de spam (spamblacklistlog)               Ver entradas de registo do filtro de edições detalhadas (abusefilter-log-detail)           Não ser afetado pelos limites de frequência de edição baseados em endereços IP (autoconfirmed)             Editar páginas protegidas com "Permitir apenas utilizadores autoconfirmados" (editsemiprotected)             Editar mensagens de outros utilizadores nas conversas estruturadas (flow-edit-post)           Mover páginas (move)         Mover categorias (move-categorypages)           Marcar edições de outros utilizadores como patrulhadas (patrol)           Sobrescrever um ficheiro existente (reupload)           Executar ações despoletadoras do captcha sem ter de passar pelo captcha (skipcaptcha)             Reiniciar vídeos falhados ou transcodificados para serem novamente inseridos na fila de tarefas. (transcode-reset)           Carregar ficheiros (upload)           Gravar livros como página comunitária (collectionsaveascommunitypage)           Gravar livros como página de utilizador (collectionsaveasuserpage)           Ter edições automaticamente marcadas como patrulhadas (autopatrol)         Burocratas Editar páginas protegidas com "Permitir apenas autorrevisores" (editautoreviewprotected)         Burocratas Mover ficheiros (movefile)       Mostrar entradas de registo de filtros de abuso marcados como privados (abusefilter-log-private)     Bloquear ou desbloquear a capacidade de edição de outros utilizadores (block)     Reverter rapidamente as edições do último utilizador que editou uma página em particular (rollback)     Ver uma lista de páginas não vigiadas (unwatchedpages)     Pesquisar páginas eliminadas (browsearchive)     Eliminar páginas (delete)     Ver entradas de histórico eliminadas, sem o texto associado (deletedhistory)     Ver texto eliminado e mudanças entre revisões eliminadas (deletedtext)     Mover páginas raiz de utilizadores (move-rootuserpages)     Burocratas Eliminar páginas em massa (nuke)     Ativar autenticação de dois fatores (oathauth-enable)     Burocratas Verificador Supervisor Adm. de Interface Importador Não criar um redirecionamento do nome antigo quando uma página é movida (suppressredirect)       Restaurar uma página (undelete)     Usar limites superiores nas consultas (queries) via API (apihighlimits)     Não desencadear o aviso de mensagens novas ao fazer edições menores a páginas de discussão (nominornewtalk)   Não afetado pelos limites de velocidade de operação (noratelimit)     Criadores de contas Burocratas Steward Ser tratado como um processo automatizado (bot)   Pseudorobô Modificar filtros de edições (abusefilter-modify)   Modificar filtros de edições com ações restritas (abusefilter-modify-restricted)   Ver filtros de abuso marcados como privados (abusefilter-view-private)   Impedir um utilizador de enviar e-mails (blockemail)   Eliminar etiquetas da base de dados (deletechangetags)   Eliminar e restaurar entradas específicas de registos (deletelogentry)   Supervisor Eliminar e restaurar edições específicas de páginas (deleterevision)   Supervisor Editar o modelo de conteúdo de uma página (editcontentmodel)   Editar a interface de utilizador (editinterface)   Adm. de Interface Editar páginas protegidas (sem proteção em cascata) (editprotected)   Editar JSON global do site (editsitejson)   Adm. de Interface Editar os ficheiros JSON de outros utilizadores (edituserjson)   Adm. de Interface Eliminar tópicos e mensagens das conversas estruturadas (flow-delete)   Desativar bloqueios globais localmente (globalblock-whitelist)   Importar páginas de outras wikis (import)   Importador Contornar bloqueios de IP, bloqueios automáticos e bloqueios de gamas de IP (ipblock-exempt)   Isento de bloqueio de IP Criar e (des)ativar etiquetas (managechangetags)   Marcar edições revertidas como edições de robô (markbotedits)   Enviar uma mensagem para vários utilizadores ao mesmo tempo (massmessage)   Fundir o histórico de edições de páginas (mergehistory)   Mover páginas com as suas subpáginas (move-subpages)   Contornar as verificações de semelhança de nomes (spoofing) (override-antispoof)   Burocratas Modificar níveis de proteção e editar páginas protegidas (protect)   Sobrescrever localmente ficheiros no repositório partilhado de imagens (reupload-shared)   Definir mentor do utilizador (setmentor)   Contornar a lista de títulos e nomes de utilizador interditos (tboverride)   Ver o registo da lista de títulos interditos (titleblacklistlog)   Ver informação sobre a atividade atual de transcodificação (transcode-status)   Privilégios específicos Privilégio Estatuto específico Ver dados privados no registo de abusos (abusefilter-privatedetails) Verificador Ver o registo de consultas dos detalhes privados do filtro de abusos (abusefilter-privatedetails-log) Verificar os endereços IP e outras informações de um utilizador (checkuser) Ver o registo das verificações de utilizadores (checkuser-log) Ver entradas ocultadas do registo de abusos (abusefilter-hidden-log) Supervisor Ocultar entradas do filtro de abusos (abusefilter-hide-log) Suprimir tópicos e mensagens das conversas estruturadas (flow-suppress) Bloquear ou desbloquear um nome de utilizador, escondendo-o ou deixando de escondê-lo do público (hideuser) Ver registos privados (suppressionlog) Ver, ocultar e restaurar revisões de páginas específicas para qualquer utilizador (suppressrevision) Ver revisões ocultas para qualquer utilizador (viewsuppressed) Editar CSS global do site (editsitecss) Adm. de Interface Editar JavaScript global do site (editsitejs) Editar os ficheiros CSS de outros utilizadores (editusercss) Editar os ficheiros JS de outros utilizadores (edituserjs) Contornar bloqueio automátido de nós de saída TOR (torunblocked) Isento de bloqueio de IP Importar páginas de um ficheiro xml (importupload) Importador Criar espaços de conversas estruturadas em qualquer local (flow-create-board) FlowBot Eliminar páginas com histórico grande (bigdelete) Steward Privilégios de mudanças de grupos Privilégio Estatuto específico Pode adicionar e remover grupos: Reversores, Eliminadores, Autorrevisores, Editores da interface, Pseudorrobôs, Criadores de contas, Administradores, Administradores da interface, Burocratas, Robôs, Utilizadores confirmados Burocratas Pode adicionar e remover grupos: Reversores, Autorrevisores, Utilizadores confirmados, Criadores de contas, Pseudorrobôs, Isentos de bloqueio de IP Administrador Remover a própria conta do grupo: Pseudorrobôs Pseudorobô Editar todos os privilégios de utilizador (userrights) Steward

Pelo que andei observando em proposta recente, e vendo como outras wikis fazem(a grande maioria não tem esse estatuto), cheguei à conclusão que o estatuto de WP:Eliminador não precisa existir pois os mesmos podem se candidatar a WP:Administradores e continuar - se quiserem - a fazer exatamente a mesma coisa(eliminação de páginas) com a vantagem de agregar funções extras que um administrador pode fazer(ver tabelas acima). Hoje temos poucos administradores fazendo com que eles estejam sobrecarregados, e há uma carência de WP:Reversores para reverter disparates e combater vandalismos(Administradores podem fazer tudo o que Reversores fazem) e gente protegendo páginas(coisa que Eliminadores não podem fazer). Não existe motivo hoje para se candidatar ao estatuto de eliminador e não de administrador, não precisa se candidatar apenas a uma parte das ferramentas, pode se candidatar a todas e usar apenas a parte que desejar. Quanto a possíveis abusos que alguém achar que eles poderiam cometer, se isso acontecer é só desnomear a pessoa, simples. E os que estão ativos e quiserem continuar com as funções de eliminar seria só se candidatar a administradores. Então é isso, vejo que eliminar o estatuto de Eliminador irá ajudar a comunidade. Vulcan (discussão) 16h37min de 1 de julho de 2013 (UTC)

Importante: Administradores não possuem obrigações, eles possuem ferramentas. O estatuto de administrador apenas faz isso: dá mais ferramentas a usuários que as desejarem para, voluntariamente, realizarem determinados tipos de edições que sejam de seu interesse; estes podem as usar ou não quando e se desejarem. Ser administrador não é algo remunerado, o estatuto não é para se sentir melhor ou superior que os outros, Citação: WP:A escreveu: «Os sysops não possuem "autoridade" em especial», é apenas para ter algumas ferramentas extras para realizar determinados tipos de edições. Vulcan (discussão) 23h22min de 1 de julho de 2013 (UTC)

Discussão

• Vulcan, existe mais uma prerrogativa para administradores: opinar como tal em DBs e, portanto, contar no quórum necessário para qualquer decisão. E eu gostaria de te fazer uma sugestão: poderia abrir um espaço aqui embaixo para que os eliminadores opinem se gostariam de virar sysops e, se não, por que? José Luiz ^disc 17h12min de 1 de julho de 2013 (UTC)

Boa ideia, aí concentra a discussão aqui, adicionei abaixo. Vulcan (discussão) 17h30min de 1 de julho de 2013 (UTC)

Convoquei no café dos eliminadores. Espero que eles opinem! José Luiz ^disc 20h58min de 1 de julho de 2013 (UTC)

Sou favorável a esta proposta. Helder 17h19min de 1 de julho de 2013 (UTC)

Penso que há aí em cima um erro. Os eliminadores não podem ver a lista de páginas que ninguém vigia ? Não sou administrador e posso vê-la. --João Carvalho ^{deixar mensagem} 21h24min de 1 de julho de 2013 (UTC)

Não. Conforme a Especial:Lista de privilégios de grupos, essa permissão é exclusividade dos administradores e dos reversores. Helder 21h27min de 1 de julho de 2013 (UTC)

• Nós vamos promover todos a administradores? Gustavo ^fala!!-fiz 21h49min de 1 de julho de 2013 (UTC)

Por mim sim, mas isso parece que "passa por cima" das regras atuais e talvez enfrente alguma resistência, se desativar o estatuto de Eliminador atualmente e seguir as regras seria necessário que eles se candidatem a adm pelo processo normal. Vulcan (discussão) 22h28min de 1 de julho de 2013 (UTC)

Não acho viável. É necessário avaliar caso a caso. O processo do PDA não pode ser ignorado. Sei que temos um número muito pequeno de administradores e gostaria muito que esse número aumentasse, mas para isso é necessário haver mais PDAs, que é a forma legítima de escolher um administrador. Érico Wouters ^msg 22h24min de 1 de julho de 2013 (UTC)

Contra essa proposta. Hoje há eliminadores ativos e q fazem muito. Até mais q sysop. Há outros q não. Mas isso tbm ocorre com os sysop, que tem alguns deles q não fazem nada, apenas fazem uma edição aqui e ali só pra não cair no inativo e perderam o estatuto. Vitor Mazuco^Msg 21h51min de 1 de julho de 2013 (UTC)

Vitor, o estatuto não interessa para nada. Se ajudarem o projecto, por pouco que seja, deixe-os em paz. É melhor pouco do que nada ! --João Carvalho ^{deixar mensagem} 22h17min de 1 de julho de 2013 (UTC)

Não João, não estou me referindo a esses usuários, eu até apoio a delegação de tarefas, mas estou referindo aqueles q nada fazem, e só faz o básico do básico pra não perder o estatuto por medo. Ficam presos a ele mas não dão motivos pra continuar no cargo. Vitor Mazuco^Msg 15h57min de 2 de julho de 2013 (UTC)

Mas eles não precisam fazer nada. Não há obrigações, são apenas ferramentas extras que eles estão permitidos a usar quando e se querem, eles são todos voluntários, não pode exigir nada deles, isso aqui não é uma empresa. Vulcan (discussão) 16h13min de 2 de julho de 2013 (UTC)

Respondendo ao Gusta: Não, quem deseja o estatuto de administrador deve se candidatar. Quando a proposta para mim não mudaria nada, continuaria tendo usuários que são ativos no processo de manutenção do projeto e outros qnão. Mas como para se conseguir um estatuto basta ser "bonzinho", "atencioso" e praticar "advocacia" para vândalos, CPUs certamente os espaços ocupados pelos atuais eliminadores seriam logo preenchidos. Fabiano ^msg 22h27min de 1 de julho de 2013 (UTC)

• Discordo da proposta que, muito francamente, me parece extemporânea. Estou quase certo que há muitos editores que têm ou terão a confiança da comunidade para eliminar páginas e que mais dificilmente terão essa confiança para serem admins. E isso não vai mudar enquanto durar o processo inquisitorial de seleção de admins (ver comentário do João Carvalho) e o stress a que estão constantemente sujeitos, pelo menos se atuarem nos casos em que possivelmente são mais necessários. Mas nem que isso não se passasse, é perfeitamente concebível que haja quem domine bem os processos de eliminação e não elimine os restantes processos reservados aos admins; embora não seja exigível que os admins sejam omniscientes em tudo quanto é tarefa administrativa, a atribuição do estatuto a alguém que, por exemplo não domine os processos de bloqueio, é algo que mais cedo ou mais tarde gera problemas (ou não, pois provavelmente a comunidade não vai dar esse estatuto a essas pessoas e acabamos com ainda menos gente a tratar das eliminações. --Stegop (discussão) 00h42min de 2 de julho de 2013 (UTC)

Discordo desta proposta por perceber que nem todos os eliminadores têm interesse em ser administradores e, desta forma, não vejo sentido em obstar editores que tem preferência de cooperar somente com as ferramentas de eliminação. Quem aspira a ter estatuto de administrador ou outro, que se candidate ao estatuto desejado. Holdfz (d) 00h56min de 2 de julho de 2013 (UTC)

Discordo Há quem tenha interesse em ECs, ERs e restauros e não domine a PB nem tenha interesse em avaliar estatutos, proteger ou bloquear. Só vai diminuir a facilidade de se conseguir editores para as tarefas hoje dadas aos eliminadores. Delegação é tudo. Fora isto, agregue-se o que já foi afirmado contra. E. Feld ^fala 01h04min de 2 de julho de 2013 (UTC)

Discordo Quem desejar se candidatar a sysop que o faça. Já temos uma carência de editores que cuidam das tarefas de eliminação, exigir deles o rigor de um PDA é contraproducente. O cargo de administrador é exigente e é ótimo que tenhamos um cargo intermediário que serve como não só como teste para o cargo superior mas também como modo de avaliação do editor pela comunidade. Cainã Marques 05h44min de 2 de julho de 2013 (UTC)

Discordo desta proposta. Como disse acima, um eliminador deveria ser um usuário que tem ferramentas para reprimir tudo que é relativo aos artigos - pode eliminar, deveria poder proteger, etc. Um administrador tem ferramentas extras para reprimir os usuários - pode bloquear, filtrar, etc. A sensibilidade requerida para lidar com pessoas (os admistradores) deve ser sempre bem maior do que a sensibilidade para lidar com coisas (os artigos). Albmont (discussão) 13h03min de 2 de julho de 2013 (UTC)

Discordo desta proposta. Pelos motivos apresentados por Albmont acima e quem desejar se candidatar a sysop que o faça. DARIO SEVERI (discussão) 14h14min de 2 de julho de 2013 (UTC)

Neutro Sempre fui contra este Estatuto que na época de sua criação me pareceu uma trapaça feita contra a comunidade, que entregou um assunto considerado sensível do projeto - o da eliminação de artigos - e que antes só editores que tivessem passado pelo crivo de uma eleição poderiam cuidar, a nomeados e muitos praticamente desconhecidos e um ou outro sem qualquer imparcialidade - declarados delecionistas ou inclusionistas - ou competência para discutir o que quer que seja. Ma, graças à, principalmente, omissão da administração que fechou os olhos ou alguns até gostaram da ação ininterrupta de trolls, povs, palpiteiros e afins nas discussões sobre votações e "consensos", que inventaram todo tipo de regra e interpretação fantasiosa ou tendenciosa ou mesmo partindo para burlas e falsificações, a verdade é que tenho que reconhecer que o projeto mudou. Qualquer um propõe e qualquer dois, três gatos pingados eliminam e não se pode falar mais nada pois a "comunidade" aceitou dar para isso o rótulo de "consenso" e "decisão da comunidade". Então, o editor "premiado" com o estatuto em si não tem culpa, apenas representa o ato final do completo desvio dos objetivos e precauções antigas e total capitulação diante de um ataque maciço e muitas vezes robótico contra os que inseriram os conteúdo que são, dentre várias atrocidades, contrários à "pesquisa inédita" dos trolls, etc. que sabem o que é e o que não é "enciclopédicos" sem sequer pesquisar o assunto, apenas decorando um trecho fora de contexto de uma regra controversa como WP:V, por exemplo. Então, só me resta dizer que entreguem as batatas aos vencedores ou, em curtas palavras, façam o que quiserem...--Arthemius x (discussão) 13h29min de 3 de julho de 2013 (UTC)

O Comentário do Arthemius é interessante, pois o eliminador outrora era um cargo mais operacional, um "tarefefeiro", pois as eliminações polêmicas eram decididas por votação, mas com a eliminação por "consenso", passaram a ter o poder supremo que decide se determinada informação deve continuar disponível ou ser ocultada aos leitores.--Raimundo57br (discussão) 16h36min de 3 de julho de 2013 (UTC)

Pergunta quantas pessoas em média participavam dessas votações(sistema antigo) e quantas em média participam hoje das discussões(sistema novo)? Vulcan (discussão) 17h00min de 3 de julho de 2013 (UTC)

Não sei e acredito que a questão não é essa. Tanto o consenso quanto a votação possuem problemas: O consenso me parece mais grave pois se aprovou uma mentira, o entendimento atual leva na verdade discussões polêmicas e forçadas a pseudo-consensos, ou falsos consensos, ou, quando muito, consensos entre participantes segundo o entendimento de quem fecha a discussão, conforme disse o Raimundo. Mas que recebe criminosamente o nome oficial de "consenso da comunidade". Na votação, o problema não era a regra, mas sim alguns editores que se utilizavam de meios ilícitos para uma vantagem momentânea e graças a isso conseguiram o que mereceram: filtros, banimentos, ESR, PE por "consenso", etc. E deram a chance a outros que se aproveitavam das suspeitas para desestabilizarem o ambiente. Mas no final ficava sempre claro quando a votação era dividida que a decisão não fora consensual, o que faz muita diferença: Eu participei de uma votação dividida sobre um artigo sobre pedofilia, perdi mas tive que aceitar pois a regra é simples e a responsabilidade editorial fica com quem votou a favor da manutenção, ou deixou de votar. E de uma discussão de consenso sobre outro artigo de pedofilia: meu argumento sobre apologia ao crime foi "desconsiderado" e o artigo foi aprovado por "consenso". Para mim isso faz muita diferença, pois o problema pela regra agora não é de quem só argumentou pela manutenção ou de quem não falou nada (quem cala consente), mas "de todos" já que é "consenso da comunidade". Isso para mim é inaceitável.--Arthemius x (discussão) 19h15min de 3 de julho de 2013 (UTC)

Não Arthemius, o problema não era a utilização de socks em votações. Era o aspecto "malvado" das votações, discutido em vários ensaios como Wikipédia:Consenso x Votação e Wikipédia:Tomada de decisão e que não precisa ser retomado aqui. Já o grande problema do consenso são pessoas que diante da derrota insistem em pensar que seu argumento foi "ignorado"ou "desconsiderado" quando foi simplesmente vencido de acordo com seus oponentes ou o mediador/fechador da discussão. Não estou te atacando, ninguém está imune a isto. Da mesma forma, em outra discussão em que sua posição foi vencedora, será outra parte a reclamar. É preciso compreender o mecanismo de consenso e não assumir má-fé dos adversários. Por exemplo, sua argumentação naquela discussão foi exemplo puro de WP:AEDE#Argumento da moralidade, foi decidido pela comunidade que este tipo de argumento não é válido e por isso é perfeitamente aceitável a expressão "consenso de comunidade". Respeitosamente. Cainã Marques 22h43min de 3 de julho de 2013 (UTC)

Gostei. O seu argumento é bom, mas não invalida o fato de os socks terem, de fato, atrapalhado a coisa toda. "Qritério de notoriedade" é, até hoje, terreno baldio por causa de um único editor (e seus diversos usuários...). De resto, teu raciocínio é muito bom: de fato havia (ou há?) no passado um motivo bom para presumir má-fé de cara das pessoas. Se isso não for quebrado, consenso algum será possível. Ou acreditamos que estamos aqui por bons motivos e bem intencionados ou vai ser o cão discutir o que seja... José Luiz ^disc 00h53min de 4 de julho de 2013 (UTC)

Eu não insisti em pensar, fui expressamente "desconsiderado" simplesmente porque ninguém lembrou ou não quis incluir nessas recomendações o respeito às leis acima das "regras" da wiki, que, aliás, nem seria necessário essa inclusão porque lei é lei mas aqui parece que precisa. Não teria problema nenhum em ficar quieto se alguém rebatesse dizendo por a+b que a lei não se aplica nessa caso, mas isso não aconteceu. Simplesmente fui "desconsiderado" pelas ditas razões e como já esperava, diga-se, mas me surpreendi quando nem sequer o assunto foi reconhecido como "polêmico" como sempre tinha sido até então, outra obviedade que achava que fosse e que pelo "consenso" passou a não ser mais. E não tenho problema nenhum com a derrota, citei como um caso concreto do problema criado não só a mim mas a todos os outros "moralistas" (?) da comunidade que achem o mesmo e que seriam "desconsiderados" igualmente. Como eu disse, aceitaram chamar esse procedimento de "consenso" então fiquemos com isso. Mas pelo menos deem o crédito a quem de direito: se foi o eliminador e um ou dois que deram o argumento "vencedor" que sejam eles os responsabilizados editorialmente e oficialmente e não a "comunidade". E deem de uma vez o poder aos eliminadores/administradores (com o devido crédito) de eliminarem ou manterem de acordo com o que acharem do tal "consenso". A comunidade propriamente dita só tinha como decidir casos polêmicos por votação, mas claramente abriu mão disso quando concordou com essas regras que, como milagre, tornam o polêmico em consenso.--Arthemius x (discussão) 01h58min de 4 de julho de 2013 (UTC)

Não, repito que não você não foi desconsiderado. Ninguém argumentou contra o fato que as leis tem prioridade sobre as regras da wiki, mas houve a discussão, iniciada por você, que o artigo cometia crime de apologia. Esta questão foi discutida (e refutada) por dois editores, embora não tenha sido citada no fechamento. Você parece achar que esta questão é polêmica e que merecia mais atenção, mas é totalmente sem sentido e ninguém deu muita bola, daí sua impressão que foi desconsiderada, e esta impressão errônea foi o que eu destaquei aí em cima. Desta forma, apesar da legislação estar (na maioria das vezes) acima das regras da Wikipédia, como nenhuma lei é/era violada pelo artigo, os seus argumentos se reduziram ao âmbito moral, o que a comunidade "se lembrou e quis incluir" como inválidos. Quanto a questão do crédito, enquanto os eliminadores sigam as orientações da comunidade ao fechar uma discussão e eleger o "vencedor", serão responsabilidade da mesma. Cainã Marques 09h50min de 4 de julho de 2013 (UTC)

Eu vejo várias PE's sendo propostas por terem sido criadas por IP e ninguém refuta ou muito menos impugna dizendo que não é do IP mas da comunidade. Antigamente, a regra dizia que a eliminação cabia à comunidade e por isso ninguém dizia que o administrador/eliminador tal foi quem eliminou o artigo. Mas agora fica claro que a comunidade abdicou desse direito, tanto com a regra nova da PE por consenso quanto quando criou o cargo de eliminador não eleito. Sendo assim não assumo nenhuma eliminação por consenso como da "comunidade" mas do eliminador/administrador. Quem discorda, fique à vontade...--Arthemius x (discussão) 11h26min de 4 de julho de 2013 (UTC)

Estou afastado das edições da Wiki há muito tempo, por isso estou meio por fora dos assuntos internos, mas essa discussão é conflitante com o que ocorria antigamente, onde queriam que os administradores tivessem "mandatos" por tempo determinado ou ainda, caso ficassem tempo sem "usufruir" dos "poderes", perderiam o "cargo" (desculpem pelo excesso de aspas, mas achei necessário), eu mesmo devo ter perdido a condição por inatividade, e agora querem nomear todo mundo, para darem conta do trabalho. Não sou contra, nem a favor, só achei curiosa a mudança de mentalidade coletiva da Wiki, parece que estamos no caminho certo.Tilgon ^Fale 20h22min de 4 de julho de 2013 (UTC)

Não li o resto da discussão, mas minha opinião é que não daria certo acabar com o estatuto de eliminador e mandar os atuais se candidatarem a administradores. Eu me oporia muito mais fortemente a algumas pessoas serem administradoras do quê a serem eliminadoras, e creio que outros editores também, de forma que o total de gente apta a apagar páginas cairia, sendo que ainda precisamos de mais.--Mister Sanderson (discussão) 12h37min de 6 de julho de 2013 (UTC)

• Concordo com a proposta. É uma das propostas com mais sentido que tenho visto nos últimos tempos. O método de eleição atual incomoda sim, e o baixo número de sysops deveria preocupar a comunidade (sempre estranho ver pouca gente que se preocupa com isso). Belanidia^Msg 17h53min de 8 de julho de 2013 (UTC)

O que é que a falta de admins tem a ver com a proposta? Qual é a relação entre acabar com os eliminadores e aumentar os admins? Eu não vejo nenhuma, pois é evidente que há muitos eliminadores que dificilmente serão aceites como admins e outros que, por uma razão ou por outra nem querem candidatar-se. Por acaso leu alguma coisa da discussão?... --Stegop (discussão) 18h05min de 8 de julho de 2013 (UTC)

Se o problema é com o modo de eleição, o que deve ser mudado é o modo de eleição. Querem meio que criar um atalho para os eliminadores se tornarem administradores, porque eles não podem se candidatar, é isso?—T_ele^s«fale comigo» 18h41min de 8 de julho de 2013 (UTC)

(conflito de edição com Teles)

Eu cheguei a pensar sobre isso que falaram de que se for extinto o estatuto de eliminador "alguns eliminadores não serão aceitos como admins"... e sabe o que eu concluí? Que se eles não seriam aceitos como admins eles não deveriam estar com o estatuto de eliminador. Ou confia na pessoa ou não confia, não existe meio termo, se não confiam para administrador então tem alguma coisa errada e a pessoa não deveria estar com o estatuto de eliminador. Em muitas outras wikis esse estatuto nem existe, para ter acesso as ferramentas de eliminador uma pessoa teria que se candidatar ao estatuto de administrador. Vulcan (discussão) 18h44min de 8 de julho de 2013 (UTC)

Assino por baixo do comentário do Vulcan. E o problema não está em "eles não poderem se candidatar". O problema é exatamente aquele que eu disse que iria acontecer aquando da discussão para aprovação deste estatuto (detesto ter razão): eliminador (especialmente com outras ferramentas combinadas) pode fazer quase tudo o que um adminstrador faz e a pouca coisa que não pode fazer não compensa a dor de cabeça de se candidatar a sysop. Nós (comunidade), criámos um sistema que desestimula totalmente as candidaturas a sysop. Belanidia^Msg 19h24min de 8 de julho de 2013 (UTC)

Citação: TheVulcan escreveu: «Ou confia na pessoa ou não confia, não existe meio termo» Hã??? Acho que não é preciso gerir pessoas ou estudar recursos humanos para que seja evidente que confiança quase invariavelmente tem associado uma ou várias áreas de atuação. Eu posso confiar em fulano para eliminar páginas mas achar que ele não tem perfil, temperamento ou conhecimentos para fazer as muitas outras tarefas de admin. --Stegop (discussão) 19h45min de 8 de julho de 2013 (UTC)

De pleno acordo com Stegop, eu confio em certas pessoas para realizarem determinados assuntos mas em outras áreas elas são péssimas. O eliminador pode fazer quase tudo o que um adminstrador faz, mas este quase é uma diferença muito importante. DARIO SEVERI (discussão) 04h26min de 9 de julho de 2013 (UTC)

Isso me lembra bastante a discussão sobre bloqueio por reversores. Tem um bom resumo dos argumentos para cada lado aqui, acho que quase todos os argumentos dali servem para cá também, e como lá não teve consenso acho bem difícil ter algum consenso aqui. E como lá foi para votação e foi aceito, se isso tb for pra votação o estatuto deve ser mantido, ainda mais por ser algo que já tem um histórico considerável de não ter problemas (sendo q o bloqueio de reversor era algo novo e mais arriscado e foi aprovado). Rjclaudio ^msg 14h04min de 9 de julho de 2013 (UTC)

E já que é algo similar, gostaria que comentassem em Wikipédia:Esplanada/geral/Bloqueio por reversores (9jul2013) o que acharam do recurso dos reversores poderem bloquear. Já passaram nove meses, e uma análise seria boa. E tb ajudaria a avaliar o impacto da separação das ferramentas de adms para outros estatutos (o de eliminador). Rjclaudio ^msg 14h16min de 10 de julho de 2013 (UTC)

Regras não são infalíveis

Durante os debates que aprovaram a "eliminação por consenso" eu propus fosse colocado em votação outro nome para o procedimento: "Eliminação conforme AEDE" e lembrei que quando os critérios de notoriedade, maior parte da comunidade entendeu que tais critérios não teriam caráter vinculante (leiam alguns comentários muito interessantes da Nice Poa, do Carioca e do Lechatjaune), o fato é muitos wikipedistas não participaram ativamente da criação dos critérios específicos, pois acreditavam que era um trabalho que não traria bons resultados.
Os critérios acabaram sendo construídos (exigindo horas e horas de debate) e poucas vezes foram aprovados por consenso (como então aceitar que a eliminação baseada em interpretação de critérios não consensuais seja denominada "eliminação por consenso"???)
Aos poucos, os eliminadores eram escolhidos, mas poucos wikipedistas davam importância a tal escolha, pois eram eleitos para tarefas operacionais (pois maior parte das eliminações polêmicas ocorria por votação), mas de uma hora para outra passaram a ter o poder supremo de decidir se determinadas informações deveriam ou não ser ocultadas dos leitores. (o pior é que na prática é muito difícil conseguir uma revisão de uma decisão de qualquer eliminador).
A participação na criação da AEDE também foi baixa pois por muito tempo foi uma "recomendação" não vinculante.--Raimundo57br (discussão) 12h00min de 4 de julho de 2013 (UTC)

Comentários dos Eliminadores sobre se tornar Administrador

Ver também: Wikipédia:Pedidos de administração/doc e WP:Esplanada/geral/Porque não querem ser administradores? (29dez2011)

Espaço para os WP:Eliminadores comentarem se gostariam de virar sysops e, se não, por que? (se não for eliminador comente na seção Discussão acima)

• Gostaria, e ajudaria bastante. Só faltam algumas edições. Gustavo ^fala!!-fiz 21h35min de 1 de julho de 2013 (UTC)

Enfim, eles não querem ser para não ser constantemente cobrados, mas alguns deles querem se tornar sysops, mas antes adquirir experiência/confiança como eliminador ajuda. Gustavo ^fala!!-fiz 21h39min de 1 de julho de 2013 (UTC) O comentário riscado foi colocado por um meatpuppet do Esquema Quintinense - Vanthorn^® 16h16min de 14 de maio de 2015 (UTC)

(Conflito de edições)

• Minha opinião. Já fui por duas vezes administrador e não o sou neste momento porque das duas vezes fui eu que renunciei ao cargo (só para informar os que não editavam por cá nessa altura). Percebo a ideia mas tenho algumas reticências em relação á sua aplicação pelo seguinte motivo: Não estou interessado, por motivo de falta de paciência, para discussões de bloqueio ou para bloquear usuários wikiadvogados. Enquanto os administradores não tiverem mais poder, usando por exemplo só o bom senso em vez de regras que se contradizem, sendo questionados a toda a hora pelas suas acções administrativas, eu não estou interessado. A liberdade de acção de um administrador, na minha opinião, devia ser muito maior e regularmente devia existir a validação ou revogação do estatuto por votação da comunidade (tipo de 6 em 6 meses, votação sem perguntas excepto continua ou não com o estatuto ?). O interrogatório para obter o estatuto é na minha opinião um disparate a que também não estou interessado em colaborar, pois a inquisição já acabou há muitos anos (não interessa se diz que vai fazer assim ou assado, o que interessa é o comportamento até à data do pedido e a comunidade por votação dizer simplesmente: pode ou não pode ter o estatuto). Para finalizar, ter o estatuto de administrador da forma como ele é actualmente não me interessa e, além do mais ter o estatuto e depois ser acusado de não ser participativo nos tais bloqueios difíceis e nas discussões de bloqueio, também não me interessa. --João Carvalho ^{deixar mensagem} 21h46min de 1 de julho de 2013 (UTC)

Ver também: Wikipédia:Esplanada/geral/Porque não querem ser administradores? (29dez2011)#João Carvalho

• Discordo desta proposta. Como já tinha referido na outra página, pessoalmente, não quero nem nunca quis ter acesso a ferramentas administrativas. Acho que actualmente, os utilizadores que possuem esse estatuto desempenham o seu papel razoavelmente (WTF?... pronto, alguns...). Mas, acima de tudo, não devo ser impedido de colaborar na mesma para a prevenção de acumulação de páginas com conteúdo fora dos parâmetros da Wikipédia. A solução não é acabar com o cargo de eliminador, isso não vai ajudar em nada a comunidade, como já foi aqui dito algures. Todos os eliminadores tiveram um dia de passar por uma avaliação para obter o estatuto, por isso, não vejo vantagem nenhuma em despromover X eliminadores com a promessa que podem vir a ser administradores. E para quem se queixa, quem não quer ser mais eliminador, basta pedir a remoção da ferramenta (e o mesmo serve para todos os outros estatutos). VítoR™  • (D) 23h18min de 1 de julho de 2013 (UTC)

• Ora, por que não? Gostaria de me tornar sysop, principalmente, pois julgo algumas ferramentas referentes à área úteis para mim. Apenas estou esperando o momento oportuno para abrir um PDA. Porém, discordo da proposta "desativar o estatuto de Eliminador"; alguns eliminadores não têm interesse em lidar com bloqueios, proteções de paginas, etc. Matheus Faria ^(msg) 05h30min de 2 de julho de 2013 (UTC) O comentário riscado foi colocado por um meatpuppet do Esquema Quintinense - Vanthorn^® 16h16min de 14 de maio de 2015 (UTC)

Revisão de ações administrativas

Actualmente, o único processo onde existe uma revisão de acções administrativas é na revisão de bloqueios a editores. Recentemente tem-se debatido a hipótese de uma revisão de acções administrativas no encerramento de eliminações por consenso. No entanto, penso que o procedimento deve ser alargado a qualquer revisão de acção administrativa, não havendo motivo para ficar restrito a uma pequena parte da wikipédia. (Note-se que para efeitos práticos desta proposta, os eliminadores executam também acções administrativas.

Quando um editor se depara com um abuso ou acção administrativa que não esteja enquadrada nas regras, não tem qualquer local onde expôr o caso: as páginas de pedidos são (correctamente) vedadas a comentários, ninguém é obrigado a justificar acções e se o editor relatar o abuso no único local público minimamente adequado (não estou a dizer que o seja), a esplanada, o mais provável é ser bloqueado por abuso do espaço público.

Alargo assim o âmbito do debate, propondo aplicar a noção de revisão a encerramentos de eliminação e a toda e qualquer acção administrativa.

Proponho também o mesmo modelo que já propus:

Proposta para implementação de revisões de ações administrativas

• Haverá um espaço próprio para pedidos listado por ordem cronológica.
• Cada pedido deverá indicar claramente quais as políticas que não foram observadas pelo eliminador/sysop/burocrata, com o auxílio de diffs. Pedidos que não sejam claros ou que não sejam fundamentados em políticas devem ser sumariamente removidos.
• Durante quatro dias, os restantes editores com estatuto semelhante ao pedido em questão poderão comentar o caso com base nas políticas e recomendações.
• Uma acção administrativa poderá ser revista quando houver consenso pela sua incorrecção, devendo ficar demonstrado de forma inequívoca quais as regras que foram infringidas ou não observadas.

Obviamente, são excepções as discussões de bloqueio (que já têm local próprio) e qualquer questão que interfira com a política de checkuser. Deixo à consideração. Antero de Quintal (discussão) 21h43min de 19 de setembro de 2013 (UTC)

Até para que se elimine burocracia adicional, eu concordaria, num primeiro momento, em estender o mesmíssimo modelo de DB para um mais amplo referente à quaisquer discussões administrativas nos termos propostos desde que, comprovado que alguém esteja abusando do modelo abrindo discussões sucessivas para provar um POV, possa ser devidamente bloqueado por fazê-lo. No mais, é justo que tal recurso exista. José Luiz ^disc 22h06min de 19 de setembro de 2013 (UTC)

Apoio a proposta, só acho que 4 dias pode ser pouco. Tetraktys (discussão) 22h46min de 19 de setembro de 2013 (UTC)

Apoio a proposta. Julgo que quatro dias é suficiente. Kenchikka (discussão) 23h06min de 19 de setembro de 2013 (UTC)

Não seria interessante permitir que só participantes da EC possam pedir revisão do bloqueio, e que a revisão só possa ser criada antes da votação da PE ser concluída, no caso de a haver? Para o primeiro caso, preocupo-me que pessoas que não estão inteiradas da situação criem pedidos de revisão, obrigando os eliminadores a conferirem a "denúncia" e terem o trabalho de argumentar um desmentimento. Para o segundo, tendo em vista que a revisão é da fase de consenso, pode surgir confusão se dois resultados coexistirem a partir dela: uma votação decidindo manter, e um consenso por eliminar.--Mister Sanderson (discussão) 23h25min de 19 de setembro de 2013 (UTC)

Discordo Atualmente já é possível pedir revisão de eliminação de páginas por meio de Wikipédia:Pedidos/Restauro e outras ações administrativas por meio de Wikipédia:Pedidos/Outros, não é preciso mais páginas de discussão.--Raimundo57br (discussão) 00h04min de 20 de setembro de 2013 (UTC) O comentário foi colocado por um fantoche de Quintinense - Vanthorn^® 00h39min de 16 de maio de 2015 (UTC)

Essas páginas têm propósitos e modelos de actuação completamente diferentes do proposto. Antero de Quintal (discussão) 00h15min de 20 de setembro de 2013 (UTC)

Explique.--Raimundo57br (discussão) 00h17min de 20 de setembro de 2013 (UTC) O comentário foi colocado por um fantoche de Quintinense - Vanthorn^® 00h39min de 16 de maio de 2015 (UTC)

Ah, você não quer que se crie um novo local para revisar PEs... Mas não discorda que deve haver um regulamento de revisão, não é? Pode-se até pedir nas páginas que você linkou, mas vejo que os eliminadores não revisam para não parecer guerra de estatutos... Sem regulamento, eles não vão se arriscar.--Mister Sanderson (discussão) 00h19min de 20 de setembro de 2013 (UTC)

O pensamento de grupo dos administradores e eliminadores não será solucionado pela nova sistemática proposta, pelo contrário a tendência é de haver bloqueios para quem fizer pedidos "mal fundamentos".--Raimundo57br (discussão) 00h23min de 20 de setembro de 2013 (UTC)

Que pensamento de grupo? E porquê abusadores do espaço públicos não deveriam ser bloqueados se incomodarem aos outros muitas vezes?--Mister Sanderson (discussão) 01h09min de 20 de setembro de 2013 (UTC)

• Basta fundamentar dentro das regras do projeto, ou a questão é a dificuldade de fazer sem apelar para o POV do "salvamento do conhecimento" e da "queima de livros"? Fabiano ^msg 00h30min de 20 de setembro de 2013 (UTC)

@ Fabiano, qual o problema, em continuar:

1. a fazer pedidos de revisão de eliminações por meio da página: Wikipédia:Pedidos/Restauro?
2. a fazer pedidos de revisão de outras ações administrativas por meio de Wikipédia:Pedidos/Outros?
3. é realmente necessário criar outra página de pedidos?--Raimundo57br (discussão) 00h33min de 20 de setembro de 2013 (UTC) O comentário foi colocado por um fantoche de Quintinense - Vanthorn^® 00h39min de 16 de maio de 2015 (UTC)

Você está misturando "ter regulamentação de revisão" com "ter de revisar em um novo lugar". Apesar do Antero ter proposto ambos, um não necessariamente depende do outro. O que o GRS73 falou é sobre a regulamentação da revisão, e a resposta que você deu é sobre ter de revisar em um novo lugar. Você percebe isso?--Mister Sanderson (discussão) 01h09min de 20 de setembro de 2013 (UTC)

1. Há necessidade de revisar eliminações em outro lugar distinto de Wikipédia:Pedidos/Restauro?
2. Há necessidade de melhorar: a regulamentação da revisão da eliminação de páginas?--Raimundo57br (discussão) 02h16min de 20 de setembro de 2013 (UTC) O comentário foi colocado por um fantoche de Quintinense - Vanthorn^® 00h39min de 16 de maio de 2015 (UTC)

1. Restauro não é sinónimo de revisão de acção administrativa. Na quase totalidade dos pedidos de restauro, a eliminação foi correcta. Portanto, a acção administrativa foi correcta. O que o pedido traz é novos dados que na altura não existiam.
2. Sim, há necessidade de regulamentação porque não há nenhuma. Antero de Quintal (discussão) 11h29min de 20 de setembro de 2013 (UTC)

1. Discordo, obviamente um Wikipédia:Pedidos/Restauro é um pedido de revisão de uma ação administrativa, aliás um pedido de restauro pode trazer fatos novos (nada impede);
2. Discordo, há regulamentação para os Wikipédia:Pedidos/Restauro: Wikipédia:Restauro--Raimundo57br (discussão) 11h45min de 20 de setembro de 2013 (UTC) O comentário foi colocado por um fantoche de Quintinense - Vanthorn^® 00h39min de 16 de maio de 2015 (UTC)

Tirando a a proposta de revisão de eliminação por consenso, e as discussões de bloqueio, que outras ações administrativas precisam costumam ter que ser revistas, e os pedidos e cafés já não resolvam? Tem algum exemplo? Mar França (discussão) 02h20min de 20 de setembro de 2013 (UTC) O comentário riscado foi colocado por um fantoche de Quintinense - Vanthorn^® 00h39min de 16 de maio de 2015 (UTC)

Todas. Antero de Quintal (discussão) 09h17min de 20 de setembro de 2013 (UTC)

Exemplifique.--Raimundo57br (discussão) 11h15min de 20 de setembro de 2013 (UTC) O comentário foi colocado por um fantoche de Quintinense - Vanthorn^® 00h39min de 16 de maio de 2015 (UTC)

Não sei o que pretende com "exemplifique". "Todas" são "todas" as acções administrativas que não estão acessíveis ao editor comum e que são inerentes a cada estatuto em questão. Para ver as atribuições de cada estatuto pode consultar as respectivas páginas informativas. Antero de Quintal (discussão) 11h23min de 20 de setembro de 2013 (UTC)

Mas em que hipóteses o pedido de revisão não pode ser feito por meio de Wikipédia:Pedidos/Restauro ou Wikipédia:Pedidos/Outros?--Raimundo57br (discussão) 11h30min de 20 de setembro de 2013 (UTC) O comentário foi colocado por um fantoche de Quintinense - Vanthorn^® 00h39min de 16 de maio de 2015 (UTC)

Ver respostas acima. Por favor não faça as mesmas perguntas vezes sem conta só para empatar a discussão. Antero de Quintal (discussão) 11h32min de 20 de setembro de 2013 (UTC)

Discordo - com o Raimundo - Não vamos dar mais chance a turminha da corporação de imolar os comuns que lhes enchem o saco com "pedidos abusivos", como ocorre nas discussões de bloqueio. Se os abusos não são coibidos pelas vias normais no momento que ocorrem, o caminho é denunciar à comunidade e sem trava de "de acordo com a política e recomendação", assim como foi feito num pedido de filtro recente.--Arthemius x (discussão) 11h42min de 20 de setembro de 2013 (UTC)

Acho interessante como é que alguém cujas únicas intervenções em espaços públicos são para descrever supostos "abusos" constantes, "ataque aos princípios do projeto" ou o carácter nazi-fascista de uma tal panelinha de estatutos que supostamente esmaga todos os "editores"... ao mesmo tempo se opõe à introdução de uma forma legítima, respeitosa, ordeira e enquadrada em regras para os editores poderem recorrer de uma edição que seja injusta ou arbitrária. Muito coerente. Pelos vistos o que interessa não é afinal a resolução ordeira de problemas; pelo contrário, o que parece interessar é precisamente potenciar e agravar os problemas, pela via do conflito permanente e ambiente de guerrilha com posts inflamatórios em locais de alta visibilidade. Antero de Quintal (discussão) 12h02min de 20 de setembro de 2013 (UTC)

Wikipédia:Não faça ataques pessoais--Raimundo57br (discussão) 12h08min de 20 de setembro de 2013 (UTC) O comentário foi colocado por um fantoche de Quintinense - Vanthorn^® 00h39min de 16 de maio de 2015 (UTC)

Caro Raimundo, quem é a "turminha da corporação" que "imola" os "comuns"? E os "grupelhos"? Como você não se manifestou pra colocar um "NFAP" quando ele escreveu, suponho que posso escrever que tem uma "turminha semi-analfabeta, provavelmente com problemas de cognição e certamente despreparada para o convívio que vive repetindo as coisas, defende que aos burros se lhes ofereça a chance de relinchar por que, coitadinhos, não sabem argumentar" sem ofender ninguém, certo? Pois imagine - hipoteticamente - que existam pessoas assim, seria justo atacá-las indiretamente? José Luiz ^disc 22h19min de 20 de setembro de 2013 (UTC)

Zé Luiz, não vou responder seu comentário nesse local, pois creio que vai tumultuar a presente discussão, por outro responderei esse tipo de questão se for feita em minha PDU, grato pela compreensão!!!--Raimundo57br (discussão) 01h40min de 21 de setembro de 2013 (UTC) O comentário foi colocado por um fantoche de Quintinense - Vanthorn^® 00h39min de 16 de maio de 2015 (UTC)

Quem falou as palavras entre aspas fui eu. E se quer nomes, vejam as discussões (DB) para a eternização de bloqueio do Junius e as tentativas de fazer o mesmo com o Raimundo e os nomes em comum. É essa turminha que usa as DB para punir editores conhecidos com bloqueios pesados e filtros eternos, ignorando propostas de acordos que apenas o Willy levou em conta e depois se defende alegando que foi decisão da comunidade, segundo me lembro, é a que me referi.--Arthemius x (discussão) 14h35min de 23 de setembro de 2013 (UTC)

As minhas interveções contrárias a propostas são daquelas que a meu ver visam aumentar o poder de decisão de determinados grupelhos que acham que só eles sabem o que é apropriado e o que não é apropriado, geralmente fundamentando em interpretações pessoais e distorcidas de regras controversas do projeto, calando a boca dos contrários com eliminações sucessivas, filtros e bloqueios.--Arthemius x (discussão) 12h12min de 20 de setembro de 2013 (UTC)

Esse "filtro recente" seria o meu? O meu não foi por pedir restauro de nada, não percebo o que tem a ver. Mas também não entendo porquê você não quer a revisão de PEs... Se o sistema de revisão começar a ser abusado, mudam-se as regras para evitar, ou filtra-se quem abusar. Simples. O problema é não haver sistema de revisão, e aí uma página erradamente apagada não ter como ser restaurada. Uma página mantida erradamente, por outro lado, não se beneficiaria do sistema novo de revisão, pois sempre pode ir a PE outra vez. Mas se alguma é apagada erradamente, já era. Você quer impedir a aplicação de um mecanismo benéfico por causa de gente que o usa errado? Há gente que usa escada rolante errado nos shoppings, mas nem por isso elas são proibidas. Você está dando importância demais a minorias.--Mister Sanderson (discussão) 21h29min de 23 de setembro de 2013 (UTC)

Não, não é o seu. Estou falando do Junius e do Raimundo. A discussão de bloqueio foi vendida como uma chance do bloqueado se defender e haver um debate sobre abusos dos administradores mas, como sempre, as pessoas subvertem as regras aos seus próprios interesses. O que vimos no caso do Raimundo foi bem emblemático. O grupelho que filtrá-lo por um grande número de tempo e o modo de conseguirem é através da discussão de bloqueio. O Willi, por mais estranho que pareça, foi o único que acatou a base de que o bloqueio não deve ser punitivo e aceitou um acordo com o Raimundo. Os demais não admitiram isso e passaram por cima dele (assim como na discussão do Junius, que até agora ninguém disse que me enganei) porque a ideia óbvia é agravar a punição o máximo possível, como conseguiram com o Junius, tentaram com o MC, FredXavier (esse eu até apoiei), etc.--Arthemius x (discussão) 21h39min de 23 de setembro de 2013 (UTC)

A discussão de bloqueio é um local para discutir o bloqueio. Se a discussão resulta no que resulta, qual é o problema? Se o resultado lhe desagrada, tente convencer as pessoas a apoiarem outra alternativa. Se você não consegue convencer, que pena; não pode culpar o sistema por isto. É por isto que não apoia revisões administrativas?--Mister Sanderson (discussão) 12h51min de 1 de outubro de 2013 (UTC)

Discordo da proposta diante da má-vontade do proponente em esclarecê-la melhor. Não acho que seja necessário um processo mais elaborado de revisão para ações administrativas que não sejam bloqueio e eliminação. Nunca vi uma grande controvérsia em uma proteção de páginas que não tivesse sido resolvida na discussão da página. Concordaria com essa revisão talvez para os pedidos de concessão das ferramentas de autorrevisor e reversor pois nesses casos já tivemos algumas controvérsias, mas talvez seja melhor mudar logo a política, exigindo que o processo de concessão fosse assim com proposto (prazo mínimo de 4 dias e por consenso entre os administradores) toda vez que se pensasse em conceder essas ferramentas a um usuário que já as teve removidas por mau uso. Mar França (discussão) 17h43min de 22 de setembro de 2013 (UTC) O comentário riscado foi colocado por um fantoche de Quintinense - Vanthorn^® 00h39min de 16 de maio de 2015 (UTC)

Pode esclarecer o que seria isso da "má-vontade"? WP:Não dissemine a desconfiança.

Citação: Não acho que seja necessário um processo mais elaborado de revisão Tem todo o direito de "não ver necessidade" na existência de revisões, mas então a sua posição é neutra, uma vez que não encontra nada a favor, mas também não encontra nenhum argumento contra que determine diferenças de princípio entre acções administrativas. Se os outros vêem essa necessidade e a justificam, você discordando sem nenhuma razão está apenas a empatar o consenso e forçar propositadamente a discórdia. Antero de Quintal (discussão) 18h16min de 22 de setembro de 2013 (UTC)

Discordo:

1. O proponente ainda não respondeu à questão da necessidade antes suscitada, pelo contrário alterou a formatação da página possivelmente para ocultar o fato de que algumas das questões suscitadas não foram respondidas;
2. Será que é por meio da desqualificação de quem discorda é que se deve obter o consenso?--Raimundo57br (discussão) 18h35min de 22 de setembro de 2013 (UTC) O comentário foi colocado por um fantoche de Quintinense - Vanthorn^® 00h39min de 16 de maio de 2015 (UTC)

@Mar França, bem lembrado a questão das ações relativas à concessão/retirada de estatutos de autorrevisor/reversor, mas creio que, por se tratar de avaliação de conduta de editores, poderia haver um processo similar ao pedido de revisão de bloqueio.--Raimundo57br (discussão) 18h39min de 22 de setembro de 2013 (UTC) O comentário foi colocado por um fantoche de Quintinense - Vanthorn^® 00h39min de 16 de maio de 2015 (UTC)

Se poderia haver um processo similar ao pedido de revisão de bloqueio, então confirma que existe necessidade de uma revisão de acções administrativas? Kenchikka (discussão) 19h23min de 22 de setembro de 2013 (UTC)

1. O Mar França tocou em um ponto: ações relativas à concessão/retirada de estatutos de autorrevisor/reversor envolvem avaliação de conduta de editores, logo poderiam ser objeto de um processo de revisão similar ao pedido de revisão de bloqueio;
2. Já existe um procedimento para revisão de eliminação de páginas: Wikipédia:Pedidos/Restauro, é melhor aperfeiçoar o que já existe ou criar outro?
3. Outras ações administrativas podem ser objeto de revisão por meio de: Wikipédia:Pedidos/Outros, é necessário criar outro mecanismo?--Raimundo57br (discussão) 19h41min de 22 de setembro de 2013 (UTC) O comentário foi colocado por um fantoche de Quintinense - Vanthorn^® 00h39min de 16 de maio de 2015 (UTC)

Sim, é necessário criar outro mecanismo. Wikipédia:Pedidos/Restauro e Wikipédia:Pedidos/Outros não são o mesmo que "revisão de acções administrativas". A esse tal processo similar ao pedido de revisão de bloqueio refere-se objetivamente à necessidade de o alargar para qualquer revisão de acções administrativas que em Wikipédia:Pedidos/Outros é simplesmente inapropriado e irresolúvel. Kenchikka (discussão) 20h15min de 22 de setembro de 2013 (UTC)

Discordo:

1. é óbvio que Wikipédia:Pedidos/Restauro e Wikipédia:Pedidos/Outros são mecanismos que propiciam revisões de ações administrativas;
2. a Discussão de Bloqueio é um mecanismo oneroso (costuma exigir muito tempo), viável quando o número de pedidos de revisões é diminuto, quantas revisões de bloqueio ocorrem por mês?
3. creio que é viável aplicar um mecanismo similar às revisões de bloqueio para pedidos de revisão de ações relativas à concessão/retirada de estatutos de autorrevisor/reversor, pois avalio que o número desses pedidos é diminuto;
4. creio que se deve discutir especificamente um aperfeiçoamento de Wikipédia:Pedidos/Restauro, mas para isso teria de ser aberta uma outra página na Esplanada.--Raimundo57br (discussão) 21h04min de 22 de setembro de 2013 (UTC) O comentário foi colocado por um fantoche de Quintinense - Vanthorn^® 00h39min de 16 de maio de 2015 (UTC)

Wikipédia:Política de bloqueio fala em "consenso" toda vez que cita "discussão de bloqueio, mas não dá muitos detalhes sobre como se chega a esse consenso; ao contrário,as decisões em caso de divergência são fechadas pelo que a maioria dos administradores acredita; isto ocorre na prática e é respaldado pelo próprio texto da política de bloqueio.

Também concordo com o Mar França no que tange ao prazo de 4 dias ser flexível; é assim na discussão de bloqueio, cujo prazo é de 3 dias mas na prática acaba durando até duas semanas.

Parece-me que, em aparente contrariedade ao contrário do que propõe o Poly até aqui, o resultado da finalização, em caso de não se atingir o consenso, deveria ser desfeito e a discussão original reaberta.

Dito isto, eu até posso concordar com a proposta do Poly e mais alguns ajustes feitos até aqui, para que seja acrescentado em WP:EC o parágrafo sobre a revisão (com eventuais modificações em relação às demais ações que se discutem aqui):

==Revisão==

• A Revisão do resultado pode ser pedida após o término de uma PE quando um editor entender que a finalização foi, por alguma razão, incorreta.
• O pedido deve argumentar de forma clara qual foi o erro por parte do eliminador que fechou o consenso, conforme as políticas e recomendações do projeto. Pedidos sem argumentação devem ser cancelados de imediato.
• O pedido deve ficar aberto enquanto não houver ao menos a manifestação de um eliminador ou administrador, além de respeitar um período mínimo de menos quatro dias, durante os quais os eliminadores/administradores podem acrescentar argumentos, numa seção específica, além daquela em que a comunidade em geral se manifesta, analogicamente a uma DB.
• A decisão sobre o mérito do pedido também seguirá por analogia os critérios da DB. Se, ao fim, se concluir que houve erro, deve-se encerrar da forma correta. Se a revisão for inconclusiva, a discussão original deverá ser reaberta e o artigo em questão eventualmente restaurado.

Estaria bom para todos assim? E. Feld ^fala 14h23min de 23 de setembro de 2013 (UTC)

Pode modificar o texto para levar em conta acções administrativas em geral? Antero de Quintal (discussão) 14h44min de 23 de setembro de 2013 (UTC)

1. Entendo que se um eliminador discordou de uma eliminação por arbitramento, não se pode dizer que houve consenso, pois há controvérsia qualificada, e, nessa hipótese o caminho menos oneroso é abrir a votação;
2. PS Quando é que as decisões da comunidade sobre eliminação deixaram de seguir regras imperfeitas e voltaram a poder ter como base o bom senso?--Raimundo57br (discussão) 14h56min de 23 de setembro de 2013 (UTC) O comentário foi colocado por um fantoche de Quintinense - Vanthorn^® 00h39min de 16 de maio de 2015 (UTC)

Não vai existir prazo máximo para se pedir revisão? Posso pedir revisão de qualquer EC criada até hoje? Daqui a alguns anos vai continuar a mesma coisa? Citação: «respeitar um período mínimo de menos quatro dias» -4dias? Nunca vi um prazo em dias negativos. Citação: «seguirá por analogia os critérios da DB». Que critérios? Quem participar da revisão vai ser bloqueado automaticamente? Citação: «Se a revisão for inconclusiva, a discussão original deverá ser reaberta» Ahn? Uma revisão inconclusiva anula a decisão anterior? Discordo. Se a revisão é inconclusiva, significa que não ficou provado que a decisão anterior era errada. Portanto, ela era certa e deve ser mantida. Não tem porquê anulá-la.--Mister Sanderson (discussão) 15h42min de 25 de setembro de 2013 (UTC)

@Raimundo, sua primeira colocação se encaixa perfeitamente na minha proposta, já a segunda depende de fatores alheios às normas. @Poly, aqui vai.

==Revisão de ações administrativas==

• A Revisão do de uma ação administrativa excluindo bloqueios (por exemplo, fechamento de PE, eliminação em geral, restauro, proteção, desproteção, inclusão ou exclusão de link na lista de proibições, edição de interface, atribuição de estatuto) pode ser pedida quando um editor entender que o ato, por alguma razão, foi incorreto.
• O pedido deve argumentar de forma clara qual foi o erro por parte do eliminador ou administrador, conforme as políticas e recomendações do projeto. Pedidos sem argumentação devem ser cancelados de imediato.
• O pedido deve ficar aberto enquanto não houver ao menos a manifestação de administrador (ou eliminador, dependendo da natureza do ato), além de respeitar um período mínimo de quatro dias, durante os quais os editores que tenham o estatuto em questão podem acrescentar argumentos, numa seção específica, além daquela em que a comunidade em geral se manifesta, analogicamente a uma DB.
• A decisão sobre o mérito do pedido também seguirá por analogia os critérios da DB. Se, ao fim, se concluir que houve erro, deve-se corrigi-lo. Se a revisão for inconclusiva, deve-se retornar ao status quo anterior ao ato.

E. Feld ^fala 15h58min de 23 de setembro de 2013 (UTC)

Citação: Efeld escreveu: «Se a revisão for inconclusiva, deve-se retornar ao status quo anterior ao ato.» De acordo com essa frase, se a revisão de uma PE terminar inconclusiva o fechamento que estava sendo revisto será mantido?--Mister Sanderson (discussão) 19h45min de 30 de setembro de 2013 (UTC)

Após refletir melhor, Concordo com a proposta, mas indago:

1. Vai fechar a atual página de pedidos de Wikipédia:Pedidos/Restauro, ou ainda vai ser possível pedir restauro temporário (que não é exatamente um pedido de revisão)?--Raimundo57br (discussão) 16h12min de 23 de setembro de 2013 (UTC) O comentário foi colocado por um fantoche de Quintinense - Vanthorn^® 00h39min de 16 de maio de 2015 (UTC)

Concordo com a proposta do Eduardo Feld, mas como a discussão original estava em Wikipédia:Esplanada/propostas/Revisão da Eliminação por consenso (13mai2013)#Proposta de 10 de setembro, e era mais específica em relação apenas à revisão da Eliminação por consenso, surge uma dúvida: o consenso que já existia por lá dizia que esse trecho da revisão seria acrescentado numa seção "revisão" em WP:EC, e isso não deve mudar; mas e o texto acima, será acrescentado aonde? Vamos acrescentar uma seção "revisão" em cada página de cada tipo de decisão administrativa que possa ser revista, ou haverá uma página central aonde esse texto ficará?

Também foi consenso a criação de Wikipédia:Revisão da eliminação por consenso ou Wikipédia:Eliminação por consenso/Revisão, páginas aonde as propostas seriam listadas, em subpáginas individuais (da mesma forma que acontece com WP:Pedidos a administradores/Discussão de bloqueio). Até criei Usuário:Mar França/Revisão de EC que seria movido para outro título e usado como predefinição na discussão da PE que deve ser revista, para abrir o processo de revisão. Qual seria o formato dos demais tipos de revisão das outras decisões administrativas? Sobre restauros, não acho que WP:P/R deve ser extinta, ela deve ser usada para pedidos de restauro sem muita controvérsia. Mar França (discussão) 21h26min de 23 de setembro de 2013 (UTC) O comentário riscado foi colocado por um fantoche de Quintinense - Vanthorn^® 00h39min de 16 de maio de 2015 (UTC)

Não houve qualquer consenso até agora sobre nada. A questão de "onde" vão ficar os pedidos é secundária e até irrelevante por agora. Se o modelo ou a implementação for consensual, que é o que é importante, essa questão pode ser decidida depois. Antero de Quintal (discussão) 22h37min de 23 de setembro de 2013 (UTC)

Não houve consenso para se usar subpáginas individuais, meu caro. Apesar de você ter insistido nisto por lá, o Antero disse que não se importa com isto desde que haja scripts, e outros editores defenderam outras coisas. É difícil acreditar que você tenha esquecido, em tão pouco tempo, do conteúdo daquela discussão.--Mister Sanderson (discussão) 19h45min de 30 de setembro de 2013 (UTC)

MisterSanderson, o script está pronto, fiz em Usuário:Mar França/Revisão de EC. Quem discordou de usar sub-página própria foi só o Raimundo, mas ele discordou de tudo, da própria ideia de revisão em si, aí não conta. Mar França (discussão) 02h28min de 1 de outubro de 2013 (UTC) O comentário riscado foi colocado por um fantoche de Quintinense - Vanthorn^® 00h39min de 16 de maio de 2015 (UTC)

E quem apoiou?--Mister Sanderson (discussão) 15h56min de 11 de outubro de 2013 (UTC)

Pergunta Gostava que estivesse esclarecido nesta discussão os argumentos na origem de um sistema de apuramento de consenso diferente da proposta inicial. Antero de Quintal (discussão) 22h37min de 23 de setembro de 2013 (UTC)

Simples, seria por analogia com a DB, com a diferença de que o ato poderia ser validado por um único administrador ou eliminador não envolvido se não houver oposição em 4 dias. E. Feld ^fala 00h03min de 25 de setembro de 2013 (UTC)

É precisamente essa a questão. Qual o argumento para se propor uma analogia com as DB, e qual o problema com o sistema da proposta? Qual é também a lógica em se obter consenso com a validação ou não de um único administrador? Quem for o primeiro a comentar passa a ter a palavra final? Isso tem um nome: wheel war ou guerra administrativa. Antero de Quintal (discussão) 00h11min de 25 de setembro de 2013 (UTC)

A analogia se justifica porque a DB já é um sistema de revisão de uma ação adminsitrativa, assim, se estende esse sistema às demais ações. Por outro lado, se só um administrador validar no prazo esta decisão é a que deve valer, não é porque foi o primeiro, mas porque não houve oposição, daí havendo a unanimidade, que é o consenso por excelência. E. Feld ^fala 00h28min de 25 de setembro de 2013 (UTC)

Se for uma decisão contrária à do outro administrador, automaticamente há uma oposição entre os dois. Isso não é consenso nem uma revisão ponderada com intuito pacificador e esclarecedor. É uma guerra administrativa tosca, que institui a figura do revisor todo-poderoso que sozinho tem a última palavra em tudo e que redunda numa corrida ao primeiro comentário. Antero de Quintal (discussão) 00h42min de 25 de setembro de 2013 (UTC)

Vc não entendeu. O fechamento em quatro dias se dá apenas se o administrador validar a decisão do outro. Senão, o debate permanece. E. Feld ^fala 00h45min de 25 de setembro de 2013 (UTC)

No caso de eliminação de artigos, havendo divergência entre dois eliminadores, o caminho menos oneroso é abrir a votação.--Raimundo57br (discussão) 01h52min de 25 de setembro de 2013 (UTC) O comentário foi colocado por um fantoche de Quintinense - Vanthorn^® 00h39min de 16 de maio de 2015 (UTC)

Mesmo que só possa ser encerrado no caso de uma validação, ainda que de forma menos grave, a questão principal mantém-se. Uma única pessoa não faz um consenso, seja para validar ou contrariar a decisão original. Quando se pede uma revisão fundamentada, o editor espera que haja o mínimo de análise.

Há uma diferença fundamental entre encerrar como conclusivo e inconclusivo. O termo conclusivo corresponde a uma conclusão, a um resultado final de um processo, do qual se podem extrair ilações e exemplos de acção. Encerrar uma discussão como conclusiva de algo que não teve sequer um mínimo de participação é grave, independentemente se concordou ou não. Se não houve participação, deve-se encerrar como inconclusivo, já que ao menos não cria modelos cuja probabilidade erro e equívoco é alta. Só os processos em que houve participação e consenso é que devem ser conclusivos, apontando a direcção para problemas semelhantes no futuro.

Dito isto, continua por esclarecer qual o problema com o sistema de determinação de consenso da proposta e qual é a vantagem que considera que o da discussão de DB tem em relação a este para ter proposto um diferente sem apontar os problemas do da proposta. Escrever apenas "porque ali é feito assim" é pouco esclarecedor. Por exemplo, entre outras, esse sistema tem uma falha muito grave que é o abuso reiterado que fazem dele, ao requererem revisões contando já com a baixa participação e a elevada probabilidade de verem um bloqueio mais do que devido suspenso unicamente por esse motivo. Não é minimamente lógico considerar uma acção indevida só porque não se participa na sua revisão. Adoptando esse sistema, praticamente deixaria de existir qualquer acção administrativa, já que haveria pedidos às centenas por dia só a contar com a falta de quorum. Antero de Quintal (discussão) 02h31min de 25 de setembro de 2013 (UTC)

@Poly, acerca do problema do retorno ao status quo nos casos de revisão de bloqueio, o que tenho a dizer é o seguinte. Recentemente, a política de bloqueio foi alterada por consenso justamente para não permitir mais esse problema. De acordo com o texto texto atual, quem pede revisão de má-fé pode ser bloqueado por abuso do espaço público. Ademais, o prazo de 3 dias hoje tem um novo sentido. Se três administradores não apoiarem, a ação continua sendo desfeita, mas a discussão prossegue e, ao final, o bloqueio pode ser restaurado. Então, persiste a analogia, desde que a ação seja algo que "na dúvida", provisoriamente se deva reverter.

"Diagramando", que proponho é aproximadamente o seguite:

Ação efetuada; revisão pedida; se abusiva, cancelada de imediato e o requerente pode ser bloqueado;

Se válida, espera-se a conclusão; se após 4 dias, somente um admin comenta a favor, e mais ninguém participa, o pedido é arquivado, e a ação administrativa mantida (ainda que a discussão seja inconclusiva).

Se, após 4 dias, há consenso entre os administradores, a ação é mantida de forma conclusiva e ação desfeita ou não conforme o consenso.

Se após um período razoável de debate não se chegar ao consenso, então a ação deve ser desfeita, justamente por não ser consensual.

Sobre a segunda hipótese (pedido de revisão válido, com um comentário em 4 dias), explico, não se pode desfazer algo que dois administradores concordaram e ninguém discordou.

Diferente é o caso de uma discussão em que, após aberto o pedido de revisão, muitos se opõem, baseados em justificativas válidas. Neste caso, não há presunção de validade da ação, razão pela qual é justo que ela seja desfeita. Repare que é isso que ocorre atualmente nas discussões de bloqueio, e nunca se propôs mudar.

Talvez o último texto que propus seja falho por não diferenciar uma discussão inconclusiva por falta de participação (nesse caso, concordo que prevalece a ação administrativa) de uma discussão em que os administradores opinaram e chegaram a um impasse. Posso reescrever a proposta de forma que isso fique mais claro, se concordarem. Agora, a proposta anterior tem um grave problema: estabelecer que toda e qualquer ação seria mantida em caso de impasse. Ela dá margem para a manutenção eterna do status quo, o que pode estimular justamente que um administrador queira ser o primeiro a aplicar a decisão, fazendo a sua opinião ser considerada "a estável" e presumidamente consensual, mesmo que, após, não haja consenso a respeito de sua validade. Deve-se buscar que não se aplique algo até que haja o consenso, não o contrário. E. Feld ^fala 16h55min de 2 de outubro de 2013 (UTC)

Apoio a sua proposta Eduardo, mas peço que deixe tudo bem explicadinho para que não haja outras interpretações. JMGM (discussão) 22h02min de 8 de outubro de 2013 (UTC)

Apoio a explicação do Eduardo e acho que mais explicado do que isso, impossível. Mar França (discussão) 02h07min de 10 de outubro de 2013 (UTC) O comentário riscado foi colocado por um fantoche de Quintinense - Vanthorn^® 00h39min de 16 de maio de 2015 (UTC)

Apoio a proposta do Eduardo e também Apoio que as discussões sejam numa página própria como defende o Mar França. Não tem um script, mas a predefinição que ele criou pode resolver o problema de automatizar o pedido de revisão, com alguns ajustes. No caso da PE, prefiro que a revisão seja feita em Wikipédia:Revisão da eliminação por consenso. Ao @Antero, pergunto se ficou bem explicado agora, e se concorda, ou que ajustes pretende fazer. Matheus ^diga✍ 23h01min de 14 de outubro de 2013 (UTC) O comentário riscado foi colocado por um fantoche de Quintinense - Vanthorn^® 00h39min de 16 de maio de 2015 (UTC)

A proposta inicial recebeu apoio. Pergunto se está bem explicada e se concorda. Antero de Quintal (discussão) 23h19min de 14 de outubro de 2013 (UTC)

Ponto de situação. Até agora houve uma proposta inicial e a meio foi criada uma alternativa. A única diferença (e conflito) está na interpretação do que é consenso para reverter uma ação administrativa, portanto vamos tirar o restante da discussão. A proposta inicial previa que uma acção administrativa fosse revertida quando houvesse consenso pela sua incorreção, à semelhança do que acontece na wikipédia anglófona. A meio o Efeld propôs que a definição de consenso fosse precisamente o oposto: que qualquer ação administrativa seria em princípio revogada quando contestada por alguém, e só seria mantida se houvesse consenso pela sua correção. Dito por outras palavras, na proposta original quando não há consenso sobre a incorreção a acção original mantém-se, na do Efeld quando não há consenso sobre a incorrecção as acções administrativas são revertidas.

Os principais argumentos são: 1) é assim que é feito na discussão de bloqueio; 2) a proposta original favoreceria o administrador que efectuou a acção em primeiro lugar, potenciando uma "corrida" para ser o autor da "decisão estável" Vamos por partes:

1) Uma discussão de bloqueio é uma tentativa de consenso para confirmar se determinado usuário teve acções que foram gravosas para o projeto. Quem está a ser julgado (o "réu") é o usuário. O bloqueio é confirmado quando se chega a um consenso em relação ao réu ter violado as normas do projeto. Quando não se tem a certeza se o réu violou as normas, in dubio pro reu e não se aplica sanções.

Num pedido de revisão, o administrador é o "réu". Quem está a ser julgado é o administrador e a sua acção. E tal como é necessário consenso para confirmar que as acções de um usuário foram gravosas para o projeto e ele deve ser censurado por x tempo, é igualmente necessário consenso para confirmar que as acções de um administrador foram gravosas para o projeto e se o deve reverter. Quando não se consegue determinar que a acção foi indevida, in dubio pro reu.

Portanto, vamos ser muito claros nisto: a proposta original é a única que, efectivamente, vai buscar a mesma metodologia das actuais discussões de bloqueio.

2) Ver como grave o facto da proposta original favorecer o status quo é um falso argumento. Sim, provavelmente até favorece um pouco e até dou isso de barato. Mas a contra-proposta ainda é pior, porque favorece sempre o "último" e favorece sempre quem é contra. Ou seja, quem passa a ter todo o poder decisório é o "último". O falso argumento é este: discordou-se da proposta por favorecer um dos lados, mas em alternativa deu-se uma que continua a favorecer um dos lados, só que o lado contrário. Epa...

Então se cada uma penaliza os dois lados as duas propostas são indiferentes? Não. Quando não há certezas e nos movemos em áreas debatíveis, penalizar constantemente o sysop/burocrata que tomou a decisão original é muito mais gravoso e ruinoso para o projeto. Vai promover o imobilismo completo dos poucos sysops que ainda dão sinais de vida e favorecer quem só gosta de conflito e de discutir o sexo dos anjos. Ninguém de valor vai estar para se maçar, se a cada vez que decide tomar uma decisão vai ter que perder dias e dias com dezenas de discussões intermináveis que não dão em nada, para no fim ver todas as acções praticamente revertidas. Se esta maluqueira avançasse e a todo o momento as páginas fossem bombardeadas de pedidos com o intuito de "não haver consenso", não me surpreenderia nada ver sysops a desistir em cascata.

A ideia da proposta inicial era simplesmente dar a hipótese aos editores de poderem contestar uma acção nitidamente errada. Entenda-se: nitidamente. Se a coisa é debatível e não se consegue apontar erros claros, assume-se a boa fé do julgamento do sysop inicial. O que a proposta do Efeld faz é, a partir do momento em que a coisa passa a ser debatível e não há uma violação clara, tirar a razão toda ao sysop inicial e passá-la toda para quem contesta. Antero de Quintal (discussão) 00h52min de 15 de outubro de 2013 (UTC)

Antero, respeito o seu raciocínio, mas não concordo. Até reconheço que o primeiro ponto da sua argumentação, sobre o in dubio pro reu faz sentido. Mas quando você diz que a contra-proposta favorece o "último" e quem é contra, aí não. A falta de consenso não se verifica por quem falou por último, e você mesmo está assumindo que os administradores vão sair por aí discordando das ações dos outros, e que será permitido pedir dezenas de revisões de forma abusiva sempre que não se concordar com a finalização. Não é assim. Por exemplo o Mar França D​ C​ E​ F foi corretamente filtrado após abrir discussões de bloqueio de forma abusiva. Se isso acontecer (abrirem pedidos de revisão abusivos) a comunidade vai aprender a lidar com quem fizer mau uso dessa possibilidade. Na pior hipótese o que vai acontecer é nenhum administrador comentar nas discussões de bloqueio abusivas e o status quo não se alterar por falta de participação (ou seja, o abusador vai cansar por ver que é inútil).

Por outro lado, o principal motivo para que seja como o Eduardo propõe é padronizar as decisões, e isso é muito importante. Se um administrador toma decisões contrárias à jurisprudência, isso não é bom pra ninguém. O ideal é que os critérios de decisão sejam próximos, que não haja decisões opostas uma à outra. Especialmente no caso da PE que é por consenso, ou seja, se não há consenso nem mesmo entre os eliminadores que o consenso fosse aquele, é porque a finalização não era realmente consensual, logo, não deve prevalecer. Matheus ^diga✍ 03h03min de 15 de outubro de 2013 (UTC) O comentário riscado foi colocado por um fantoche de Quintinense - Vanthorn^® 00h39min de 16 de maio de 2015 (UTC)

Claro que favorece o último. O "último" é entendido como o(s) contestatário(s) e que chegam por último à resolução do problema, por oposição ao primeiro, que é o sysop que interviu inicialmente para resolver o problema. Não é o "último a comentar" (!). Não havendo consenso é sempre favorecido o que contestou, o que é grave e a explicação está em cima. Isto não tem nada a ver com o facto do pedido ser ou não abusivo. Antero de Quintal (discussão) 08h45min de 15 de outubro de 2013 (UTC)

Concordo plenamente com o ponto de vista do Antero.--Mister Sanderson (discussão) 18h36min de 10 de novembro de 2013 (UTC)

Concordo com a proposta inicial e com a segunda proposta do E.Feld. Sobre o local do pedido, tenho preferência por aproveitar o WP:Pedidos, podendo ficar como Wikipédia:Pedidos/Revisão de ações administrativas ou algo parecido. _T^itoncio_itoncio (Discussão) 12h57min de 24 de outubro de 2013 (UTC)

Poly, por mais que eu tente, não consigo ver lógica no que diz, e muito menos concordar. quem contesta a revisão só será beneficiado se houver consenso entre os administradores de que a revisão está incorreta, ou um "dissenso participativo". Isso já foi muito bem explicado pelo Matheus acima. Portanto, na minha proposta, não há essa coisa de "beneficiar o último". há, sim, uma o benefício à ampla participação do corpo administrativo, que seria chamado a participar mais vezes sempre que houver um questionamento sério sobre a melhor interpretação naquele caso. Se os administradores não participarem da discussão, presume-se que concordam com ela, mas se há discordância a respeito dela, ela não prevalecrá. Até entendo que não concorde com isso, mas a maioria pelo visto concorda com a visão que defendo, e sendo isso aqui uma "tentativa de consenso sobre a revisão do consenso" já começamos mal em não encontrar o consenso aqui, embora, em diversos momentos, desde o início desta discussão, outros participantes tenham cedido aos seus argumentos, uma vez que o formato final até aqui está mais próximo do que você propôs do que o que foi proposto inicialmente e sugerido por outros no decorrer. Todos aceitamos as suas sugestões, menos nessa questão da manutenção do status quo do administrador, mesmo em caso de dissenso contrário.

Sendo assim, gostaria que você fosse capaz de ceder quanto a este único ponto, no que eu me comprometo a buscar soluções no futuro, ou até mesmo apoiar a sua proposta futuramente, caso a minha seja aprovada e os problemas que supõe ocorram (o que não acredito). Se você não for capaz de ceder quanto à única discordância, lamento, mas não há outra saída a não ser a votação entre os dois formatos de revisão. Já passou mais tempo do que devia pra isso ser decido, já que é discutido desde maio. E. Feld ^fala 05h44min de 30 de outubro de 2013 (UTC)

Citação: quem contesta a revisão só será beneficiado se houver consenso entre os administradores de que a revisão está incorreta Não sei se não compreende a sua própria proposta, se é ingénuo ou se está a deliberadamente tentar enganar os participantes. O que propôs foi que quando não haja consenso, o requerente do pedido tenha sempre razão. O que escreveu aí em cima foi o que eu propus e que é igual ao sistema da en.wiki. Também não vejo onde está essa "maioria". Também me enoja essa tentativa de culpabilizar os outros pelo atraso do processo de consenso, quando foi você que insistiu numa alternativa que já sabia que não ia ser aceite, porque já não o foi no passado e isto já era uma tentativa de consenso com base em discussões passadas, mas eliminando o que não foi aceite. Também agradeço que não atire areia para os olhos dos participantes fingindo que houve "cedência em massa", e portanto seria a vez dos defensores da proposta inicial "cederem" um pouco: o cerne da questão é o formato de decisão, o resto são questões menores e óbvias, ou que para muita gente é até indiferente. Já expliquei em detalhe os problemas decorrentes e ainda não vi contra-argumentação. Antero de Quintal (discussão) 10h23min de 30 de outubro de 2013 (UTC)

Gostaria de saber se vai ser possível recorrer contra negativas de pedidos de restauro de página.--Raimundo57br (discussão) 10h01min de 30 de outubro de 2013 (UTC)

Se a página for eliminada é que se deve pedir a revisão, já para as antigas, pode se abrir uma brecha. _T^itoncio_itoncio (Discussão) 10h16min de 30 de outubro de 2013 (UTC)

E.Feld, por mais que eu tente, não consigo ver lógica no que diz. O que defende deve ser o presente mais sonhado pelos especialistas em subverter regras, pois basta uma opinião de admin "hã... se calhar aquilo foi feito de boa fé... isso vai pode ir contra a segunda vírgula do ponto 1.2.3 da regra X, etc." numa discussão pouco participada para que uma ação seja revogada. --Stegop (discussão) 15h58min de 30 de outubro de 2013 (UTC)

• Não consigo entender como é que misturamos "consenso" com "sanções" e acabamos nessa trapalhada. Até nos países menos civilizados, revisões de decisões em julgado são definidas por voto majoritário, em geral alinhando-se os votos a favor ou contra a opinião do relator. Mas fora isso, achar que é benéfico para alguém que num caso de falta de consenso entre administradores sobre a decisão de um deles dever-se-á revertê-la é contraproducente, na medida que só fomenta o atrito constante entre eles e entre admins e a comunidade, quando deveríamos é buscar (i) acreditar que conseguimos ter uma relação de confiança mútua que minimize muito os casos onde a revisão é necessária e (ii) quando ela ocorrer, que seja por decisão por voto majoritário simples. A simples existência da revisão votada deverá estimular que mais gente se candidate ao cargo e coloque sua reputação junto da sua opinião.... José Luiz ^disc 20h05min de 30 de outubro de 2013 (UTC)

Pegando a ideia do voto majoritário, até onde eu saiba as discussões de bloqueio são por votação. Digo, na prática, pois apesar da PB falar bastante em 'consenso entre adms', no final o que decide é se tem 50%+1 e mínimo de 3 votos a favor, e isso pra mim é votação e não consenso, e até hoje nunca vi nenhuma decisão que não seguisse esse 50%+1. 'Só' se usa consenso para decidir o tempo de bloqueio (pq há o limite de 72h pra discutir, e algum prazo tem que ser decidido), o que não é aplicável para a maioria das outras ações de administradores (que são um simples sim/não). Rjclaudio ^msg 00h40min de 31 de outubro de 2013 (UTC)

@Claudio, é isso mesmo!

@Stegop, já foi dito aí em cima, isso só aconteceria se os administradores fossem todos subvertedores das regras, ou simpatizantes daqueles que o fazem. Mas isso já seria presunção de má-fé. E se não houver participação, é mantida a ação administrativa contestada, então o que você supõe é impossível.

@Zé, concordo totalmente com você. Se somos uma comunidade, com todas as suas divisões e discordâncias internas, precisamos em primeiro lugar confiar uns nos outros para chegar à melhor solução. Sobre a as decisões serem tomadas por maioria de votos quando houver discordâncias, a proposta inicial do Mar França seguia por esse caminho, que o Eduardo Feld concordou: Citação: Eduardofeld escreveu: «Quanto à proposta em si, eliminadores são eleitos pela comunidade para aplicar as políticas e recomendações; no caso de divergência entre eles, no que tange à interpretação destas políticas, é racional que a divergência seja decidida em votação. É dessa forma que acontece nas decisões entre administradores ou entre burocratas, como, por exemplo, nas DBs.» Mas também houve oposição, por exemplo:Citação: MisterSanderson escreveu: «Eu me oponho a concluir o que a maioria dos eliminadores decidir, pois a decisão não deve ser por votação. O exemplo que você disse do 5×1 está todo errado... Não interessa quantos são contra ou a favor em uma discussão, consenso não é unanimidade, não interessa a quantidade numérica das pessoas, mas a força dos argumentos» O Poly discordou também.

Daí restam três opções para o caso de não-consenso: i) Mantem-se a ação administrativa se houver divergência a respeito de sua validade. ii)Desfaz-se a ação administrativa se houver divergência a respeito de sua validade. iii) Mantém-se a opinião da maioria se houver divergência a respeito da validade. Eu prefiro a terceira hipótese, que já é o que é feito na discussão de bloqueio, mas rejeito totalmente apenas a primeira. Como podemos resolver esse não-consenso? Matheus ^diga✍ 20h42min de 5 de novembro de 2013 (UTC) O comentário riscado foi colocado por um fantoche de Quintinense - Vanthorn^® 00h39min de 16 de maio de 2015 (UTC)

@rjclaudio, efeld: a comparação com a discussão de bloqueio não pode ser feita porque há uma diferença fundamental.

• Uma discussão de bloqueio envolve ações de sim/não ou on/off. Decide-se se vai ou não bloquear determinado editor. O dilema permite que o resultado tanto possa ser uma acção (bloquear/confirmar) ou inação (não bloquear) por parte dos administradores. Quando se opta por uma inação (não bloquear), isso não tem consequências para a wikipédia.
• No entanto, a maioria das outras ações não envolve decisões com sim/não, mas antes a escolha entre uma de duas decisões: A/B' em que é obrigatório escolher uma delas numa ação. A inação não é uma opção. Por exemplo, ao encerrar um pedido de estatutos ou uma votação com um prazo estipulado, o administrador tem que decidir e tomar uma ação dentro de determinado prazo. Pode ser a ação A ou a B. Validar ou recusar o pedido.

Por outras palavras, numa revisão de bloqueio pode-se converter uma ação numa inação. Um bloqueio pode ser convertido em desbloqueio, sem consequências para a organização da Wikipédia. Mas, ao contrário dos pedidos de desbloqueio, numa eventual revisão posterior de grande parte das outras situações não é possível reverter essa ação para uma inação. Só é possível tornar a ação A na ação B ou a ação B na ação A. Por exemplo, quando for revista a atribuição de um estatuto, a ação pode converter uma deliberação "atribuído" em "recusado", ou vice-versa. Ou seja, alterna entre as opções A e B. Mas nunca passa para uma inação. Não é possível simplesmente desfazer a decisão e toda a gente fazer de conta que nunca aconteceu nada. Antero de Quintal (discussão) 05h37min de 6 de novembro de 2013 (UTC)

Esclareça o que entende por inação. Inclui-se "não confirmar" um bloqueio? Se é isso e que me parece óbvio pois estamos falando de "revisão", há o efeito para a comunidade pois o administrador que efetuou o bloqueio fica sujeito a um pedido de desnomeação. A própria inação sem bloqueio prévio pode levar a isso mas ai seria indiretamente.--Arthemius x (discussão) 10h54min de 6 de novembro de 2013 (UTC)

Um bloqueio removido tem várias consequencias para a comunidade.

1. Se o bloqueio era mesmo indevido, o administrador passa a ter feito uma ação indevida, estando sujeito a desnomeação, principalmente se não for o primeiro bloqueio removido.
2. Se o bloqueio era correto, o usuário passa a ficar impune / livre mesmo após ter feito uma ação 'indevida', ou seja, não 'aprende' que fez algo errado e não deve voltar a fazer
3. Dos dois modos, para a Wikipédia isso gera um precedente que será usado quando outros usuários (ou ele mesmo) fizerem a mesma coisa (ou algo parecido).

Então mesmo para um bloqueio, a 'simples' remoção gera consequencias para a comunidade. E isso é válido para todas as ações administrativas, incluindo a recusa de um pedido de estatuto e a desproteção de uma página.

E como eu falei, a revisão de bloqueio não é um simples sim/não, apesar de na maioria das vezes ser assim. Há também os casos em que se decide aumentar ou diminuir o tempo de bloqueio, mudar para um filtro de edições, remover o bloqueio com uma 'condicional' (entendi e não vou mais fazer isso), entre outras opções. Rjclaudio ^msg 11h56min de 6 de novembro de 2013 (UTC)

Todas essas opções exigem consenso ou uma maioria de votos. Para fazer qualquer ação é preciso consenso/maioria. Consenso para haver bloqueio. Consenso para novo tempo de bloqueio. Quando não há consenso, há uma inação: o bloqueio é levantado, como se nunca tivesse acontecido.

Isto só é possível acontecer em processos em que haja a opção entre ação/inação, e nunca em processos onde tenha obrigatoriamente de haver uma ação, só não se sabe se a, b, c, etc. Há processos em que a inação não é uma opção, em particular os que envolvem prazos, tendo obrigatoriamente que ser encerrados e tendo que se optar entre a ou b. Neste caso, cria-se um desequilíbrio: a falta de consenso por a obriga à adopção da alternativa b. Na prática, o que estão a propor é que na ausência se consenso/maioria se continue a optar por a/b.

Como isto está, provavelmente, a ser confuso de digerir, vou dar exemplos práticos para que se compreenda o absurdo da situação.

• Vamos dar o exemplo de uma revisão de encerramento por consenso que chega ao fim do prazo. O sysop tem duas opções básicas: mantém o artigo (ação A) ou elimina (ação B). A inação é deixar a discussão infinitamente em aberto e nunca mais ser encerrada. Imaginemos que o sysop mantém o artigo (opção "A") Alguém contesta e pede uma revisão. Imaginemos que os sysops se dividem nos comentários. Segundo a vossa teoria, como não há consenso, muda-se a decisão de manutenção (opção A) para a eliminação (opção B). E aqui está o problema: ao contrário de um bloqueio, em que é possível suspender/remover esse bloqueio (inação), aqui não é possível simplesmente "reverter" a ação ou remover o encerramento. Uma discussão de eliminação tem que ser encerrada nesse prazo e tem que ser escolhida uma opção. Não é possível deixá-la em aberto até ao infinito. Portanto, em termos práticos, a falta de consenso mudou uma ação A para uma ação B.

Volto a frisar: atente-se no absurdo que estão a propor, em que a falta de consenso dá origem a uma ação (B). Isto é amoral e inédito em processos de resolução de disputas. Mais do que isso, abre as portas para o exploiting constante da situação, ao dar o controlo completo dos processos administrativos a quem opte por ficar na sombra e só opte pela via da contestação para mudar ações para resultados do seu agrado forçando falta de consenso. Em suma, o que estão a propor é, na falta de consenso, passar-se de uma ação que não foi consensual para outra ação ainda menos consensual, com a agravante acrescida de promover o "wheel warring", incitar a discórdia entre o corpo administrativo, fazer perder tempo e favorecer o estilo fútil de gestão de disparar comentários em discussões penalizando quem trabalha e faz alguma coisa.

Se tem mesmo que ser, tendo em vista facilitar o consenso, e mesmo que não seja do meu completo agrado, não me oponho de todo a que esse método seja seguido nas decisões que se pautem pelo binómio ação/inação, desde que naquelas onde esteja implícita uma ação obrigatória seja seguido o processo inicialmente proposto. Antero de Quintal (discussão) 13h15min de 6 de novembro de 2013 (UTC)

Nas nossas políticas atuais, o que acontece quando não há um consenso em algum processo que precisa de uma decisão? Ele é fechado e a decisão é "inconclusivo". O que isso significa?

Uma PE também precisa de uma solução com um prazo, e se não tiver consenso vai pra votação, e se não tiver uma decisão (2/3 para algum dos lados) toma-se uma decisão: fechar a PE como inconclusiva, mantendo o status quo e o artigo é mantido.

Em um pedido de administração na prática é a mesma coisa, 3/4 apoiando é aprovado, 3/4 não apoiando é negado, nem um nem outro é não-consenso, que pode significar prorrogar ou negar.

Os pedidos de ferramentas que não tem participação da comunidade são fechados como inconclusivos, que na prática significa 'negado'.

Pra autorrevisor e reversor, se o primeiro negar e o segundo apoiar, o pedido fica em aberto até aparecer um terceiro, ou seja, enquanto não se decidir por um dos lados o usuário não recebe as ferramentas, que significa mantém o status quo, como se o pedido nunca tivesse sido feito.

GE e conflitos entre usuários também, tem gente a favor de uma edição X, gente a favor da versão que estava antes, alguma decisão deve ser tomada, e a decisão é: se não tiver consenso, mantém o status quo, que é a versão que estava. É como se fosse uma GE administrativa, um adm protege, outro discorda e desprotege, outro volta a proteger, desprotege, etc, e a solução para esse impasse / não-consenso é reverter e voltar ao status quo: não protege.

Ou seja, na falta de consenso o pedido é fechado como inconclusivo, que pode significar manter o status quo (na maioria dos casos) ou prorrogar o prazo, ou levar para a votação.

Fizeram uma PE, fecharam como eliminar, pediram a revisão, não teve consenso. Então a PE seria fechada como inconclusiva, que significa levar para a segunda fase da PE: PE por votação.

Fizeram um pedido de ferramentas, aprovaram (ou negaram), pediram a revisão, não teve consenso, então fecha o pedido como inconclusivo, que significa o usuário não recebe as ferramentas.

Fizeram um pedido de proteção, responderam protegendo a página, pedem a revisão, não há consenso, então reverte pro status quo: página não fica protegida.

Por que para a tomada de decisão o não-consenso significa uma coisa, mas para a revisão um não-consenso significaria outra? Se antes de eu fechar uma PE eu conversasse com os administradores pedindo a opinião deles, e depois da discussão não houvesse consenso, o correto seria eu fechar a PE como inconclusiva, certo? Ou seja, PE iria para votação. Mas se eu me adiantasse e fechasse ela como eliminar, e depois alguém (que até pode ser eu mesmo) pedisse a opinião dos outros adms, acontecesse a mesma discussão e a mesma conclusão, e a minha primeira ação seria mantida, e a PE fechada como eliminada. Pq a diferença? Por eu ter 'corrido' para tomar uma decisão, essa decisão passa a ter prioridade?

Rjclaudio ^msg 14h20min de 6 de novembro de 2013 (UTC)

Citação: Poly escreveu: «passar-se de uma ação que não foi consensual para outra ação ainda menos consensual» - não entendi o que seria uma 'ação ainda menos consensual'. Se é por consenso, então é peso dos argumentos, e só não haveria consenso se tivesse bons argumentos para ambos os lados, então a meu ver não há um lado que é menos consensual que o outro, ambos os lados tem o mesmo peso. Só haveria 'menos consensual' se você estivesse considerando que há 5 adms apoiando uma ação X e apenas 1 apoiando a ação Y e aí sim a ação Y seria 'menos consensual', mas se for para contar cabeça entra na opção de "não há consenso = faz-se votação, 50%+1" que é a usada na DB.

Citação: com a agravante acrescida de promover o "wheel warring" - um usuário faz uma edição em um artigo, a 'regra' manda primeiro eu discutir e se não tiver consenso volta a versão estável, e se eu por acaso reverter e depois insistir em reverter fazendo uma GE eu sou bloqueado por GE. Você considera que essa regra promove uma GE? Uma regra que diz discute, e se não tiver consenso reverte, promove GE? Eu diria que é o contrário, se for uma regra de "se não tiver consenso mantém a versão atual" aí sim vai promover a GE por incentivar os usuários a serem 'rápido no gatilho' (rápido na reversão) para manterem a sua versão.

Citação: incitar a discórdia entre o corpo administrativo - Não vejo (espero) algum administrador que fique com raiva e guarde mágoa dos outros administradores por eles terem sido 'contra' a sua ação, também não vejo essa regra incentivando os administradores a discordarem da ação do primeiro, e não vejo o 'incentivo a pedir revisão para torcer pelo não-consenso' como algo ruim, pois quanto mais discussão mais as regras são analisadas e mais precedentes para se basear para tomar decisões no futuro, e isso vai incentivar a encontrar casos em que não há consenso pela interpretação das regras.

Rjclaudio ^msg 14h40min de 6 de novembro de 2013 (UTC)

Com o Cláudio. Antero, toda PE tem um prazo padrão pra ser encerrada, mas desde que o processo de eliminação por consenso foi implementado, raramente elas terminam nesse prazo. E isso é até bom, já que muitas vezes os artigos foram melhorados devido ao tempo extra, ou soluções melhores foram encontradas justamente por causa desse tempo de consenso maior. Então, numa revisão de PE, se não houver consenso entre os administradores de que a primeira ação é devida, pode-se reabrir a PE e aguardar mais tempo para se atingir o consenso, de um modo que os argumentos sejam melhor discutidos. Ou pode-se transformar em votação, que é o previsto na política para quando não houver consenso na fase de discussão. Essas duas saídas são a "inação". Mas se a tomada de decisão for como propõe o Zé, por maioria entre os sysops, então se um eliminador fecha uma PE de um modo e outros cinco discordam, não se pode dizer que aquela decisão foi "menos consensual", pelo contrário, foi mais próximo de um consenso do que a decisão tomada por somente um sysop. Matheus ^diga✍ 21h27min de 6 de novembro de 2013 (UTC) O comentário riscado foi colocado por um fantoche de Quintinense - Vanthorn^® 00h39min de 16 de maio de 2015 (UTC)

Votação criada. E. Feld ^fala 05h38min de 10 de novembro de 2013 (UTC)

Que tal, para padronização, colocar a opção Wikipédia:Pedidos/Revisão de ações administrativas na seção Caso sejam feitos em página separada das demais, qual o melhor título? _T^itoncio_itoncio (Discussão) 19h50min de 10 de novembro de 2013 (UTC)

@Rjclaudio Não, no caso de consensos de eliminações o "status quo" ou o ponto neutro não é a votação. Isso é falso. A votação é apenas uma das escolhas (ações) à disposição do sysop ao encerrar a discussão, tão válida ou possível de ser contestada como qualquer das outras. O vosso sistema não desfaz a ação nem propõe nada de neutro, mas antes impõe à força uma das opções de encerramento. Pergunta: se alguém contesta um encerramento indevido alegando que o sysop colocou em votação uma coisa que só teve argumentos para manter, por exemplo, segundo o vosso "sistema" qual seria o "status quo" neutro para onde se reverter? Antero de Quintal (discussão) 22h31min de 10 de novembro de 2013 (UTC)

Vou assumir que Citação: só teve argumentos para manter signifique "os argumentos para eliminar não eram válidos, e os para manter era, então só havia argumentos válidos para manter, e não deve ir para votação, deve fechar como Manter). Então o questionamento é se o argumento x para eliminar é ou não válido.

E aí eu devolvo a pergunta: se você vai encerrar uma PE e encontra um argumento que tem dúvida, realmente dúvida, se é válido ou não, ou você entende pela discussão que por um ponto de vista pode ser válido mas por outro ponto de vista não seria, o que você faz? Você decide que, pela sua interpretação das regras, é ou não é válido e fecha, ou diz que há dúvida / falha na clareza das regras e leva para votação, ou deixa a PE em aberto até pedir mais opiniões dos outros administradores?

É o mesmo caso. Se não há consenso entre os administradores que um argumento é válido, algo deve ser feito, ou decidimos que um argumento sem-consenso não é válido (devemos desconsiderar todos os argumentos em que não há certeza/consenso que siga as regras), ou decidimos que é válido (se não se enquadra em nenhum dos casos previstos para anulação, e parece seguir alguma regra, então em caso de dúvida e para liberdade de expressão, é válido), ou decidimos que temos dúvida de interpretação e deixamos a comunidade decidir (leva para votação), ou se suspende o processo até a comunidade decidir (volta para o status quo cancelando a PE, e a comunidade discute as regras para tornar mais claro o que fazer sobre esse argumento).

A minha opção seria a terceira (votação) ou quarta (cancela / inconclusiva / status quo), ou seja, se os adms tem dúvida, deixa a comunidade decidir, por votação ou por discussão das regras.

Alguma coisa deve ser feita. Só não podemos ter a situação em que há 50 adms que acham q o argumento x não é válido (e portanto encerra como apagar e não leva para votação), e 50 achando que não é válido (e portanto, votação), e o resultado ser: o primeiro no gatilho a fechar a PE decide, dando plenos poderes a um adm para se sobrepor a total falta de consenso da comunidade.

Rjclaudio ^msg 22h57min de 10 de novembro de 2013 (UTC)

[Ver]

WP:ADMIN - Aumentar o estágio probatório

A seguinte discussão encontra-se encerrada. Por favor não a modifique. Comentários posteriores devem ser feitos numa nova secção. Segue-se um resumo das conclusões obtidas nesta discussão.

Aprovada e implementada a Proposta 1.

---

Proposta 1

Problema detectado: tanto os administradores quanto os eliminadores precisam estar registrados há, no mínimo, 6 meses, para poderem se candidatar a esses cargos. Ora essa, se a função de administrador engloba totalmente a de eliminador e ainda traz privilégios adicionais, não seria natural que o escrutínio para esse cargo fosse maior? Como fazer um escrutínio maior se ambos passam por "estágio probatório" igual, de apenas 6 meses?

O tempo mínimo de existência no projeto não é, ou não deveria ser apenas uma exigência formal, mas sim um "estágio probatório", um período para avaliação tanto da habilidade para o cargo quanto dos aspectos comportamentais mesmo. Isso visa impedir o acesso ao cargo por pessoas que não têm capacidade de lidar com a responsabilidade que receberão, seja porquê não entendem as atribuições (o que é óbvio), quanto as que não têm comprometimento com a Wikipédia (o que não parece tão óbvio e quero expor agora).

É sabido que há um fantocheiro que foca seus esforços no aliciamento dos incautos (principalmente novatos) para que cheguem ao cargo de Administrador e, detendo maiores capacidades depois de eleitos, façam a pedido o que o fantocheiro deseja, ou até cedam a conta diretamente. Esse é um problema grave, e qualquer editor com somente 6 meses de Wikipédia ainda não tem conhecimento suficiente sobre o projeto, e muito menos o comprometimento desejado, para não deixar os novos poderes obtidos caírem nas mãos erradas.

Solução proposta: aumentar o tempo mínimo de registro para o cargo de administrador, de 6 meses para 12 meses.

Pois:

Se o prazo requerido fosse maior (digamos, 12 meses), isso dificultaria o trabalho dos aliciadores, que teriam de passar o dobro do tempo "cultivando" seus fantoches até poderem fazer uso dos privilégios, e portanto aumentaria a chance de dar errado e o tempo deles ser perdido, pois seria mais fácil obter evidências de comportamento indevido das contas, e pedir verificação, antes mesmo que chegassem a ser eleitas. Também, um editor legítimo eleito teria menos probabilidade de 'trocar favores' ou ceder a conta totalmente se tivesse mais experiência e comprometimento com o projeto, o que um novato de 6 meses ainda não tem.

Obs.: Eu acharia interessante aumentar também o prazo para o cargo de eliminador, já que também é um cargo visado pelo fantocheiro, mas não estou fazendo questão nesse momento.

--Mister Sanderson (discussão) 22h54min de 19 de janeiro de 2020 (UTC)

Concordo com a proposta de aumentar o prazo de 6 para 12 meses necessário para requerer o estatuto de sysop. Yanguas ^diz!-fiz 23h04min de 19 de janeiro de 2020 (UTC)

Comentário O problema parece ter mais a ver com a idade/maturidade do que o tempo de casa. Se houvesse alguma forma de determinar idade mínima (como para verificador/supervisor), seria algo a se pensar. Como não há, cabe à comunidade, identificar, pelos aspectos exteriores que são apresentados pelas edições, "qual é a desse editor", como dizemos aqui no Brasil. aumento de tempo mínimo é algo a se pensar, mas não vejo, em princípio, ligação com o caso. Millennium ^bug 23h14min de 19 de janeiro de 2020 (UTC)

@Millennium bug: Isso só faria o fantocheiro escolher seus aliciados entre editores mais velhos. E discordo que idade cronológica e maturidade andem necessariamente juntas. Há editores quarentões que se comportam como crianças mimadas, e editores bem jovens que demonstram maturidade. Lembro agora do Vini 175, que tinha menos de 20 anos quando foi eleito administrador e sempre foi respeitado pela comunidade. Yanguas ^diz!-fiz 23h26min de 19 de janeiro de 2020 (UTC)

Já tivemos administrador com 11 anos que fez (e ainda faz) um ótimo trabalho tanto com as ferramentas administrativas como no DP. Eu mesmo me tornei sysop com menos de 15 anos e sempre tive uma boa relação com a comunidade, tal como outros casos que conheço da mesma faixa etária. Dessa forma, idade não pode ser generalizada como fator de risco e regra para definir a maturidade de alguém, embora para se tornar checkuser seja exigido o mínimo de 18 anos. Nesse caso, por envolver acesso a informações privadas, é claramente correto existir uma idade mínima. No entanto, maturidade sim está diretamente ligada a badernas e aliciamentos e isso falta em muita gente (dentre crianças e adultos). --HVL disc. 01h39min de 20 de janeiro de 2020 (UTC)

Citação: Millennium bug escreveu: «Como não há, cabe à comunidade, identificar, pelos aspectos exteriores que são apresentados pelas edições, "qual é a desse editor", como dizemos aqui no Brasil.» A ideia de aumentar o tempo mínimo para se tornar administrador é exatamente dobrar o tempo para a comunidade ver "qual é a dele".--Mister Sanderson (discussão) 10h46min de 20 de janeiro de 2020 (UTC)

Comentário Acredito que deveria ser levado em consideração não quantidade de edição ou tempo no projeto, e sim a qualidade das contribuições. Mesmo sendo permitido um editor com seis meses de registro se candidatar a administrador, a quantidade de votos favoráveis para esses novatos têm sido preocupante? Pelo que vi, os requisitos de aprovação já são rigorosos, é necessário obter 75% de votos válidos favoráveis. Quantos editores nos últimos dez anos conseguiram o estatuto com apenas seis meses de registro? ✍️A.WagnerC (discussão) 23h48min de 19 de janeiro de 2020 (UTC)

Citação: A.WagnerC escreveu: «Acredito que deveria ser levado em consideração não quantidade de edição ou tempo no projeto, e sim a qualidade das contribuições.» Como você propõe que a qualidade seja medida?--Mister Sanderson (discussão) 10h47min de 20 de janeiro de 2020 (UTC)

@MisterSanderson: Através da análise das contribuições. Lá é possível verficar as edições que o(a) candidato(a) tem feito no projeto. É um processo árduo, mas é importante, pois permite conhecermos o perfil desse(a) editor(a). O pessoal muitas vezes prefere utilizar as ferramentas para ver quantas reversões, edições e páginas criadas. Isso também é importante, mas tem que ser complementar. Mas não sou contra a sua proposta de elevar o tempo mínimo de registro no projeto. ✍️A.WagnerC (discussão) 11h00min de 20 de janeiro de 2020 (UTC)

A.WagnerC, isso seria o ideal, mas não sei quantos voluntários teriam tempo de sobra para checar, candidatura-a-candidatura, milhares de edições para ver se o editor pode mesmo se tornar administrador ou não.--Mister Sanderson (discussão) 11h04min de 20 de janeiro de 2020 (UTC)

@A.WagnerC: Como disse o MisterSanderson, essa proposta seria o ideal, mas me parece utópica e, portanto, contraproducente. Além disso, cada editor tem um critério próprio de "qualidade", e isso emperraria ainda mais as já burocráticas discussões e decisões no projeto. Yanguas ^diz!-fiz 16h28min de 20 de janeiro de 2020 (UTC)

@Yanguas:. Eu mudei de ideia e Concordo também com a proposta 1. Estamos a avaliar aqui os critérios objetivos para que o editor possa se candidatar para administrador. Os subjetivos, analisamos durante o pedido. ✍️A.WagnerC (discussão) 16h41min de 20 de janeiro de 2020 (UTC)

Comentário Não creio que isto seja uma coisa que possa ser imposta com regras. Entre 6 meses, 1 ano ou 2 anos vai dar ao mesmo. O que tem que mudar é a cultura de exigência e responsabilização no ato eleitoral. Há uns tempos, para ser administrador era necessário ter experiência significativa de edição e alguma participação em discussões da comunidade. Atualmente muita gente vota a favor de qualquer coisa que mexa. Basta um novato ficar uns meses a carregar no fastbuttons e há logo uma série de gente que vota a favor para administrador. Passou-se do 80 (super-difícil) a 8 (escandalosamente fácil). Parece que o critério de eleição deixou de ser experiência, integridade e comprometimento com o projeto para ser uma espécie de miss simpatia ("ah, novato tem zero de experiência e nunca participou em nada, mas é bacana e dou voto de cofiança"). Mesmo com red flags gritantes levantadas nas eleições, continuam a votar a favor. Depois ficam muito surpresos quando aparecem fantocheiros na administração ou com decisões desastrosas. É tão fácil um fantocheiro chegar a sysop que até dói. JMagalhães (discussão) 00h03min de 20 de janeiro de 2020 (UTC)

Citação: JMagalhães escreveu: «Parece que o critério de eleição deixou de ser experiência, integridade e comprometimento com o projeto para ser uma espécie de miss simpatia» A ideia da proposta é mudar isso, ao menos em parte. Quanto mais tempo o "novato bacana" passar sem fazer nada de significativo, mais claramente ficará exposto que o potencial que as pessoas vêem nele não se realiza. Se o tempo mínimo de registro aumentar, será mais difícil um fantocheiro chegar a administrador.--Mister Sanderson (discussão) 10h50min de 20 de janeiro de 2020 (UTC)

@JMagalhães:, concordo plenamente contigo. Acho ainda que a maioria vota mais baseado em sua relação pessoal, ou para pagar algum favor, do que visando a capacidade para exercer o cargo. É por isso que apoio a proposta de aumentar o estágio probatório. Yanguas ^diz!-fiz 16h28min de 20 de janeiro de 2020 (UTC)

Concordo a proposta. Se quiserem acrescentar três mil edições como requisito, também concordo (é muito fácil chegar em dois mil - cinquenta edições por dia no domínio principal e com quarenta dias alcança).FábioJr de Souza ^msg 01h21min de 20 de janeiro de 2020 (UTC)

Concordo. Poderia ter alguns requisitos a mais, como tempo com a ferramenta de reversão ou autorrevisão. Eta Carinae (discussão) 01h25min de 20 de janeiro de 2020 (UTC)

Concordo com você, EVinente. Que tal lançar uma contraproposta? Crie um tópico, como o JMagalhães fez, e lance lá sua redação para os demais editores avaliarem.--Mister Sanderson (discussão) 10h59min de 20 de janeiro de 2020 (UTC)

Eu Concordo pois embora não elimine 100% o risco de uma conta com más intenções conseguir as ferramentas administrativas, como bem ressaltado pelo JMagalhães, teremos um dificultador desse processo. Sob o mesmo contexto aproveito para questionar se não seria válido substituir o item "2 000 edições válidas no domínio principal" dos requisitos da administração para algo do tipo: "2 000 edições válidas no domínio principal que preferencialmente envolvam um histórico de combate ao vandalismo, adição de conteúdo e manutenção em geral". Da forma como consta atualmente, é repassada a ideia de que basta reverter 2 000 vandalismos com scripts como "reversões e avisos" ou "FastButtons" no DP durante 6 meses que já pode ser julgado como apto. Tal como fui rebatido pelo MisterSanderson, entendo que a checagem dessa atuação pelos participantes de um pedido exigiria uma consulta aprofundada nas contribuições do candidato, mas justamente por isso que incluí o "preferencialmente". Não seria uma obrigação — embora o adequado seria que fosse, mas assim sendo provavelmente ficaríamos a nível crítico em quantidade de sysops —, mais como uma sugestão a ser levada em consideração pelo avaliado e pelos avaliadores. --HVL disc. 01h39min de 20 de janeiro de 2020 (UTC)

@HVL: Vide proposta 2 mais em baixo. JMagalhães (discussão) 01h49min de 20 de janeiro de 2020 (UTC)

Concordo. No entanto, sendo a proposta III também aprovada, os efeitos desta seriam superados e, portanto, penso, nem precisaria ser acrescentado na política, de modo a evitar tautologia. Érico (disc.) 15h25min de 20 de janeiro de 2020 (UTC)

Concordo. Lá embaixo "concordei com as duas". Aqui deixo claro. Millennium ^bug 16h20min de 20 de janeiro de 2020 (UTC)

Concordo. Pedro H. ^diz×fiz 17h28min de 20 de janeiro de 2020 (UTC)

Discordo da proposta 1. Apesar da iniciativa ser boa, exigir o aumento de um ano para requisito mínimo a flag de administrador não resolverá a questão das contas ilícitas, uma vez que é abrirá brecha para contas dormentes (com mais de um ano de registro) que já tiveram alguma edição válida no domínio principal antes, possa retornar ao projeto realizando a quantidade mínima de edições para o cumprimento deste requisito. Neste caso, o período mínimo de um ano poderia ser menos de um mês dependendo do período em que esta conta esteve dormente no projeto, além de ser subjetivo para os burocratas cancelarem ou não a votação. WikiFer ^msg 18h13min de 20 de janeiro de 2020 (UTC)

Citação: WikiFer escreveu: «abrirá brecha para contas dormentes (com mais de um ano de registro) que já tiveram alguma edição válida no domínio principal antes, possa retornar ao projeto realizando a quantidade mínima de edições para o cumprimento deste requisito.» Isso já é possível agora, e continuará sendo depois. Aumentar o prazo de registro não facilita que isto aconteça. Por outro lado, torna mais evidente este tipo de padrão, o que 6 meses não torna tão claro.--Mister Sanderson (discussão) 22h14min de 20 de janeiro de 2020 (UTC)

MisterSanderson Bom, você disse que aumentar o tempo de seis meses para um ano continuará servindo de brecha para a aparição destas contas; a verdade é que ampliação desse tempo só vai prorrogar que haja a prática do surgimento destas contas, não solucionar o problema – as contas dormentes continuarão surgindo. Contudo, você não chegou a imaginar que, talvez, o principal problema no processo de escolha para novos administradores seja, de fato, o excessivo número de edições semiautomáticas? Acredito que seja por isso que os vândalos estão subvertendo a regra. WikiFer ^msg 22h48min de 20 de janeiro de 2020 (UTC)

WikiFer, ok, mas você tem alguma contraproposta para acabar com as contas dormentes?--Mister Sanderson (discussão) 12h40min de 22 de janeiro de 2020 (UTC)

MisterSanderson Não tenho porque Wikipédia:Conta dormente ainda não foi regulamentada, só sabemos que burocratas podem anular votos com base na interpretação deles se existir evidências de meatpuppetry para manipular uma votação. Neste caso uma conta dormente com alguma edição válida poderia ressurgir ao projeto e cumprir estes requisitos, o que não seria um impedimento para o cumprimento dos requisitos mínimos. Quanto ao período inativo e o tempo que eles editam no projeto, a comunidade, neste caso, iria avaliar numa PDA. WikiFer ^msg 13h52min de 22 de janeiro de 2020 (UTC)

WikiFer, se você não tem como fazer o que é ideal, e a proposta não faz mal algum, porquê se opor à ela? Não percebo nenhum efeito colateral negativo que possa surgir a partir da ampliação do tempo do estágio probatório.--Mister Sanderson (discussão) 18h28min de 22 de janeiro de 2020 (UTC)

MisterSanderson Analisando melhor os comentários apresentados, vi que o único usuário que não demonstrou posição favorável a sua proposta foi o Saturnalia0, mas ele manteve-se neutro nas propostas 1 e 2 (neste caso pode-se desconsiderá-lo); JMagalhães também descartou posição contrária. Nesta proposta você já me refutou, afirmando que manter com seis meses não mudará a prática das contas dormentes. Sendo assim, irei ajustar minha proposta 4 com base nessa e, assim, podemos estabelecer o consenso na proposta 4. WikiFer ^msg 18h54min de 22 de janeiro de 2020 (UTC)

WikiFer, devo presumir que você deixou de se opor à Proposta 1?--Mister Sanderson (discussão) 19h00min de 22 de janeiro de 2020 (UTC)

MisterSanderson Sim, nesta edição eu já risquei minha posição inicial quanto à proposta 1. Falta você fazer o mesmo sobre sua posição inicial na proposta 4 e estabelecer um novo parecer lá. WikiFer ^msg 19h06min de 22 de janeiro de 2020 (UTC)

• Concordo Não resolve, mas ajuda. José Luiz ^disc 03h02min de 21 de janeiro de 2020 (UTC)

• Concordo. Chronus (discussão) 21h32min de 27 de janeiro de 2020 (UTC)

---

A discussão acima encontra-se encerrada. Por favor não a modifique. Comentários posteriores devem ser feitos numa nova secção.

Proposta 2: deixar de contabilizar edições automáticas para o acesso a estatutos

Lanço aqui uma segunda proposta: deixar de contabilizar edições automáticas para o acesso a estatutos.

Atualmente são necessárias 2000 edições no domínio principal para poder lançar uma candidatura a administrador. No entanto, com ferramentas como o fastbuttons, reversão e avisos e hotcat, é muito fácil chegar às 2000 edições em poucos/dias semanas. Isto corrompe e subverte o espírito da regra e torna o projeto extremamente vulnerável a socks e contornos de bloqueio. Esta falha tem sido sucessivamente explorada por fantocheiros que querem obter rapidamente estatutos sem ter muito trabalho e ficam o dia todo a carregar num botão. Portanto, proponho que a partir de agora passem a ser contabilizadas apenas edições manuais que efetivamente acrescentem ou melhorem o conteúdo, tal como a regra pretende.
A contabilização pode ser feita com a ferramenta Autoedits no Wmflabs

Obs: isto é uma segunda proposta diferente, não deixem de opinar sobre a proposta mais acima. JMagalhães (discussão) 01h48min de 20 de janeiro de 2020 (UTC)

@JMagalhães, e então, houve consenso ou não na sua contraproposta? Mr. Sand. ❧ Ano ⓬ 11h00min de 1 de maio de 2021 (UTC)

Concordo com a segunda proposta, em relação ao estatuto de administrador. Eu acho essa proposta de deixar de contabilizar edições automáticas melhor do que a de aumentar o tempo mínimo. Pois a estratégia dos fantocheiros é justamente aumentar a quantidade de edições através dessas ferramentas de edição automática. Com essa segunda proposta, privilegiará os editores que colocam a mão na massa. Quanto à primeira proposta, eu me mantenho neutro. ✍️A.WagnerC (discussão) 01h56min de 20 de janeiro de 2020 (UTC)

Neutro Para ambas propostas. O tempo de uso não significa muito se a conta esteve inativa por um período considerável, e o número de edições (automáticas ou não) também não diz muito, mas sim a qualidade e diversidade das mesmas. Um usuário que apenas combate vandalismo e nada mais, clicando em "reverter" em vandalismos óbvios, passa em ambos critérios mas não (só) por isso teria meu apoio. A avaliação subjetiva e caso-a-caso continua sendo a maior ferramenta de avaliação, os requisitos mínimos são meros filtros. Não me importo com o aumento e restrições propostos, mas acho que pouco adicionam. Saturnalia0 (discussão) 02h05min de 20 de janeiro de 2020 (UTC)

@JMagalhães: Sabe se existe alguma ferramenta que faz essa contabilização? --HVL disc. 02h15min de 20 de janeiro de 2020 (UTC)

@HVL: Sim JMagalhães (discussão) 02h17min de 20 de janeiro de 2020 (UTC)

Sendo assim, também Concordo com a proposta 2, porém sugiro que a ferramenta seja indicada no item do critério. --HVL disc. 02h21min de 20 de janeiro de 2020 (UTC)

Jmagalhães, eu só vou concordar com a Proposta 2 caso a ferramenta apontada por você seja incluída no texto da proposta, como sugeriu o HVL. Se isso não for feito, existe o risco de cada burocrata seguir a estatística de uma ferramenta diferente, e assim, acabar gerando discrepâncias.--Mister Sanderson (discussão) 11h30min de 22 de janeiro de 2020 (UTC)

@MisterSanderson: Hum, já tinha concordado. De qualquer forma, acrescentei lá em cima o link para o XTools. JMagalhães (discussão) 15h05min de 22 de janeiro de 2020 (UTC)

HVL, já que você concordou com a Proposta 2, seria interessante você opinar sobre a Proposta 4, que engloba a 2.--Mister Sanderson (discussão) 11h30min de 25 de janeiro de 2020 (UTC)

Jmagalhães, notei que, abrindo minhas estatísticas, não estão contabilizadas as milhares de edições que fiz no AWB há uns 8 anos atrás. Ou seja, existe um furo nessa ferramenta, que não permite ela funcionar 100% para determinar o cumprimento ao critério.--Mister Sanderson (discussão) 10h58min de 20 de janeiro de 2020 (UTC)

@MisterSanderson: de facto parece não estar a contabilizar edições automáticas muito antigas. O Érico também se queixava que não contabilizava correctamente edições do Huggle de 2011. Pode ter a ver com o facto de nessa época as etiquetas de edição não existirem ou serem diferentes; é uma questão a ver no futuro. Mas edições mais recentes parecem estar a ser corretamente contabilizadas, e no fundo é isso que interessa porque estamos a falar de distinguir "novatos do fastbuttons" com conta criada nos últimos meses ou anos. JMagalhães (discussão) 11h50min de 20 de janeiro de 2020 (UTC)

Concordo Com ambas as propostas. Mesmo com essas restrições, continua sendo fácil o suficiente para quem está comprometido. Não acredito que essas propostas sejam uma solução definitiva para o problema e talvez não resolvam, mas também não vejo prejuízo. Millennium ^bug 03h10min de 20 de janeiro de 2020 (UTC)

Concordo com essa proposta, também.FábioJr de Souza ^msg 03h21min de 20 de janeiro de 2020 (UTC)

Fabiojrsouza, já que você concordou com a Proposta 2, seria interessante você opinar sobre a Proposta 4, que engloba a 2.--Mister Sanderson (discussão) 11h30min de 25 de janeiro de 2020 (UTC)

Concordo completamente. Parabéns ao Mister Sanderson pela proposta! :). Micael D. ^{Oi, meu chapa!} 10h44min de 20 de janeiro de 2020 (UTC)

Micael D., você me parabenizou pela proposta, porém o fez na seção da proposta do JMagalhães. Afinal, você está concordando com a minha proposta, com a proposta dele, ou com ambas?

Micael D., já que você concordou com a Proposta 2, seria interessante você opinar sobre a Proposta 4, que engloba a 2.--Mister Sanderson (discussão) 11h30min de 25 de janeiro de 2020 (UTC)

Estou concordando com ambas, Mister! Enfim, Feito. Opinei sobre todas as propostas aqui apresentadas. Micael D. ^{Oi, meu chapa!} 13h47min de 25 de janeiro de 2020 (UTC)

Concordo, pois da forma como está, a letra da lei contradiz o espírito da mesma.--Mister Sanderson (discussão) 10h54min de 20 de janeiro de 2020 (UTC)

Concordo. Érico (disc.) 15h23min de 20 de janeiro de 2020 (UTC)

Érico, já que você concordou com a Proposta 2, seria interessante você opinar sobre a Proposta 4, que engloba a 2.--Mister Sanderson (discussão) 11h30min de 25 de janeiro de 2020 (UTC)

Concordo, não vejo impedimentos. Leandro Drudo (discussão) 16h46min de 20 de janeiro de 2020 (UTC)

Leandro Drudo, já que você concordou com a Proposta 2, seria interessante você opinar sobre a Proposta 4, que engloba a 2.--Mister Sanderson (discussão) 11h30min de 25 de janeiro de 2020 (UTC)

Concordo. Parece ser a melhor alternativa. Mas também acho que há de se desconsiderar o uso do botão "desfazer". Pedro H. ^diz×fiz 17h28min de 20 de janeiro de 2020 (UTC)

Pedrohoneto, já que você concordou com a Proposta 2, seria interessante você opinar sobre a Proposta 4, que engloba a 2.--Mister Sanderson (discussão) 11h30min de 25 de janeiro de 2020 (UTC)

Observação: Esta proposta parece ser interessante, mas é importante ressaltar que a prática excessiva de salvamentos sucessivos e edições menores é muito adequado para um novato que inicia seu desempenho no projeto (meu início), portanto ignorar as edições semiautomáticas não significa que resolverá a questão, porque edições menores e salvamentos sucessivos não fazem parte deste requisito. Além disso, o XTools identifica o comando Desfazer como uma edição semiautomática quando, na verdade, deveria ser uma edição manual, pois se trata em desfazer um vandalismo, podendo até realizar algumas modificações na edição que está prestes a ser desfeita (vai que existe resquícios mínimos de vandalismo numa edição + conteúdo referenciado a ser expandido); quanto a ferramenta de reversor (comando Reversão), aí sim poderia considerar como semiautomática porque só reverte edições de vandalismo claro, além do que só reverte múltiplas edições de um único editor apenas. Portanto, não gostaria de discordar da proposta 2 por este motivo, mas acredito que deve-se discutir melhor esse ponto antes de aplicar qualquer consenso. WikiFer ^msg 18h13min de 20 de janeiro de 2020 (UTC)

@WikiFer: É insustentável para um fantocheiro tentar ganhar edições à conta de salvamentos sucessivos. Os salvamentos sucessivos são proibidos e à segunda ou terceira tentativa o mais provável é acabar bloqueado. De qualquer forma, nenhuma destas soluções é milagrosa. Ajudam, claro, mas há um esforço final de escrutínio que tem obrigatoriamente que ser feito por quem está a votar e que nenhuma regra pode substituir. É a tal questão da cultura e responsabilidade que eu comentei na proposta 1. JMagalhães (discussão) 23h06min de 20 de janeiro de 2020 (UTC)

JMagalhães Eu compreendo a importância de atualizar os requisitos mínimos para a eleição de novos administradores, inclusive, ultimamente a comunidade vem tendo o costume de eleger novos administradores sem analisar o desempenho deles no projeto pelo domínio principal, isso ocorre quando não há evidências de que este usuário não possa receber a confiança do projeto. Em relação a sua proposta, antes de me posicionar, até gostaria de aguardar como será definido a contabilização de edições semiautomáticas no que diz respeito ao comando Desfazer que, ao meu ver, é uma edição manual (passível de modificações antes de ser desfeito) e necessário para o novato já ter o costume de combater o vandalismo justificando no sumário de edições. WikiFer ^msg 23h25min de 20 de janeiro de 2020 (UTC)

@WikiFer: Uma edição que ao desfazer também modifique conteúdo nunca é contabilizada como desfazer. JMagalhães (discussão) 15h05min de 22 de janeiro de 2020 (UTC)

JMagalhães Só que o XTools registra essa edição como semiautomática porque usou o botão Desfazer, é isso que deve ser questionado, pois nem sempre todo conteúdo a ser desfeito pode ser considerado vandalismo. Às vezes o sujeito inclui vandalismo + conteúdo válido ao mesmo tempo, o que resultaria num ajuste da edição desfeita modificando a edição antes de salvar. WikiFer ^msg 15h11min de 22 de janeiro de 2020 (UTC)

@WikiFer: É isso que estou a dizer. Se a edição for mais do que desfazer, não é contanilizada como desfazer. JMagalhães (discussão) 15h14min de 22 de janeiro de 2020 (UTC)

JMagalhães Neste caso, o número de edições válidas pelo comando Desfazer teria que ser analisado caso a caso; só não seria subjetivo para os burocratas aplicarem requisito das 2000 edições se este já cumprir a quantidade das não-semiautomáticas. WikiFer ^msg 15h21min de 22 de janeiro de 2020 (UTC)

Concordo José Luiz ^disc 03h04min de 21 de janeiro de 2020 (UTC)

jbribeiro1, já que você concordou com a Proposta 2, seria interessante você opinar sobre a Proposta 4, que engloba a 2.--Mister Sanderson (discussão) 11h30min de 25 de janeiro de 2020 (UTC)

Há edições por ferramentas automáticas que não são marcadas como tal. Por isso, algum cuidado com isso. GoEThe (discussão) 11h48min de 21 de janeiro de 2020 (UTC)

• Concordo. Chronus (discussão) 21h32min de 27 de janeiro de 2020 (UTC)

Proposta 2.1: deixar de contabilizar edições automáticas para o acesso a estatutos e considerar experiência técnica

Em adição ao texto do JMagalhães, também considero oportuno que os candidatos tenham experiência técnica (reversor e autorrevisor), bem como participação regular nos meandros da comunidade. Então proponho em adição:

1. Mínimo de 1 ano de experiência regular com a ferramenta de reversão e/ou autorrevisão (atribuída após pedido);
2. Participação regular nas discussões de eliminação, EAD, entre outras de relevância para se qualificar a experiência pregressa do candidato;

-- Eta Carinae (discussão) 14h54min de 20 de janeiro de 2020 (UTC)

@EVinente, e então, houve consenso ou não na sua contraproposta? Mr. Sand. ❧ Ano ⓬ 11h00min de 1 de maio de 2021 (UTC)

Concordo exceto quanto ao "atribuída após pedido". Se a pessoa quer ferramentas que permitem bloquear e eliminar páginas, deve demonstrar que tem algum conhecimento nessas áreas (até porque, os estatutos são para ajudar o editor em tarefas que estão desempenhando.FábioJr de Souza ^msg 15h19min de 20 de janeiro de 2020 (UTC)

Concordo com o ponto I, mas não com o II, que é subjetivo e portanto não pode ser um critério mínimo, aferido sumariamente como pressuposto de abertura do pedido. A participação em discussões ou votações deve ser julgada pela comunidade, e não pelos burocratas quando estes avaliam se o pedido pode ou não continuar. Érico (disc.) 15h21min de 20 de janeiro de 2020 (UTC)

Érico, o ponto I não é subjetivo também? O que é "experiência regular"? Não é algo que vai variar dependendo do burocrata que avaliar o pedido?--Mister Sanderson (discussão) 11h27min de 22 de janeiro de 2020 (UTC)

MisterSanderson Não é subjetivo. Está lá: 1 ano de experiência regular como autorrevisor ou reversor. Não permite julgamento político pelos burocratas. Érico (disc.) 13h39min de 22 de janeiro de 2020 (UTC)

Érico, existe uma grande diferença entre "1 ano de experiência" e "1 ano de experiência regular". A questão é que para o primeiro termo, basta conferir a data de atribuição do estatuto de autorrevisor/reversor, contar se passaram-se 12 meses, e dar um resultado. Para o segundo termo, por causa da palavra "regular", torna-se necessário ver quão assiduamente o estatuto foi realmente usado, mas não há um padrão de referência para diferenciar "1 ano de experiência regular" de "1 ano de experiência irregular". Com base em quê um burocrata poderá afirmar que a experiência não foi regular?--Mister Sanderson (discussão) 13h55min de 22 de janeiro de 2020 (UTC)

Concordo com o conteúdo exposto pelo JMagalhães na proposta de número 2.

Os atuais requisitos mínimos são fracos, pois: (i) "protege" a comunidade de um "novato" obter as ferramentas por apenas seis meses, sendo que alguns banidos vem tomando pose de contas já existentes. (ii) estabelece um número mínimo de edições facilmente atingido por ferramentas (semi)automáticas.

Sobre o que propôs o EVinente, concordo com o primeiro item; contudo, o segundo item é um pouco subjetivo. Quem irá determinar que o usuário tem participação regular (o que seria regular?). Eu vejo o segundo item como um requisito dos participantes das candidaturas em avaliar a aptidão do candidatado. Edmond Dantès ^{d'un message?} 16h05min de 20 de janeiro de 2020 (UTC)

Concordo com o item i, Discordo da frase "atribuída após pedido e Discordo do item ii, per anteriores. Millennium ^bug 16h38min de 20 de janeiro de 2020 (UTC)

Concordo com o primeiro item da proposta, mas discordo do segundo dela, pelo mesmo motivo dos usuários acima. Leandro Drudo (discussão) 16h44min de 20 de janeiro de 2020 (UTC)

Discordo em absoluto do primeiro ponto. A ideia á primeira vista até parece boa. Mas ninguém considerou o escandaloso potencial de abuso que isto tem. Se um administrador não quiser que um desafeto seja alguma vez eleito sysop, basta remover lhe um dos estatutos, fazendo com que uma decisão da comunidade passe a ser unilateral. E pode continuar a fazer isto indefinidamente, na prática minando qualquer possibilidade do desafeto ser avaliado pela comunidade. (e não, não venham dizer que ações vingativas não acontecem neste projeto nem que não é possível pegar um toda e qualquer miudeza para "justificar" a remoção) JMagalhães (discussão) 17h12min de 20 de janeiro de 2020 (UTC)

Discordo. Tornar-se administrador não é uma "promoção" dos demais estatutos. Além das ferramentas serem independentes umas das outras, um administrador não precisa ser ativo no combate ao vandalismo para ser eleito, já que cada um é livre para atuar na área que mais lhe apetecer. Impor que alguém precise reverter edições só fomenta a cultura de termos editores-robôs como administradores. Pedro H. ^diz×fiz 17h28min de 20 de janeiro de 2020 (UTC)

Discordo do ponto I, que abre subjetividade quanto ao "mínimo de 1 ano com experiência regular". Uma conta pode editar de forma ativa no mês de janeiro e fevereiro, se ausentar entre março e maio, depois volta em junho, e ausenta no mês de setembro... por aí vai. A verdade é que exigir 1 ano de experiência pode abrir interpretações se esta "experiência" deve ocorrer durante um ano de atividade ou um 12 meses completo em contribuições com o projeto, ignorando o período de ausências. Quanto ao ponto II, não podemos esquecer que os requisitos mínimos é uma prerrogativa para os burocratas determinarem se um PDA está apto para ser validado ou não; portanto, exigir participação em discussões de eliminação, EADs, e entre outros, é uma função da comunidade avaliar, não dos burocratas. WikiFer ^msg 18h13min de 20 de janeiro de 2020 (UTC)

Discordo de ambos os pontos pelo que foi exposto pelo JMagalhães. --HVL disc. 19h17min de 20 de janeiro de 2020 (UTC)

• Concordo com o primeiro item, mas não com i segundo. Chronus (discussão) 21h32min de 27 de janeiro de 2020 (UTC)

Proposta 3

Lanço aqui uma terceira proposta:

"Um administrador deve possuir estatuto de eliminador/reversor por pelo menos seis meses e 1000/500 ações administrativas".

Assim foca nas ações administrativas e não em edições comuns, sem deixar de considerar essas edições. Pra deixar claro: 1000 ações administrativas pra eliminador e 500 pra reversor (que só pode bloquear). -- Sete de Nove ^msg 15h31min de 20 de janeiro de 2020 (UTC)

@79a, e então, houve consenso ou não na sua contraproposta? Mr. Sand. ❧ Ano ⓬ 11h00min de 1 de maio de 2021 (UTC)

MisterSanderson Parece que não, só um "concordo", mas muitos "discordo"s com argumentos diferentes! -- Sete de Nove ^msg 11h42min de 1 de maio de 2021 (UTC)

@79a, posso então encerrar essa seção com "proposta reprovada"? Mr. Sand. ❧ Ano ⓬ 09h41min de 7 de maio de 2021 (UTC)

Concordo Há a necessidade de se aplicar regras mais rigorosas aos estatutos, sobretudo no que se diz a respeito a ferramentas sensíveis. Deixar de contabilizar edições automáticas é uma proposta importante, não é difícil atingir 2000 edições através de ferramentas automatizadas, há também a necessidade de avaliar criteriosamente o editor através de suas contribuições "manuais" e benéficas ao projeto, bem como uma análise comportamental e participações em discussões da comunidade. Ações administrativas também são importantes para melhor avaliação do candidato. Embora não considere as propostas apresentadas como a solução definitiva ao problema, dificultará e reduzirá o êxito de aliciadores e a obsessão pelo poder. Jhonnycach ^(Discussão) 16h02min de 20 de janeiro de 2020 (UTC)

Em relação à proposta 3 em especial, também estou em desacordo. Cada um possui vocações e áreas de atuação dentro do projeto, e cada um deles tem sua importância. É problemático um editor(a) se submeter em uma área de atuação em que não possui afinidade por números, nem todos atuam em eliminações e um administrador atua em diversas áreas. A observação feita pelo Millennium bug é importante. Jhonnycach ^(Discussão) 19h27min de 20 de janeiro de 2020 (UTC)

Jhonnycach, a Proposta 3 desconsidera que cada administrador tem diferentes vocações. Presume que todos devem necessariamente se especializar em eliminações. O que você tem a dizer a respeito disto?--Mister Sanderson (discussão) 11h29min de 22 de janeiro de 2020 (UTC)

MisterSanderson, conforme citei acima, discordo desta proposta. Ter conhecimentos sobre a política de eliminação é importante, mas ser ativo na área não deveria ser fator crucial para admissão de administradores. As ferramentas administrativas oferecem muito mais tarefas a serem executadas, como proteções, bloqueios estendidos, gerenciamento de privilégios, supressões...muitos fatores devem ser levados em consideração. Jhonnycach ^(Discussão) 11h50min de 22 de janeiro de 2020 (UTC)

Jhonnycach, você não disse que discorda. Seu comentário é um "concordo". Será que você se confundiu?--Mister Sanderson (discussão) 12h38min de 22 de janeiro de 2020 (UTC)

MisterSanderson Concordei com as propostas anteriores e fiz um novo comentário discordando deste em particular, embora discorde também do ponto I da proposta 2.1, como bem observado pelo JMagalhães. De fato ficou confuso e peço desculpas por isto. Jhonnycach ^(Discussão) 12h45min de 22 de janeiro de 2020 (UTC)

Discordo Cada admin tem vocações diferentes. Não é necessário ser mestre em bloqueio de ip ou em eliminação para o estatuto. Não dá para substituir a análise de cada votante sobre o usuário por um calhamaço de critérios objetivos - aí, sim, pode dificultar e desestimular quem tenha vocação mas não tenha saco paciência ou prazer para ficar o dia inteiro fazendo tarefas repetitivas. Assim, do mesmo modo que se está desvalorizando a tarefa repetitiva em uma proposta, se valoriza tal tarefa em outra. Então, os requisitos, ao se acumularem, se somam: o candidato terá que ter 2000 edições no DP sem contabilizar os automatizados e, além dessas edições terão que ter mais duas mil reversões, para que um quarto dessas resultem em bloqueio. Conclusão: requisito demais e desnecessário. Millennium ^bug 16h27min de 20 de janeiro de 2020 (UTC)

PS: Ao "quantificar" bloqueios e eliminações como portfolio de realizações da conta, há um problema até mais sutil aqui: o usuário que estiver nesta fase será tentado a bloquear ou eliminar, em detrimento das outras opções, como não bloquear, manter em observação, avisar, impugnar ER, melhorar e ajudar a manter, mandar para PE, não necessariamente porque aquelas sejam as ações melhores, mas porque dão número. Enfim, "remunerar um policial pelo número de prisões ou um juiz pelo número de condenações" nunca foi uma boa ideia. Millennium ^bug 16h34min de 20 de janeiro de 2020 (UTC)

Tal como o Millennium bug, também acho que cada administrador pode ter uma vocação diferente, e que por isso não se deve cobrar que todos sejam canivetes suíços. Mas, por enquanto, prefiro não opinar oficialmente sobre a Proposta 3.--Mister Sanderson (discussão) 16h33min de 20 de janeiro de 2020 (UTC)

Comentário Como Érico destacou, estamos a analisar aqui critérios objetivos. Os subjetivos são tratados quando vamos votar no candidato. Então, o que for decidido aqui, lógico que não vai resolver definitivamente os problemas, mas entendo que nem devemos pensar nisso no tocante aos critérios objetivos. Esses critérios objetivos só servem para o burocrata avaliar se ele pode pedir ou não o estatuto. É por isso que Discordo da proposta 2.1, Sobre a proposta 3, entendo que está valorizando mais as pessoas que usam ferramentas de edições semiautomáticas. E como bem disse Millennium bug, algumas pessoas podem ficar tentadas e até mesmo abusar da ferramenta de bloqueio, por isso, apesar de eu apreciar a proposta de 79a, eu não acho viável a proposta 3, mas vou ficar neutro. ✍️A.WagnerC (discussão) 16h39min de 20 de janeiro de 2020 (UTC)

Discordo Nem todos os administradores têm interesse por eliminações. A ferramenta é muito ampla e as atribuições de administrador são muito diversas. JMagalhães (discussão) 17h17min de 20 de janeiro de 2020 (UTC)

Discordo, per Millennium. Pedro H. ^diz×fiz 17h29min de 20 de janeiro de 2020 (UTC)

@Millennium bug, A.WagnerC e JMagalhães: Eu não especifiquei "eliminações", mas "ações administrativas". Quanto aos "abusos", se ocorrerem, é um bom motivo pra não atribuir o estatuto. Será que 1000/500 ações administrativas em seis meses é muita coisa? A ideia aqui é ver o que o editor faz com as ferramentas que tem e criar "efetivamente", um "estágio" (obrigar a passar antes por "eliminador" ou "reversor", e isso não é difícil). Se não faz uso dessas ferramentas, será que precisa do estatuto maior? -- Sete de Nove ^msg 17h37min de 20 de janeiro de 2020 (UTC)

O estatuto de administrador tem muito mais ferramentas e atua em muito mais áreas do que eliminação de páginas. JMagalhães (discussão) 17h50min de 20 de janeiro de 2020 (UTC)

@JMagalhães: É ações administrativas (você leu o que eu escrevi?) -- Sete de Nove ^msg 17h55min de 20 de janeiro de 2020 (UTC)

Uma ação administrativa é uma ação que no software MediaWiki só possa ser realizada com privilégios de administrador. Vou considerar que eliminações são também ações administrativas, dado que o estatuto de eliminador é uma versão light do de administrador. De resto, não percebo o que é bque entende por ações administrativas. É bloqueio por reversores? Está a exigir que para alguém se poder candidatar a administrador tenha que ter bloqueado 1000 pessoas nos últimos seis meses? Balha-me deus... JMagalhães (discussão) 18h05min de 20 de janeiro de 2020 (UTC)

Discordo da proposta 3. Nem todo administrador precisa se candidatar a eliminador para estar apto a flag. Eu, por exemplo, fui eleito sysop em 2015 sendo apenas autorrevisor e reversor. Além disso, a quantidade de bloqueios (nível reversor) cabe a comunidade avaliar, não aos burocratas. WikiFer ^msg 18h13min de 20 de janeiro de 2020 (UTC)

Comentário Eu conheço uma administradora muito boa, mas que usa pouco as ferramentas de ação administrativa. ✍️A.WagnerC (discussão) 19h02min de 20 de janeiro de 2020 (UTC)

Discordo segundo o que foi colocado pelo Millennium bug. Eu próprio atuo muito pouco na eliminação de páginas. --HVL disc. 19h17min de 20 de janeiro de 2020 (UTC)

Também me ponho como Neutro nessa proposta. Micael D. ^{Oi, meu chapa!} 13h43min de 25 de janeiro de 2020 (UTC)

Proposta 4 – adendo das propostas 1 e 2

Com base no que foi discutido nas propostas anteriores, lanço essa aqui para determinar o consenso e aplicar no texto da política de administradores:

Para solicitar a permissão de administrador, o usuário, deverá possuir:

• Uma conta com pelo menos seis meses um ano de registro;
• 2 000 edições válidas no domínio principal;
  • Edições semiautomáticas não são contabilizadas (com exceção do botão Desfazer);

Os usuários que não cumprirem os requisitos supracitados poderão ter seus pedidos cancelados a qualquer momento por um burocrata antes do prazo de encerramento.

Acredito que isso já é suficiente para aplicar o consenso. WikiFer ^msg 15h32min de 22 de janeiro de 2020 (UTC)

Discordo, é essencial para mim que o prazo mínimo de registro seja de, pelo menos, 12 meses. A sua proposta anularia a minha proposta original.--Mister Sanderson (discussão) 16h44min de 22 de janeiro de 2020 (UTC)

MisterSanderson Mas a sua proposta foi refutada pelo JMagalhães sob alegação que deve-se avaliar um usuário com base no desempenho das edições no domínio principal, além de que aumentar o tempo não mudará a cultura como a comunidade deve avaliar um candidato. WikiFer ^msg 16h51min de 22 de janeiro de 2020 (UTC)

Eu não me posicionei contra a proposta. Só comentei que era insuficiente e que o problema é mais cultural do que técnico. JMagalhães (discussão) 16h59min de 22 de janeiro de 2020 (UTC)

Não se posicionou contra, mas apresentou razões pelas quais o período de tempo não seria benéfico para a proposta. Além disso, outros usuários também chegaram a se manifestar a respeito do tempo também. WikiFer ^msg 17h11min de 22 de janeiro de 2020 (UTC)

Risquei minha discordância pois agora o texto da Proposta 4 já foi alterado para uma forma da qual não discordo.--Mister Sanderson (discussão) 19h09min de 22 de janeiro de 2020 (UTC)

@WikiFer, e então, houve consenso ou não na sua contraproposta? Mr. Sand. ❧ Ano ⓬ 10h59min de 1 de maio de 2021 (UTC)

MisterSanderson Sim, houve consenso pela proposta 4 (minha contraproposta) conforme já havia explicado, resta só aguardar se o Phabricator conseguiu remover o uso do botão Desfazer das estatísticas de edições semiautomáticas. WikiFer ^msg 03h35min de 2 de maio de 2021 (UTC)

Esta "proposta 4" só está a gerar confusão desnecessariamente. A primeira parte é a repetição da proposta 1. A segunda parte é a repetição da proposta 2, com a única diferença de desfazer uma edição não contar como edição semi-automática. Sobre este último ponto já tinha sido referido que quando se desfaz uma edição E se modifica de alguma forma o conteúdo, essa edição não é contabilizada pelo XTools como "desfazer". JMagalhães (discussão) 19h51min de 22 de janeiro de 2020 (UTC)

JMagalhães A proposta 4 é um adendo das propostas 1 e 2, com a inclusão de abrir uma exceção em relação ao botão Desfazer pois o XTools identifica estas edições como semiautomática (meus dados constam mais de 2 mil edições pelo desfazer como semiautomática). Sendo assim, é importante deixar bem claro para os burocratas antes de legalizar qualquer candidatura para uma PDA – este adendo é para estabelecer o consenso. WikiFer ^msg 19h57min de 22 de janeiro de 2020 (UTC)

As duas propostas iniciais já estavam encaminhadas para o consenso, com praticamente unanimidade a favor. Essa questão do desfazer ou não pode ser perfeitamente levantada na própria proposta e deixada à consideração dos restantes. Quem concordar consigo pode referir que tem igual posição. Não é preciso abrir duas propostas para a mesma coisa, que só vão gerar confusão para a obtenção de um consenso. JMagalhães (discussão) 20h03min de 22 de janeiro de 2020 (UTC)

Também acho inadequado lançar uma nova proposta que incorpore duas outras só para mudar um detalhe de uma delas. Parece-me um tiro no pé, pois repetitividade tende a não atrair participação da comunidade. Só espero que não acabe atrapalhando as demais propostas dessa forma. --Mister Sanderson (discussão) 20h06min de 22 de janeiro de 2020 (UTC)

Comentário Dei uma reformulada na subseção da proposta 4, registrando o adendo, acredito que isso pode ter gerado a tal confusão. No entanto, a proposta 4 já deixa organizado como se deve ser alterado a política de administradores, cabendo apenas decisão sobre este tema do XTools, algo que até o usuário Pedrohoneto levantou esta questão. Isto não é um problema que vai atrapalhar um consenso que já foi estabelecido em duas propostas anteriores. WikiFer ^msg 20h11min de 22 de janeiro de 2020 (UTC)

Repito e esclareco o que disse na proposta 2. Há ferramentas automáticas que não são contadas no X-tools, porque não deixam nenhuma indicação diagnóstica no sumário de edição. É temerário fiar-se nisso para determinar que uma edição não é automática. GoEThe (discussão) 16h20min de 24 de janeiro de 2020 (UTC)

Quais? JMagalhães (discussão) 16h29min de 24 de janeiro de 2020 (UTC)

GoEThe O sistema do XTools costuma deixar de registrar edições semiautomáticas. Eu já realizei aprox 1000 edições com AWB em 2015 e o site não registrou. A proposta 2 descarta edições semiautomáticas; já a proposta 4 é um adendo que abre uma exceção ao botão Desfazer. WikiFer ^msg 16h31min de 24 de janeiro de 2020 (UTC)

o Java wiki browser que eu saiba, pelo menos, e qualquer uma que não esteja nessa lista, em geral, obviamente. Mesmo o Awb tem uma opção para n colocar no sumário de edição que ele foi usado. GoEThe (discussão) 19h35min de 24 de janeiro de 2020 (UTC)

Ok, vou requisitar a inclusão. JMagalhães (discussão) 23h03min de 24 de janeiro de 2020 (UTC)

Eu já pedi em [1]

Monitorada no Phabricator
Tarefa T235482

, mas não parece ser possível. GoEThe (discussão) 11h19min de 28 de janeiro de 2020 (UTC)

Concordo com os termos exatos da proposta 4. Argumentos já apresentados. Por mim, encerra! ✍️A.WagnerC (discussão) 20h25min de 24 de janeiro de 2020 (UTC)

Concordo com a proposta e com encerrar o debate. Millennium ^bug 04h09min de 25 de janeiro de 2020 (UTC)

Concordo com a proposta final. Vanthorn^® 04h31min de 25 de janeiro de 2020 (UTC)

Concordo com a proposta final. Micael D. ^{Oi, meu chapa!} 13h45min de 25 de janeiro de 2020 (UTC)

Concordo com a proposta e encerrar a questão. FábioJr de Souza ^msg 14h50min de 25 de janeiro de 2020 (UTC)

Esta "proposta 4" só está a confundir. O texto repete as propostas 1 e 2, que já tinham um amplo consenso. A única diferença é a introdução de um adendo que propõe que desfazer edições volte a ser incluído nas contas para obtenção do estatuto. No entanto, isto não está nada claro. Creio que as pessoas estão a apoiar convencidas que isto é a proposta 1 e 2 em conjunto. E sobre o adendo em si, eu Discordo. O objetivo destas propostas tem sido assegurar que o candidato tem um mínimo de histórico na criação/melhoria de conteúdo, respeitando o espírito da regra. Nesse contexto, em que é que desfazer edições é diferente de desfazer edições com o botão de reversão, com o script reversão e avisos ou com o Huggle? Nenhum. Qual é o sentido de uma candidatura de alguém que a única coisa que fez no projeto foi desfazer 2000 edições? Em que é que isso é diferente de usar outros scripts? Em que é que isso combate exatamente a fantocheria? JMagalhães (discussão) 15h44min de 25 de janeiro de 2020 (UTC)

Acredito que você esteja esquecendo que o estatuto de administrador é redundante com o de reversor, que exige que o usuário tenha conhecimento no combate ao vandalismo para receber a flag. O uso do comando Desfazer é uma prática recomendável para todos os usuários que estão iniciando no projeto, podendo justificar edições no sumário, além de modificar parte do texto a ser desfeito antes de salvar uma edição. Portanto, seu parecer, na verdade, está prejudicando o consenso de toda esta discussão, uma vez que o adendo é justificamente para resolver esta questão que o usuário Pedrohoneto registrou antes mesmo da minha avaliação sobre a proposta 2. Alegar que "está a confundir" é subestimar os cinco pareceres favoráveis pela proposta 4 acima, que já inclui tudo que foi discutido por aqui. WikiFer ^msg 16h18min de 25 de janeiro de 2020 (UTC)

Que confusão sem pés nem cabeça. Exigir que a pessoa tenha no mínimo 2000 edições de afetivo acréscimo/melhoria de conteúdo não significa que a pessoa não possa ter também ações de combate ao vandalismo. As duas coisas não são mutuamente exclusivas. Também já lhe foi dito vezes sem conta que desfazer e modificar conteúdo não conta como edição automática. O que o seu adendo vai permitir é que novatos que nunca criaram/modificaram conteúdo se possam candidatar a administrador. Por outras palavras, é sabotar toda a proposta e voltar praticamente ao ponto onde estamos, onde fantocheiros chegam à administração com um mínimo de trabalho e só a desfazer vandalismo óbvio. JMagalhães (discussão) 16h34min de 25 de janeiro de 2020 (UTC)

É justamente por isso que a proposta 4 é necessária, pois uma pessoa também deve ter ações no combate ao vandalismo sem a necessidade de usar uma ferramenta semiautomática, isso não impedirá que o usuário contribua no domínio principal. Por outro lado, todas as edições do comando Desfazer é contabilizado como edição semiautomática, eu mesmo já provei isso apresentando mais de 2 mil edições recentes minha sobre este botão. A proposta 4 é para abrir uma exceção sobre este comando, para que os burocratas possam desconsiderar o comando Desfazer da lista de edições semiautomáticas. Não se pode confundir um comando atribuído para todos os usuários deste projeto com a prática de novatos nunca modificarem conteúdo, pois para usar AWB precisa ser autorrevisor, para usar o Huggle precisa ser reversor, a única forma de um fantocheiro burlar o sistema é usando FastButtons e Reversão e Avisos, estes sim possuem comandos que vão além da prática de desfazer um vandalismo. Da mesma forma que usuários bem intencionados podem expandir conteúdo de artigos, podem também desfazer vandalismos de artigos que eles já vigiam no projeto, usando um botão já disponível para todos eles, é a prática da presunção de boa-fé. WikiFer ^msg 16h46min de 25 de janeiro de 2020 (UTC)

Concordo com o teor da proposta, mas Neutro em relação à inclusão da opção "Desfazer" na contagem de edições. Se por um lado indica que a conta tem interesse em combater vandalismo, pelo outro basta um mal intencionado desfazer 1600 vandalismos manualmente intercalados com outras 400 de adição de fonte em um esboço aleatório para que a comunidade o veja como apto. Com isso eu realmente opto por me abster nesse ponto, mas caso seja dada uma alternativa ou eu mesmo pense em algo posso voltar para opinar. --HVL disc. 17h12min de 25 de janeiro de 2020 (UTC)

Contudo, a comunidade seria soberana para questionar as múltiplas edições de vandalismos desfeitos do usuário, a ponto de avaliar se este receberia a flag de administrador ou não. A proposta que está sendo alterada aqui é apenas como os burocratas deverão legalizar a abertura de uma PDA. WikiFer ^msg 17h20min de 25 de janeiro de 2020 (UTC)

Comentário É importante ter em mente, também, que quem vai decidir se a pessoa vai ser eleita ou não é a comunidade. Então, se a pessoa abusou do botão desfazer, isso vai ser levado em conta. Ademais, a conta terá que ter um ano de registrada. Só usar o botão desfazer durante um ano....FábioJr de Souza ^msg 17h50min de 25 de janeiro de 2020 (UTC)

Concordo com essa última proposta apresentada. --Editor DS.s (discussão) 02h40min de 26 de janeiro de 2020 (UTC)

Comentário As propostas estão apenas avaliando os critérios de admissibilidade para a candidatura. Não precisa haver muita complexidade. Se houver suspeita de que o candidato é um fantocheiro, é só votar contra. É bom lembrar que o requisito de aprovação é de 75%. ✍️A.WagnerC (discussão) 03h08min de 26 de janeiro de 2020 (UTC)

• Concordo. Chronus (discussão) 21h32min de 27 de janeiro de 2020 (UTC)

Contra, não é necessária uma Proposta 4 se a Proposta 1 e a 2 já são suficientes.--Mister Sanderson (discussão) 10h52min de 28 de janeiro de 2020 (UTC)

Consenso?

Parece quase unânime que a vontade da comunidade é aumentar o rigor dos requisitos mínimos para o estatuto de administrador. Houve ampla concordância com duas das propostas, que foram, posteriormente, sintetizadas nesta última proposta com um adendo. Embora tenha havido alguma divergência sobre a conveniência ou não de se criar essa proposta autônoma com a repetição das anteriores ou, alternativamente, se discutir unicamente o adendo, parece que, ao fim, os editores que opinaram concordam com o conteúdo da proposta 4. Podemos encerrar isso e aplicar? Millennium ^bug 01h21min de 28 de janeiro de 2020 (UTC)

Millennium bug De minha parte, encerrar. FábioJr de Souza ^msg 03h00min de 28 de janeiro de 2020 (UTC)

De minha parte também. ✍️A.WagnerC (discussão) 03h13min de 28 de janeiro de 2020 (UTC)

A proposta 4 não é uma síntese das propostas 1 e 2. As propostas 1 e 2 já tinham um consenso praticamente apurado, depois apareceu esta proposta 4, que se fez passar por um texto praticamente idêntico ao das duas, mas que na realidade introduziu um adendo: não contar edições de desfazer como edições automáticas. Como é evidente, isso é dar uma volta de 360º e sabotar por completo a proposta 2, voltando exatamente ao ponto onde estávamos no início. Foi toda a gente na conversa da "proposta de síntese", sem na realidade se ter apercebido disto. O consenso é para aplicação das propostas 1 e 2. JMagalhães (discussão) 07h48min de 28 de janeiro de 2020 (UTC)

Vc é favorável a contar o uso do botão desfazer como edição automática? Normalmente, usamos esse botão em reversões não óbvias, que merecem uma análise, um sumário, mormente quando não se trata de vandalismo. Entendo sua preocupação e concordo com ela, no sentido de que algum editor abuse dessa dessa opção, revertendo vandalismo desta forma, como forma de "burlar" os requisitos ou mesmo por não ter ainda o botão de reversão. No entanto, se formos mais fundo nesta discussão de valoração de edições, veremos que o buraco é mais embaixo, porque existem outras formas de fraudar esta exigência. Apenas para pensar num exemplo simples sem se esforçar muito para isso, se o "aspirante" em questão sair aleatoriamente procurando erros triviais como falta de vírgula ou sua colocação incorreta ou mesmo fazendo mínimas melhorias na estrutura sintática, sem usar o AWB para isso, necessariamente essas edições são valoradas como melhor do que as do Huggle ou Fastbuttons? O fato é que estamos arrastando a discussão por minúcias que não têm tanta importância, porque o "problema", se é que se pode dizer assim, só pode ser resolvido a partir da análise, caso a caso, de cada PDA, subjetivamente, na qual a qualidade da atividade do editor pode ser valorada. Dada a situação atual, só vejo duas soluções para essa discussão não se tornar interminável: ou uma parte cede e concorda com o adendo, ou, alternativamente, aplicamos as duas propostas iniciais afirmando apenas que edição automática é o que o XTools diz que é e abrimos, em seguida, outra proposta para regulamentar essa definição e, eventualmente "abrandar" as alterações aqui deliberadas. Por mim, pelo bem do consenso, concordo com a aplicação das propostas 1 e 2, se os demais editores cederem de igual modo. Millennium ^bug 10h14min de 28 de janeiro de 2020 (UTC)

Não é uma questão de ser "favorável". O recurso ao botão desfazer é e sempre foi considerado uma edição automática: não é mais do que um atalho para fazer o artigo voltar automaticamente ao texto da versão anterior. Ter uma candidatura de alguém que nunca fez mais nada do que desfazer 2000 edições continua a padecer do mesmo problema inicial: não houve real trabalho de acréscimo/melhoria de conteúdo. Por outro lado, rever gamaticalmente e ortograficamente um texto é trabalho a sério, ainda que as diferenças em kb sejam mínimas. As propostas 1 e 2 estavam praticamente aprovadas. A "minúcia" e implicância vieram depois. Eu avisei ao início que só ia criar confusão e arrastar a discussão. Para não variar, estava certo. JMagalhães (discussão) 10h20min de 28 de janeiro de 2020 (UTC)

Tudo bem, embora discordando de que desfazer necessariamente não seja um trabalho a sério, peço que os demais opinem sobre a aplicação das propostas 1 e 2. Millennium ^bug 10h56min de 28 de janeiro de 2020 (UTC)

Comentário Já pode aplicar o consenso da proposta 4, que unifica tudo e estabelece o adendo pela remoção do comando Desfazer na lista de edições semiautomáticas. Nesse exemplo aqui, desfiz conteúdo sem fonte e, posteriormente, o usuário desfez minha edição inserindo fonte (a edição dele jamais deve ser considerado como semiautomática), é justamente situações como essa devem ser contabilizados no número de edições principal. Desfazer vandalismo ou conteúdo sem fonte, podendo inserir referência e corrigir a edição desfeita é a prova de que este deve ser uma exceção. Ninguém está acima de uma decisão majoritária, a comunidade é soberana na aplicação de qualquer consenso na Esplanada; resultado contrário a isso é subestimar da inteligência dos usuários que deram parecer favorável a proposta. WikiFer ^msg 12h47min de 28 de janeiro de 2020 (UTC)

O botão "desfazer" permite a inclusão de edições manuais. É diferente do botão "reverter" que é automático. Logo, Concordo com as propostas 1,2 e 4. Se não há consenso quanto a isso, que se abra uma votação. ✍️A.WagnerC (discussão) 12h54min de 28 de janeiro de 2020 (UTC)

Consenso da proposta 1 (aumentar de seis meses para um ano)

Enquanto se discute o que é considerado edição semi-automática e como contabilizar edições, há consenso que o período mínimo deve passar de seis meses para um ano. Podemos aplicar? Millennium ^bug 15h15min de 1 de fevereiro de 2020 (UTC)

@Millennium bug: De acordo. ✍️A.WagnerC (discussão) 15h35min de 1 de fevereiro de 2020 (UTC)

Millennium bug Sim, também estou de acordo. Houve consenso pela proposta 1. WikiFer ^msg 15h41min de 1 de fevereiro de 2020 (UTC)

Bom, acho que não há por que não aplicar, já que todos concordam. Assim, Feito. Millennium ^bug 16h11min de 1 de fevereiro de 2020 (UTC)

E os burocratas

Por uma questão, no mínimo, de isonomia, creio que seria o caso de aplicar também em WP:POLB. Millennium ^bug 16h15min de 1 de fevereiro de 2020 (UTC)

Millennium bug Neste caso, eu tenho que discordar porque o critério para eleição de eliminadores e burocratas é por consenso, diferente de sysop que é por votação. São funções diferentes que requer do usuário mais conhecimento da política do que técnico. WikiFer ^msg 16h19min de 1 de fevereiro de 2020 (UTC)

Discordo Burocratas eu acho desnecessário modificar, eliminadores também. Não vamos ampliar a discussão, que durante todo esse tempo se referiu a administradores. ✍️A.WagnerC (discussão) 16h55min de 1 de fevereiro de 2020 (UTC)

Discordo pelas razões dos que me atecederam. Ademais, está difícil encontrar um consenso nos administradores. Vamos resolver esse e depois faz-se uma proposta sobre os demais.FábioJr de Souza ^msg 18h35min de 1 de fevereiro de 2020 (UTC)

---

A discussão acima encontra-se encerrada. Por favor não a modifique. Comentários posteriores devem ser feitos numa nova secção.

Página de usuário eliminada

O usuário Yanguas eliminou minha página sem qualquer aviso ou indicação exata (precisa, específica) do conteúdo em minha página, ou de qualquer ação de edição que eu tenha tomado. Essa eliminação constitui, no meu ponto de vista, uma total e absoluta arbitrariedade injustificável. Se eliminadores tomam para si esse tipo de poder policial, julgador e de execução, estarão apenas colocando em risco a propalada isenção da Wikipedia. Naturalmente, ficarei feliz em acatar, se pontos, textos, frases específicos, junto com suas devidas interpretações forem comunicadas aqui, acompanhados pela razão pela qual as diretrizes e as políticas da Wikipédia foram desobedecidas por mim. Clovis de Andre (discussão)