@Leon saudanha: Eu usei o petscan para fazer um teste com a categoria de filmes, só essa categoria deu mais de 6 mil artigos com a marca de sem fontes, mesmo separando uma página para cada ano vai dar listas muito grandes. O ideal seria se todos artigos já estivessem pré-separados em um banco de dados e uma ferramenta cruzasse com a categoria de artigos sem fontes de ano ou de mês, sendo uma ferramenta e não uma lista em uma página faz com que a lista seja automaticamente atualizada se a marca for removida de um artigo. Eu tenho que reformar uma ferramenta no Toolforge que gera listas e posso adicionar essa função. Só que tenho muitas coisas pendentes ainda para fazer, ainda nem consegui terminar de redirecionar os asteroides, então provavelmente vou demorar para conseguir fazer isso. Danilo.mac(discussão) 00h57min de 20 de agosto de 2020 (UTC)
Olá Danilo, compreendo a situação. De qualquer modo, fico no aguardo de que tenha tempo livre para fazer as alterações necessárias. Boas edições!
Fiquei em dúvida. O mobile.js é aplicável aos usuários que editam utilizando aplicativos móveis, como o do Android? ━ ALBERTOLEONCIO Who, me? 16h05min de 2 de setembro de 2020 (UTC)
@Albertoleoncio: Confesso que não conhecia esses aplicativos, costumo acessar a Wikipédia somente pelo desktop. Eu entrei no canal #wikimedia-mobile no IRC e perguntei lá, o dev lá me respondeu que os aplicativos Android/iOS obtêm o HTML do mw:Page Content Service, que aparentemente não usa o Common.js nem o Mobile.js, e os aplicativos ainda fazem algumas modificações nesse HTML antes de exibir ao usuário. O dev que me atendeu é novo na Wikimedia mas foi atencioso e vai ver com outros devs se existe alguma alternativa. Então por enquanto ainda não temos uma alternativa de implementação que se aplique também aos aplicativos. Danilo.mac(discussão) 19h01min de 2 de setembro de 2020 (UTC)
Olá. Em princípio não recebem a mesma mensagem, mas sim algo personalizado, como o {{anonblock}}, explicando as regras e mostrando como criar um registo. Quando se coloca essas predefinições nas justificações de bloqueio, elas são mostradas aos IPs (eu mesmo já testei).-- Darwin Ahoy! 21h38min de 4 de setembro de 2020 (UTC)
@DarwIn: Eu não sabia, espero que usem uma predefinição diferente dessa annonblock se forem realmente usar o bloqueio, pois essa é mais voltada para faixas de IP que fizeram muitos vandalismos. Vou ajustar minha justificativa lá na votação. Danilo.mac(discussão) 21h54min de 4 de setembro de 2020 (UTC)
Sim, será uma criada para o efeito, com informação semelhante ao filtro, e com certeza não falará em vandalismos.-- Darwin Ahoy! 23h36min de 4 de setembro de 2020 (UTC)
Olá Danilo. Estava a ler os comentários na discussão da votação sobre IPs e vi a tua Quarry sobre edições revertidas em Agosto e cruzei-me também com este comentário do Halfak e pensei que era uma boa maneira de ver o "stress do sistema". Cruzar quantas edições são revertidas e quantas o ORES indica serem provavelmente vandalismo. Também seria bom ter uma ideia quão fiável é o ORES a detectar edições a reverter. Será talvez mais fácil fazer que uma amostragem manual. Houve também uma amostragem de 4000 mil edições recentemente para melhor o ORES. Não sei se dá para aceder aos dados em bruto para calcular algumas estatísticas. Tem aqui detalhes do modelo ORES, mas não sei bem o que os números querem dizer. GoEThe (discussão) 16h13min de 30 de setembro de 2020 (UTC)
@GoEThe: Essa amostragem e estatísticas são do modelo de estimativa de qualidade, não de reversão. A última vez que vi as estatísticas de reversão (em 2017 pelos meus registros) a precisão estava em 82%, ou seja, em 82% das edições revertidas o ORES conseguiu prever que seriam revertidas. Eu discordo do que o Halfak disse, inclusive eu era voluntário no inicio do desenvolvimento do ORES e uma das coisas que me fez abandonar o projeto é por sua precisão não ser alta o suficiente para ser usada em um robô antivandalismo (o que era uma das minhas principais motivações nesse projeto), naquela época eu gerei gráficos como este, esse é um tipo de gráfico usado para verificar a precisão e ajustar o threshold (valor de estimativa acima do qual a edição será considerada reversão), e mostra que a quantidade de falsos positivos seria muito grande para ser usado em um robô e a quantidade de falsos negativos muito grande para dizer para os patrulhadores que uma parte das edições não precisam ser verificadas. Para diminuir o número de falsos negativos (edições que precisam ser revertidas mas que não foram identificadas como tal) seria preciso usar um threshold muito baixo, o que não compensaria pois diminuiria muito pouco o trabalho dos patrulhadores sem descartar totalmente a chance de falso negativo. E a razão porque nem ORES nem outra inteligência artificial disponível hoje consegue atingir a precisão que precisaríamos é que esses algorítimos não são capazes de compreender os aspectos subjetivos do texto da edição, eles não entendem por exemplo se o texto adicionado faz sentido no contexto daquele artigo ou se as regras de edição foram cumpridas, são coisas muitos complicadas mesmo para a inteligência artificial disponível atualmente, são coisas que ainda só são capazes de serem interpretadas pelo nosso cérebro. Então ainda que a precisão tenha melhorado nesses últimos anos, não tem como usarmos o ORES para diminuir o trabalho dos patrulhadores sem com isso deixarmos vandalismos não revertidos para trás. Danilo.mac(discussão) 18h42min de 30 de setembro de 2020 (UTC)