Wikipédia:Esplanada/tudo

Origem: Wikipédia, a enciclopédia livre.
Saltar para a navegação Saltar para a pesquisa
▼ Ir para o fim da página ▼
Boas-vindas à Esplanada (todas as secções)!
Esta página agrupa todas as subseções da Esplanada numa só página.
  • Se quiser vigiar toda a Esplanada, deverá aceder às respectivas páginas (anúncios, propostas e geral) e clicar na aba "vigiar" em cada uma delas.
  • Para adicionar comentários não use a aba "editar" desta página. Para isso recorra às ligações disponíveis no inicío de cada secção.
  • Para ter certeza de que o conteúdo desta página está atualizado, clique em atualizar.
  • Atalhos para as secções desta página: ▼ Anúncios | ▼ Propostas | ▼ Geral
  • Veja também as mudanças recentes nas esplanadas.

Índice


Anúncios

Secção de anúncios da Esplanada ◄ Anúncios | ▼ Propostas | ▼ Geral | início
Esta secção é utilizada para todo tipo de anúncios relacionados com a Wikipédia em português de forma direta ou indireta. Consulte também Wikipedia:Notícias, Jornal da Wikipédia e Wikizine.
clique aqui para adicionar um novo tópico na secção anúncios


Pedido de opinião do usuário Tuga1143

Saudações. Anuncio aqui a abertura do meu pedido de opinião para quem quiser participar. Obrigado. Luís Almeida "Tuga1143 00h58min de 3 de janeiro de 2020 (UTC)

Wikipédia:CheckUser/Candidaturas/Tks4Fish/2

Anuncio a todos que solicitei a renovação do estatuto de CheckUser/Verificador. —Thanks for the fish! talkcontribs 21h36min de 3 de janeiro de 2020 (UTC)

Pedido de uso do AWB

Solicitei permissão para usar o AWB, em Wikipédia:Semirrobôs/pedidos/AWB/MisterSanderson/2.--Mister Sanderson (discussão) 21h02min de 4 de janeiro de 2020 (UTC)

Discussão sobre Processo Estratégico recomeça em janeiro

Linha do tempo até junho de 2020.

Boa tarde a todos!

Venho à Esplanada apenas para deixar um breve comunicado sobre o Processo Estratégico. Na segunda metade de janeiro, recomeçaremos as discussões sobre o processo, de modo similar ao iniciado em 2019. Desta vez, entretanto, o objetivo não será mais o de criar ideias e elaborar recomendações. Agora que as recomendações já foram criadas, nosso objetivo será o de validar as recomendações, aprovando ou desaprovando e dando nossa contribuição sobre como elas podem ser melhoradas ou como podem ser melhor implementadas. Podemos, por exemplo, expor nossa noção sobre quão urgente ou importante é determinada recomendação ou sinalizar quais recomendações podem ser implementadas posteriormente.

Nas últimas semanas, os Escritores têm trabalhado no resumo das 89 recomendações. Esse material - ainda em formação - será o objeto de análise e validação por parte da comunidade. O início das discussões está previsto para a segunda metade de janeiro de 2020, como pode ser acompanhado em nossa Linha do Tempo.

Por último, gostaria de divulgar esta lista de mensagens criada com o objetivo de informar aos interessados sobre o Processo Estratégico. Nela, serão enviadas mensagens indicando etapas do processo, mensagens importantes do Core Team e qualquer material específico sobre nossas discussões. Caso queiram receber as mensagens, podem entrar em contato comigo ou adicionar o nome na lista. É esperado que o fluxo seja baixo, com uma mensagem por semana.

Fico à disposição para qualquer dúvida ou comentário. Nos vemos em breve! LTeles (WMF) (discussão) 19h33min de 5 de janeiro de 2020 (UTC)

Pesquisa de interesse sobre primeira Wiki Conferência Brasil

Olá a todas e todos! Queremos organizar uma conferência nacional no Brasil ao fim de 2020. O primeiro passo é termos dados sobre o interesse e as preferências da comunidade na realização da conferência.

Peço que preencham a seguinte pesquisa.

Estou a disposição para quaisquer dúvidas ou sugestões. Ederporto (discussão) 15h55min de 15 de janeiro de 2020 (UTC)

Essa pesquisa é feita no Google Forms, estejam atentos à política de privacidade e aos termos de uso.

Wikipédia:Administradores/Pedidos de aprovação/Armagedon2000

Anuncio a todos que me auto-nomeei ao cargo de Administrador. Armagedon2000 msg 03h15min de 18 de janeiro de 2020 (UTC)

Wiki Loves Folklore

WLL Subtitled Logo (transparent).svg

Hello Folks,

Wiki Loves Love is back again in 2020 iteration as Wiki Loves Folklore from 1 February, 2020 - 29 February, 2020. Join us to celebrate the local cultural heritage of your region with the theme of folklore in the international photography contest at Wikimedia Commons. Images, videos and audios representing different forms of folk cultures and new forms of heritage that haven’t otherwise been documented so far are welcome submissions in Wiki Loves Folklore. Learn more about the contest at Meta-Wiki and Commons.

Kind regards,
Wiki Loves Folklore International Team
— Tulsi Bhagat (contribs | talk)
sent using MediaWiki message delivery (discussão) 06h15min de 18 de janeiro de 2020 (UTC)

Movement Learning and Leadership Development Project

A equipe de desenvolvimento comunitário da Fundação Wikimedia está buscando aprender mais sobre a maneira como os voluntários aprendem e se desenvolvem para os diversos papéis que existem no movimento. Nosso objetivo é construir uma estrutura informada do movimento que forneça clareza compartilhada e descreva caminhos acessíveis sobre como crescer e desenvolver habilidades dentro do movimento. Para esse fim, estamos procurando falar com você, nossa comunidade, para aprender sobre sua jornada como voluntário da Wikimedia. Se você se juntou ontem ou esteve aqui desde o início, queremos ouvir sobre as muitas maneiras como os voluntários se juntam e contribuem para o nosso movimento.

Para saber mais sobre o projeto, visite a página no Meta. Se você estiver interessado em participar do projeto, preencha este formulário simples do Google. Embora possamos não ser capazes de falar com todos que manifestarem interesse, recomendamos que você preencha este breve formulário se estiver interessado em participar!

LMiranda (WMF), 14h03min de 22 de janeiro de 2020 (UTC)

  • Não, obrigado.Jo Loribd 17h51min de 22 de janeiro de 2020 (UTC)}}

Pedido para se tornar eliminador

Olá, anuncio a todos que iniciei um pedido para me tornar eliminado na wikipedia. Wikipédia:Eliminadores/Pedidos de aprovação/luandersonplayplay2 Luanderson Camilo (discussão) 00h14min de 23 de janeiro de 2020 (UTC)

Este pedido foi cancelado por o usuário não cumprir os requisitos mínimos. Luís Almeida "Tuga1143 00h33min de 23 de janeiro de 2020 (UTC)

Chamada aberta para subsídios do projeto

Wikimedia logo family complete-2013.svg

Saudações! o Programa de Subsídios de Projeto está aceitando propostas até 20 de fevereiro para financiar idéias experimentais e comprovadas, como pesquisa, divulgação off-line (incluindo séries de edição, workshops, etc.), organização on-line (incluindo concursos) ou fornecimento de outro suporte para a construção de comunidades para projetos da Wikimedia.

Oferecemos os seguintes recursos para ajudá-lo a planejar seu projeto e concluir uma proposta de concessão:

Com agradecimentos, I JethroBT (WMF) (talk) 19h06min de 24 de janeiro de 2020 (UTC)

Wikipédia:CheckUser/Candidaturas/Millennium bug/3

Anuncio que iniciei o pedido de aprovação supracitado. A participação da comunidade é, portanto, requerida. Érico (disc.) 18h28min de 26 de janeiro de 2020 (UTC)

Wikipédia:Supervisão/Candidaturas/Editor D.S

Anuncio à todos que me candidatei ao grupo dos supervisores. Obrigado! --Editor DS.s (discussão) 00h47min de 27 de janeiro de 2020 (UTC)


Propostas

Secção de propostas da Esplanada ▲ Anúncios | ◄ Propostas | ▼ Geral | início
Esta secção é utilizada para todo tipo de anúncios relacionados com a Wikipédia em português de forma direta ou indireta.
clique aqui para adicionar um novo tópico na secção propostas



Desburocratizar a permissão para uso do AWB

Não vejo lógica em continuarmos avaliando pedidos de uso do AWB. Do mesmo modo que o estatuto de reversor dá acesso automático ao Huggle, o estatuto de autorrevisor daria acesso automático ao AWB. Simples assim. Millbug fala 04h42min de 20 de dezembro de 2019 (UTC)

Discordo. Tarefas (semi-)automáticas e em larga escala devem ser anunciadas e debatidas. Além disso, o AWB só funciona se o nome do editor estiver incluido em Wikipédia:AutoWikiBrowser/CheckPage, vai incluir 680 nomes que até podem não querer acesso a uma ferramenta que não entendem? GoEThe (discussão) 11h09min de 20 de dezembro de 2019 (UTC)
Symbol declined.svg Discordo per Goethe. JMagalhães (discussão) 13h57min de 23 de dezembro de 2019 (UTC)
Millennium bug, devido ao impacto que a ferramenta pode fazer nas mãos de alguém inconsequente, Symbol declined.svg Discordo de liberar o acesso pra geral. Que tal, ao invés disto, acabar com essa limitação aqui: Citação: Só podem ser gravadas, no mínimo, a cada 20 segundos, a menos que o usuário possua o estatuto de robô, que permite automaticamente a inaplicação dessa limitação; ?--Mister Sanderson (discussão) 11h39min de 26 de dezembro de 2019 (UTC)
Parece-me uma boa ideia. Millbug fala 15h56min de 26 de dezembro de 2019 (UTC)

Symbol support vote.svg Apoio a proposta do MisterSanderson em revogar esta limitação de 20 segundos por edição para se usar o AWB. WikiFer msg 17h55min de 26 de dezembro de 2019 (UTC)

Também Symbol support vote.svg Apoio essa sugestão dele. —Pórokhov Порох 16h51min de 27 de dezembro de 2019 (UTC)

Symbol support vote.svg Apoio a sugestão do MisterSanderson, mas Symbol oppose vote.svg não a do Millennium bug. Leefeniaures audiendi audiat 07h39min de 29 de dezembro de 2019 (UTC)

Symbol question.svg Pergunta Os que estão a apoiar a remoção do intervalo de tempo mínimo de 20 segundos sabem 1) porque é que existe e 2) quais são as potenciais consequências de o remover? JMagalhães (discussão) 07h43min de 29 de dezembro de 2019 (UTC)

Há alguma consequência relevante além do perigo de mais edições problemáticas serem empreendidas antes de se perceber o engano? Porque, se for questão de atenção, vejo mais ônus que bônus em um limite tão longo. Leefeniaures audiendi audiat 09h45min de 29 de dezembro de 2019 (UTC)
Não percebi. O que é isso de ónus e bónus? JMagalhães (discussão) 09h49min de 29 de dezembro de 2019 (UTC)
Quero dizer que, entre continuar com o atraso que dificulta o padrão de boas edições repetitivas que vejo alguns editores fazerem e assumir um risco de editores com AWB cometerem erros de correção mais custosa, prefiro a segunda opção. Isso, certamente, pressupondo que as consequências são as que disse. Leefeniaures audiendi audiat 11h10min de 29 de dezembro de 2019 (UTC)
Essas edições repetitivas com menor intervalo de tempo são feitas pedindo o estatuto de robô. JMagalhães (discussão) 11h55min de 29 de dezembro de 2019 (UTC)
Tem razão... Por óbvio que seja, não pensei na possibilidade de alguém criar uma nova conta com estatuto de robô apenas para editar manualmente em AWB sem os limites estatutários, sempre associei os bots ao automatismo. Neste caso, Symbol oppose vote.svg não apoio a proposta. Leefeniaures audiendi audiat 12h56min de 29 de dezembro de 2019 (UTC)
Leefeni de Karik, qual a necessidade de ter uma conta separada só para AWB?--Mister Sanderson (discussão) 20h06min de 29 de dezembro de 2019 (UTC)

Symbol comment vote.svg Comentário O intervalo de 20 segundos escrito em Wikipédia:Semirrobôs serve apenas para limitar o controle de edições numa conta e deve ser aplicado para AWB e Huggle. No entanto, reversores que usam esta última ferramenta para reverter vandalismo, mandar mensagem ao IP ou conta registrada sobre o vandalismo feito isso não tem como fiscalizar. É uma regra que, na prática, só funciona como uma "atenção", não como limitação de edições. É uma burocracia exagerada. Caso este realize edições semirrobóticas com frequência (150 edições por dia) aí sim seria necessário a criação de uma conta para atribuir o estatuto de robô. WikiFer msg 14h38min de 29 de dezembro de 2019 (UTC)

Symbol declined.svg Discordo Antes de se propor alterar normas, é preciso saber porque é que essas normas foram criadas e existem. Há quem esteja a confundir o AWB com um robô. O AWB não é um robô. O AWB é uma ferramenta auxiliar que requer que cada edição seja verificada por um humano. Os 20 segundos servem para garantir que cada edição não só é verificada pelo próprio operador, como também o conjunto das edições pode ser verificada por outros editores a uma escala de tempo humana. Sem espaçamento de tempo, alguém já parou para imaginar o flood nas mudanças recentes? Como é que se controla isso? Alguém já imaginou o pesadelo de ter que reverter milhares de edições erradas? Quem quiser realizar edições robóticas em massa deve fazer um pedido para obter o estatuto de robô, mas tendo as suas edições escrutinadas à partida e permitindo serem ocultas nas MR. Apesar disto, não tenho objeções a que o limite baixe para 10 segundos. JMagalhães (discussão) 14h53min de 29 de dezembro de 2019 (UTC)

A ideia da redução do limite de 10 segundos é excelente e tem meu Symbol support vote.svg apoio, mas ninguém aqui disse que AWB é um robô; por outro lado, usuários que tenham interesse em realizar múltiplas edições podem muito bem ter uma conta robô usando essa ferramenta. Acredito que a única razão válida pela qual o excesso de edições semirrobóticas numa conta principal é a poluição das MRs (não ser ocultado) que, de fato, atrapalha quem analisa as demais edições. WikiFer msg 15h15min de 29 de dezembro de 2019 (UTC)
@GoEThe, Leefeni de Karik e WikiFer: Baixar para 10 segundos, concordam? Millbug fala 15h19min de 29 de dezembro de 2019 (UTC)
Concordo, se nesse caso os usuários pedirem flood flag temporariamente. GoEThe (discussão) 10h59min de 30 de dezembro de 2019 (UTC)
Citação: JMagalhães escreveu: «Sem espaçamento de tempo, alguém já parou para imaginar o flood nas mudanças recentes?» Basta usar o CTRL+F do navegador para destacar todas as ocorrências de "AWB", e ignorar as linhas marcadas quando estiver patrulhando. Sempre foi possível fazer isto.--Mister Sanderson (discussão) 20h12min de 29 de dezembro de 2019 (UTC)
Symbol support vote.svg Concordo com a proposta do JMagalhães de reduzir o tempo entre os salvamentos para 10 segundos, pois já usei o AWB anteriormente e sei que nem sempre é necessário levar 20 segundos ou mais para analisar um diff.--Mister Sanderson (discussão) 16h20min de 30 de dezembro de 2019 (UTC)
Symbol declined.svg Discordo totalmente. O limite de edições por minuto serve igualmente para não haver sobrecarga nos servidores, aliás, esse é um dos grandes motivos pelos quais existe a flag de bot, porque ai sim o sistema está mais preparado para edições massivas. Reduzir o limite de semirobôs para 6 edições por minuto não faz qualquer sentido, até porque significa que os humanos vão poder editar a uma velocidade maior do que um robô. Se um operador de semi-bot realiza tarefas em que a limitação de 20 segundos é um atraso é porque muito provavelmente está a realizar uma tarefa de bot. Alchimista Fala comigo! 23h30min de 7 de janeiro de 2020 (UTC)
@Alchimista: Acredito que a sobrecarga dos servidores não deveria motivo de preocupação (WP:SLOW). Isso também não significa que um usuário ira realizar edições autonomamente como se fosse um bot (uma edição a cada 20 segundos significa um limite de 4320 edições/dia, o que é bem plausível para um bot mas é humanamente impossível). Vejo também que a redução para 10 segundos possibilite um melhor aproveitamento do tempo do editor, onde possa contribuir mais sem se preocupar com o contador de segundos do AWB. Dependendo do caso, obter a flag de WP:Pseudorobôs como já foi sugerido pelo GoEThe pode ser bem adequada. ━ ALBERTOLEONCIO Who, me? 01h35min de 8 de janeiro de 2020 (UTC)
Alchimista, de que forma a flag de bot evita a sobrecarga dos servidores? Não consigo perceber nenhuma relação entre as duas coisas.--Mister Sanderson (discussão) 10h49min de 8 de janeiro de 2020 (UTC)

Symbol declined.svg Discordo da parte de liberar o acesso, mas Symbol support vote.svg Concordo com a retirada do limite de tempo. Primeiro que, exceto quanto aos administradores, o uso é aprovado (não são muitos a usar a ferramenta) de forma a não haver tanto impacto assim (impacto teria com mais de 600 autorrevisores com 3 edições por minuto). Depois, o editor tem que conferir a edição, então não serão uma enormidade de edições por minuto. FábioJr de Souza msg 14h27min de 8 de janeiro de 2020 (UTC)

Os editores devem rever a edição, mas tecnicamente é possível simplesmente carregar no botão de gravar sem conferir nada. A velocidade máxima aí é apenas o tempo de carregar a página e carregar no botão. GoEThe (discussão) 16h11min de 8 de janeiro de 2020 (UTC)
Se eu tenho confiança da comunidade para ser administrador, com todas as permissões decorrentes, tenho que saber lidar com o AWB... Mas não sou contra reduzir para 10 segundos.FábioJr de Souza msg 16h49min de 8 de janeiro de 2020 (UTC)

Symbol declined.svg Discordo de tudo que foi proposto. O acesso a AWB deve ser feito por usuários qualificados. Também discordo de remover ou reduzir o limite de edições, pois a conta passaria a ter uma função de robô, além de sobrecarregar o sistema e aumentar consideravelmente o número de edições presentes.

Novamente discutimos o mesmo tópico com usuários concordando sem demonstrar conhecimento dos motivos para tais restrições. Edmond Dantès d'un message? 23h10min de 17 de janeiro de 2020 (UTC)

Poderia mandar o link com os motivos? Millennium bug 00h43min de 18 de janeiro de 2020 (UTC)
@Millennium bug: um autorrevisor pode ter conhecimento das políticas, saber referenciar um artigo e o estruturar seguindo o livro de estilo, mas que é completamente diferente do que editar com sintaxes avançadas. O mesmo se enquadra aos reversores. Além disso, os usuários que possuem acesso ao AWB necessitam estar elencados numa página, o que resultaria em mais trabalho e burocracia já que cada novo autorrevisor, por exemplo, precisará ter seu nome inserido na lista de permissão. Então não vejo banalizar a permissão à ferramenta como adequada, principalmente pelos requisitos de autorrevisor não abranger a capacidade do usuário em usar o AWB.
Sobre o limite de edições, o objetivo da ferramenta semi-automática é de que as edições sejam supervisionadas. Eu concordo com os usuários que dizem que existem casos que não levam vinte segundos para supervisionar; contudo, abolir o limite vai resultar na hipótese de que os usuários simplesmente apertarão o botão de gravar sem de fato supervisionar, e isso já aconteceu. Outro efeito colateral é aumentar o número de edições nas mudanças recentes, sobrecarregando os patrulhadores presentes. Além disso, essa mudança pode fazer com que contas normais atuem em tarefas de robôs.
No início de 2019, uma proposta semelhante foi aberta e obteve a discordância de uma boa quantidade de editores. Então, vejo um retorno ao tópico meses depois como um exagero. Sei que você não criou com o propósito de diminuir a restrição de 3 edições por minutos, mas a discussão tomou esse caminho. Edmond Dantès d'un message? 01h27min de 18 de janeiro de 2020 (UTC)

Symbol declined.svg Discordo totalmente. A ideia de tirar o limite de tempo é boa, mas há o lado ruim. Várias edições semiautomáticas acontecendo ao mesmo tempo poderia sobrecarregar o servidor, e isso seria muito pior para todos. Então, vendo que o lado ruim pesa mais que o bom, opino pela não modificação das regras, pelo menos neste momento. ✍️A.WagnerC (discussão) 23h17min de 17 de janeiro de 2020 (UTC)

Reduzir tempo de absenteísmo para remoção da flag de autorrevisor

Atualmente, o texto sobre Wikipédia:Autorrevisores permite que a remoção da flag por absenteísmo aconteça depois de cinco anos de inatividade – resultado de uma discussão aprovada por consenso em 2013. A ideia, naquela ocasião, era apenas "facilitar a vida dos editores" para que não houvesse a necessidade de vigiar as MRs, além de valorizar a "tal confiança" que o administrador ou burocrata depositou nele. Contudo, este modelo tornou-se desnecessário nos dias atuais, uma vez que o número de autorrevisores ativos somente em 2019 é mais de 77%, ou seja, bem superior se fizermos uma comparação com os usuários que editaram pela última vez até 2018.

Para fins de registro, analisando todos os 673 autorrevisores que possuem esta flag (exceto eliminadores ou administradores que já possuem absenteísmo de seis meses), 520 usuários editaram em 2019 (77,2%), 63 em 2018 (9,3%), 41 em 2017 (6%), 28 em 2016 (4,1%) e 21 em 2015 (3,1%). Abaixo será registrado uma lista de contribuição de cada usuário, classificado por sua última edição, incluindo mês e ano de sua última edição para facilitar o entendimento desta proposta.

Obs.: o trecho seguinte está "compactado" de modo a despoluir visualmente o contexto da página toda.

*Nota: A lista estará em ordem alfabética, mas em ordem decrescente (edição mais recente para a mais antiga).

2019 – 520 autorrevisores ativos (77,2%)
  1. !d'O Magriço valho (dez/2019)
  2. 555 (dez/2019)
  3. 88marcus (dez/2019)
  4. A.WagnerC (dez/2019)
  5. Adriell (dez/2019)
  6. Affavoritaweb (dez/2019)
  7. Agent010 (dez/2019)
  8. Agiesbrecht (dez/2019)
  9. Agronopolos (dez/2019)
  10. Aisteco (dez/2019)
  11. Ajmcbarreto (dez/2019)
  12. Ajpvalente (dez/2019)
  13. Albertoleoncio (dez/2019)
  14. Alexandre M. B. Berwanger (dez/2019)
  15. Allan CZ (dez/2019)
  16. Almanaque Lusofonista (dez/2019)
  17. Alvoradaking (dez/2019)
  18. Amanda Hoelzel (dez/2019)
  19. AndersonPv (dez/2019)
  20. Andregraca (dez/2019)
  21. André Augusto C. da Silva (dez/2019)
  22. Angrense (dez/2019)
  23. Anjo-sozinho (dez/2019)
  24. Antonio Prates (dez/2019)
  25. Aolynthon (dez/2019)
  26. Archaeodontosaurus (dez/2019)
  27. ArgonSim (dez/2019)
  28. ArionEstar (dez/2019)
  29. Armagedon2000 (dez/2019)
  30. Athena in Wonderland (dez/2019)
  31. Auréola (dez/2019)
  32. Aviz2000 (dez/2019)
  33. Awikimate (dez/2019)
  34. Bad Boy97 (dez/2019)
  35. Bageense (dez/2019)
  36. Betty VH (dez/2019)
  37. Blamed (dez/2019)
  38. Bolhones (dez/2019)
  39. Borowskki (dez/2019)
  40. Braz Leme (dez/2019)
  41. Bruno Meireles (dez/2019)
  42. CS1982 (dez/2019)
  43. Caio Brandão Costa (dez/2019)
  44. Caio! (dez/2019)
  45. CaiusSPQR (dez/2019)
  46. Camervan (dez/2019)
  47. Carrion (dez/2019)
  48. Cesarakg (dez/2019)
  49. Charles keen (dez/2019)
  50. Chebellatopa (dez/2019)
  51. Chico (dez/2019)
  52. Chicocvenancio (dez/2019)
  53. Cidcn (dez/2019)
  54. Clarice Reis (dez/2019)
  55. Claudio M Souza (dez/2019)
  56. Coltsfan (dez/2019)
  57. CommonsDelinker (dez/2019)
  58. Comuna de Paris (dez/2019)
  59. Conrado (dez/2019)
  60. CostaPPPR (dez/2019)
  61. Creditor Editor (dez/2019)
  62. Cyberlima785 (dez/2019)
  63. DanGFSouza (dez/2019)
  64. DanielTom (dez/2019)
  65. Danielly Campos Dias (dez/2019)
  66. Dantadd (dez/2019)
  67. DanteCan (dez/2019)
  68. Dbastro (dez/2019)
  69. Dianakc (dez/2019)
  70. Didifelisberto (dez/2019)
  71. Dilcinha (dez/2019)
  72. Dornicke (dez/2019)
  73. Douglasboavista (dez/2019)
  74. Dr. Lenaldo Vigo (dez/2019)
  75. Dravinia (dez/2019)
  76. DutchDevil (dez/2019)
  77. Ederporto (dez/2019)
  78. Edu! (dez/2019)
  79. Elder N (dez/2019)
  80. Eleefecosta (dez/2019)
  81. Elilopes (dez/2019)
  82. EnaldoSS (dez/2019)
  83. Eric abiog (dez/2019)
  84. EricaAzzellini (dez/2019)
  85. Erick Soares3 (dez/2019)
  86. Erico Tachizawa (dez/2019)
  87. Esopo (dez/2019)
  88. Ezco Musaos (dez/2019)
  89. Fabiobarros (dez/2019)
  90. Fasouzafreitas (dez/2019)
  91. Feldmann (dez/2019)
  92. Felipe P (dez/2019)
  93. Femme Fatale (dez/2019)
  94. Fernandobrasilien (dez/2019)
  95. Fgnievinski (dez/2019)
  96. Filipeschaves (dez/2019)
  97. Flávia Varella (dez/2019)
  98. Fma (dez/2019)
  99. FrontLine (dez/2019)
  100. Gabriel C (dez/2019)
  101. Gabriel bier (dez/2019)
  102. GabrielStella (dez/2019)
  103. Gabrielrs (dez/2019)
  104. GiFontenelle (dez/2019)
  105. Giloliveira1994 (dez/2019)
  106. GualdimG (dez/2019)
  107. Guilherme (dez/2019)
  108. Gustaveb (dez/2019)
  109. GünniX (dez/2019)
  110. HCa (dez/2019)
  111. Hallel (dez/2019)
  112. Hedwig in Washington (dez/2019)
  113. Hipersyl (dez/2019)
  114. Hlges (dez/2019)
  115. Hml.sdi (dez/2019)
  116. Hqfngawz (dez/2019)
  117. Hyju (dez/2019)
  118. IacobusBr (dez/2019)
  119. Igordebraga (dez/2019)
  120. Ismael Silva Oliveira (dez/2019)
  121. JCMA (dez/2019)
  122. JackCrazy5 (dez/2019)
  123. Jackson Cordeiro Brilhador (dez/2019)
  124. Jadolfo (dez/2019)
  125. Jairinho (dez/2019)
  126. JardelW (dez/2019)
  127. JeanVitorSouza (dez/2019)
  128. Jflabreu (dez/2019)
  129. Jhonnycach (dez/2019)
  130. Jin-gook (dez/2019)
  131. JoJan (dez/2019)
  132. Joalpe (dez/2019)
  133. Joao0Paulo (dez/2019)
  134. Joao4669 (dez/2019)
  135. Joaovitorbf (dez/2019)
  136. Joelkaula (dez/2019)
  137. Johnny Paes (dez/2019)
  138. Jolielegal (dez/2019)
  139. JonJon86 (dez/2019)
  140. Jonas kam (dez/2019)
  141. JonasBR (dez/2019)
  142. José João Salles (dez/2019)
  143. JotaCartas (dez/2019)
  144. JozeSlb (dez/2019)
  145. João Justiceiro (dez/2019)
  146. João Victor Costa (dez/2019)
  147. Jsobral (dez/2019)
  148. Kaktus Kid (dez/2019)
  149. Kleiner (dez/2019)
  150. Kongs (dez/2019)
  151. LF337 (dez/2019)
  152. Lagape (dez/2019)
  153. Lauro Chieza de Carvalho (dez/2019)
  154. Laurosouza11 (dez/2019)
  155. Leandro Drudo (dez/2019)
  156. Leandro LV (dez/2019)
  157. Leone Melo (dez/2019)
  158. Leosls (dez/2019)
  159. Levs (dez/2019)
  160. LodeRunner (dez/2019)
  161. Loidez (dez/2019)
  162. Lourencoalmada (dez/2019)
  163. Luan (dez/2019)
  164. Lucas Landin (dez/2019)
  165. Lucas11925 (dez/2019)
  166. LucasFVenturini (dez/2019)
  167. LucasT.Aquino (dez/2019)
  168. Lucasmf23 (dez/2019)
  169. Lucaspdantas (dez/2019)
  170. Lucio Luiz (dez/2019)
  171. Lucs1994 (dez/2019)
  172. Luiz F. Fritz (dez/2019)
  173. Luiz265 (dez/2019)
  174. Luizengmec (dez/2019)
  175. Luizpuodzius (dez/2019)
  176. Luk3 (dez/2019)
  177. Luks25 (dez/2019)
  178. Lustmoon (dez/2019)
  179. Luz28 (dez/2019)
  180. MOC (dez/2019)
  181. MSN12102001 (dez/2019)
  182. MagicSenna (dez/2019)
  183. Magrellinha (dez/2019)
  184. Maisonneuve (dez/2019)
  185. Manope2011 (dez/2019)
  186. Manuel de Sousa (dez/2019)
  187. Manuelvbotelho (dez/2019)
  188. Marcoasxd (dez/2019)
  189. Mariomaniaco (dez/2019)
  190. Mary Eleanor de Normandy (dez/2019)
  191. Matheus Camcho (dez/2019)
  192. MatheusMtHs (dez/2019)
  193. Max51 (dez/2019)
  194. Maxtremus (dez/2019)
  195. Mbassis (dez/2019)
  196. Mcorrlo (dez/2019)
  197. Micael 106 (dez/2019)
  198. Micael D. (dez/2019)
  199. Microdri (dez/2019)
  200. MiguelMadeira (dez/2019)
  201. Miguelrangeljr (dez/2019)
  202. Mikebarross (dez/2019)
  203. Milca jnr (dez/2019)
  204. Minerva97 (dez/2019)
  205. MisterSanderson (dez/2019)
  206. Mizunoryu (dez/2019)
  207. Moretti (dez/2019)
  208. Mrzero (dez/2019)
  209. Music01 (dez/2019)
  210. Mário NET (dez/2019)
  211. NAMmc2 (dez/2019)
  212. NMaia (dez/2019)
  213. Nahschneider (dez/2019)
  214. Naldo Arruda (dez/2019)
  215. Naner Wikipedista (dez/2019)
  216. Nanny321 (dez/2019)
  217. Nelson R. de Lima Filho (dez/2019)
  218. Neofox-san (dez/2019)
  219. Neomoses (dez/2019)
  220. Net Esportes (dez/2019)
  221. Norris (dez/2019)
  222. NosLida (dez/2019)
  223. O revolucionário aliado (dez/2019)
  224. Orchi (dez/2019)
  225. Oursana (dez/2019)
  226. Pablo Busatoo (dez/2019)
  227. Pablodiego15 (dez/2019)
  228. Paladinum2 (dez/2019)
  229. Pascoal IV (dez/2019)
  230. Patricia CV (dez/2019)
  231. PauloSimoes (dez/2019)
  232. Pedro Toniazzo Terres (dez/2019)
  233. Pedrohoneto (dez/2019)
  234. Phill ad (dez/2019)
  235. Pilgerowski (dez/2019)
  236. Polemaco (dez/2019)
  237. Porantim (dez/2019)
  238. Praxidicae (dez/2019)
  239. Prima.philosophia (dez/2019)
  240. ProntComando (dez/2019)
  241. Psem25832 (dez/2019)
  242. Py4nf (dez/2019)
  243. Rachmaninoff (dez/2019)
  244. RafaAzevedo (dez/2019)
  245. Raul Caarvalho (dez/2019)
  246. RayAlt (dez/2019)
  247. Rei Momo (dez/2019)
  248. Renan Rabbit (dez/2019)
  249. Renzo Grosso (dez/2019)
  250. Reporter (dez/2019)
  251. Rgps (dez/2019)
  252. Rhodes00 (dez/2019)
  253. Ricarlos Almagro (dez/2019)
  254. Richvianbonett (dez/2019)
  255. RickMorais (dez/2019)
  256. Ricvelozo (dez/2019)
  257. Robertogilnei (dez/2019)
  258. Robson correa de camargo (dez/2019)
  259. Rockysantos (dez/2019)
  260. Rodrigoan (dez/2019)
  261. RodsTR (dez/2019)
  262. RonaldB (dez/2019)
  263. Roni1986 (dez/2019)
  264. Rui Gabriel Correia (dez/2019)
  265. Ródi (dez/2019)
  266. Rúdisicyon (dez/2019)
  267. Sarah Pereira Marcelino (dez/2019)
  268. Sarilho1 (dez/2019)
  269. Sartius (dez/2019)
  270. Schridon (dez/2019)
  271. Sethemanuel (dez/2019)
  272. Simplus Menegati (dez/2019)
  273. SirEdimon (dez/2019)
  274. Slade (dez/2019)
  275. Sorocabano 32 (dez/2019)
  276. Sphynx-SN (dez/2019)
  277. Stego (dez/2019)
  278. Sudhertzen (dez/2019)
  279. Superplástico (dez/2019)
  280. Suzy Oh (dez/2019)
  281. Sylvio Sant (dez/2019)
  282. TaahCaaroline (dez/2019)
  283. Taketa (dez/2019)
  284. Teixant (dez/2019)
  285. Tetizeraz (dez/2019)
  286. Tetraktys (dez/2019)
  287. Tfda tapro (dez/2019)
  288. The Joker (dez/2019)
  289. TheCrazy (dez/2019)
  290. Theocfar (dez/2019)
  291. Theodoxa (dez/2019)
  292. Theys York (dez/2019)
  293. ThrasherÜbermensch (dez/2019)
  294. Tiago de Jesus Neves (dez/2019)
  295. Tiburcio43 (dez/2019)
  296. Tintazul (dez/2019)
  297. Tonyjeff (dez/2019)
  298. Tschis (dez/2019)
  299. Tuvalkin (dez/2019)
  300. Umberto Bottura (dez/2019)
  301. User7778 (dez/2019)
  302. VdSV9 (dez/2019)
  303. Vinicius Lima (dez/2019)
  304. ViniciusBR11 (dez/2019)
  305. Vitor12345 (dez/2019)
  306. Vitruviano (dez/2019)
  307. Weslen Fillipe (dez/2019)
  308. WiFábio (dez/2019)
  309. Wiforst (dez/2019)
  310. Xavier1824 (dez/2019)
  311. Xuxo (dez/2019)
  312. Yasméssica (dez/2019)
  313. Ygor Alves (dez/2019)
  314. YgorD3 (dez/2019)
  315. Young Brujah (dez/2019)
  316. YuriNikolai (dez/2019)
  317. Zarco (dez/2019)
  318. Zervim (dez/2019)
  319. AdriAg (nov/2019)
  320. Alessandro Sil (nov/2019)
  321. Andrevruas (nov/2019)
  322. Arouck (nov/2019)
  323. Ary29 (nov/2019)
  324. Bruno N. Campos (nov/2019)
  325. Capmo (nov/2019)
  326. CarlosCunha (nov/2019)
  327. Claudio Pistilli (nov/2019)
  328. Coelhomiq (nov/2019)
  329. Curiapeba (nov/2019)
  330. Eduardo Pazos (nov/2019)
  331. Feliciomendes (nov/2019)
  332. Frajolex (nov/2019)
  333. Francisco Quiumuento (nov/2019)
  334. Fábio Miguel (nov/2019)
  335. Fúlvio (nov/2019)
  336. GUROMETAL (nov/2019)
  337. Gerbilo (nov/2019)
  338. Gjpab (nov/2019)
  339. HenriqueCrang (nov/2019)
  340. Jaideraf (nov/2019)
  341. Joãofcf (nov/2019)
  342. Keplerbr (nov/2019)
  343. LPrati (nov/2019)
  344. LTeles (WMF) (nov/2019)
  345. Lucas Pianta (nov/2019)
  346. Luizdl (nov/2019)
  347. Manuel Anastácio (nov/2019)
  348. Maragm (nov/2019)
  349. Marcelo Henrique Bittencourt (nov/2019)
  350. Marcric (nov/2019)
  351. Marcus Cyron (nov/2019)
  352. Mariordo (nov/2019)
  353. Mike Peel (nov/2019)
  354. MuriloHDD (nov/2019)
  355. Oona (nov/2019)
  356. Pedro Aguiar (nov/2019)
  357. Rafazmr (nov/2019)
  358. Rodrigogomesonetwo (nov/2019)
  359. Roger Otoni (nov/2019)
  360. Rush (nov/2019)
  361. Sampayu (nov/2019)
  362. Sir Lestaty de Lioncourt (nov/2019)
  363. Skeptikós (nov/2019)
  364. Titoncio (nov/2019)
  365. Torsade de Pointes (nov/2019)
  366. Vargenau (nov/2019)
  367. Vituzzu (nov/2019)
  368. Agnyeszka (out/2019)
  369. Al Lemos (out/2019)
  370. Alexandre Fiori (out/2019)
  371. AlvoMaia (out/2019)
  372. Casnouto (out/2019)
  373. DanielFreitas (out/2019)
  374. Diegoftq2 (out/2019)
  375. DmitryN (out/2019)
  376. Eazy-P (out/2019)
  377. Econt (out/2019)
  378. Edviges (out/2019)
  379. Feen (out/2019)
  380. Felipe da Fonseca (out/2019)
  381. Gabriel Yuji (out/2019)
  382. Geobage (out/2019)
  383. Jamadruga (out/2019)
  384. Jimmy.T. (out/2019)
  385. João Sousa (out/2019)
  386. Lord Mota (out/2019)
  387. Lucas RdS (out/2019)
  388. Mad Fox (out/2019)
  389. Marcus274 (out/2019)
  390. Mecanismo (out/2019)
  391. Mig Ling (out/2019)
  392. Pathoschild (out/2019)
  393. Pedro Jorge (out/2019)
  394. Pedu0363 (out/2019)
  395. Porto Mineiro (out/2019)
  396. Pqnonwba (out/2019)
  397. Retornaire (out/2019)
  398. Summerzith (out/2019)
  399. WMFOffice (out/2019)
  400. WPTBR (out/2019)
  401. Xandi (out/2019)
  402. ZackTheJack (out/2019)
  403. Dilermando (set/2019)
  404. DocElisa (set/2019)
  405. Doutorgrillo (set/2019)
  406. Felipe.moraislima (set/2019)
  407. G.M (set/2019)
  408. Iuri i10 (set/2019)
  409. Japf (set/2019)
  410. L-0395 (set/2019)
  411. Maddox (set/2019)
  412. Madmarioni (set/2019)
  413. Malafaya (set/2019)
  414. Marcosfaria70 (set/2019)
  415. Mateusthunder (set/2019)
  416. N4TR!UMbr (set/2019)
  417. Nistelrooy (set/2019)
  418. PauloHenrique (set/2019)
  419. Solstag (set/2019)
  420. UrsoBR (set/2019)
  421. WBV1986 (set/2019)
  422. Warley Felipe C.S. (set/2019)
  423. Wilberty (set/2019)
  424. Épico (set/2019)
  425. Acscosta (ago/2019)
  426. Berthold Werner (ago/2019)
  427. Carlos28 (ago/2019)
  428. Everton137 (ago/2019)
  429. Fulviusbsas (ago/2019)
  430. Giorgione62 (ago/2019)
  431. Helder Monter (ago/2019)
  432. Hímeros (ago/2019)
  433. Imagens SM (ago/2019)
  434. João Xavier (ago/2019)
  435. Meriade (ago/2019)
  436. Pereira Pedro (ago/2019)
  437. Raafael (ago/2019)
  438. Regi-Iris Stefanelli (ago/2019)
  439. Spoladore (ago/2019)
  440. Thiago MTB (ago/2019)
  441. Vini 175 (ago/2019)
  442. Webysther (ago/2019)
  443. Yone Fernandes (ago/2019)
  444. Brunonar (jul/2019)
  445. Carlírio Neto (jul/2019)
  446. Daniel Cavallari (jul/2019)
  447. Eamaral (jul/2019)
  448. Geovani.s (jul/2019)
  449. Kelvin Samuel (jul/2019)
  450. L%27Éclipse (jul/2019)
  451. LuanSP (jul/2019)
  452. Totodu74 (jul/2019)
  453. Trierweiller (jul/2019)
  454. Tuga9890 (jul/2019)
  455. Usien6 (jul/2019)
  456. Wallinson (jul/2019)
  457. +Electricity (jun/2019)
  458. Adailton (jun/2019)
  459. Alefher Andrade Cordeiro (jun/2019)
  460. Amalário de Metz (jun/2019)
  461. Brandizzi (jun/2019)
  462. Bruno Ramos Uehara (jun/2019)
  463. Chairhandlers (jun/2019)
  464. Danilo.mac (jun/2019)
  465. Domusaurea (jun/2019)
  466. GABS (jun/2019)
  467. Hgh1993 (jun/2019)
  468. Jesielt (jun/2019)
  469. JohnR (jun/2019)
  470. Lemarlou (jun/2019)
  471. Lucas S.C (jun/2019)
  472. Matemágico (jun/2019)
  473. Nice poa (jun/2019)
  474. Observatore (jun/2019)
  475. Sergio Kaminski (jun/2019)
  476. Alexanderps (mai/2019)
  477. Berganus (mai/2019)
  478. Carlos Luis M C da Cruz (mai/2019)
  479. Caçador de Palavras (mai/2019)
  480. Chapulinaaa (mai/2019)
  481. Daniel.Vitor1 (mai/2019)
  482. Eduardo Kazuo (mai/2019)
  483. Fabsouza1 (mai/2019)
  484. Georgez (mai/2019)
  485. Kim richard (mai/2019)
  486. Materialscientist (mai/2019)
  487. Romaine (mai/2019)
  488. ThiagoEFreitas (mai/2019)
  489. Cdmafra (abr/2019)
  490. Fox de Quintal (abr/2019)
  491. Jefferson055 (abr/2019)
  492. Mateus RM (abr/2019)
  493. PauloEduardo (abr/2019)
  494. Rodrigolopes (abr/2019)
  495. Xaosflux (abr/2019)
  496. Defender (mar/2019)
  497. DreamNight (mar/2019)
  498. Gustavotcabral (mar/2019)
  499. Jorden (mar/2019)
  500. Pinhelense (mar/2019)
  501. Rmv1 (mar/2019)
  502. Swendt (mar/2019)
  503. Wikimasterbz (mar/2019)
  504. AlvaroMolina (fev/2019)
  505. ApoloFebo (fev/2019)
  506. Beria (fev/2019)
  507. Cainamarques (fev/2019)
  508. Gabriel dos Santos (fev/2019)
  509. Juntas (fev/2019)
  510. P.H.SPFC (fev/2019)
  511. Pedro Me. (fev/2019)
  512. Uxbona (fev/2019)
  513. FilipeFalcão (jan/2019)
  514. Hunz (jan/2019)
  515. Jonas AGX (jan/2019)
  516. King of Prussia (jan/2019)
  517. LeoFaria (jan/2019)
  518. Lijealso (jan/2019)
  519. Luandersonplayplay2 (jan/2019)
  520. Palaciano (jan/2019)
2018 – 63 autorrevisores (9,3%)
  1. Augusto Reynaldo Caetano Shereiber (dez/2018)
  2. Giro720 (dez/2018)
  3. Instambul (dez/2018)
  4. JJ Cuela (dez/2018)
  5. Jackgba (dez/2018)
  6. João Carvalho (dez/2018)
  7. Kascyo (dez/2018)
  8. MikaelSilveira (dez/2018)
  9. Wsdantas (dez/2018)
  10. Danilomath (nov/2018)
  11. Dennylson Adam (nov/2018)
  12. O Sem Autoridade (nov/2018)
  13. Ajrsferreira (out/2018)
  14. Jasão (out/2018)
  15. José Tadeu Barros (out/2018)
  16. Marcelportugal (out/2018)
  17. Mobyduck (out/2018)
  18. Ninux2000 (out/2018)
  19. Stangbot (out/2018)
  20. Xutzão (out/2018)
  21. Leonardorejorge (set/2018)
  22. Raylton P. Sousa (set/2018)
  23. Taba1964 (set/2018)
  24. Bonifácio (ago/2018)
  25. Ceresta (ago/2018)
  26. JeffBruno (ago/2018)
  27. Leoherdy (ago/2018)
  28. Nevinho (ago/2018)
  29. Slaytanic (ago/2018)
  30. Andrelz (jul/2018)
  31. EUDOXIO (jul/2018)
  32. Epinheiro (jul/2018)
  33. Gean (jul/2018)
  34. Lucas Secret (jul/2018)
  35. NonSecta (jul/2018)
  36. Opaulo (jul/2018)
  37. !SilentTest (jun/2018)
  38. BOT-vinnik (jun/2018)
  39. FranciscoMG (jun/2018)
  40. Lucas.Belo (jun/2018)
  41. Nuno Tavares (jun/2018)
  42. OTAVIO1981 (jun/2018)
  43. Picknick (jun/2018)
  44. Rumanovsk (jun/2018)
  45. Terriffic Dunker Guy (jun/2018)
  46. ThiagoRuiz (jun/2018)
  47. Gato Preto (mai/2018)
  48. Vinifel1999 (mai/2018)
  49. AlchemistOfJoy (abr/2018)
  50. Belanidia (mar/2018)
  51. Castelobranco (mar/2018)
  52. Gunnex (mar/2018)
  53. Leszek Janczuk (mar/2018)
  54. PH.testes (mar/2018)
  55. Aspargos (fev/2018)
  56. Conde de Morcerf (fev/2018)
  57. KiraTHO (fev/2018)
  58. Sage (Wiki Ed) (fev/2018)
  59. AlexSP (jan/2018)
  60. Arthemius x (jan/2018)
  61. MelM (jan/2018)
  62. RodrigoAndradet (jan/2018)
  63. ValterVB (jan/2018)
2017 – 41 autorrevisores (6%)
  1. B.Lameira (dez/2017)
  2. Brazuka! (dez/2017)
  3. PedroPVZ (dez/2017)
  4. Jmvkrecords (nov/2017)
  5. PViz (nov/2017)
  6. W.SE (nov/2017)
  7. Faduart (out/2017)
  8. LP Sérgio LP (out/2017)
  9. Mariliawikipedia (out/2017)
  10. Nakinn (out/2017)
  11. Scott Tomlinson (out/2017)
  12. Edissom (set/2017)
  13. Vinctus (set/2017)
  14. Gustavo Siqueira (ago/2017)
  15. Aflis (jul/2017)
  16. L%27editeur (jul/2017)
  17. Lina Yab (jul/2017)
  18. Bisbis (jun/2017)
  19. Faltur (jun/2017)
  20. Fsantos222 (jun/2017)
  21. Giullia Duarte Almeida (jun/2017)
  22. Gustavo gho (jun/2017)
  23. J. A. S. Ferreira (jun/2017)
  24. Magioladitis (jun/2017)
  25. Mars Rover (jun/2017)
  26. Alelapenya (mai/2017)
  27. Rathbone (mai/2017)
  28. Swblade (mai/2017)
  29. NelsonCM (abr/2017)
  30. Nuno Raimundo (abr/2017)
  31. JBarreto (mar/2017)
  32. Johnmartins (mar/2017)
  33. Judcosta (mar/2017)
  34. Conde Ed Dantes (fev/2017)
  35. Lordcaio (fev/2017)
  36. Pintopc (fev/2017)
  37. WOtP (fev/2017)
  38. Acdallago (jan/2017)
  39. Bya97 (jan/2017)
  40. Mayckon.trudes (jan/2017)
  41. Ungolo (jan/2017)
2016 – 28 autorrevisores (4,1%)
  1. Amestis (dez/2016)
  2. PedR (dez/2016)
  3. Burmeister (nov/2016)
  4. Fabiano Tatsch (nov/2016)
  5. Grind24 (nov/2016)
  6. Michaelpires (nov/2016)
  7. Victor Andrade (nov/2016)
  8. Escoria79 (out/2016)
  9. La marionette (out/2016)
  10. Ludmilson (out/2016)
  11. Qualquerumxx (out/2016)
  12. Xico CLJ (out/2016)
  13. Gabriel Guilherme (set/2016)
  14. PatríciaR (ago/2016)
  15. Colaborador 2.542 (jul/2016)
  16. CorreiaPM (jul/2016)
  17. Mathonius (jul/2016)
  18. Outis (jul/2016)
  19. Um simples Wikipedista (jul/2016)
  20. Alexg (mai/2016)
  21. José Luís Ávila Silveira (mai/2016)
  22. Pedro Noronha e Costa (mai/2016)
  23. Pingo7 (mai/2016)
  24. Tegmen (mai/2016)
  25. FilRB (abr/2016)
  26. Israelrocha (abr/2016)
  27. SuperBraulio13 (abr/2016)
  28. Dudu 18 (jan/2016)
2015 – 21 autorrevisores (3,1%)
  1. SallesNeto BR (dez/2015)
  2. Sowiki50 (dez/2015)
  3. PbBR8498 (set/2015)
  4. Luckas Blade (ago/2015)
  5. Plasticinax (ago/2015)
  6. Dir3itista (jul/2015)
  7. Dreispt (jul/2015)
  8. Loess (jul/2015)
  9. Anne Valladares (jun/2015)
  10. Ariel C.M.K. (jun/2015)
  11. Gabryelsl (jun/2015)
  12. Luckas Parker (jun/2015)
  13. Ana Bruta (mai/2015)
  14. Daniel Mietchen (mai/2015)
  15. OS2Warp (abr/2015)
  16. Takeshi-br (abr/2015)
  17. Eduardo P (mar/2015)
  18. Tiago Peixoto (mar/2015)
  19. Ermeson15 (fev/2015)
  20. MaxJornalista (fev/2015)
  21. Dark-Y (jan/2015)

Com base neste registro, fica claro que não há mais a necessidade da ampliação do absenteísmo para autorrevisores, visto que mais de 77% são ativos em 2019. Sendo assim, proponho que seja reduzido o tempo de cinco anos para um ano, assim será possível que nosso projeto tenhamos autorrevisores ativos e que estejam acompanhando as mudanças nas políticas e recomendações do projeto, algo que um autorrevisor deve estar familiarizado para se manter com a flag.

Absenteísmo também é motivo legítimo para revogação do acesso para todos os autorrevisores que se encontrem editorialmente inativos há cinco anos um ano.

Só para concluir a proposta, manter a flag para autorrevisores inativos há mais tempo faz com que eles estejam desatualizados com as mudanças de políticas e recomendações do projeto. Um exemplo que pode impactar diretamente neste usuário são as mudanças aprovadas em WP:NÃOINFO, impedindo que haja bandeirinha em predefinições de infocaixas, além de mudanças semelhantes em artigos de campeonatos e clubes de futebol. Um autorrevisor pode retornar ao projeto contrariando essas regras – inserindo bandeirinhas – e os vigilantes do artigo nem deverão perceber, uma vez que a edição deste está patrulhada. O estatuto de autorrevisor não é um entulho especial para contas inativas; estes deverão estar ativos no projeto e os dados de 2019 provam esta necessidade que não prejudica em nada no projeto. WikiFer msg 23h45min de 30 de dezembro de 2019 (UTC)

Symbol declined.svg Discordo, é a flag mais inofensiva de todas, não tem motivo pra ter um absenteísmo curto. As políticas mudam, mas nada que seja gigantesco de um ano pro outro a ponto de justificar a remoção da flag. O editor pode ficar enferrujado de um ano pro outro, mas não é como se ele desaprendesse o que é a Wikipédia. —Pórokhov Порох 23h55min de 30 de dezembro de 2019 (UTC) O texto riscado foi colocado por um fantoche de Quintinense D​ C​ E​ F​ B

Pórokhov, ok, você discorda que seja um ano. Mas e se for mais que um ano, e menos que cinco? Em outras palavras, você é contra qualquer redução, ou só contra a redução para um ano.?--Mister Sanderson (discussão) 00h07min de 31 de dezembro de 2019 (UTC)
Pórokhov: Se a gente for analisar os autorrevisores que editaram no ano de 2018, foram menos de 10%, número bem baixo comparado com 2019. Mesmo que eles percam a flag eles poderão recuperar novamente caso retornem ao projeto e decidem voltar a editar, isso já acontece com os usuários que perdem a flag de reversor por absenteísmo. A ideia da proposta é justamente evitar que haja esse entulho de autorrevisores inativos. Se o número de ativos em 2019 não fosse tão alto, até justificaria não remover, mas a ideia tem o objetivo de organizar àqueles que fazem jus ao estatuto e que contribuem de alguma forma no projeto. WikiFer msg 00h24min de 31 de dezembro de 2019 (UTC)

Symbol support vote.svg Concordo FábioJr de Souza msg 23h59min de 30 de dezembro de 2019 (UTC)

Symbol support vote.svg Concordo GhostP. disc. 00h57min de 31 de dezembro de 2019 (UTC)

Symbol support vote.svg Concordo com a redução para um ano. Luís Almeida "Tuga1143 01h42min de 31 de dezembro de 2019 (UTC)

Symbol support vote.svg Concordo com uma redução, mas não sei se um ano é uma boa ideia... Só sei que cinco anos é demais para a pessoa ficar longe da Wikipédia e voltar não só com conhecimento das políticas, mas também com costume. Editar bem não é como andar de bicicleta. Leefeniaures audiendi audiat 03h33min de 31 de dezembro de 2019 (UTC)

Symbol support vote.svg Concordo com a proposta. João Henrique (Mensagens) 15h30min de 31 de dezembro de 2019 (UTC)


Em janeiro de 2013, o JMagalhães propôs abolir o absenteísmo para autorrevisores e houve um quase consenso unânime, com apoio de Danilo.mac, Py4nf e João Carvalho. Apenas não foi consenso por causa do Teles, que aceitou um tempo alargado de 5 anos, daí o consenso. Por que andar na direção contrária agora? Tem que ter uma boa razão.-- Leon saudanha 19h18min de 31 de dezembro de 2019 (UTC)

Leon saudanha Só uma correção: em 2013 o usuário Teles sugeriu como alternativa daquela proposta com prazo de um ano (esse sim era o tempo exato), isso bem no começo daquela discussão. Esta sugestão inicial do Teles que poderia ter levado adiante; além disso, a proposta daquela época deu ênfase apenas ao fato de facilitar o trabalho para quem patrulha as MRs e a valorização do administrador que promoveu estes usuários com a flag de autorrevisor. A proposta atual é o reflexo do entulho de contas inativas causadas por aquela proposta, é totalmente diferente e mais novo o que está se discutindo nos dias atuais. WikiFer msg 20h47min de 31 de dezembro de 2019 (UTC)
Desculpe, não percebi. O que é isso de "entulho"? Um autorrevisor é um "entulho" de quê? JMagalhães (discussão) 11h33min de 1 de janeiro de 2020 (UTC)
JMagalhães O "entulho" que eu me refiro é o falacioso número de autorrevisores que existe no projeto, mas que "apenas" existe. Entre 2015 a 2018, tivemos um número inferior a 25% de autorrevisores inativos, sendo menos de 10% somente em 2018; por outro lado, podemos nos orgulhar de termos mais de 77% de autorrevisores ativos em 2019, o que faz jus ao espírito de edição e inspira o objetivo de alterar esta regra. WikiFer msg 12h27min de 1 de janeiro de 2020 (UTC)
Não percebo. Qual é exatamente o problema em haver autorrevisores inativos? Que haja pessoas com ferramentas inativas eu percebo o problema. Não percebo onde está o problema de autorrevisores, dado que isso não corresponde a qualquer ferramenta. JMagalhães (discussão) 13h59min de 1 de janeiro de 2020 (UTC)
JMagalhães Autorrevisores inativos não participam do projeto, não editam, ou seja, não há edições autopatrulhadas, muito simples. A presença deles na lista de autorrevisores traz um resultado falacioso na prática. Nada na vida é eterno, se a pessoa fica muito tempo ausente é porque já não faz jus a ferramenta. Contudo, isto não impede que esta possa ter a flag de volta ao retornar ao projeto, basta só solicitar a reatribuição. WikiFer msg 15h04min de 1 de janeiro de 2020 (UTC)

Symbol support vote.svg Concordo com a redução para um ano. Quem se afasta por cinco anos está mais que desactualizado e desinteressado. Vanthorn® 21h41min de 31 de dezembro de 2019 (UTC)

Symbol question.svg Pergunta Alguém já fez um estudo comparativo com as outras wikis, sobre o tempo de abstenseísmo (se ele existe) e sobre quais as regras vigentes e quais as reflexões e estudos que as motivaram, para poder subsidiar melhor o que decidimos aqui? Millbug fala 23h58min de 31 de dezembro de 2019 (UTC)

Millennium bug O absenteísmo para autorrevisores foi criado na regulamentação da flag em 2009 e quatro anos mais tarde foi proposto a revogação dela, mas acabou por ampliar este tempo. No entanto, apresentei dados que mostram a razão pela qual o tempo de absenteísmo deve ser reduzido, visto que a função dela é justamente para o editor ter suas edições patrulhadas automaticamente, isto é, o número de usuários ativos em 2019 (acima de 77%) é mais do que suficiente para fazer jus a flag. Quanto ao comparativo em outras wikis, na versão anglófona, não há nada no texto que tenha absenteísmo, porém lá a realidade é outra, o critério mínimo para atribuição da flag é ter no mínimo 25 artigos criados e mesmo assim contas mais novas podem não receber a flag se o administrador não quiser aprovar, além do grande número de usuários ativos que existe na Wikipédia em inglês. O objetivo desta proposta é fazer com que o autorrevisor possa contribuir com o projeto. WikiFer msg 12h27min de 1 de janeiro de 2020 (UTC)

Symbol declined.svg Discordo Só existem desvantagens e nenhuma vantagem. Vai dar muito mais trabalho aos administradores e à própria pessoa em termos de remoção e reatribuição, quando por outro lado não existe nenhum benefício associado à redução. Peço desculpa, mas não percebi o que é isso de estar "a par de novas regras". Autorrevisor significa escrever com o mínimo de qualidade, referenciar bem, conhecer o manual de estilo e seguir meia dúzia de regras básicas. Essas regras básicas mantêm-se inalteráveis desde 2001. Não percebo de onde apareceu esta exigência super maluca para autorrevisores de conhecer todas as regras em minúcia. Se nem administradores ativos estão a par de todas as regras e alterações, de um momento para o outro isso passou a ser exigido a simples editores autorrevisores? JMagalhães (discussão) 11h31min de 1 de janeiro de 2020 (UTC)

JMagalhães Não vejo qual desvantagem, que eu saiba a flag só será reatribuída caso o usuário retorne ao projeto e decida voltar a editar como antes, isto é, o próprio usuário deverá pedir a flag de volta, podendo até explicar as razões pela inatividade antes do administrador reatribuir. Quanto a remoção, não sei se você percebeu, mas nesta proposta mesmo eu criei uma lista que inclui todos os 673 autorrevisores (com exceção de eliminadores e administradores), separando pelo período que eles editaram, anualmente, entre 2015 a 2019, ou seja, eu já dei a "cola" para que todos os administradores e burocratas deste projeto que já podem fazer o monitoramento dos próximos usuários a perderem a flag. Se o problema for esse, a ideia seria criar uma subseção (na página de Wikipédia:Autorrevisores) de monitoramento destas contas e fazer atualização no penúltimo dia de cada mês. Eu já aproveito este momento e, caso esta proposta de redução para um ano aconteça, eu já preparo esta lista para os reversores também. Isso é o de menos, só gastei algumas horas para organizar a lista, agora ver as contribuições de cada usuários é mais fácil; pelo Google Chrome eu já abro 20 abas de uma vez e pronto. Quanto as regras, é verdade que o autorrevisor deve conhecer o manual de estilo, editar e referenciar bem, mas aí eu te pergunto: isso acontece para quem não edita no projeto há mais de um ano? Se o objetivo desta flag é valorizar o espírito de edição, um usuário inativo não cumpre este requisito. Se a gente for depender de autorrevisores inativos, os artigos vão continuar péssimos do jeito que tá, pois somente quem edita é capaz de mudar toda esta situação. WikiFer msg 12h27min de 1 de janeiro de 2020 (UTC)
Ao fim de um ano as pessoas esquecem-se por completo de como fazer um artigo? JMagalhães (discussão) 13h59min de 1 de janeiro de 2020 (UTC)
JMagalhães Ao fim de um ano, eles não editam e sequer mudam a qualidade dos artigos, questão de lógica. Se a ferramenta de autorrevisor dá o privilégios deles terem suas edições autopatrulhadas, qual a razão de ficarem mais de um ano sem aparecer edições deles no histórico dos artigos? A verdade é que um usuário autoconfirmado editando atualmente – que tem suas edições fiscalizadas por terceiros – possui mais benefícios ao projeto do que um autorrevisor inativo que não traz sinal de vida. Hoje temos mais de 77% de autorrevisores que valorizam a importância desta ferramenta que são as edições. WikiFer msg 15h04min de 1 de janeiro de 2020 (UTC)
Você está a assumir, erradamente, que toda a gente que fica inativa nunca mais volta a editar. No entanto, há imensos editores que voltam ao projeto passado 1, 2, 3, 4 anos. É por isso que não se remove a flag de imediato. JMagalhães (discussão) 15h37min de 1 de janeiro de 2020 (UTC)
JMagalhães Nós nunca saberemos quando eles vão voltar, seja daqui 1, 2, 3 ou 4 anos, como você mesmo disse. Contudo, se estes voltarem e quiserem contribuir novamente com o projeto, eles poderão solicitar a flag de volta. Isto não é novidade. WikiFer msg 16h38min de 1 de janeiro de 2020 (UTC)
Foi precisamente para não se estar constantemente a remover e reatribuir a flag que em 2013 se estabeleceu o prazo de 5 anos. JMagalhães (discussão) 17h30min de 1 de janeiro de 2020 (UTC)
JMagalhães Só não podemos esquecer que a primeira alternativa proposta pelo usuário Teles foi com período de um ano, sugestão ignorada pelos usuários naquela discussão de 2013, que é tão atual para o ano de 2020. WikiFer msg 18h44min de 1 de janeiro de 2020 (UTC)
A primeira alternativa foi pura e simplesmente eliminar qualquer prazo. Não percebo porque é que você está constantemente a mencionar essa sugestão de um ano, que não recolheu qualquer apoio, e o período aprovado por unanimidade foi de cinco anos. JMagalhães (discussão) 08h48min de 2 de janeiro de 2020 (UTC)
JMagalhães Que eu saiba a proposta alternativa de um ano também não recebeu discordância (que foi a primeira contra-proposta daquela discussão), aliás, ninguém se manifestou de maneira contrária naquela discussão. Como a sugestão foi completamente ignorada (que é diferente de ser rejeitada) não se pode descartar aquela opção – hoje se aplica para redução para um ano. WikiFer msg 13h35min de 2 de janeiro de 2020 (UTC)

Symbol declined.svg Discordo proposta resolve problema nenhum, e cria mais burocracia desnecessária. GoEThe (discussão) 14h26min de 2 de janeiro de 2020 (UTC)

GoEThe Não cria burocracia desnecessária, muito pelo contrário, servirá até para sabermos os usuários que receberam a confiança do administrador e burocrata a contribuir com o projeto. O estatuto de autorrevisor possui a função de valorizar as edições – por isto que estes possuem edições autopatrulhadas. Se um autorrevisor não edita, não registra suas edições para o projeto, qual a função de se manter com a flag? Eu mesmo já até apresentei uma lista com todos os 673 autorrevisores deste projeto, separei eles anualmente (entre 2015 a 2019) justamente para sabermos quem está próximo de perder a flag por absenteísmo. A partir do momento que a proposta for aprovada, o único controle será em relação àqueles que estarão inativos há mais de um ano; eu já tenho solução para isto também. WikiFer msg 14h54min de 2 de janeiro de 2020 (UTC)
Mas qual é o problema de um autorrevisor não editar? A função serve para patrulhadores não terem que revisar edições que são de boa qualidade à partida. Não havendo essas edições, não gera trabalho adicional para ninguém. Limitando o tempo de absentismo possível, tem que haver esse controle mais apertado de quantos autorrevisores estão ausentes retirar o estatuto, e se algum deles voltar alguém terá que reatribuir o estatuto. São pelo menos três ações a mais. GoEThe (discussão) 15h07min de 2 de janeiro de 2020 (UTC)
GoEThe Autorrevisores que não editam deixam um resultado falacioso na lista de autorrevisores do projeto – não reflete ao número de usuários com edições autopatrulhadas na prática. Pode não gerar trabalho para ninguém, mas a ausência deles também não resolverá em nada a qualidade dos artigos. Se hoje nós temos 77% de autorrevisores (porcentagem superior até mesmo para aprovação de uma candidatura a administrador) comprometidos em editar no projeto, significa que não haverá problema algum para a Wikipédia na questão envolvendo os inativos, isto é, se algum deles voltar para ativa e quiserem a flag de volta, é possível que eles até esclareçam a razão pela inatividade, o que dará motivos para que o administrador/burocracia possa reatribuir. WikiFer msg 15h23min de 2 de janeiro de 2020 (UTC)
E qual a consequência de ter um número X de autorrevisores em que uma parte não editou nos últimos anos? É a percentagem de inactivos que influencia alguma ação dos activos? Ninguém tem nada a ver com as razões de inactividade dos editores, não devem esclarecer coisa alguma. Deixem lá isso. GoEThe (discussão) 15h27min de 2 de janeiro de 2020 (UTC)
GoEThe Compreendo que ninguém seja obrigado a falar das razões de inatividade, principalmente se for envolvendo motivos pessoais, que não envolve o projeto. No entanto, usuários autoconfirmados ativos – que possuem edições fiscalizadas por terceiros – trazem maior benefício para o projeto do que autorrevisores inativos que sequer dão sinal de vida. Por esta razão, fica claro que a lista de autorrevisores precisa refletir ao que é mais importante nesta flag: a edição. Ninguém aqui obriga a pessoa ser ativa, mas também não podemos manter a flag para quem não edita. A gente respeita a decisão deste usuário, assim como, este deve respeitar sua ausência perante ao projeto também. WikiFer msg 15h39min de 2 de janeiro de 2020 (UTC)

Symbol comment vote.svg Comentário São tantos autorrevisores inativos assim a ponto de gerar um trabalho enorme removê-los? É só me informar que removo tudo... Ademais, qual a real probabilidade de alguém com três anos de afastamento, por exemplo, voltar a editar? Além disso, se o problema é com um ano, pode-se adotar uma proposta alternativa de dois anos. FábioJr de Souza msg 15h18min de 2 de janeiro de 2020 (UTC)

Fabiojrsouza Exatamente, eu até já organizei a lista com todos estes dados justamente para facilitar na aprovação desta proposta. Percebe-se que entre 2015 a 2018 o número de autorrevisores inativos é inferior a 25%, sendo menos de 10% somente no ano de 2018. Isto significa que a aprovação desta proposta só flexibilizará a importância de termos autorrevisores que contribuem com o projeto, uma vez que são mais de 77% em 2019. Quanto ao tempo, inicialmente foi sugerido um período de um ano em razão dos dados apresentados, por isto que este tempo mínimo de um ano reflete mais a proposta de redução. WikiFer msg 15h23min de 2 de janeiro de 2020 (UTC)
A questão não é quantidade ou facilidade, é necessidade. GoEThe (discussão) 15h32min de 2 de janeiro de 2020 (UTC)
GoEThe Justamente por isso que estou propondo a alteração da regra. O mais importante não é quantidade e sim a qualidade (necessidade), o fato de termos usuários que contribuem com o projeto. A proposta é mais do que simples – não tem muito segredo! WikiFer msg 15h41min de 2 de janeiro de 2020 (UTC)
GoEThe Exato. Qual a necessidade de manter usuários com dois a quatro anos, por exemplo, com o estatuto se eles não editam? Até porque, mais cedo ou mais tarde vão perder do mesmo jeito. Não há a necessidade de termos contas com estatutos de autorrevisor se elas não editam. Uma conta que não edita tendo a confiança da comunidade?(?)FábioJr de Souza msg 16h05min de 2 de janeiro de 2020 (UTC)
Não vejo sinceramente o problema com a situação actual. GoEThe (discussão) 16h10min de 2 de janeiro de 2020 (UTC)

Eu to lendo toda a discussão e fazendo esforço, mas não consigo concordar. Fabiojrsouza vc diz que pode remover e reacrescentar todos facilmente, tudo bem, mas as regras não podem ser pensadas com base na sua disponibilidade. Daqui há um ou cinco anos, o inativo pode ser você, e quem vai se disponibilzar a ter esse trabalho à toa? O absenteísmo não existe para termos uma lista "bonitinha" só com quem ta ativo, ele tem um propósito. Um administrador que ficar cinco anos inativo estará desatualizado sobre a jurisprudência das discussões de bloqueio; um eliminador que ficar cinco anos inativo pode estar desatualizado sobre critérios de notoriedade e outras decisões em PEs; mas um autorrevisor que ficar cinco anos sem editar, vai estar desatualizado sobre WP:Verificabilidade, WP:NPI, WP:Princípio da imparcialidade e o livro de estilo? Não, porque isso não muda! E isso é o mínimo que se precisa conhecer para se ter esse estatuto. Se um autorrevisor passa 5 anos sem editar e volta criando uma centena de artigos até receber o estatuto de volta, teremos uma centena de artigos para serem patrulhados sem necessidade. —Pórokhov Порох 17h50min de 4 de janeiro de 2020 (UTC) O texto riscado foi colocado por um fantoche de Quintinense D​ C​ E​ F​ B

@Pórokhov: Naturalmente, respeito sua opinião. É claro que as regras não são feitas com base na minha disponibilidade, mas as regras também não são feitas pensando na disponibilidade ou não dos outros editores no futuro (caso contrário, nenhuma regra é feita). Claro que daqui a alguns anos estarei inativo. No entanto, o projeto é dinâmico e sempre surge alguém para atuar nessa área. Veja que o Stuckkey, um grande editor, deixou de realizar suas edições. Mas outros vieram e passaram a realizar os bloqueios e eliminações. Recentemente temos outros editores liderando o "ranking" das eliminações e bloqueios. E vida que segue...
Mas, já que leu a discussão toda, viu que cerca de 153 teriam o estatuto removido. Pode ser um trabalho grande agora, mas não quer dizer que todo ano de janeiro um administrador vai ver a lista e retirar 150 editores. Eu acho que é lógico que poucos terão o estatuto removido no futuro. Desculpe não ter deixado claro, mas quando disse que removeria tudo (e não disse que faria isso em um dia), quis dizer que o principal não é analisar a questão pelo lado da dificuldade de retirar esses estatutos, mas sim da necessidade de termos uma quantidade de autorrevisores que têm o estatuto, mas não editam. Ademais, se o que um autorrevisor precisa pra editar não muda e Citação: Pórokhov escreveu: «passa 5 anos sem editar e volta criando uma centena de artigos» pra que absenteísmo de autorrevisor?
Ademais cedo ou tarde, se não voltarem a editar, serão removidos.
Não vejo a questão pelo lado de Citação: Pórokhov escreveu: «termos uma lista "bonitinha"» mas sim de evitar Citação: WikiFer escreveu: «um resultado falacioso na lista de autorrevisores do projeto – não reflete ao número de usuários com edições autopatrulhadas na prática». Não custa lembrar que o objetivo do estatuto de autorrevisor é evitar que as edições de certos editores sejam patrulhadas. Se ele não edita... Não acho que um autorrevisor, ao voltar, vai criar cem artigos em um dia. Enfim.FábioJr de Souza msg 19h04min de 4 de janeiro de 2020 (UTC)

Symbol declined.svg Discordo Uma redução de cinco anos para um ano, depois de pouco tempo decorrido do consenso de cinco anos, é desproporcional. Os requisitos para se tornar um autorrevisor não são exigentes como o de administrador e eliminador. O que se exige do autorrevisor é que ele tenha conhecimento das regras básicas e procure agir sempre de boa-fé em suas edições. Um autorrevisor que ficar sem editar por mais de um ano não ficará desatualizado, visto que as regras básicas pouco se alteram. Agora se quiserem reduzir para quatro ou três anos, não oferecerei oposição. Mas um ano entendo que é um período muito curto, e a pessoa pode se afastar da Wikipédia nesse período por várias questões. Aí depois de um ano, se essa pessoa voltar, vai ter aquela burocracia toda para reincluí-lo novamente no estatuto? Por essas razões que eu não concordo com uma redução de um ano. ✍️A.WagnerC (discussão) 18h04min de 4 de janeiro de 2020 (UTC)

Caro @A.WagnerC: as propostas são feitas como ponto de partida para uma discussão. Assim, ter começado com um ano não quer dizer que vai terminar com um ano. Pelo que vejo, a ideia básica é estabelecer um novo tempo para absenteísmo. Pode ser outro período. Eu mesmo aventei, acima, a possibilidade de dois anos. Veja que, de certa forma, você não discordada totalmente da ideia principal e sim do tempo. Consenso é para chegar em algo comum.FábioJr de Souza msg 19h04min de 4 de janeiro de 2020 (UTC)

Symbol comment vote.svg Comentário Só complementando o que o usuário Fabiojrsouza respondeu acima, o estatuto de autorrevisor possui a função de contribuir com o projeto e foi por esta razão que esta flag foi atribuída na época que estes usuários estavam disponíveis. Apesar dos inativos autorrevisores terem conhecimento da política de verificabilidade, nada de pesquisa inédita, princípio de imparcialidade e livro de estilo, estas políticas e recomendações são úteis para valorizar a edição, ou seja, quem contribui inserindo conteúdo. Em momento algum são regras que beneficiam autorrevisores a terem privilégio vitalício de suas edições autopatrulhadas quando se está inativo há cinco anos. Aliás, cinco anos não é cinco dias e nem cinco meses – durante este período de ausência qualquer pessoa pode muito bem concluir um curso de ensino superior e seguir outro caminho longe desse projeto; dizer que deve retornar criando vários artigos é um argumento subjetivo. Quanto ao trabalho dos administradores e burocratas em organizar a lista, hoje temos 153 autorrevisores que estão ausentes até o final de 2018 - a única "dificuldade" seria a remoção desta flag neste momento, isto é, porque estamos falando de editores inativos nos anos de 2015, 2016, 2017 e 2018. Obviamente o número não será o mesmo no final deste ano para a entrada de 2021. E caso algum deles retornem ao projeto, não vejo burocracia alguma na reatribuição da flag, uma vez que administradores e burocratas devem usar a ferramenta de privilégios (não serve para guardar de enfeite). Eu mesmo estou usando para remover usuários inativos que já estão em absenteísmo, conforme os critérios atuais para autorrevisores e reversores, não vejo nada de problemático em usar uma ferramenta administrativa. Portanto, devemos ressaltar a importância de um autorrevisor cuja principal função do estatuto: a edição. WikiFer msg 16h56min de 5 de janeiro de 2020 (UTC)

O estatuto de autorrevisor não é atribuído para dar privilégio a quem o recebe, mas a quem patrulha as MRs. Ao contrário dos outros estatutos, não outorga ferramentas adicionais a quem o recebe. O estatuto não é dos autorrevisores, é dos patrulhadores. GoEThe (discussão) 14h29min de 6 de janeiro de 2020 (UTC)
GoEThe Mas a prática das edições patrulhadas nas MRs só acontece quando um autorrevisor contribui com o projeto, da mesma forma quando este expande conteúdo dos artigos, de acordo com as políticas e recomendações que eu citei acima. Isso, de fato, não vai impedir que o usuário continue tendo a flag de autorrevisor para facilitar o trabalho dos patrulhadores de MRs. A inatividade que é uma outra história, é o inverso de tudo isso que eu falei. WikiFer msg 14h37min de 6 de janeiro de 2020 (UTC)
A remoção da ferramenta continua a ser uma ação desnecessária, porque não resolve nenhum problema. E cria ações extra que antes não eram precisas. GoEThe (discussão) 14h41min de 6 de janeiro de 2020 (UTC)
GoEThe Como a ausência de um usuário inativo há mais de um ano pode ser um problema ao projeto? Problema é acreditar que um autorrevisor que não edita há mais de um ano continue tendo suas edições autopatrulhadas quando, na verdade, estas edições não são utilizadas para contribuir com o projeto. A ferramenta de privilégios deve ser utilizada pelos administradores e burocratas tanto pela remoção, quando pela reatribuição (se vier acontecer). Quando um administrador perde sua flag por absenteísmo e decide retornar ao projeto, quem deve tomar a iniciativa para pedir a reatribuição da flag de volta é quem esteve inativo. É uma prática comum do projeto, não vejo novidade alguma nisso. Sem contar que o tempo de absenteísmo para autorrevisores aqui é mais que o quíntuplo de todas as outras ferramentas, embora não vou questionar essa desproporcionalidade, mas a prática da edição é um requisito para ser autorrevisor. Se ninguém conquistou este direito sendo inativo, não acredito que estando inativo é que permanecerá com ela. WikiFer msg 15h03min de 6 de janeiro de 2020 (UTC)
Mas quais edições, se o usuário está inactivo? Os usuários estarem inactivos não traz nenhuma consequência ao projecto, tirando a sua ausência do projecto. GoEThe (discussão) 15h27min de 6 de janeiro de 2020 (UTC)
GoEThe Neste caso devemos respeitar a ausência deles enquanto estão inativos e registrar os que editam no projeto. Como eu já havia dito, ninguém aqui vai obrigar autorrevisores a editarem, mas também não podemos permitir que inativos mantenham a flag justamente por ter um efeito oposto do estatuto que receberam: a prática de ter edições autopatrulhadas. A responsabilidade de pedir a flag de volta num provável retorno ao projeto (Wikipédia:Pedidos/Autorrevisor) caberá ao usuário, não aos administradores e burocratas. Melhor do que termos um falacioso número de autorrevisores que não correspondem ao objetivo do estatuto. WikiFer msg 15h33min de 6 de janeiro de 2020 (UTC)

Exatamente como disse o editor GoEThe. O objetivo do estatuto é o de facilitar o trabalho de quem patrulha. Se a pessoa recebeu esse atributo, é porque, em princípio, é um usuário de confiança, e essa confiança não se perde por conta de um período ausente. ✍️A.WagnerC (discussão) 14h53min de 6 de janeiro de 2020 (UTC)

A.WagnerC Não estou contestando os usuários que conseguiram a confiança da comunidade, mas em relação ao tempo de absenteísmo que este usuário terá com o estatuto. A confiança, de fato, nunca deixará de existir, mas a falta de edições necessárias para contribuir com o projeto, isso deixará de ter. Você já chegou a refletir que esse período total de cinco anos pode até ser a razão pela qual muitos editores costumam se ausentar do projeto, justamente pelo fato deles terem uma garantia com suas edições continuarem autopatrulhadas? Se pegarmos os 77% de autorrevisores ativos que editaram em 2019 (porcentagem superior para aprovação de sysop), eles não deixaram o projeto em segundo plano só porque garantiram a flag, eles valorizam a importância deste estatuto que é a prática da edição. WikiFer msg 15h03min de 6 de janeiro de 2020 (UTC)
A.WagnerC Acho importante ter em mente que existe a possibilidade do editor perder o estatuto por absenteísmo. O que se discute aqui é o período. Esses editores, se não voltarem a editar, perderão o estatuto em cinco anos. Isso é um fato. O GoEThe está equivocado, pois (ao menos pelo que entendi, salvo melhor juízo) dá a entender que esses usuários não perderão o estatuto. Mas perderão, depois de cinco anos.FábioJr de Souza msg 15h33min de 6 de janeiro de 2020 (UTC)
A diferença é que passados 5 anos será muito raro um editor voltar, pelo que quem quiser perder tempo a tirar essas flags não faz mal a ninguém (só não obriguem alguém a fazê-lo). Mas passado apenas 1 ano, é ainda possível alguém voltar e ter que: ou pedir novamente a flag ou alguém notar que já foi autorrevisor e atribuí-la, tirando as edições que entretanto fizer e que patrulhadores tiverem que verificar sem necessidade. GoEThe (discussão) 16h23min de 6 de janeiro de 2020 (UTC)
Mesmo com a redução do absenteísmo para um ano, nenhum administrador ou burocrata será obrigado a remover a flag deles – embora seja recomendável por causa da regra – na verdade, até hoje existem usuários inativos que já quebraram um período de inatividade superior a seis meses só para garantir a ferramenta de reversor, ou seja, nenhum administrador ou burocrata verificou suas contribuições quando estava ausente há mais de seis meses. No meu caso, por outro lado, eu já tenho registrado uma lista dos atuais autorrevisores e reversores – este último eu classifiquei pelos últimos seis meses, então sei quem estará próximo de perder a flag a aplicarei a remoção por absenteísmo. No caso dos autorrevisores não será diferente. WikiFer msg 16h49min de 6 de janeiro de 2020 (UTC)
GoEThe Por que não propõe um prazo de 2 a 3 anos, se o problema é um ano?FábioJr de Souza msg 18h09min de 6 de janeiro de 2020 (UTC)


GA candidate.svg Apoio fraco Um aspecto que considero importante lembrar, talvez, seja a questão de segurança. Um autorrevisor tem o poder de editar predefinições e módulos de alto impacto e artigos importantes que foram protegidas a esse nível. Desconheço se algo assim já tenha ocorrido, mas deve existir a chance de uma conta antiga ser invadida/comprometida e utilizada de má-fé, ou o usuário que foi autorrevisor pode "mudar" após alguns anos e querer fazer edições não construtivas. Estou apenas conjecturando, mas não vejo problemas em remover a flag após alguns anos de absenteísmo, embora acredite que 1 ano seja um tanto curto (porque não 2 ou 3 anos?). ━ ALBERTOLEONCIO Who, me? 16h44min de 6 de janeiro de 2020 (UTC)

Albertoleoncio Exatamente, bem lembrado a respeito das predefinições e da conta invadida/utilizada por outrem. Imaginemos que algum amigo ou familiar consiga ter acesso a conta inativa desse sujeito e utilize de má-fé, todo o contexto da flag de autorrevisor atribuída na época acaba ficando em vão justamente por conta desse tipo de situação. Além disso, não posso deixar de especificar a possibilidade de uma conta dormente de autorrevisor retornar ao projeto só para participar de uma votação de extrema importância aqui na comunidade – atualmente burocratas tem autonomia para interpretar uma possível anulação de votos de contas dormentes (somente por evidência de meat), porém a flag de autorrevisor pode servir de argumento para anistiar o usuário e ter o voto validado; neste caso a inatividade de autorrevisor pode sim comprometer o futuro do projeto, em caso de ser conta dormente (algo que nem foi regulamentado ainda). Quanto ao tempo de absenteísmo, eu levei em consideração pelo tempo de um ano com base nos dados apresentados entre 2015 a 2019, enfatizando o último ano, quando tivemos mais de 77% de autorrevisores ativos. WikiFer msg 18h13min de 6 de janeiro de 2020 (UTC)

Eu sou a favor a partir de 3 anos. ✍️A.WagnerC (discussão) 16h47min de 6 de janeiro de 2020 (UTC)

Continuação da proposta: 30 de dezembro de 2020

Symbol comment vote.svg Análise: Com base no que foi debatido nesta proposta inicial que tem o intuito de reduzir o tempo de absenteísmo para flag de autorrevisor por um ano, é possível afirmar que a comunidade deu parecer pela sua redução, embora não ficou estabelecido o tempo exato para ser reduzido. A proposta também recebeu parecer contrário, mas todas estas alegações foram refutadas, conforme os registros desta discussão. Entretanto, percebe-se que ainda faltam esclarecer algumas coisas para que se possa determinar o consenso, ou seja, a minha ideia seria reabrir esta discussão novamente no dia 30 de dezembro de 2020, pelas seguintes razões:

  • registrar as 153 contas de autorrevisores entre 2015 e 2018 que voltaram a apresentar alguma edição no projeto em 2020 (para sabermos se vale a pena manter estas contas com a flag);
  • verificar se haverá uma porcentagem adequada entre as contas de 2015 e 2018 retornando ao projeto (no mínimo 25% das 153 contas inativas);
  • verificar se o número de autorrevisores ativos em 2020 deve aumentar, comparando-se com os 77% de ativos em 2019;
  • o número de novos autorrevisores que forem inclusos durante o ano de 2020 será registrado e informado neste novo registro para evitar questionamentos;
  • atualizar a lista apresentada no início desta proposta substituindo Especial:Contribuições para Usuário: (vou transferir transferi do bloco de notas para cá) para que a comunidade que já tenha ativado os pop-ups no seu gadget possam posicionar a seta do mouse sobre a conta para monitorar a última vez que editaram;
  • verificar se estes autorrevisores entre 2015 e 2018 realmente decidiram voltar a contribuir no projeto de maneira ativa, não somente para registrar sua única edição anual;
  • durante o ano de 2020, os 21 autorrevisores de 2015 devem perder a flag se não voltarem a contribuir no projeto; um já perdeu, falta 20.

Durante esta discussão, tivemos argumentos contrários sob com alegação de que a inatividade dos autorrevisores poderia burocratizar ainda mais o trabalho dos administradores e burocratas quando eles retornarem ao projeto. Pois bem, com base no registro dos autorrevisores entre 2015 e 2018 que serão apresentados a comunidade no dia 30 de dezembro de 2020, saberemos quem retornou e decidiu contribuir com o projeto, além dos que simplesmente voltaram a registrar sua edição e, em seguida, desapareceram do projeto novamente. Isto refutará a narrativa de que os autorrevisores poderão atrapalhar a ação administrativa pedindo a flag de volta, comprovando-se que os registros de inatividade deverão se repetir ou até aumentar durante o ano de 2020 (até o fim de 2019 tivemos 153 autorrevisores ausentes de 673). Acredito que a redução é necessária, mas é somente com dados estatísticos que o consenso será aplicado e resolverá os argumentos da futurologia. Agora o projeto já possui conhecimento da inatividade destes autorrevisores e, por fim, poderá acompanhar em tempo real toda esta lista que eu desenvolvi em 2019 durante todo o período de 2020. WikiFer msg 05h30min de 19 de janeiro de 2020 (UTC)

Desativar o Projeto Esportes e repassar as atribuições ao Projeto Entretenimento

Problema identificado: o WikiProjeto Desporto é um projeto sem muita atividade. Devagar-quase-parando! Vejam a atividade total dele, ano a ano (totais de tópicos criados):

  1. 2012: 01;
  2. 2013: 22;
  3. 2014: 03;
  4. 2015: 04;
  5. 2016: 04;
  6. 2017: 04;
  7. 2018: 06;
  8. 2019: 03.
  • Total: 47 tópicos, em 8 anos;
  • Média: 06 ao ano.

Para efeito comparativo, as estatísticas do Projeto Entretenimento:

  1. 2012: 14;
  2. 2013: 87;
  3. 2014: 09;
  4. 2015: 05;
  5. 2016: 21;
  6. 2017: 17;
  7. 2018: 11;
  8. 2019: 11.
  • Total: 175 tópicos, em 8 anos;
  • Média: 22 ao ano.

Solução proposta:

  1. desativar;
  2. passar suas atribuições ao Projeto Entretenimento, afinal, os torneios esportivos servem somente para entreter os telespectadores.

--Mister Sanderson (discussão) 22h19min de 9 de janeiro de 2020 (UTC)

Symbol comment vote.svg Comentário Esporte e entretenimento não são a mesma coisa. Na verdade, estão muito longe de ser a mesma coisa.--SirEdimon (discussão) 00h04min de 10 de janeiro de 2020 (UTC)

SirEdimon, mesmo que discorde do ponto 2 ("passar suas atribuições ao Projeto Entretenimento"), gostaria de saber o que pensa sobre o ponto 1 ("desativar").--Mister Sanderson (discussão) 11h26min de 10 de janeiro de 2020 (UTC)

Quem em pleno 2020 se importa se os projetos da Wikipédia em português estão ativos ou não? Seguindo a lógica do proponente, todos os projetos deveriam ser fundidos no projeto aviação, já que todos nós estamos nesta vida só de passagem.

Falando mais sério, no passado foram criados oito "superprojetos" (arte, ciência, ciências sociais, desporto, entretenimento, história e sociedade, música e saúde) justamente para centralizar as discussões de temas minimamente relacionados. A pouca atividade não é culpa de um projeto específico, mas sim da falta de interesse dos poucos usuários ativos que restam nesta enciclopédia. Além de que "sem muita atividade" não significa "abandonado". Enfim, juntar todo tipo de assunto numa baciada só não é a solução. Pedro H. diz×fiz 18h19min de 10 de janeiro de 2020 (UTC)

Pedrohoneto, no dia em que se tornar necessário fundir todos os superprojetos, seria melhor um título "Projeto Curadoria", "Projeto Biblioteconomia", ou "Projeto Manutenção".--Mister Sanderson (discussão) 19h46min de 10 de janeiro de 2020 (UTC)

Symbol comment vote.svg Comentário O que a gente precisa entender é que a Wikipédia tem seus momentos de inatividade em determinados projetos, ou seja, não se pode esperar que todos estejam ativos em cada projeto diferente. A argumentação do Pedrohoneto esclarece muito bem sobre esta questão. WikiFer msg 21h07min de 10 de janeiro de 2020 (UTC)

Sigo a mesma linha de pensamento do Pedrohoneto. A pouca atividade é transversal a projetos e criação de conteúdo. Não é misturando projetos sem relação nenhuma que isso vai mudar. JMagalhães (discussão) 23h03min de 10 de janeiro de 2020 (UTC)

Endosso o comentário de Pedrohoneto. A proposta de transferência+desativação não vai aumentar o interesse por artigos desse tema, tampouco vai melhorar os artigos desse tema. --Luan (discussão) 14h52min de 14 de janeiro de 2020 (UTC)

Sugestão Wikipédia Dark Mode

Sugestão: Wikipédia Dark Mode

O Dark Mode é uma tendência actual, muitas empresas estão a adaptar o seu software com este modo visual.[1][2]

Eu sei que existem soluções não-oficiais de tornar o tema visual do Wikipédia em modo Dark.

Como por exemplo: https://github.com/vitaly-zdanevich/wikipedia-userstyle-dark-minimum

A sugestão seria tornar o método não-oficial para oficial e os utilizadores e/ou visitantes terem uma opção de alterarem o Tema Visual ao seu gosto.

Ao nível do layout a opção ficaria acessível na secção do rodapé da Wikipédia, como também seria adicionado aos 5 temas visuais existentes no menu Preferências - Aparência.

Obrigado, PVieiraCoding @ 11h00min de 14 de janeiro de 2020 (UTC)

Referências

Isso já é possível na app: [1] GoEThe (discussão) 12h10min de 14 de janeiro de 2020 (UTC)
Não seria útil abranger esta opção a versão Web? Obrigado, PVieiraCoding @ 12h17min de 14 de janeiro de 2020 (UTC)
Parece que já há planos para isso: mw:Extension:DarkMode. GoEThe (discussão) 12h30min de 14 de janeiro de 2020 (UTC)
Obrigado pela informação GoEThe. Cumprimentos, PVieiraCoding @ 13h59min de 14 de janeiro de 2020 (UTC)
  • Essa opção é muito confortável para longas leituras, gosto de utilizar especialmente no app do Kindle web . Na Wikipédia, em preferências/gadgets existe uma opção de blackskin com texto em verde claro faz pelo menos dez anos, mas para uso em desktops e notes eu prefiro configurar pelo navegador, o Firefox tem extensões para isso, acredito que o Crome também e o Explorer, bom, quem se importa com o Explorer.Jo Loribd 14h57min de 14 de janeiro de 2020 (UTC)

Proposta de critério de notoriedade para meias e atacantes sem currículo de mata mata no futebol brasileiro

O texto seguinte foi movido de: Wikipédia_Discussão:Critérios_de_notoriedade/Desporto#Proposta de critério de notoriedade para meias e atacantes sem currículo de mata mata no futebol brasileiro


Estava estudando a lista de artilheiros da libertadores e do brasileiro no ano passado e pensei baseado na análise da sequência dos maiores artilheiros do Flamengo agrupados por semelhanças e sequência do primeiro quartil estatístico baseado na moda e na média ponderada para criar um critério de notoriedade específico para qualquer atacante ou meia independente da idade que nunca foi decisivo em um mata mata em que participam times brasileiros, pois é esse nível de jogo que faz que o time não caia para a serie b e que seja decisivo em pontos corridos sem comprometer o time em vários campeonatos ao mesmo tempo:

Esportes coletivos
  • Campeões ou recordistas nacionais;
    • § Para os meias e atacantes do futebol brasileiro que não possuem no seu currículo atuação decisiva em mata mata envolvendo times ligados a CBF se deve ter no mínimo 13 gols em um campeonato brasileiro de pontos corridos no caso de jogadores que começaram a disputar o brasileiro depois de 2003.
  • Todos os que receberam medalha de ouro, prata ou bronze em uma edição de Jogos Olímpicos, jogos continentais, campeonatos mundiais ou campeonatos continentais.
    • Estes critérios são válidos apenas para os desportos reconhecidos internacionalmente pela SportAccord (a antiga GAISF) e pela FIA.
    • Para atletas portadores de necessidades especiais, são válidos os mesmos critérios para os jogos correspondentes.

Para estudo de caso agrupei por características semelhantes os jogadores Bruno Henrique, Arrascaeta e Gabigol e usei como argumento o fato de que o Flamengo está melhorando no entrosamento em pouco tempo, o Flamengo ganhou a libertadores sem comprometer o brasileiro (ao contrário, o que ocorreu foi que o foco do time cresceu e que os desempenhos do time nos 2 campeonatos se estimularam mutualmente) sendo que depois de chegar a final do mundial por exemplo o Internacional demorou 10 anos para cair e ainda por cia sem ganhar brasileiro e que o time carioca chegou a final de um mundial. O que acham? Jacopo Venenoso (discussão) 14h56min de 17 de janeiro de 2020 (UTC)

Symbol declined.svg Discordo da proposta. Os critérios de notoriedade para esporte se refere a todas as modalidades. A sua proposta se limita apenas ao futebol e dá ênfase apenas a "times ligados a CBF", ou seja, é um critério exclusivo para o futebol brasileiro, e não dos demais países, que também possui seu campeonato nacional. Além disso, estabelecer um número mágico de 13 gols no campeonato nacional abriria subjetividade em discussões de eliminação, uma vez que muitos usuários poderiam questionar: por que um jogador que balança as redes 12 vezes durante 38 rodadas do campeonato brasileiro não pode ser considerado um "recordista nacional"? Sua proposta não tende a solucionar os critérios aprovados em 2019, mas criar subjetividade a respeito dos números de gols marcados por um atleta, além de limitar a regra apenas para o futebol brasileiro (os outros países então ficariam de fora), ignorando que o critério se refere a todas as modalidades, sem exceção. WikiFer msg 15h09min de 17 de janeiro de 2020 (UTC)
É que a liga brasileira é melhor do que as ligas da África e América de onde vem a maioria dos jogadores então ela deve ser o critério mínimo. Jacopo Venenoso (discussão) 16h23min de 17 de janeiro de 2020 (UTC)
Jacopo Venenoso Se a liga brasileira é melhor que as demais ligas (o que se encaixa num critério de importância subjetiva SUBJ – um argumento a evitar em discussões de eliminação), não faz sentido ter um critério mínimo, uma vez que o nível técnico do campeonato já dificultaria ainda mais na possibilidade de que haja algum jogador recordista nacional. Para refutar a sua tese, pegamos o exemplo do argentino Germán Cano, que foi artilheiro das últimas quatro edições do campeonato colombiano pelo Independiente de Medellín, fez 41 gols em 47 jogos na temporada de 2019, superando até mesmo o português Cristiano Ronaldo que marcou 39 vezes (ver O Globo Esportes), e graças a esses números o clube Vasco da Gama contratou ele. Isto mostra que o desempenho goleador dele atraiu um time brasileiro, o que deixa bem claro que a liga brasileira não está acima de qualquer outra liga. WikiFer msg 18h13min de 17 de janeiro de 2020 (UTC)

Vou fazer então uma nova proposta:

Esportes coletivos
  • Campeões ou recordistas nacionais;
    • § Para os meias e atacantes do futebol brasileiro que não possuem no seu currículo atuação decisiva em mata mata envolvendo times ligados a CBF se deve ter no mínimo 17[1] gols em qualquer campeonato brasileiro de pontos corridos no caso de jogadores que começaram a disputar o brasileiro depois de 2003.
  • Todos os que receberam medalha de ouro, prata ou bronze em uma edição de Jogos Olímpicos, jogos continentais, campeonatos mundiais ou campeonatos continentais.
    • Estes critérios são válidos apenas para os desportos reconhecidos internacionalmente pela SportAccord (a antiga GAISF) e pela FIA.
    • Para atletas portadores de necessidades especiais, são válidos os mesmos critérios para os jogos correspondentes.

Referências

  1. Usando como critério de notoriedade a comparação entre Aristizábal que fez 5 gols na copa do Brasil de 2003 do cruzeiro e comparar com a posição de Luis Fabiano no brasileiro e copa do Brasil de 2012 além de descartar Arrascaeta

Melhorou os critérios? Jacopo Venenoso (discussão) 16h22min de 17 de janeiro de 2020 (UTC)

É que quem faz 17 gols no Brasileiro uma hora vai ganhar mata mata e/ou pontos corridos; e/ou ser recordista em alguma competição. Muitos jogadores sequer foram para seleção e por terem artigos na wikipedia são capitães de times grandes como no caso do Soteldo ou ganham salários altos com apoio da torcida como no caso do Sassá. Também deve-se considerar que o campeonato brasileiro as vezes é inferior ao europeu e o fato da liga argentina ser menos competida por exemplo isso faz que ele possam focar mais em mata mata continentais já que poucos times são fortes nas ligas vizinhas ao contrário do brasileiro que é mais equilibrado na disputa. Jacopo Venenoso (discussão) 16h31min de 17 de janeiro de 2020 (UTC)
Jacopo Venenoso O critério atual não exige que o jogador seja artilheiro de um torneio de pontos corridos para ser considerado um "recordista nacional". Se este fazer o maior número de hat-tricks de um campeonato nacional na história (ou pelas últimas décadas), se fazer dos maiores números de gols de falta (ou de pênaltis) no torneio, se for um dos mais indisciplinados (em números de cartões vermelhos), tudo isso pode servir de argumentação como "recordista nacional". O seu critério busca limitar a possibilidade de um jogador de futebol ter artigo na Wikipédia, pois não precisa fazer no mínimo 17 gols em pontos corridos para receber tal critério. Além disso, volto a afirmar: os critérios de notoriedade são para todas as modalidades, e quando eu digo todas as modalidades, envolve de todos os países, sem exceção. Você quer criar uma regra que seria válida apenas para o futebol brasileiro, o que não se encaixaria com o intuito destes critérios. WikiFer msg 18h13min de 17 de janeiro de 2020 (UTC)
Mas é mérito ter mais cartões vermelhos? Se for, se acrescenta como outro critério de notoriedade, nada em prejuízo. E segundo Bruno Formiga, é muito fácil fazer gol de pênalti, difícil é escanteio. Jacopo Venenoso (discussão) 18h27min de 17 de janeiro de 2020 (UTC)
Um jogador indisciplinado traria notoriedade pelo jeito explosivo que ele é, não pelos gols marcados em campo. Ser "recordista nacional" é existir a comprovação de que este jogador trouxe algum feito notável que atrai os veículos de imprensa, o que é necessário para cumprir com o critério geral de notoriedade. Quanto a gol de pênalti, você diz que é fácil, mas eu disse o jogador que mais fez gols de pênalti num campeonato, não quem apenas faz, é diferente. Se pênalti é tão fácil, a concorrência pelo posto de quem mais balançou as redes com gols de pênalti na temporada será maior. E como você mesmo afirmou, fazer gol olímpico é mais difícil, o que daria a oportunidade para alguém ser "recordista nacional" por gols olímpicos. WikiFer msg 18h34min de 17 de janeiro de 2020 (UTC)
É estatisticamente + difícil passar na federal em jornalismo do que fazer gol de pênalti. Jacopo Venenoso (discussão) 18h39min de 17 de janeiro de 2020 (UTC)
Eu te garanto que passar na federal em jornalismo é tão concorrido quanto ser o maior artilheiro da temporada com gols de pênalti. Não adianta só "fazer gol de pênalti", tem que ser um dos que mais fizeram, é diferente. Ser "recordista nacional" significa isso. WikiFer msg 18h42min de 17 de janeiro de 2020 (UTC)
Tem estudos de pênalti em que a posição do chute se o atacante souber bater faz que a chance de defesa do goleiro seja 0. Então não é tão difícil se a pessoa tiver treinamento e explosão física. E o cara pode ser artilheiro em qualquer ano, não precisa ser todos os anos. E no bem da verdade, eu tinha condições de passar na federal em jornalismo e nem por isso tenho artigo aqui Jacopo Venenoso (discussão) 18h48min de 17 de janeiro de 2020 (UTC)
Essa possibilidade só existe quando um jogador consegue converter o pênalti pelo alto (Aránguiz contra o Brasil). Não é algo que todos podem ter, só que o fato de ser recordista requer números, estatísticas, não apenas saber converter pênaltis. E sim, se um jogador foi recordista numa única temporada, ele já considerado notável por isso e teria artigo na Wikipédia. WikiFer msg 18h55min de 17 de janeiro de 2020 (UTC)
Qual é o seu critério mínimo de conversão de pênaltis então? Ganso se não tivesse curriculo p/ exemplo não seria notório pois errou pênalti contra o Fabio rebaixado. Jacopo Venenoso (discussão) 19h01min de 17 de janeiro de 2020 (UTC)
Eu não estou propondo nenhuma alteração nos critérios, apenas exemplificando para você o significado de "recordistas nacionais", critério que não se encaixa apenas em pênaltis, mas em qualquer outro exemplo que eu já expliquei acima. E novamente repito: este critério não é válido só para futebol e muito menos para o futebol do Brasil, todos os esportes faz jus de WP:ESPORTISTAS. Nos esportes coletivos, seja campeão ou recordista nacional ou ter ganho medalha de ouro, prata ou bronze em qualquer campeonato continental para cima se encaixa nos critérios. WikiFer msg 19h09min de 17 de janeiro de 2020 (UTC)

Isso é sério? Os critérios de notoriedade necessitam abranger um contexto geral. A proposta se limita ao cenário brasileiro com um argumento ultrapassado de números mágicos.

O fulano marca n gols e tem notoriedade pelo o quê mesmo? Outra proposta que visa agregar a aceitação de qualquer biografia de futebolista brasileiro. Enquanto aos jogadores portugueses? Isso nem deveria ser levado a sério. Edmond Dantès d'un message? 23h19min de 17 de janeiro de 2020 (UTC)

Esta proposta só pode ser uma piada. Meias e atacantes, e ainda por cima nos "mata mata" [sic]? O que vem depois? Critério para goleiros nas fases de grupos? Critérios para atacantes que erram pênaltis? Acaso o projeto virou "Futepédia" agora? Como falar em critério para posições do futebol se WP:DESPORTISTAS nem tem critério para futebolistas? Ora, faça-me o favor! Yanguas diz!-fiz 14h22min de 18 de janeiro de 2020 (UTC)

Symbol declined.svg Discordo de todas as propostas. São confusas, desnecessárias, de pouca utilidade para uma enciclopédia. A palavra "decisivo", por exemplo, qual critério para se dizer que tal jogador foi decisivo ou não? Além disso, não abrange jogadores de outras nacionalidades e competições. Ademais, não há muitos "mata-matas" no futebol brasileiro. ✍️A.WagnerC (discussão) 04h28min de 26 de janeiro de 2020 (UTC)

Adoção de novas secções a WP:N

Wikipédia:Critérios de notoriedade é uma recomendação da Wikipédia que trata de "estabelecer que tipos de artigos deverão ser considerados relevantes". No entanto, em comparação com en:WP:N, a recomendação na Wikipédia não possui certas secções que acredito que seriam úteis, por explicarem e estabelecerem bem o escopo da recomendação. Assim, proponho a adoção dessas secções restantes.

As secções a serem consideradas são:

  • "Notability guidelines do not apply to content within an article",
  • "Article content does not determine notability",
  • "Notability requires verifiable evidence",
  • "Notability is not temporary",
  • "Notable topics have attracted attention over a sufficiently significant period of time",
  • "Whether to create standalone pages",
  • "Why we have these requirements",
  • "Common circumstances",
  • e "Articles not satisfying the notability guidelines".

A meu ver nenhuma das secções mencionadas que não estão atualmente na ptwiki contradiz qualquer política ou recomendação já existente. Assim, a expansão de WP:N com a adoção de tais secções beneficiariam a ptwiki.

Nota: Esta proposta tem somente a intenção de adicionar conteúdo a WP:N, e não tem a intenção de alterar ou remover qualquer outra política ou recomendação existente na Wikipédia. A única secção existente que seria alterada é "Quando criar páginas próprias", mas nenhum texto existente naquela secção seria removido ou modificado, apenas (algumas peças de) texto da secção "Whether to create standalone pages" seria adicionado, conforme decisão da comunidade. --CaiusSPQR(discussão) 21h33min de 19 de janeiro de 2020 (UTC)

O argumento para a adoção é um mero "existe na anglófona, então por que não adote aqui?" Quais são as questões que apontam na Wikipédia lusófona? Os critérios de notoriedade gerais é sucinto, coeso e claro. Edmond Dantès d'un message? 20h16min de 23 de janeiro de 2020 (UTC)

@Conde Edmond Dantès: WP:N basicamente apenas diz quais são os critérios de notoriedade, mas não fala sobre questões como artigos que não satisfazem os critérios de notoriedade, que é algo mencionado na WP:Política de eliminação, mas que a WP:N não discorre sobre. Também as secções, por mais que algumas sejam curtas, não discorrem sobre o escopo de WP:N, ou explica porque existe, ao contrário de WP:BPV, uma política que fundamenta sua existência. Ademais, as secções esclarecem ao que WP:N se aplica (a tópicos, no caso), enquanto a atual recomendação não o faz. --CaiusSPQR(discussão) 00h23min de 24 de janeiro de 2020 (UTC)
Não compreendo seu argumento. Edmond Dantès d'un message? 01h41min de 24 de janeiro de 2020 (UTC)

@CaiusSPQR: É complicado e pouco claro avaliar algo assim "no escuro". Porque não cria um ensaio primeiro? Eu (e provavelmente muitos outros) se sentiriam mais confortáveis para dar opiniões. ━ ALBERTOLEONCIO Who, me? 01h38min de 24 de janeiro de 2020 (UTC)

Eu também não estou disposto a avaliar a proposta enquanto o texto proposto não estiver claramente declarado.--Mister Sanderson (discussão) 16h19min de 24 de janeiro de 2020 (UTC)

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


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)

Symbol support vote.svg 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)

Symbol comment vote.svg 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)

Symbol comment vote.svg 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 Symbol support vote.svg 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)

Symbol comment vote.svg 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)

Symbol support vote.svg 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)

Symbol support vote.svg Concordo. Poderia ter alguns requisitos a mais, como tempo com a ferramenta de reversão ou autorrevisão. EVinentefale comigo 01h25min de 20 de janeiro de 2020 (UTC)

Symbol support vote.svg 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 Symbol support vote.svg 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)

Symbol support vote.svg 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)

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

Symbol support vote.svg Concordo. Pedro H. diz×fiz 17h28min de 20 de janeiro de 2020 (UTC)

Symbol declined.svg 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)
  • Symbol support vote.svg Concordo Não resolve, mas ajuda. José Luiz disc 03h02min de 21 de janeiro de 2020 (UTC)

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)

Symbol support vote.svg 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)

Symbol neutral vote.svg 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 Symbol support vote.svg 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)

Symbol support vote.svg 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)

Symbol support vote.svg 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)

Symbol support vote.svg 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, Yes check.svg Feito. Opinei sobre todas as propostas aqui apresentadas. Micael D. Oi, meu chapa! 13h47min de 25 de janeiro de 2020 (UTC)

Symbol support vote.svg 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)

Symbol support vote.svg 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)

Symbol support vote.svg 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)

Symbol support vote.svg 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)

Symbol comment vote.svg 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)

Symbol support vote.svg 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)

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;

-- EVinentefale comigo 14h54min de 20 de janeiro de 2020 (UTC)

Symbol support vote.svg 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)

Symbol support vote.svg 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)

Symbol support vote.svg 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)

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

Symbol support vote.svg 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)

Symbol declined.svg 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)

Symbol declined.svg 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)

Symbol declined.svg 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)

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

  • Symbol support vote.svg 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)

Symbol support vote.svg 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)

Symbol declined.svg 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)

Symbol comment vote.svg 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 Symbol declined.svg 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)

Symbol declined.svg 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)

Symbol declined.svg 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)

Symbol declined.svg 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)

Symbol comment vote.svg 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)

Symbol declined.svg 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 Symbol neutral vote.svg 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)

Symbol declined.svg 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)

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)

Symbol comment vote.svg 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 [2], mas não parece ser possível. GoEThe (discussão) 11h19min de 28 de janeiro de 2020 (UTC)

Symbol support vote.svg 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)

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

Symbol support vote.svg Concordo com a proposta final. Vanthorn® 04h31min de 25 de janeiro de 2020 (UTC)

Symbol support vote.svg Concordo com a proposta final. Micael D. Oi, meu chapa! 13h45min de 25 de janeiro de 2020 (UTC)

Symbol support vote.svg 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 Symbol declined.svg 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 Symbol neutral vote.svg 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)

Symbol comment vote.svg 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)

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

Symbol comment vote.svg 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)

Symbol oppose vote.svg 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)

Symbol comment vote.svg 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, Symbol support vote.svg 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)

Poderiam fazer uma gincana aqui ao estilo #wikifontes sobre filosofia e história

@Bafuncius e Xavier1824: Como vejo que vocês são os editores mais ativos nesse tema podemos dar continuidade ao desafio depois do wikifontes. Filosofia é o tema que gera mais artigos e dá mais acessos aqui junto com história então proponho isto. Jacopo Venenoso (discussão) 15h58min de 20 de janeiro de 2020 (UTC)

Como o título não pegou, aqui o transcrevo:"fazer uma gincana ao estilo #wikifontes sobre filosofia e história". Jacopo Venenoso (discussão) 16h00min de 20 de janeiro de 2020 (UTC)
Oi Jacopo Venenoso! Sou novato aqui no projeto, gosto de mexer mais no tema de filosofia sim por contato pessoal meu com a área e acabo editando algumas por hobby de vez em quando, mas com certeza não sou um dos mais ativos! Se buscar no histórico dos principais artigos, tem vários outros usuários veteranos que precederam todo o trabalho e continuam editando até hoje. Eu também não tenho competência técnica para definir uma gincana nesse estilo, mas se alguém puder criar, ficarei feliz de participar também. Acho que é uma boa proposta esse desafio, muitos artigos dos dois temas ainda precisam de mais fontes de qualidade e informações acessíveis. Tudo de bom! Bafuncius (discussão) 16h14min de 20 de janeiro de 2020 (UTC)

Uniformizar títulos e conteúdos de artigo.

Para facilitar a navegação pela Wikipédia e unificá-la , deveríamos uniformizá-la. Por exemplo, há artigos que dão uma breve introdução ao assunto e listam os parques nacionais de países, porém, há artigos com título de "Parques nacionais de xxx" e há artigos com título de "Lista de parques nacionais de xxx". Uniformizar os títulos seria definir que o primeiro exemplo deve ser igual ao segundo e vice-versa.

Davi Moura Araújo (Aracaju, Sergipe) (discussão) 20h21min de 27 de janeiro de 2020 (UTC)

Fim do mandato para verificadores

Olá. Proponho que acabemos com o trecho de Wikipédia:CheckUser/Candidaturas que determina um mandato de um ano de uso da ferramenta de verificação para administradores que foram eleitos para o cargo. Além de já termos um processo de eleição bastante rígido, temos também regras rigorosas sobre a perda da ferramenta em caso de mau uso, que, além de abusos, abrangem casos de inatividade e preveem que aquele que porventura perder o estatuto de checkuser também seja obrigado a ser reavaliado pela comunidade nos cargos de sysop e burocrata. Ademais, temos um problema crônico de falta de verificadores na Wikipédia lusófona e excessos burocráticos como esses em nada ajudam. Pelo o que pude pesquisar, o assunto não é debatido desde 2009, quando a realidade da pt.wiki era outra. Em suma, proponho que os trechos em negrito sejam apagados:

  • Os usuários interessados em obter o estatuto de CheckUser (verificador de contas) deverão ter, pelo menos, 18 anos de idade, estar explicitamente acima da idade a partir da qual podem atuar sem o consentimento paternal na área de jurisdição da sua residência e assinar o acordo de confidencialidade para informações não públicas, de maneira a que possam ser qualificáveis para utilizar a ferramenta.
  • Os usuários devem ser escolhidos por votação.
  • O número de verificadores de contas não é limitado, porém, espera-se bom senso da comunidade para não dar a muitos usuários o acesso a informações privadas.
  • Somente administradores podem obter o estatuto de verificador de contas.
  • A perda do estatuto de administrador implica a perda imediata e automática do estatuto de verificador de contas.
  • O período de atuação dos verificadores de contas está limitado a 1 (um) ano.
  • Não há limite de renovações de mandato.
  • Os usuários interessados em obter o acesso podem criar a página com o pedido de aprovação para si próprios ou ser indicados por terceiros.

Chronus (discussão) 22h07min de 27 de janeiro de 2020 (UTC)

Chronus, de que forma o mandato de 1 ano causa o alegado problema crônico de baixo número de verificadores? Por acaso deixar mandato por tempo indeterminado vai aumentar o número de editores que se candidatam?--Mister Sanderson (discussão) 22h10min de 27 de janeiro de 2020 (UTC)
@MisterSanderson: Mas eu não disse que é o mandato a causa do evidente problema crônico do baixo número de verificadores. O raciocínio é simples: se temos poucos verificadores e o cargo têm atraído poucos candidatos, porque gastar o tempo e a energia da comunidade para reavaliar, todos os anos, os poucos administradores já considerados confiáveis e que podem ser desestimulados a continuar a exercer a função? Não faz sentido. Isso que chamei de "excesso burocrático". Chronus (discussão) 22h15min de 27 de janeiro de 2020 (UTC)
Para evita que o Quintinense consiga uma conta de verificador, talvez? Há alguns anos houve um verificador pego com conduta imprópria e expulso do cargo logo depois de voltar de um período de inatividade. Agora esses períodos de inatividade, nos quais um editor "muda de ideia" e dá a conta pra um fantocheiro vão virar regra, Chronus? --Mister Sanderson (discussão) 22h17min de 27 de janeiro de 2020 (UTC)
@MisterSanderson: Do que você está falando? A regra de remoção de acesso da ferramenta já determina: "qualquer verificador que esteja inativo por mais de um ano poderá ter seu acesso removido." Dá na mesma de estabelecer um mandato de um ano, não? Qual é a sua preocupação? Chronus (discussão) 22h21min de 27 de janeiro de 2020 (UTC)
Chronus, estar inativo significa não realizar nenhuma edição da Wikipédia? Critério muito frouxo para garantir a lealdade do verificador à Wikipédia. Um verificador poderia passar anos fazendo 1 correção ortográfica ao mês e passaria anos com o estatuto, segundo a regra de remoção de acesso. Mas nunca seria reeleito assim. É esse tipo de caso que me preocupa, gente que não tem mais interesse e comprometimento com a Wikipédia, mas ainda detém estatutos.--Mister Sanderson (discussão) 22h31min de 27 de janeiro de 2020 (UTC)

───────────────────────── @MisterSanderson: Citação: MisterSanderson escreveu: «Chronus, estar inativo significa não realizar nenhuma edição da Wikipédia?» A regra não diz explicitamente isso. Eu, por exemplo, interpretei como "inativo no uso da ferramenta". Em todo o caso, podemos mudar a frase de Wikipédia:CheckUser#Remoção de acesso de:

Qualquer verificador que esteja inativo por mais de um ano poderá ter seu acesso removido.

para:

Qualquer verificador que não use a ferramenta por mais de um ano terá seu acesso removido.

O que acha? Chronus (discussão) 22h36min de 27 de janeiro de 2020 (UTC)

Chronus, com essa proposta eu Symbol support vote.svg Concordo. Pode-se criar uma seção separada para ela, a fim dos demais participantes não se confundirem sobre qual proposta estão comentando?--Mister Sanderson (discussão) 22h37min de 27 de janeiro de 2020 (UTC)
Mas são propostas interligadas, MisterSanderson. A especificação sobre que tipo de inatividade estamos a falar no caso de perda de acesso da ferramenta é justamente para evitar a manutenção do mandato de um ano. Chronus (discussão) 22h54min de 27 de janeiro de 2020 (UTC)
Cabe salientar na proposta que os registros do uso da ferramenta de verificação é restrito aos verificadores, stewards e Ombudsmen, de modo que essa forma de mensuração fica limitada, a menos que possamos aprovar um meio de aferição (por exemplo solicitar a um steward que confirme a atuacao) para se manter a ferramenta. EVinentefale comigo 01h46min de 28 de janeiro de 2020 (UTC)

Symbol declined.svg Discordo Não percebo burocracia demasiada: como o proponente percebeu são poucos editores no cargo (três), digamos que dobre, é literalmente meia dúzia de revalidações por ano, para uma ferramenta que dá acesso aos dados de acesso dos editores do projeto, que me parece bom que seja revalidada periodicamente. As coisas parecem estar andando bem e esse item não me parece empecilho a novas candidaturas. O que acho que podemos fazer, e lembro de ter lido um comentário de que já estaria sendo feito por alguns, é convidar mais pessoas para o cargo, e não apenas isso, como também incentivar usuários ativos e bons a trabalhar não apenas no domínio principal, mas também com as ferramentas administrativas (reversor, administrador, para que eventualmente sejam bons candidatos a checkuser). Saturnalia0 (discussão) 01h11min de 28 de janeiro de 2020 (UTC)

@Saturnalia0: Como "as coisas parecem estar andando bem" se só temos três editores no cargo? E qual é a necessidade desse mandato de um ano se qualquer verificador perde a ferramenta automaticamente em caso de abuso ou inatividade? Além de inútil, esse mandato é redundante em relação ao período de inatividade imposto pela regra de remoção de acesso ao recurso, que já estabelece o período de um ano. De qualquer forma, boa sorte com os "convites" e "incentivos de usuários ativos e bons", parece que está dando resultado. O nosso trio de verificadores que o diga... Chronus (discussão) 01h48min de 28 de janeiro de 2020 (UTC)
As votações me parecem andar bem e não me parecem ser empecilho a novas candidaturas. Por que seriam? Considero-as importantes não como complemento a regras sobre inatividade, mas pelo caráter de revalidação, como expliquei. Saturnalia0 (discussão) 02h05min de 28 de janeiro de 2020 (UTC)
E quanto a aumentar o período do mandato para 2 anos, conforme proposto pelo EVinente abaixo, também discorda? Chronus (discussão) 02h12min de 28 de janeiro de 2020 (UTC)

Acho que o tempo de mandato poderia ser expandido de 1 pra 2 anos. Me parece aceitável. EVinentefale comigo 01h42min de 28 de janeiro de 2020 (UTC)

@EVinente: E remover qualquer mandato com tempo preestabelecido não lhe parece "aceitável" por qual motivo? Chronus (discussão) 01h49min de 28 de janeiro de 2020 (UTC)
Pela razão que acredito que uma revalidação é uma forma de se "prestar contas" a comunidade sobre o trabalho, bem como permitir que se possa ser discutido a atuação do verificador. Concordo que um ano, para os padrões que temos agora, é enfadonho, então aumentar esse tempo em que temos que passar avaliando o verificador é algo aceitável. EVinentefale comigo 01h54min de 28 de janeiro de 2020 (UTC)
@EVinente: Nesse caso, repito a pergunta que fiz ao Saturnalia: qual é a necessidade desse mandato de um ano se qualquer verificador perde a ferramenta automaticamente em caso de abuso ou inatividade? A "prestação de contas" é feita diariamente, através do trabalho apresentado pelos verificadores. Não há necessidade de uma votação anual para atestar o bom ou mau trabalho deles. Chronus (discussão) 01h56min de 28 de janeiro de 2020 (UTC)
Por isso que coloco um prazo maior. Me parece adequado que tenhamos um prazo, não mais de um ano. Até porque não temos um conselho de arbitragem que teria um respaldo maior para se promover checkusers por tempo maior. Lembro que até stewards passam por confirmações anuais. EVinentefale comigo 02h01min de 28 de janeiro de 2020 (UTC)
@EVinente: Você não respondeu ao meu questionamento acima. E, portanto, ainda não entendi qual é a utilidade prática da manutenção de um mandato com tempo preestabelecido. Mas ok. Se houver grande resistência ao fim do mandato, Symbol support vote.svg Apoio a sua proposta de ampliá-lo para dois anos. Dos males, o menor. Chronus (discussão) 02h09min de 28 de janeiro de 2020 (UTC)

───────────────────────── @OnlyJonny, RadiX, Teles, Jbribeiro1, Lord Mota, Érico, Biologo32, Stegop, Tks4Fish, Stanglavine, Tuga1143, Millennium bug e HVL: Vocês que exercem ou já exerceram o cargo de verificador, o que acham da proposta? Chronus (discussão) 02h09min de 28 de janeiro de 2020 (UTC)

Symbol declined.svg Discordo Verificadores e supressores manejam com informações sensíveis, e com isso, é preciso que a comunidade tenha total confiança neles, e a melhor maneira de se averiguar isso é a partir de votações periódicas, onde os usuários podem averiguar sua conduta, se o mesmo usou a ferramenta com frequência, tal como outras coisas que não poderiam ser usadas como motivo num pedido de desnomeação (por mais que já tenham tentado), o que permitiria que o mesmo permanecesse mesmo sendo mal visto por todos, tal como pode acontecer com os administradores. Mas não me oponho em ampliar para 2 anos. Mr. Fulano! Fale 02h19min de 28 de janeiro de 2020 (UTC)

Proposta 2: ampliação do período de mandato de verificadores e supressores e definição de "inatividade"

Visto que alguns editores se sentem mais confortáveis em avaliar periodicamente os verificadores, ao invés de deixá-los exercer um mandato sem período de tempo predeterminado, resolvi "refinar" a proposta que fiz acima.

Em Wikipédia:CheckUser/Candidaturas e Wikipédia:Supervisão/Candidaturas, sugiro a seguinte alteração (em negrito):

  • Os usuários interessados em obter o estatuto de CheckUser/Oversight deverão ter, pelo menos, 18 anos de idade, estar explicitamente acima da idade a partir da qual podem atuar sem o consentimento paternal na área de jurisdição da sua residência e assinar o acordo de confidencialidade para informações não públicas, de maneira a que possam ser qualificáveis para utilizar a ferramenta.
  • Os usuários devem ser escolhidos por votação.
  • O número de verificadores/supervisores de contas não é limitado, porém, espera-se bom senso da comunidade para não dar a muitos usuários o acesso a informações privadas.
  • Somente administradores podem obter o estatuto de verificador de contas/supervisor.
  • A perda do estatuto de administrador implica a perda imediata e automática do estatuto de verificador de contas/supervisor.
  • O período de atuação dos verificadores de contas/supervisores está limitado a 2 (dois) anos.
  • Não há limite de renovações de mandato.
  • Os usuários interessados em obter o acesso podem criar a página com o pedido de aprovação para si próprios ou ser indicados por terceiros.

Em Wikipédia:CheckUser#Remoção de acesso, sugiro a seguinte alteração (em negrito):

Qualquer verificador que não use a ferramenta por mais de seis meses terá seu acesso removido após a inatividade na função ser confirmada por um steward ou por outro verificador.

Em Wikipédia:Supervisão#Remoção do acesso, sugiro a seguinte adição:

Qualquer supressor que não use a ferramenta por mais de seis meses terá seu acesso removido após a inatividade na função ser confirmada por um steward ou por outro supressor.


@EVinente, Saturnalia0, Mr. Fulano e MisterSanderson: O que acham da nova proposta? Chronus (discussão) 02h32min de 28 de janeiro de 2020 (UTC)

Symbol support vote.svg Concordo Acredito que um aumento para dois anos pode ser até benéfico para a comunidade. Mas acredito que o período de inatividade deveria ser menor, tipo 6 meses, assim como é para os administradores. Isso evita que a ferramenta fique na mão de alguém que não a utiliza. Mr. Fulano! Fale 02h39min de 28 de janeiro de 2020 (UTC)

Symbol support vote.svg Concordo. Nós já tivemos algumas discussões sobre esse assunto nos últimos anos. Em todas, me manifestei no sentido de acabar com os mandatos para verificadores de contas e supressores.

É verdade que a Wikipédia em Português possui suas particularidades. No entanto, não considero-as suficientes para que sejamos a única wiki onde verificadores e supressores possuem mandato; ainda mais tão curto.

Assim, concordo com a proposta de aumentar o mandato para 2 anos, como solução de compromisso.

No entanto, tenho algumas observações:

i) esta regra deveria ser aplicada também aos supressores. Não vejo qualquer motivo para a distinção;
ii) que passe a valer apenas aos verificadores e supressores aprovados a partir de agora, de modo a evitar acusações de se tratar de um intento casuísta.

Érico (disc.) 04h45min de 28 de janeiro de 2020 (UTC)

@Érico e Mr. Fulano: Symbol support vote.svg Apoio ambas as sugestões. Alterei o texto da proposta. Chronus (discussão) 09h26min de 28 de janeiro de 2020 (UTC)

Symbol support vote.svg Concordo com a proposta. EVinentefale comigo 10h20min de 28 de janeiro de 2020 (UTC)

Symbol support vote.svg Concordo com esta proposta, que reflete o meio-termo, bem como o adendo do Érico, ou seja, aumenta para dois anos ex nunc. Millennium bug 10h48min de 28 de janeiro de 2020 (UTC)

Em que pese eu ser verificador e supressor, acredito que o mandato deveria ser, sim, removido, tendo em vista que somos o único projeto com esta particularidade. No entanto, Symbol support vote.svg concordo com esta proposta, que ajuda na situação. —Thanks for the fish! talkcontribs 15h12min de 28 de janeiro de 2020 (UTC)

Symbol support vote.svg Concordo com o proposto, muito embora eu não discordasse do fim do mandato. --HVL disc. 16h25min de 28 de janeiro de 2020 (UTC)

Symbol support vote.svg Concordo com a proposta 2. Determina mandato de dois anos para supervisores e verificadores, além de estabelecer um prazo de até seis meses para que não seja destituído a ferramenta por inatividade na função, assim evita que estes usuários não deixam de usar a flag durante o mandato. WikiFer msg 19h43min de 28 de janeiro de 2020 (UTC)

Atualização do texto de WP:ATAQUEOFFWIKI

Olá. Diante das graves revelações trazidas à tona por duas discussões de bloqueio (vide aqui e aqui), sugiro que façamos uma atualização do texto de WP:ATAQUEOFFWIKI, principalmente porque não temos mais um conselho de arbitragem.

O texto atual diz o seguinte:

A Wikipédia não pode regular comportamento em meio que não esteja sob controle da Wikimedia Foundation, mas ataques pessoais feitos em qualquer outro lugar criam dúvida sobre se as ações internas de um editor são conduzidas em boa-fé. Postar ataques pessoais ou difamações fora da Wikipédia é danoso à comunidade e ao relacionamento de um editor com ela, especialmente quando tais ataques violam a privacidade de outro editor. Tais ataques podem ser vistos como fatores agravantes por administradores e são evidências aceitas em processos de resolução de disputas, incluindo casos de arbitragem.

Atenção: ligações externas para conteúdo assediante, ofensivo ou que viole a privacidade de editores da Wikipédia são inaceitáveis. A inserção de ligações externas desta natureza é considerada endosso do seu conteúdo.

A alteração que proponho está em negrito:

A Wikipédia não pode regular comportamento em meio que não esteja sob controle da Wikimedia Foundation, mas ataques pessoais feitos em qualquer outro lugar criam dúvida sobre se as ações internas de um editor são conduzidas em boa-fé. Postar ataques pessoais ou difamações fora da Wikipédia é danoso à comunidade e ao relacionamento de um editor com ela, especialmente quando tais ataques violam a privacidade de outro editor. Tais ataques podem ser vistos como fatores agravantes por administradores e são evidências aceitas em processos de resolução de disputas e discussões de bloqueio, principalmente se forem proferidos nos canais externos de comunicação definidos pela comunidade.

Atenção: ligações externas para conteúdo assediante, ofensivo ou que viole a privacidade de editores da Wikipédia são inaceitáveis. A inserção de ligações externas desta natureza é considerada endosso do seu conteúdo.

Chronus (discussão) 22h17min de 27 de janeiro de 2020 (UTC)

@79a, Renato de carvalho ferreira, Editor D.S, Conde Edmond Dantès, Yanguas, JMagalhães, Fabiojrsouza, EVinente, OnlyJonny, Tuga1143, Leefeni de Karik, HVL, Fronteira, Pedrassani, Rodrigo Padula, Stegop, Érico, Ricardo Ferreira de Oliveira e Vanthorn: Como participaram das DBs que mencionei acima, sugiro que também participem dessa discussão. Chronus (discussão) 23h49min de 27 de janeiro de 2020 (UTC)

Chronus, o que garante que uma evidência offwiki não seria objeto de black propaganda?--Mister Sanderson (discussão) 22h27min de 27 de janeiro de 2020 (UTC)
@MisterSanderson: Isso está relacionado com a minha proposta exatamente em qual aspecto? Chronus (discussão) 22h30min de 27 de janeiro de 2020 (UTC)
Não é óbvio? Sua proposta abre margem para bloqueios baseados em provas forjadas.--Mister Sanderson (discussão) 22h32min de 27 de janeiro de 2020 (UTC)
@MisterSanderson:, se a alteração proposta foca-se "principalmente se forem proferidos nos canais externos de comunicação", como daria para eu forjar num canal externo algo que você disse sem nunca ter dito? Estaria lá a sua mensagem escrita por si... certo? Ou refere-se a uma pessoa que crie uma conta, nesse canal, com o seu nome e comece a falar um monte de asneiras? Luís Almeida "Tuga1143 22h42min de 27 de janeiro de 2020 (UTC)
Tuga1143, seu primeiro argumento é falho pois as mensagens podem ser apagadas. Se alguém faz um ataque e depois apaga a mensagem, como vai-se provar que o ataque foi feito? Similarmente, se alguém digita algo errado e depois apaga a mensagem, e outro usuário aparece com uma captura de tela, quem garantirá que a captura de tela não foi forjada, se a mensagem original foi obliterada? A Wikipédia tem um histórico "inapagável", que no máximo pode ser ocultado pelos oversighters, mas não é assim no resto da internet.
O seu segundo argumento foi certeiro: há contas fakes em redes sociais que já foram apontadas em discussões de bloqueio como pertencendo a "fulano que já foi banido", ou "ciclano que deve ser banido", embora os nomes das contas não permitissem identificar, mas quem garante? O Facebook, o WhatsApp, o Telegram vão fornecer dados pessoais de seus usuários para os verificadores da Wikipédia? Nunca, nem sob processo judicial! E o contrário: e quando o nome permite identificar claramente, quem vai garantir que a conta foi criada pela própria pessoa, ou por um inimigo da pessoa caçando um bloqueio? Nesse cenário, imagine se o Chico tivesse criado uma conta fake com o seu nome, Tuga, para comprovar a teoria mirabolante dele? Poderia ter sido você o quase-banido, ao invés dele.
Essa proposta do Chronus, embora bem-intencionada, é perigosíssima!--Mister Sanderson (discussão) 22h49min de 27 de janeiro de 2020 (UTC)
Não há perigo, MisterSanderson. Como bem disse o Tuga1143, a alteração proposta foca-se "principalmente se forem proferidos nos canais externos de comunicação", que são públicos e, portanto, podem ser acessados por diferentes pessoas que, inclusive, podem testemunhar a veracidade do ataque off-wiki em questão. Chronus (discussão) 23h04min de 27 de janeiro de 2020 (UTC)
Há perigo, Chronus:
  1. o fato de serem meios de visibilidade pública não impede o uso de contas fakes para propaganda negra, ou seja, meu argumento exposto ao Tuga1143 permanece irrefutado;
  2. o fato de serem meios de visibilidade pública não impede que mensagens sejam deletadas, ou seja, meu argumento exposto ao Tuga1143 permanece irrefutado;
  3. "principalmente" não é sinônimo de "exclusivamente", o que significa que meios não aprovados previamente pela comunidade são aceitos pelo texto da sua proposta. Alguém pode fazer um w:en:domain squatting no meu blog pessoal e assim, passando-se por mim, escrever ofensas que me garantiriam o banimento da Wikipédia.
Consequentemente, sou Symbol oppose vote.svg Contra sua proposta.--Mister Sanderson (discussão) 23h11min de 27 de janeiro de 2020 (UTC)

───────────────────────── @MisterSanderson: Amigo, a "minha" proposta apenas explicita melhor algo que já está em vigor, visto que WP:ATAQUEOFFWIKI já abrange ataques proferidos nos meios não aprovados previamente pela comunidade. Além disso, atente-se para o fato de que "tais ataques podem ser vistos como fatores agravantes por administradores e são evidências aceitas em processos de resolução de disputas e discussões de bloqueio". Em suma, ninguém será bloqueado simplesmente porque fez, em uma determinada ocasião, um ataque off-wiki. Isso só será interpretado como um motivo complicador dentro do contexto de uma discussão de bloqueio, ou seja, em casos onde o editor em questão já tem histórico nesse tipo de conduta tóxica. Chronus (discussão) 23h23min de 27 de janeiro de 2020 (UTC)

Não é verdade, Chronus, que Citação: WP:ATAQUEOFFWIKI já abrange ataques proferidos nos meios não aprovados previamente pela comunidade. Atualmente, é dito lá que ataques offwiki são evidências aceitas em arbitragem, não em bloqueio. Bloqueio e arbitragem não são a mesma coisa. Minha oposição é por sua proposta tornar regra o uso de mensagens offwiki como motivo para bloqueios, quando deveriam ser exceção, já que os administradores que vão se manifestar sobre o bloqueio não têm forma de comprovar a autenticidade das provas apresentadas. É melhor absolver mil culpados do que condenar um inocente. --Mister Sanderson (discussão) 23h31min de 27 de janeiro de 2020 (UTC)
Então, de novo, a minha proposta não torna regra o uso de mensagens offwiki como motivo para bloqueios, mas sim permite o uso de tais ataques externos como fator agravante em discussões de bloqueio que já estiverem em andamento. Percebe a diferença? Ademais, se você acha que mensagens offwiki não podem ter sua veracidade comprovada, então deveríamos anular essa e essa DBs, desbloquear os envolvidos e considerar todos os administradores que as apoiaram como equivocados? Chronus (discussão) 23h49min de 27 de janeiro de 2020 (UTC)
Mister Sanderson, é por isso que existem DBs onde se discute a veracidade das alegações. Nas duas que estão a ocorrer actualmente, nenhum dos usuários negou o acto. Imaginemos que ambos negavam ter dito seja o que for, ou negavam nunca ter agido por meat, ou que alegavam que a conta nem era deles e eles nunca tiveram conhecimento de tal coisa... então seria algo a ser analisado, comparado com edições on-wiki, etc... caso se julgasse a total inocência das pessoas, seria feito um pedido aos administradores desses canais (que acho que serão "sempre" usuários da nossa wiki) para bloquearem o quanto antes essas contas falsas usadas unicamente para denegrir a imagem de alguém e/ou para causar estragos... não vejo qual seria o problema. O Chronus não está a propor que se possam sentenciar inocentes, está proposto que haja investigação/intervenção por parte da comunidade em relação a um qualquer usuário: ou ele realmente é culpado ou servirá para agirmos em defesa da sua integridade e inocência. Se algum dia alguém tentar fazer isso para te prejudicar, nós gostaríamos de estar aqui para te defender e solicitar o banimento de tal conta dos canais de comunicação da comunidade. Pelo menos é o que eu acho. Luís Almeida "Tuga1143 00h25min de 28 de janeiro de 2020 (UTC)
@Chronus: o que o MisterSanderson diz é absolutamente verdade. Só quem está no momento numa sala de chat pode saber o que realmente é dito, e apenas nesse momento. Mesmo que se considere como "público" um espaço ao qual você apenas consegue aceder se registar o seu número de celular e baixar a app, o que já de si será muito discutível que entre na categoria de público, as mensagens podem ser apagadas a qualquer momento, e os recortes falsificados - ou colocados em contexto fraudulento para propagar mentiras graves, como fizeram comigo nessa DB. Não acho que a proposta seja especialmente grave, pois ela somente se aplica a meios de comunicação sancionados pela comunidade, que funcionariam como uma espécie de extensão da Wikipédia - e, portanto, sem relação com canais informais de comunicação como o Telegram - mas ela é sem dúvida equivocada, como muito bem expôs o Sanderson.-- Darwin Ahoy! 00h30min de 28 de janeiro de 2020 (UTC)
Citação: DarwIn escreveu: «Não acho que a proposta seja especialmente grave, pois ela somente se aplica a meios de comunicação sancionados pela comunidade - e, portanto, sem relação com canais informais de comunicação como o Telegram»
  1. A proposta não se aplica somente aos meios aprovados pela comunidade, pois é usada a palavra "principalmente", ao invés de "exclusivamente", no texto, conforme já apontei antes;
  2. O grupo do Telegram é listado em Wikipédia:Canais externos de comunicação, isso não faz dele um canal oficial?
--Mister Sanderson (discussão) 10h34min de 28 de janeiro de 2020 (UTC)

Symbol support vote.svg Concordo com a proposta. Quando o texto diz " Tais ataques podem ser vistos como fatores agravantes por administradores e são evidências aceitas em processos de resolução de disputas e discussões de bloqueio, principalmente se forem proferidos nos canais externos de comunicação definidos pela comunidade. ", é preciso ter em mente que estamos falando de proposição de norma. Então, dizer "principalmente se forem proferidos nos canais externos de comunicação definidos pela comunidade" remete a que tenhamos a ideia de que a ofensa praticada em canal definido pela comunidade é mais gravosa que uma situação análoga em canal não aprovado pela comunidade. Assim, esse seria um caso mais grave.

Veja que, no direito penal brasileiro, quem pratica um crime contra determinadas pessoas tem um aumento de pena. Código Penal.

"Art. 61 - São circunstâncias que sempre agravam a pena, quando não constituem ou qualificam o crime: (...) II - ter o agente cometido o crime: (...) e) contra ascendente, descendente, irmão ou cônjuge;"FábioJr de Souza msg 23h45min de 27 de janeiro de 2020 (UTC)

Fabiojrsouza, a respeito dos meios não-oficiais, como se vai saber se algo dito na Desciclopédia, por exemplo, terá sido afirmado realmente pelo editor que acusar-se ter dito? É perfeitamente possível que seja qualquer outra pessoa editando lá. Não é possível fazer a associação entre os dois perfis.--Mister Sanderson (discussão) 13h49min de 28 de janeiro de 2020 (UTC)
MisterSanderson Se alguém pedir o bloqueio de um editor nessa situação, eu acredito que o acusado vai alegar isso que você falou e aqueles dentre os 71 administradores que participarem terão discernimento suficiente para analisar os argumentos e decidir a questão. FábioJr de Souza msg 14h12min de 28 de janeiro de 2020 (UTC)

Symbol comment vote.svg Comentário Com efeito, ofensas proferidas offwiki merecem censura, no entanto, alguns pontos precisam ser discutidos. Primeiro, existe alguma forma de verificabilidade que garante que determinada conta no Telegram pertence a determinado usuário da Wikipedia? Porque seria fácil algum terceiro entrar no grupo e se passar por mim ou outra pessoa (já adianto que não tenho conta no Telegram, nunca me interessei em usar esse app). Outro ponto que não me agradou é a forma como as evidências foram postas nas duas últimas DB. Já questionei com Érico, e ele me deu um argumento convincente, pelo menos em relação às duas últimas DBs, mas, no contexto geral, as evidências não podem ser postas daquela forma. Frase soltas, escritas pelo acusador, do que supostamente o acusado escreveu, nos induz a crer no ponto de vista do acusador. Mas e se de repente ele estiver equivocado? Não quero dizer com isso que Renato está equivocado, nem Érico, é só um questionamento hipotético. DarwIn já nos mostrou que frases soltas, separadas de seu contexto, podem gerar interpretações equivocadas. Por isso, eu creio que deveria ser analisada a possibilidade de colocar os prints da conversa, de preferência completa, a fim de que possamos conhecer o contexto. ✍️A.WagnerC (discussão) 03h06min de 28 de janeiro de 2020 (UTC)

A.WagnerC Primeiramente, falta a assinatura no comentário acima. No mais, se alguém está acusando de modo equivocado, caberia ao acusado apresentar ao menos indícios de que a acusação não teria fundamento. FábioJr de Souza msg 02h02min de 28 de janeiro de 2020 (UTC)
FábioJr de Souza, mas aí você está revertendo o ônus da prova. Cabe a quem acusa mostrar provas. Mesmo aqui na Wikipédia se A pede o bloqueio ou sanção de B, é A quem tem fornecer indícios de que B violou as regras. Se A acusa B sem fornecer provas pode ser considerado ataque pessoal ou disseminação de desconfiança e é A quem, provavelmente, sofrerá a sanção.--SirEdimon (discussão) 02h15min de 28 de janeiro de 2020 (UTC)
SirEdimon De início, se você não colocar a predefinição não terei como responder (pois não saberei da mensagem a mim endereçada) e a mensagem ficará "solta" na discussão... Quanto ao mérito, num processo judicial o que ocorre? O autor apresenta seus argumentos com aquilo que acha que prova o que alega. O acusado apresenta sua defesa questionando aquilo que acha que deve questionar (pode, inclusive, questionar a validade das provas apresentadas). Isso não fere o ônus da prova (que, por sua vez, não é acima do direito de ação).Cada um tem que provar o seu lado. Passando para a Wikipédia, veja que alguém abrir uma discussão de bloqueio (comparando com o direito de ação) não quer dizer que a comunidade vai concordar com o que foi alegado. Então, se a pessoa se defende, ela vai alegar o que acha interessante para contestar as provas. Mas, se a pessoa apresenta aquilo que acha que é prova e ninguém contesta... Exemplo para ficar fácil entender o que disse no comentário anterior e agora. Se eu abro DB e digo que alguém descumpriu alguma regra e apresento o link, o "acusado" tem que apresentar alguma alegação e prova que invalide o link. Só para reforçar... O A.WagnerC disse acima (e foi ao comentário dele que respondi) Citação: Frase soltas, escritas pelo acusador, do que supostamente o acusado escreveu, nos induz a crer no ponto de vista do acusador.(...)já nos mostrou que frases soltas, separadas de seu contexto, podem gerar interpretações equivocadas. Por isso, eu creio que deveria ser analisada a possibilidade de colocar os prints da conversa, de preferência completa, a fim de que possamos conhecer o contexto. Ora, o editor apresentou aquilo que ele entende que prova o que alega, se o acusado não concorda, que apresente argumentação para questionar isso. Esse é o sentido do meu comentário. Ademais, se quem avalia acha que a prova não é adequada, não vai levá-la em consideração. Quem deseja provar algo deve ter isso em mente. E corre o risco da decisão sobre o tipo de prova que usa.FábioJr de Souza msg 02h53min de 28 de janeiro de 2020 (UTC)


Symbol question.svg Pergunta Tendo em mente que privacidade e anonimato são princípios fundadores e fundamentais na Wikipedia e em todos os projetos da Fundação Wikimedia (inclusive é isso que garante o funcionamento de algumas WPs e, literalmente, a sobrevivência de seus editores em várias partes do mundo) e que a quebra desses princípios ("outing") é algo grave e sancionável, gostaria de saber como essa proposta não é uma quebra de WP:REVELAR. Porque ao se revelar que mensagens supostamente pertencem a editor A ou B (como está sendo feito) também se é revelado "quem" são os editores A ou B "na vida real", já que as contas em redes sociais (Twitter, Telegram, Facebook, etc.) contém informações pessoais das pessoas (basta ver quem postou as referidas mensagens nas referidas redes sociais para saber dados pessoais dos editores envolvidos). A meu ver a única forma de essa proposta não ser um "outing" e, portanto, quebra de WP:REVELAR é se: A - Houvesse forma segura e inconteste de comprovar a identidade de quem está por trás de tais contas nas redes sociais (o que, a meu ver, é impossível) e B - O editor revelar volutariamente que a conta na tal rede social pertence a ele. Porque se apenas comprovassemos que a conta pertence a editor A e revelassemos a informação sem que ele se "revelasse" volutariamente seria "outing" e se ele se revelasse, mas não tivessemos como ter absoluta certeza de que a pessoa na rede social é o editor da Wikipédia que ele diz ser, correriamos o risco de cometer erros sérios, porque qualquer um pode se passar por outra pessoa na internet.--SirEdimon (discussão) 02h11min de 28 de janeiro de 2020 (UTC)

@Fabiojrsouza: Quem acusa não pode jogar o ônus todo para o acusado. Quem acusa tem que apresentar evidências do ato ilícito, e não simplesmente acusar e esperar que o acusado prove que a acusação é falsa. Em todos os países democráticos o processo acusatório funciona dessa forma. Só no inquisitório que isso não é respeitado. Além disso, há o risco da pessoa acusada nem sequer tomar conhecimento de que está ocorrendo uma DB em seu desfavor, visto que essas discussões levam em média menos de uma semana, e o acusado pode nem logar na Wikipedia nesse período, já que não é todo mundo que edita diariamente. Aí se a pessoa ficar off durante um tempo, e não impugnar as evidências (porque ninguém impugna pelos outros), ele será bloqueado, ainda que as mensagens estejam fora de contexto? Porque uma coisa é julgar quando a ofensa é aqui, onde é possível se visualizar toda a conversa, outra coisa é julgar um ato ocorrido em ambiente externo, onde não temos acesso à íntegra da conversa. Quando se pensa em propostas como essas, temos que pensar que podem acontecer fraudes, e nessas fraudes o inocente pagar o pato, se não houver um processo justo.✍️A.WagnerC (discussão) 03h06min de 28 de janeiro de 2020 (UTC)
A.WagnerC Primeiro que você colocou sua resposta em outro lugar (como que respondendo à pergunta). Mas tudo bem...Citação: Quem acusa não pode jogar o ônus todo para o acusado. Eu não disse que pode jogar o ônus todo no acusado e não disse que deve Citação: simplesmente acusar e esperar que o acusado prove que a acusação é falsa. O que eu disse foi Citação: Ora, o editor apresentou aquilo que ele entende que prova o que alega, se o acusado não concorda, que apresente argumentação para questionar isso.. O acusado tem sim que fazer uma manifestação, nem que seja para dizer que as provas não são válidas porque não tem como provar que aquela conta corresponde à que está na Wikipédia (num processo judicial, no mundo real, seria nomeado um defensor dativo, então o acusado não ficaria sem defesa). Se deixa de manifestar, assume a consequência. Sobre as outras considerações... Vamos então mudar o sistema de revisão de bloqueio. Só pode deliberar se tiver certeza absoluta que o acusado teve ciência inequívoca da DB (que pode ficar anos aberta se a pessoa não editar logada ...)? Nem todos os princípios do direito processual penal são aplicáveis à Wikipédia... Na Wikipédia, os participantes devem analisar os argumentos. Se não há defesa, quem julga vai analisar a pertinência da prova. No mais... Citação: Quando se pensa em propostas como essas, temos que pensar que podem acontecer fraudes, e nessas fraudes o inocente pagar o pato, se não houver um processo justo. Que fraudes?FábioJr de Souza msg 03h45min de 28 de janeiro de 2020 (UTC)
@Fabiojrsouza: Fraudes como colocar fora de contexto uma frase relacionada ao monstro de Suzanno e a um editor daqui que vive nesses fóruns extremistas, e afirmar que ela é sobre o Renato; ou que comentários sobre protecção de editores contra processos judiciais por editarem a Wikipédia são instruções para usar fantoches ilícitos. Ou forjamento de recortes, publicação de conversas que nunca ocorreram, etc. Esse tipo de fraudes.-- Darwin Ahoy! 03h52min de 28 de janeiro de 2020 (UTC)
@DarwIn: Quem acusa apresenta o que acha que prova o alegado. Quem quer se defender apresenta a prova do que alega em defesa... No mais...FábioJr de Souza msg 04h02min de 28 de janeiro de 2020 (UTC)
@Fabiojrsouza: Ou seja, para você nem precisa que seja, basta só que pareça, para já ser. Não precisa de investigação, de verificação, de confirmação. Qualquer acusação fraudulenta como essas que apontei aí já bastaria para destruir um editor, na ausência de defesa do acusado (seja porque motivo for - e a morte da pessoa é um deles). Pode até ser essa a sua opinião, mas isso não é minimamente aceitável em nenhum sítio que se tome por civilizado.-- Darwin Ahoy! 04h21min de 28 de janeiro de 2020 (UTC)
@DarwIn: É você que está dizendo Citação: Ou seja, para você nem precisa que seja, basta só que pareça, para já ser. e não eu. Ter alguém acusando, alguém defendendo e alguém julgando é básico em matéria de processo. Cada um tem sua parcela de direitos e sua parcela de deveres. No mais, nós temos 71 administradores para, justamente, garantir que tudo ocorra dentro das regras e da forma correta. Então...FábioJr de Souza msg 04h35min de 28 de janeiro de 2020 (UTC)

Symbol comment vote.svg Comentário Acho extraordinário como é que num texto tão simples e básico as pessoas conseguem imaginar um milhão de coisas que não estão lá escritas. A regra diz respeito a ataques feitos em locais externos contra editores deste projeto. É só isso. Simples. Se não é ataque público, não tem nada que meter o bedelho. Gostava de perceber como é que a partir daqui se extrapola de forma descabida que se tem legitimidade para vasculhar e expor a participação de editores na vida pública em sociedade, em todo e qualquer outro assunto que não sejam ataques a editores. Isto parece-me criar mentiras, falácias e pânicos morais para fazer oposição na falta de argumentos legítimos. JMagalhães (discussão) 09h48min de 28 de janeiro de 2020 (UTC)

Dito isto, e apesar da regra existir de forma incontestável, eu também partilho da preocupação com operações de false flag. Isto é, trolls de má fé que se possam registar com o nome de outros utilizadores no sentido de os tentar incriminar. Isto não é um cenário implausível. Lembro que o LeandroTelesRocha fazia muito isso em outras wikis. De qualquer forma, o ónus de provar que são a mesma pessoa é de quem acusa.
De qualquer forma, estes ataques só têm ação destrutiva quando existe uma audiência de outros utilizadores do projeto. Ou seja, só são motivo de preocupação ataques em grupos ou plataformas de alguma forma ligada ao projeto e frequentados por vários editores. JMagalhães (discussão) 10h05min de 28 de janeiro de 2020 (UTC)
JMagalhães, se Citação: só são motivo de preocupação ataques em grupos ou plataformas de alguma forma ligada ao projeto, porquê a proposta usa a palavra "principalmente" ao invés de "exclusivamente"?--Mister Sanderson (discussão) 10h50min de 28 de janeiro de 2020 (UTC)

Symbol support vote.svg Concordo com a proposta mas eu trocaria de: "e discussões de bloqueio, principalmente se forem proferidos nos canais externos de comunicação definidos pela comunidade" para "e discussões de bloqueio, quando forem proferidos nos canais externos de comunicação definidos pela comunidade". Isto porque em outros canais fica difícil detectar uma possível fraude. Ricardo F. OliveiraDiga 10h44min de 28 de janeiro de 2020 (UTC)

Ricardo Ferreira de Oliveira, sua proposta é mais razoável do quê a original, por excluir o termo "principalmente".--Mister Sanderson (discussão) 13h46min de 28 de janeiro de 2020 (UTC)

Symbol declined.svg Discordo da proposta do modo como está feito, pelos mesmos motivos do Mister Sanderson e Sir Edimon. O que é urgente adotar é um código de conduta universal que possa ser imposto nas plataformas que sejam consideradas "(semi-)oficiais" para que sejam mencionadas na Wikipédia. E claro que ataques offwiki podem servir de evidências adicionais em caso cá dentro, mas é preciso ter muita atenção às preocupações já levantadas de autenticidade e contexto das mensagens. GoEThe (discussão) 11h16min de 28 de janeiro de 2020 (UTC)

GoEThe, o código de conduta universal é pertinente, mas como fazer valer a letra da lei? Isto é, de que maneira quem for dono de um grupo qualquer será obrigado a fazer cumprir o código de conduta? Bloquear-se-ia, na Wikipédia, o editor dono da sala de chat se ele recusar-se a expulsar um membro do grupo? Bloquear-se-ia, na Wikipédia, o editor dono da sala de chat se ele recusar-se a deletar alguma mensagem ofensiva?--Mister Sanderson (discussão) 13h55min de 28 de janeiro de 2020 (UTC)
Não penso que esse seja o caminho. Cada canal deve impor esse código de conduta, caso queira pertencer ao Universo Wikimedia. Havendo violações reiteradas nesse canal sem que os moderadores, após serem chamados à atenção, tomem medidas para que o espaço cumpra com o código e se mantenha um espaço seguro e amigável, seria des-reconhecido pela comunidade da Wikipédia em Português e não seria mais mencionado nas páginas do projecto e de ajuda. Vejam por exemplo, o código de conduta para espaços técnicos da Wikimedia mw:Code of Conduct/pt e a política de espaço amigável para eventos foundation:Friendly space policy. GoEThe (discussão) 14h07min de 28 de janeiro de 2020 (UTC)

Symbol declined.svg Discordo pelos motivos já levantados pelo Mister Sanderson, Sir Edimon e GoEThe. Não havendo um processo de verificabilidade estabelecido para acusações desse género, coisa que já é difícil fazer num espaço como o Slack, que perde as mensagens antigas ao fim de algum tempo, ou como o Telegram, cujas mensagens podem ter o próprio conteúdo alterado durante algum tempo, e podem ser eliminadas em qualquer altura, abre-se a porta para todo o tipo de fraudes e abusos.-- Darwin Ahoy! 13h43min de 28 de janeiro de 2020 (UTC)

Symbol support vote.svg Concordo com a proposta do Chronus. É impossível fazermos publicidade na nossa wiki de canais externos sem termos pelo menos algum tipo de regulação. Como diz o Chronus e muito bem, também acho que ataques podem ser vistos como fatores agravantes por administradores e são evidências aceitas em processos de resolução de disputas e discussões de bloqueio, principalmente se forem proferidos nos canais externos de comunicação definidos pela comunidade. Em matéria de privacidade, se houver algum ataque num canal privado ou em conversa entre dois editores, é óbvio que temos que respeitar o direito à privacidade como sempre o fizemos e sempre o iremos fazer. Não podemos nunca controlar a privacidade de uma pessoa que conversa em privado no Telegram ou no Facebook... não é para isso que estamos aqui, nem é isso que estamos a discutir aqui. Aqui estamos a discutir a possibilidade de, dentro dos canais de comunicação externa definidos pela nossa comunidade, sendo esses canais de teor publico, que se passe a ter o mínimo de escrutínio sobre o que se publica ali. Eu não posso ir ao canal do Telegram nem ao grupo do Facebook e chamar um qualquer editor de "filho da **** nazi, salazarista fascista, etc", já para não falas dos óbvios casos de meat e aliciamento. Se a nossa comunidade define X canais externos, então esses canais devem ir de encontro, pelo menos mínimamente, com a ética da nossa comunidade. Contudo, após o fim deste discussão, isto é, se esta proposta for aceite pela comunidade, acho igualmente importante definirmos quais são esses canais, de que forma podemos pedir às pessoas que regulam esses canais para colaborarem com a nossa comunidade (por exemplo, registar e eliminar ataques quando estes acontecem) de modo a que as pessoas possam ser chamadas à responsabilidade aqui e, dentro desse canal, chegar a um consenso sobre qual seria o melhor destino para quem proferiu tal ataque. Além disso, no seguimento desta ideia, sendo que os canais definidos teriam um teor publico, seria igualmente interessante que o registo de tais ataques pudesse ser usado como evidências em DBs por aqui, sob a forma de screenshot por exemplo; novamente repito, para conversas provadas em canais privados, tal nunca se aplicaria. Relativamente às alegações e preocupações como as do Mister Sanderson, compreendo perfeitamente as suas preocupações e partilho delas, mas é importante frizar que quando se inicia uma discussão eu não posso pura e simplesmente acusar, por exemplo o Mister Sanderson, de ter dito A, B ou C. Vou dar o exemplo do JardelW: foi feita uma acusação sobre ele; ele não negou o que a acusação disse, e todos os intervenientes no canal (a esmagadora maioria deles usuários desta wiki) sabem que ele sempre se identificou como sendo o JardelW, e se ainda houvesse dúvidas, poderia ser feita uma análise comportamental e editorial entre o que a conta dizia/fazia com o que o usuário dizia/fazia aqui. Ninguém é julgado à toa aqui na wiki, existe um processo de deliberação, apresentação e análise de provas, é tão simples quanto isso. Se as pessoas (ou os canais) querem "desviar-se do escrutínio da comunidade" é simples... não são canais externos da comunidade e deixam de receber qualquer reconhecimento e publicidade aqui, e se até for preciso cria-se uma lista de canais desaconselhados (por exemplo, imaginemos que o Quintinense cria um e tenta fazer publicidade aqui). Em suma, o que fazemos em privado não diz respeito a ninguém... mas aquilo que fazemos num canal de comunicação externa da wikipédia diz respeito à comunidade da wikipédia, e se somos acusados de algo, tem que existir provas e argumentos para tal, e como é natural a pessoa acusada tem que ter o direito a se defender, e com isto não estou a dizer nada que já não aconteça aqui na nossa wiki. Concordo com esta proposta do Chronus e faço um apelo por mais discussão sobre o assunto e futuras propostas, de modo a assegurar um SafeSpace off-wiki onde possamos conviver (quem quiser claro, ninguém é obrigado) em segurança e confiança. Luís Almeida "Tuga1143 16h18min de 28 de janeiro de 2020 (UTC)

(conflito de edições) Muita embora eu pessoalmente não seja adepto do politicamente correto, é importante distinguir essa renúncia de ofensas, ataques morais e assédio oculto e discernir o momento e espaço oportunos onde seu uso não é necessário. Há de se considerar que em um ambiente público em que é estimulada a convivência de usuários novatos, veteranos e mesmo inativos a adoção de um linguajar como o que estamos vendo pode ser interpretada como a Wikipédia sendo um ambiente agressivo, da mesma forma que abre espaço para a conivência com a realização de assédio (explícito ou velado) on-wiki. Dessa forma surge a necessidade de que a regulação atualmente prevista em WP:ATAQUEOFFWIKI seja colocada em prática mediante a devida especificação e acredito que a proposta original cumpra essa função. As discussões de bloqueio existem justamente para julgar a procedência ou não de sanções ligadas a esses casos, através da abertura de espaço para a comunidade e administradores debaterem tais situações quando necessário, além da exposição de defesa.

Ressalto que acho válida a sugestão do GoEThe sobre a implantação de um código de conduta local (para cada canal) e imagino que tal condução possa ser o suficiente para resolver muitos imbróglios dentro do canal, mas ataques explícitos contra usuários, a comunidade e o escopo da Wikipédia, cometidos em rede pública destinada a debater assuntos sobre a wiki, deixam claro a visão do abusador referente ao seu sentido dentro do projeto e por isso cabem ser debatidos on-wiki também caso haja evidências. Dentro disso seria importante distinguir o que pode ser sancionado com um simples banimento do canal, distinguido essas circunstâncias dos casos mais graves, como as situações que exemplifiquei, que seriam enquadrados como violações passíveis de sanção na wiki. Por analogia, é como se alguém que trabalha em uma empresa começasse a ofender seus colegas e atitudes da firma nas redes de comunicação para todos verem. Posteriormente o indivíduo verá as consequências. Dessa forma, eu Symbol support vote.svg Concordo com as alterações propostas pelo Chronus, porém um código de conduta válido dentro da rede pode ser acrescentado ao seu teor. --HVL disc. 16h19min de 28 de janeiro de 2020 (UTC)


Geral

Secção geral da Esplanada ▲ Anúncios | ▲ Propostas | ◄ Geral | início
Esta secção é utilizada para todo tipo de anúncios relacionados com a Wikipédia em português de forma direta ou indireta.
clique aqui para adicionar um novo tópico na secção geral

Wikipédia:Esplanada/geral



Rodapé da Esplanada ▲ Anúncios | ▲ Propostas | ▲ Geral | início