Wikipédia:Filtro de edições/56

Branqueamento por novo editor
Status
Desautorizando (aviso).
Manutenção
Média. Requer acompanhamento até 11/2013 pois em algumas situações o editor acrescenta pouca informação num artigo que é muito pequeno (exemplo). No futuro, o parâmetro new_size pode ser aumentado mediante evolução na quantidade de kb dos artigos mínimos.
Resumo
O filtro evoluiu de ação nenhuma até desautorizar num campo diversificado de opções ao incluir todas as contas, desconsiderar o parâmetro old_size (detectando assim todo tipo de redução) e desconsiderando se houve edição recente pelo editor (evitando o "vandalismo continuado").
Ferramentas
Código Discussão Histórico Testes Registros Análise
Falsos positivos
Total	7
Lista	Lista filtrada (com gadget) (PS: futuramente, poderíamos ver os 5 mais recentes aqui mesmo)
Tarefas
indefinido

Ao me deparar com este vandalismo que não foi detectado pelo filtro 56 (<40 new_size era maior que 40) me ocorreu que este filtro ainda pode ser melhorado com o incremento do parâmetro new_size. Estava pensando que os parâmetros sendo trabalhados pelos filtros 66, 53 e 67 poderiam ser utilizados aqui. Ora, se artigos com menos de 40 bytes são avisados e etiquetados a mesma analogia se aplica aqui, isto é, converter um artigo com mais de 500 para menor que 40. Acho que podemos subir o valor de new_size para 50 quando o filtro 53 ser atualizado ou deixar este como está caso seja deixado no modo desautorizar o que estaria alinhado com o filtro 66. OTAVIO1981 (discussão) 12h49min de 30 de julho de 2013 (UTC)

Acho que esse filtro é o mesmo que o filtro 03 - Conta nova removendo conteúdo, a diferença é que este tem menos exceções, e só funciona com remoção de mais de 460 bytes (o outro é pra 300 bytes) e só quando o artigo final é pequeno (o outro é pra qualquer tamanho final de artigo). Rjclaudio ^msg 17h39min de 14 de agosto de 2013 (UTC)

Sim, concordo que os filtros são para a mesma coisa. O porém é que uma remoção de 300 bytes em um artigo de 90000 pode ser perfeitamente válida (vamos supor que fez uma revisão do texto e calhou de retirar 300 bytes) enquanto a redução para um tamanho em que já estamos desautorizando a criação (por não achar nada "aproveitável" tem toda a cara de vandalismo. Entendo que o caminho é o filtro 56 ficar no modo desautorizar, enquanto o 3 ainda dá o benefício da dúvida justamente por ignorar o tamanho final do artigo. Não me oponho, aplicar o mesmo edit_delta neste filtro 56, isto é, remoção de texto superior a 300 no qual o artigo final tem menos de 50 bytes (o 66 atual). Enfim, o ideal é analisar a fundo o filtro 3 para ver se a taxa de falso positivos é baixa. No momento, estou focado em outros filtros mas posso dar uma olhada amostral neste também.OTAVIO1981 (discussão) 20h50min de 14 de agosto de 2013 (UTC)

Entendi a diferença, concordo então. Aumentei o new_size para 50 (igual ao PN mínima 1) e diminui o old_size para 350 (igual ao filtro 3 de remoção de conteúdo). Vou começar a analisar esse filtro para depois aumentarmos para impedimento. Rjclaudio ^msg 18h02min de 15 de agosto de 2013 (UTC)

Analisei agora o que falta. Todos os últimos 500 registros do filtro foram corretos. Agora é esperar uns dias até acumular registros dos novos parametros.

Eu to pensando agora se não é melhor voltar o filtro pro parametro anterior e já mudar para impedimento (500 registros em 1 mes e meio, é suficiente) e criar um outro filtro para testarmos o novo parametro. E assim teriamos uma lista só com os registros com o novo parametro, sem misturar com os antigos, facilitando a análise.

Até pq estou pensando se não deviamos aumentar um pouco mais o new_size, pq diferente de um artigo novo, há uma grande remoção, então um <50 é pouco, queria testar com <80 (PN mínima com etiqueta), ou mesmo <100, <150 (PN mínima em teste). Rjclaudio ^msg 18h55min de 15 de agosto de 2013 (UTC)

Concordo em passar o filtro para o modo desautorizar com os parâmetros antigos. Desde que passou para o modo avisar, foram feitos 78 salvamentos que foram posteriormente revertidos, representando 30% do conjunto de ações (avisar+salvar). Em relação a criar um novo filtro para aumentar o limite deste, concordo e como o filtro inicialmente só vai assinalar no registro acho que podemos testar com 150 e mudar eventualmente se houver muitos falsos positivos (o que duvido muito).OTAVIO1981 (discussão) 20h10min de 15 de agosto de 2013 (UTC)

OTAVIO1981, o filtro 56 registrou 332 ações desde que passou a enviar avisos até o momento do seu comentário. Aparecem 73 "diff" na lista de registros, então são cerca de 22% (ou os 30% se referem a outra coisa?), apenas uma ação no domínio anexo.

Que versão anterior concorda em usar para impedir edições? Concordo em retornar para a versão de 9 de agosto de 2013 e ativar o impedimento das edições que forem detectadas.

Rjclaudio, entre os últimos 500 registros que citou, há o 1338948 que foi marcado como falso positivo. Helder 22h04min de 15 de agosto de 2013 (UTC)

Feito, reverti pra edição do dia 9 que o Helder falou, passei o filtro para impedimento, e criei o Filtro 119, com new_size<150 e old_size>350. Rjclaudio ^msg 03h03min de 16 de agosto de 2013 (UTC)

Helder, considerando os seus números foram 259 ações de aviso das quais 73 foram salvas. Isto dá algo em torno de 28% de ações convertidas. Avaliar a eficiência com 73/332 (número de salvamentos sobre o total) causa uma distorção quando o aviso torna-se ineficiente. Exemplo, 100 avisos com 100 salvamentos daria 100% de ações convertidas pelo meu cálculo, isto é, o aviso não valeu de nada e pelo seu cálculo seria 50% de conversão. Uma vez que o desejável é ter uma baixa taxa de salvamentos somente com o aviso, acho que meu cálculo reflete isto melhor.OTAVIO1981 (discussão) 11h52min de 16 de agosto de 2013 (UTC)

Parâmetro de usuários

Porque usamos exceções para 'confirmed' in user_groups e user_name in article_recent_contributors. Existe alguma situação em que um admin vai converter qualquer conteúdo do domínio principal para algo menor do que 40 bytes? redirects não conta porque já são exceções. O editor ter contribuído recentemente no artigo dá direito de branqueá-lo? Este exemplo do Rjclaudio não foi detectado por conta disso e é uma "brecha" que pode ser explorada pelo vândalo. Supondo que ele faz uma alteração maléfica que não é detectada, pode tentar fazer outra edição maléfica que é apagar todas as informações e irá conseguir por conta da brecha. Quanto mais eu analiso o filtro percebo que os únicos parâmetros que interessam são os tamanhos iniciais e finais e as exceções de redirect e domínio principal. Vocês conseguem ilustram um possível artigo com menos de 40 bytes?OTAVIO1981 (discussão) 13h59min de 30 de agosto de 2013 (UTC)

Concordo em remover essas exceções. A ideia do recent_contributors era o usuário adicionar conteúdo ao artigo, mas depois remover por algum motivo. Mas aí depois de remover o artigo teria menos de 40 bytes seria inútil, então errado, e deve ser evitado. No aviso poderia ser explicado pro usuário enviar para ER caso ele tenha sido o criador do artigo, pois novatos tendem a criar artigo e branquear depois ao invés de ER. Pro !confirmed, mesma coisa, sem situações que sirva um artigo com <40 bytes.

A ideia é aumentar esse valor, com os parametros do filtro de Branqueamento (2). Aí ainda seria válido? Lá já não há o !confirmed , então podiamos tirar daqui. Se formos tirar o recent_contributors, bom tirar logo por lá que ainda não tem nenhuma ação. Rjclaudio ^msg 14h10min de 30 de agosto de 2013 (UTC)

Você mencionando ERs me fez pensar se não seriam exceções também. Principalmente se formos excluir o parâmetro confirmados. [ver exemplo que seria impedido. Tem alguns editores que apagam todo o texto e deixam só a TAG aí seriam impedidos. Até já falamos sobre isso que não é regulado ainda. Então para retirar estes dois parâmetros acho que deveríamos incluir exceções para ERs. Acho que podemos tirar o recente_contributors do 119 até para monitorar melhor as possibilidades a medida que formos ampliando os parâmetros. OTAVIO1981 (discussão) 14h47min de 30 de agosto de 2013 (UTC)

Falsos positivos e a questão do parâmetro confirmed

Rjclaudio, novamente a questão do "vandalismo continuado" aqui que permite passar pelo filtro. Outro ponto: o filtro precisa ignorar quando é feita uma conversão de um texto numa desambiguação. Ontem ocorreu um falso positivo de uma desambiguação que foi editada e não foi possível reverter à versão original. Se fosse um vandalismo só seria possível removê-lo fazendo uma pequena edição (entrando para o article_recent_contributors) primeiro. Deste modo, a proposta que tenho para o filtro é:

action='edit'

& new_size < 150

& old_size > 350

& (article_namespace == 0 | article_namespace == 102)

& ! user_name in article_recent_contributors

& ! new_wikitext irlike '#redirec|disambig|{{(subst:)?(vda|er[\|}[0-9])'

Lembrando que estamos admitindo falsos positivos nos artigos menores que 150. Seria possível usar o AWB para remover as desambiguações desta lista? Acho que vale a pena um esforço de ampliá-los e retirar esta possibilidade de FP. OTAVIO1981 (discussão) 11h55min de 9 de setembro de 2013 (UTC)

Fiz a diferença entre a lista de páginas que têm até 149 bytes (copiada da página especial que indicou) e de páginas que transcluem a Predefinição:Desambiguação e obtive estes 672 resultados (só não sei porque algumas desambiguações ainda ficaram na lista). Helder 19h55min de 5 de outubro de 2013 (UTC)

Novato?

O texto seguinte foi movido de: Wikipédia Discussão:Filtro de edições#Novato?

Fui marcar este lixo como SPAM e fui impedido várias vezes por um dos filtros. Mensagem: Citação: "Esta ação foi identificada automaticamente como prejudicial, e foi consequentemente bloqueada. Se você crê que a sua edição foi construtiva, por favor informe-nos o que você estava a tentar fazer. Nós vamos analisar o problema e informar a causa, ou vamos corrigir o sistema para que tal mensagem não apareça novamente, se for necessário. Uma breve descrição da regra com a qual a sua ação coincidiu é: "Branqueamento por novo editor." Se não for pedir muito, um pouco de atenção e não colocar contas que tem milhares de edições na mesma vala comum de contas novas; não pretendo perder tempo pedindo autorização, para marcar lixo como lixo. Fabiano ^msg 03h22min de 11 de setembro de 2013 (UTC)

O texto acima foi movido de: Wikipédia Discussão:Filtro de edições#Novato?

Proposta de nova configuração

O filtro de teste 119 está com poucos disparos então proponho a configuração abaixo que seria uma "fusão" e testar quantos são os casos de vandalismos continuados, isto é, o vandalo edita a página e depois branqueia.

action == 'edit'

& new_size < 150

& ( article_namespace == 0 | article_namespace == 102 )

& user_name in article_recent_contributors

& ! new_wikitext irlike '#redirec|{{(?:subst:|msg:)?(?:vda|er[\|}0-9]|d[ei]sambig)'

coments? OTAVIO1981 (discussão) 16h10min de 5 de outubro de 2013 (UTC)

Se o filtro 119 estivesse com o código sugerido, ele não teria detectado certos registros (em que o usuário não estava entre os últimos editores da página), como por exemplo: 1415421, 1414896, 1414768, 1414034 e 1413773. Helder 20h47min de 5 de outubro de 2013 (UTC)

Acho que não expliquei corretamente minha proposta. O 56 está utilizando o parâmetro "& !user_name in article_recent_contributors" então ele detecta estes casos que mencionou. A minha idéia aqui é medir quantos fazem o dito "vandalismo continuado" de forma complementar ao 56, isto é, lá detecta quem tentou branquear "de primeira" e aqui quem contribuiu e tentou branquear "de segunda". Caso não haja FP, a idéia então é simplesmente remover "& !user_name in article_recent_contributors" do 56 então ele detectara tanto de 1ª quanto de 2ª. Sds, OTAVIO1981 (discussão) 22h00min de 5 de outubro de 2013 (UTC)

Testei a configuração acima (atualizada), que pretendo implementar no 56, com o script de regressão e todos os últimos 200 casos seriam disparados normalmente. Então, assumindo que todas os casos típicos de conversão de um texto grande para um pequeno estão cobertos (marcação de ER/VDA com branqueamento, reversão de vandalismo em desambiguações (notar que variei esta detecção pois temos 2 redirs)) acho que não haverá falsos-positivos. Vou acompanhar de perto por uns dias para ver se está tudo bem. OTAVIO1981 (discussão) 16h39min de 9 de outubro de 2013 (UTC)

FeitoAtualizado! Aproveitei e melhorei o aviso. OTAVIO1981 (discussão) 17h07min de 9 de outubro de 2013 (UTC)

Helder.wiki e Rjclaudio, o parâmetro new_size está alto e provocando alguns falsos positivos. Pode ocorrer do editor criar um artigo pequeno (new_size > 70) e fazer uma edição logo em seguida disparando este filtro como branqueando quando podia estar até aumentando o texto para algo entre 70 e 150. Se o limite mínimo para criação é 70, acho que estes filtros devem ficar alinhados porém este valor de 70 já precisa de um update e na outra discussão comento mais. Para o momento, gostaria de saber se vcs concordam com o alinhamento pois aí quando atualizar faço os 2 filtros. Sds, OTAVIO1981 (discussão) 14h20min de 18 de outubro de 2013 (UTC)

Citação: podia estar até aumentando o texto - O & edit_delta < 0 não garante que há uma remoção de conteúdo? Estamos usando ele no filtro de teste 119, pq mesmo não usamos nesse filtro ativo de impedimento? Rjclaudio ^msg 14h30min de 18 de outubro de 2013 (UTC)

Estamos usando o old_size >0 para garantir que o artigo já existia. Não tem problema de usar neste filtro também pelo que entendo.OTAVIO1981 (discussão) 16h49min de 18 de outubro de 2013 (UTC)

Impedido de branquear página

O texto seguinte foi movido de: WP:Filtro de edições/Solicitações#Impedido de branquear página

Olá. Fui utilizar a nova marcação {{ESR-VDA}} na página Johnnas Oliva, porém o FastButtons falhou. Tentei manualmente e não salvou. Achei que fosse o link que havia citado, modifiquei e mesmo assim não passou. A explicação logo após isso era que por estar branqueando a página, possivelmente um vandalismo. Isso nunca aconteceu antes e creio que o filtro é aplicado somente a usuários não-confirmados e IPs. • L‘éditeur^? 14h00min de 24 de outubro de 2016 (UTC)

O filtro 56 se aplica a todos, sem exceção (ver WP:Filtro de edições/56#Parâmetro de usuários). Helder 15h06min de 24 de outubro de 2016 (UTC)

@He7d3r: isso não acontecida com a atinga marcação de {{VDA}}. Já removi com ela muito mais bytes sem problema algum. Não há um tipo de restrição do filtro para algumas situações, como em marcações de eliminação? • L‘éditeur^? 15h37min de 24 de outubro de 2016 (UTC)

Sim, o filtro teria que levar em conta no mínimo essa predefinição, pois ela deve apagar todo o conteúdo da página, já que VDA não pode permanecer de jeito nenhum. !Silent (discussão) 15h41min de 24 de outubro de 2016 (UTC)

O texto acima foi movido de: WP:Filtro de edições/Solicitações#Impedido de branquear página

Na verdade, quem propõe eliminação semirrápida não deve apagar o conteúdo do artigo, mas sim adicionar a predefinição no início da página. Então acredito que a configuração atual do filtro esteja correta. Helder 17h44min de 24 de outubro de 2016 (UTC)