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)

@He7d3r: houve um consenso aqui em extinguir a atinga marcação de {{VDA}} e incluí-la no sistema de ESR, criando então a {{ESR-VDA}}. Todo conteúdo que violar os direitos autorais deve ser removido, e é isso que tanto a marcação antiga quanto a nova fazem. No entanto, o filtro só começou a barrar com o novo template. • L‘éditeur^? 18h20min de 24 de outubro de 2016 (UTC)

Exato. VDA é VDA e não deve permanecer na página. O que essa predefinição faz é exatamente o mesmo que as outras que foram fundidas a ela faziam. !Silent (discussão) 18h33min de 24 de outubro de 2016 (UTC)

Então também falta atualizar a página da política e a documentação da predefinição, pois nenhuma delas menciona essa remoção... Helder 19h44min de 24 de outubro de 2016 (UTC)

Em WP:VDA é mencionado que "Se todo o conteúdo de uma página for suspeito de infração de direito de autor, então o conteúdo do artigo deve ser substituído pela nota padrão {{VDA}}". !Silent (discussão) 19h48min de 24 de outubro de 2016 (UTC)

Se entendi bem a proposta aprovada na Esplanada, passamos a ter duas ações independentes:

• VDA flagrante, isto é, inequívoco, provado: ER (regra 13), que resulta em eliminação imediata
• VDA suspeito, isto é, uma desconfiança para a qual não existe prova explícita: ESR-VDA, que resulta em uma espera de prova de que não é VDA ou solicitação de permissão à OTRS.

Assim, indicação para ESR deve, sim permanecer na página, uma vez que a possível VDA é apenas uma suspeita, não algo inequívoco. Kleiner ^msg 19h49min de 24 de outubro de 2016 (UTC)

Não somente para casos suspeitos, como de confirmados. Porém, nem todos os casos confirmados são casos de ER#13 devido a possibilidade de OTRS. • L‘éditeur^? 19h52min de 24 de outubro de 2016 (UTC)

??? Se o VDA é confirmado, o que faz alguém deixar de usar ER pra usar ESR? Como assim, possibilidade de OTRS para VDA confirmado? Kleiner ^msg 19h56min de 24 de outubro de 2016 (UTC)

Textos VDA potencialmente enciclopédicos podem ser mantidos caso o autor permita. Leia mais em WP:OTRS. • L‘éditeur^? 20h00min de 24 de outubro de 2016 (UTC)

hahaha, amigo, leia WP:DA. Se o autor permitiu, segundo a licença aceita aqui, não é VDA, não há violação. Não existe VDA mantida, se foi mantida é porque não é mais Violação de Direitos Autorais. Outra coisa, não existe "possibilidade de OTRS". Se foi feito um pedido à OTRS, tem que esperar o resultado do pedido, não é caso de eliminação. Se não foi feito pedido algum, não tem porque deixar de marcar ER pra marcar ESR, esperar um pedido que provavelente nunca virá. Kleiner ^msg 20h14min de 24 de outubro de 2016 (UTC)

Me referia à página da política de eliminação semirrápida que citei acima. Helder 20h07min de 24 de outubro de 2016 (UTC)

A questão me parece muito simples:

• VDA provado sem pedido à OTRS: ER (branqueando ou não, não importa).
• Suspeita de VDA sem pedido à OTRS: ESR sem branqueamento.
• VDA provado ou suspeito com OTRS em andamento: ESR com prorrogação de até 15 dias para esperar o resultado do ticket, também sem branqueamento.

Kleiner ^msg 20h18min de 24 de outubro de 2016 (UTC)

Não percebo seus motivos de graça. Somente pode averiguar se há pedidos de OTRS em aberto os seus voluntários. Nós, meros editores da Wikipédia, temos apenas de esperar eles emitirem o ticket. Não temos bola de cristal. A marcação antiga de VDA dava 30 dias (com o conteúdo removido) para esperar o OTRS. O consenso foi integrá-lo a ESR e diminuir esse tempo que era exagerado. Talvez esteja estranhando o processo por não estar familiarizado com a politica de eliminação nem ter participado da discussão. • L‘éditeur^? 20h34min de 24 de outubro de 2016 (UTC)

Acho engraçado esse seu paternalismo de vir colocar link pra documentação como quem diz: "vá aprender mais". Eu já encontrava, discutia, marcava e apagava VDA antes mesmo de você ter conta aqui. Se você tivesse lido mais em WP:OTRS, veria que não é preciso ter bola de cristal; existe predef pra marcar páginas com ticket pendente (algo colocado por quem fez o pedido ou por quem assumiu o ticket). A proposta na Esplanada foi simplificar o processo de eliminação de VDA que era conflitante, já que não havia padronização entre a ER13 e as 3 ou 4 marcações de VDA distintas, cada uma com uma documentação. O consenso alcançado na esplanada (que já li e reli, não preciso participar da discussão pra ler seu resultado) foi exatamente o que já expus e repito novamente: VDA provado >> ER13, VDA suspeito >> ESR-VDA. A dúvida que está causando essa discussão é tão somente se o texto em ESR-VDA deve ser removido ou deixado no artigo. Eu argumento que deve ser mantido, já que suspeita não é prova, e temos que assumir a boa-fé sempre que possível. Kleiner ^msg 23h14min de 24 de outubro de 2016 (UTC)

Já marcava antes de eu ter conta? Ora, as coisas mudaram muito de lá pra cá e aparentemente andas sumido da área pois não o vejo. Além disso, parece também não saber o que é um VDA impróprio da regra ER#13. Então você quer eliminar um VDA antes mesmo de dar a opotunidade do autor enviar para OTRS? Pois este não é procedimento atual, se quiser mudar, fique livre a criar uma proposta na esplanada. • L‘éditeur^? 23h25min de 24 de outubro de 2016 (UTC)

Você quer qualquer outra coisa, menos discutir o assunto chave aqui (apagar ou não texto suspeito de VDA sob ESR). O Silent fez uma nova proposta onde, explicita e inequivocamente propôs usar ESR-VDA pra casos suspeitos e ER13 pra casos de VDA confirmados, proposta essa aprovada por MachoCarioca, Bia, Luk3, Darwin, Stegop, Papa Christus, Wikifer e, vejam só, até um usuário chamado "L'editeur" concordou mais de uma vez. Ponto final. Querer negar isso é querer negar que 1+1=2. Nunca disse que antigamente se fazia assim ou assado (até porque, se procurar todo meu histórico, jamais encontrará edição minha usando ER13), estou falando do agora, do decidido por consenso na Esplanada (por você mesmo e outros, sem eu ter metido o bedelho em nada). Kleiner ^msg 00h24min de 25 de outubro de 2016 (UTC)

O assunto é o mesmo ainda: esse filtro está impedindo {{ESR-VDA}} de funcionar corretamente. Será que tive um lapso enorme ou ainda não entendeu a proposta? Jamais suspeita de VDA deve ser removida de qualquer artigo sem que apresente evidências concretas da suspeit). A {{ESR-VDA}} remove justamente porque são VDAS confirmados e deu-se o periodo de 7 dias para que o autor envie OTRS (E adivinha quem criou o template assim? Ele mesmo! O proponente !Silent). Após o ticket de em andamento, a marcação pode até ser removida. Mas parece somente está contra as novas regras e sequer participou da discussão da esplanada. • L‘éditeur^? 00h36min de 25 de outubro de 2016 (UTC)

Na verdade, como pode ver no teste da predef e na página da proposta, o que se ficou decidido foi justamente o que Kleiner disse: ER#13 para casos flagrantes e ESR-VDA para casos suspeitos. Então, esclarecida a dúvida, farei com que o FastButtons não apague mais o conteúdo inteiro da página. !Silent (discussão) 01h10min de 25 de outubro de 2016 (UTC)