Usuário:HenriqueCrang/tarefa

Grupo de Usuários Wikimedia no Brasil
Ir para navegação Ir para pesquisar

Página de realização da Tarefa para vaga de Data analyst consultant. Aqui será feito um relato passo-a-passo das atividades feitas pelo Usuário:Crang115.


Após ler as duas propostas de tarefas foi feita a opção por trabalhar com a segunda:

"Entre abril e junho de 2012, a comunidade fez um experimento: atribuiu aos reversores ferramentas e autorização para bloquearem vândalos. Que dados você coletaria e como para fazer uma análise sobre as vantagens e/ou desvantagens dessa possível mudança nas regras da Wikipédia?"

Começando os Trabalhos[editar]

Feita a escolha da tarefa fui buscar dados já coletados sobre o assunto disponíveis. Observei a tabela de dados compilada pelo OTAVIO1981 disponível na própria página do meta com a tarefa e resolvi brincar um pouco com os números alí apresentados, que mostram quantidades de edições e reversões feitas por administradores e reversores.

Torturando os Dados[editar]

Ao ter posse de alguns dados sobre um assunto que se está começando uma análise é sempre importante torturá-los um pouco. Nesse processo de tortura podemos apertá-los, espremê-los, virá-los de cabeça para baixo(!) na tentativa deles revelarem alguma informação relevante.

Dados brutos de edições e reversões[editar]

Começo aqui a fazer alguns cruzamentos com os dados disponibilizados pelo OTAVIO1981. Um dos indicadores que podemos utilizar para medir a eficácia do experimento observando apenas esses dados é a diminuição de vandalismos dado o esperado aumento na velocidade do bloqueio. Assim, utilizarei como métrica de comparação o número de edições feitas para cada reversão em cada período e sua evolução ao longo do tempo dentre reversores, administradores e também do somatórios dos dois grupos.

Quanto maior for esse índice, mais edições foram feita a cada reversão, o que indica um peso menor das reversões no trabalho dos usuários. Quanto menor for índice, mais peso tiveram as reversões dentre as atividades realizadas pelos usuários.

Relação de Edições por Reversões feitas por Administradores e Reversores

Ano 2011 2012
Grupo 1º Trimestre 2º Trimestre 1º Trimestre 2º Trimestre
Edições 212117 158674 197686 206265
Reversões 33247 33568 36973 36736
Edições por Reversão 6.38 4.73 5.35 5.61
Variação em relação ao período anterior - -25.91% 13.11% 5.01%


Relação de Edições por Reversões feitas por Reversores

Ano 2011 2012
Grupo 1º Trimestre 2º Trimestre 1º Trimestre 2º Trimestre
Edições 128098 87810 121970 131804
Reversões 17364 16405 22034 22496
Edições por Reversão 7.38 5.35 5.54 5.86
Variação em relação ao período anterior - -27.44% 3.42% 5.84%


Gráfico feito para comparar a evolução do índice de edições a cada reversão de administradores e reversores da Wikipédia lusófona.

Relação de Edições por Reversões feitas por Administradores

Ano 2011 2012
Grupo 1º Trimestre 2º Trimestre 1º Trimestre 2º Trimestre
Edições 84019 70864 75716 74461
Reversões 15883 17163 14939 14240
Edições por Reversão 5.29 4.13 5.07 5.23
Variação em relação ao período anterior - -21.95% 22.75% 3.17%


Ao observar esses dados podemos ver que a atribuição aos reversores de ferramentas e autorização para bloquearem vândalos no 2º Trimestre de 2012 (entre abril e junho de 2012) não surtiu um impacto muito significativo na relação de edições por reversão dos Reversores, que apresenta um crescimento em relação ao período anterior apenas levemente superior ao dos Administradores.

Assim, esse cruzamento de dados não parece ser muito elucidativo para nossa questão específica. Porém, podemos observar nele algo muito interessante: a brusca queda do índice no segundo trimestre de 2011 aconteceu com o número de reversões se mantendo relativamente estável e com o número de edições tendo uma considerável diminuição. O que isso signifca? por enquanto não tenho menor ideia...

Para continuar olhando esses dados pensei em ir atrás dos números do 3º e 4 trimestre de 2011, porém me deparei com algo preocupante: a planilha feita pelo usuário Rjclaudio possui dados que não batem com os apresentados pelo OTAVIO1981! Enviei mensagens para os dois explicando a situação e perguntando qual metodologias eles utilizaram na obtenção dos dados, afim de entender se (e quais d)esses dados são confiáveis.

Após trocar mensagens com o OTAVIO1981 pude ver aqui um rascunho do "Relatório de Análise do teste 'Reversores bloqueando vândalos'", que esclarece a metodologia utilizada na obtenção dos dados que utilizei. A partir desse relatório e da interação com o Jbribeiro1 aqui na página pude entender melhor as questões envolvidas nesse experimento e então me aprofundei no longo debate ocorrido na comunidade para analisar seus resultados. Entendendo melhor a questão além dos número que utilizei para começar o trabalho pude perceber que existem vários outros fatores que devem ser levados em consideração para podermos dar uma resposta com segurança sobre o experimento.

A tortura de dados me apontou um caminho de partida, mas agora a deixarei de lado para ir atrás desses outros fatores que estão fazendo falta em nossa análise.

Questões[editar]

Usar total do mês ou apenas os primeiros 28 dias?[editar]

Na análise feita pela comunidade foram utilizadas essas duas abordagens. A primeira pode causar distorções pois os trimestres não teriam o mesmo número de dias, porém a segunda também pode causá-las caso os dias descartados da análise sejam dias de semana de maior atividade de nosso espaço amostral de usuários (eles podem ser mais ativos nos fins de semana ou em dias de semana).

Face esse cenário, para evitar ambas possíveis distorções sugiro que sejam utilizados os dados de todos os dias do mês, e que eles sejam dividos pelo número de dias de cada mês. Assim, teremos o dado "média diária do mês", que pode ser utilizado para comparações de períodos de durações distintas sem causar prejuízo para a comparação.

Filtro de Edições pode impactar os dados?[editar]

O filtro de edições impede usuários de realizarem algumas edições que potencialmente seriam revertidas. A alteração(ou adição ou remoção) de um filtro pode impactar no número de reversões demandandas. Será que no período analisado ocorreu alguma mudança relevante nos filtros? E se aconteceu, foi ela impactante para a demanda de reversões?

Por exemplo, o filtro de Conteúdo ofensivo que pode evitar vandalismos foi alterado no dia 21-02-2012. Se essa alteração tiver mudado significativamente o número de resultados desse filtro ela pode interferir em nossa análise.

Para responder a essa questão acredito que possamos buscar o número de vezes que um filtro impediu uma edição por mês (fazendo o mesmo ajuste "média diária do mês" da questão) e analisá-lo junto aos números de reversões para sabermos se ele pode ter impactado ou não no esperimento.

Atuação dos Bots pode impactar os dados?[editar]

Bots têm participação relevante no número de reversões

A mesma dúvida levantada para os filtros vale para os bots. Uma pesquisa feita com dados de 2011 mostra que os Bots têm participação de quase 20% nas reversões feitas na Wikipédia lusófona. A alteração da eficiência dos Bots pode impactar diretamente na demanda por reversões feitas por humanos.

Afim de conferir se isso não pode estar influenciando a curva de nossa análise devemos observar também a evolução das reversões nos trimestres (utilizando a mesma "média diária do mês" explicada anteriormente).

Quantos Reversores utilizam o Huggle?[editar]

Essa é uma questão "2 em 1"! Como vemos na figura ao lado, em 2011 quase 30% das reversões foram feitas por usuários não-administradores sem auxílio do Huggle. Saber quais revisores utilizam ou não a ferramenta e qual seu volume de atuação pode nos mostrar o impacto de usuários que não são nem administradores e nem reversores em nossos dados. Saber o comportamento desse grupo de usuários e monitorá-lo ao longos dos trimestres analisados pode nos mostrar variações na curva assim como as duas últimas questões.

Além disso, cruzar os dados entre reversores que usam e não usam a ferramenta Huggle pode nos mostrar o quanto ela ajuda (ou não) o trabalho. Esse dados podem fomentar futuramente campanhas de melhoria na qualidade do dia-a-dia das pessoas que desempenham a função de reversores.

Quantos bloqueios os administradores deixaram de fazer?[editar]

Aqui estamos olhando diretamente para a relação entre edições e reversões. Porém, se o experimento foi bem sucedido em diminuir a carga de trabalho dos administradores em realizar reversões e bloqueios isso não significa que necessariamente eles tenham gasto esse tempo com edições. Administradores tem outras tarefas a realizar, e esse aproveitamento pode não estar sendo constatado por nossa avaliação.

Buscando averiguar essa informação, devemos buscar o número de bloqueios feitos tanto pelos administradores como pelos reversores. Se confirmando que a carga de trabalho dos administradores foi aliviada, poderemos depois buscar saber onde esse tempo foi gasto seguindo pistas que essa pesquisa nos dará.

Qual percentual de vandalismo vem de IPs e contas não confirmadas?[editar]

Conforme a página do experimento os reversores tiveram permissão apenas de bloquear IPs e contas não confirmadas. Saber esse percentual pode ajudar a ler com mais clareza o resultado da questão anterior.

Qual a frequência individual dos vândalos?[editar]

Saber a frequência de repetição individual dos vândalos e quem trata as reincidências pode nos ajudar a saber o quanto de trabalho dos administradores pode ser poupado com os bloqueios feitos pelos reversores.

Em um cenário que os reversores não podem bloquear, eles podem reverter um vandalismo e solicitar bloqueios aos administradores. No tempo entre a solicitação do reversor e o atendimento pelo administrador, o vândalo pode atacar novamente. Nesse caso, se o reversor não estiver atento, o administrador provavelmente quando for olhar o caso para decidir pelo bloqueio irá reverter o novo vandalismo. Se esse cenário for comprovado pelos dados, muito possivelmente o bloqueio feito diretamente pelos reversores irá diminuir a carga de trabalho dos administradores.

Além disso, olhando para a curva de nossa análise vemos uma variação muito pequena no número de reversões feitas, porém esse número pode nos mostrar se existia uma tendência de crescimento do vandalismo e se o experimento foi responsável por manter estável evitando um pico no trimestre.

Quanto tempo leva entre um pedido de bloqueio e sua análise?[editar]

Esse dado se analisado junto das informações da questão anterior pode nos mostrar quantos atos de vandalismo foram evitados com o bloqueios sendo feito diretamente pelos reversores.

Se o intervalo entre a reincidência for menor que o tempo que buscamos descobrir aqui poderemos afirmar que o experimento terá diminuido a demanda por reversões.

Qual o desvio padrão de nossas médias?[editar]

Nossos dados apontam para um número 3 vezes maior de reversores sobre administradores (114 x 37), porém sabemos que todos eles não trabalham no mesmo ritmo e nem a todo tempo. Os números brutos se analisados per capta nos mostram um trabalho mais intenso do menor grupo sobre o maior. Porém, será que todos os reversores estão ativos?

Observando o desvio padrão poderemos ver o quanto discrepante pode estar a atuação dos usuários, e a partir dessa informação poderemos, se for o caso, criar uma linha de corte que separe apenas os usuários considerados ativos e recalcular apenas com eles a relação per capta de trabalho para compararmos a atuação dos dois estatutos.

Quais dados coletar[editar]

Para responder as questões da seção anterior será necessário coletar dados de distintas naturezas para cruzá-los

Data de Entrada e Saída de Administradores e Reversores[editar]

Para evitar a possibilidade de que o afastamento (ou mudança de estatuto) de um grande contribuidor afete nossa pesquisa é importante que possamos coletar os dados sabendo qual era o estatuto do usuário na data da ação que está sendo analisada.

Assim, considerando que iremos estudar apenas dados de Janeiro de 2011 a Junho de 2012, necessitaremos da lista de todos os administradores e reversores de 01-01-2011 00h00 e todas as atribuições e retiradas de usuários desses estatutos até 30-06-2012 23h59. O dado obtido deve contém: usuário, estatuto anterior, novo estatuto, data e hora da alteração.

Todas as ações de Administradores e Reversores[editar]

Uma das possíveis vantagens que o experimento pode ter gerado é a melhoria do tempo gasto por administradores e reversores na Wikipédia. Dessa forma, é importante termos a descrição de todas as ações realizadas pelo grupo apontado na coleta anterior no período estudado (de 01-01-2011 00h00 a 30-06-2012 23h59). Aqui também estarão os bloqueios feitos pelos administradores, que serão importantes para nossa avaliação. O dado obtido deve conter: usuário, estatuto, ação (reversão, edição de artigo, criação de artigo, bloqueio, ...), data e hora.

Todas as ações de Reversão[editar]

Para mensurar o quanto a participação de bots ou usuários não reversores nem administradores podem influenciar nossos dados, para tentar identificar padrões na ação de vândalos individualmente assim como para avaliar o uso do Huggle nas reversões se faznecessário coletar informações sobre todas as reversões feitas no período de de 01-01-2011 00h00 a 30-06-2012 23h59). O dado obtido deve conter: usuário reversor, usuário revertido, usuário revertido é confirmado ou não, reversão feita pelo Huggle ou não, data e hora.

Lista de Bots Reversores[editar]

Para poder filtrar as informações as informações anteriores precisaremos de uma lista dos Bots que atuam na Wikipédia desde 01-01-2011 00h00. É importante não deixarmos de fora da lista bots que possam não estar mais ativos atualmente mas que tenham atuado no período de nossa amostra. O dado obtido deve conter: nome do usuário bot.

Edições Não Autorizadas por Filtros de Edição[editar]

A atuação dos filtros de abusos pode evitar vandalismos. Assim, é preciso coletar todas as tentativas de edição que não foram autorizadas no período pesquisado para saber se nenhuma mudança neles pode ter gerado impacto nas informações que estamos analisando. O dado obtido deve conter: filtro, usuario não autorizado, usuário não autorizado é confirmado ou não, data e hora.

Como Coletar Dados[editar]

Para obter os dados previstos no tópico anterior talvez seja necessária mais de uma abordagem diferente. Aqui irei explicar as duas principais abordagens técnicas e uma adicional.

No caso da avaliação específica desse experimento, que apresenta um recorte temporal definido, podemos trabalhar com uma base de dados que seja populada apenas uma vezes para gerar relatórios e gráficos estáticos. Porém, se for o caso desse ou outros experimentos serem analisados sob a mesma ótica ao longo do tempo e exista o interesse de ser feito um acompanhamento diário da evolução dos índices, os script de coleta de dados podem ser programados para rodar todos os dias, coletando apenas as novas informações para a base de dados auxiliar e permitindo assim a criação de relatórios e gráficos dinâmicos, que se atualizem automaticamente.

Acesso a API[editar]

Uma das formas de acesso aos dado é a API da Wikipédia. API é a sigla em ingês para Interface de Programação de Aplicativos, que basicamente significa uma forma de interagir com os serviços de um sistema, obtendo ou fornecendo dados, através de um canal de comunicação sem ser necessário ter acesso direto a base de dados ou ao software.

A a API do MediaWiki está bem documentada, e inclusive pude ver que os dados que usei no início dessa tarefa trabalhados pelo OTAVIO fora obtidos através da API por meio do uso de um script feito pelo usuário Hélder.

Navegando por páginas HTML[editar]

Na página de discussão foi apresentada uma questão: todas as informações que queremos obter estão armazenadas na base de dados? Somando-se a essa questão, formulo outra: todas as informação que precisamos estarão disponíveis através da API?

Muitas vezes a resposta para essas duas tarefas pode ser não. Mas, sabemos que algumas das informações que queremos estão em páginas do projeto. Assim, nos casos quando não for possível coletar os dados através da API, poderemos desenvolver script que identifiquem padrões em páginas indicadas por nós e façam a coleta de dados.

Pesquisas com usuáros[editar]

As vezes não iremos encontrar simplesmente nos bancos de dados respostas para nossas perguntas. Algumas ações que influenciam em nossas análises não estão logadas, ou nem mesmo poderia ser.

Na página de discussão pensamos na seguinte questão: "e se o experimento de fato diminui o trabalho dos administradores, mas isso não se reverteu em mais trabalho em outras possíveis atividades dentro da Wikipédia?". Como poderíamos seguir essa trilha? Olhando para nossos dados, poderemos apenas (se for o caso), apontar para uma diminuição nas atividades desse estatuto, porém sem nenhum poder de gerar conclusões. Em casos como esse, para chegarmos a conclusões se farão necessárias pesquisas como essas para apontar as tendências dos usuários.

Exibindo Resultados[editar]

Coletados os dados, chega o momento de cruzá-los e exibir resultados. Conforme dito no tópico sobre a coleta dos dados, aqui não será necessário para esse experimento criar resultados dinâmicos, pois temos um recorte de tempo pré-estabelecido no passado.

Observando a página do experimento podemos identificar Possíveis efeitos positivos e Possíveis efeitos negativos que foram listados pela comunidade. Acredito que nessa fase seja importante que os resultados da análise procurem ajudar na resposta dessas questões. Dessa forma, vou listá-las abaixo e comentar em azul como a análise pode ajudar a avaliação das questões.


Possíveis efeitos positivos[editar]

  • Quanto menos tempo e energia o administrador gastar com bloqueios óbvios, mais ele poderá atuar nas outras tarefas que dependem de mais análise e confiança da comunidade
    • Possível contra-argumento: Os bloqueios a vandalos são as tarefas que ocupam menos tempo entre as ações dos administradores, não tendo muito efeito para os administradores

Respondendo a questão Quantos bloqueios os administradores deixaram de fazer? teremos já um vator de quanta energia deixou de ser gasta nesse processo, e depois observando os dados de Todas as ações de Administradores e Reversores e relacionando os dois poderemos ver se o possível contra-argumento tem razão.

  • Maior agilidade no bloqueio de vândalos, pois temos mais pessoas atuando na área. Com isso, temos menos dano para o projeto e os vândalos são mais rapidamente orientados e reabilitados.
    • Estatística: nos pedidos de bloqueio de dezembro de 2011, de 58 pedidos de bloqueio a ips, 26 pedidos foram atendidos em menos de 3 horas, 6 entre 3~6 horas, 12 com mais de 6, e 14 não tiveram resposta (pode ter sido efetuado o bloqueio, mas não teve resposta ao pedido). Alguns dos pedidos atendidos foram negados com a justificativa de "parou de editar" (ou seja, a demora na resposta tornou o bloqueio desnecessário)

Respondendo a questão Quanto tempo leva entre um pedido de bloqueio e sua análise? veremos claramente se foi obtida a esperada maior agilidade.

  • Eliminação da burocracia de precisar fazer um pedido a administradores para bloquear um vândalo quando o próprio usuário é capaz de fazer esse bloqueio

Aqui debruçados na informação Todas as ações de Administradores e Reversores poderemos ver se os pedidos de bloqueio diminuiram, e quanto os reversores se tornaram autônomos nessa tarefa. Nesse ponto será importante analisar a variância dos números entre os reversores, pois um grupo pequenos de reversores que tenham utilizado bastante a ferramenta pode esconder da curva um grupo maior que a tenha pouco utilizado.

  • Redução da pirâmide de poder, dando a outros usuários além dos administradores a ferramenta de bloqueio a vândalo

Observar a questão anterior com informações per capta deixará claro quantos reversores mudanram de lugar na pirâmide utilizando a ferramenta.

  • Possibilidade de bloquear vândalos diretamente pelo Huggle

Respondendo a questão Quantos Reversores utilizam o Huggle? e observando quais ações de bloqueio foram utilizadas veremos se essa possibilidade foi de fato absorvida pelos reversores.


Possíveis efeitos negativos[editar]

  • As ferramentas de administradores estarão muito divididas entre os diversos estatutos, permitindo que um usuário tenha acesso a eliminação e ao bloqueio (limitado) sem ser administrador, criando uma espécie de estatuto paralelo de administrador (administrador completo, e semi-administrador)

Nesse caso entendo que os dados não serão suficientes para responder a questão. Cabe a realização de uma pesquisa com os administradores para saber se durante o experimento ele se sentiram convivendo com semi-administradores

  • Fazer do estatuto de reversor uma etapa intermediária (pré-requisito) para ser administrador, pois os reversores terão acesso parcial a uma ferramenta dos administradores
  • Redução o número de candidatos a administradores, com usuários que poderiam ser administradores se tornando apenas reversores,
    • Possível contra-argumento: a ferramenta de bloqueio terá atuação limitada, não impedindo que quem queira a ferramenta completa se torne administrador.

Essa questão não tem como ser avaliada pela análise. Ela demanda um espaço de tempo maior para que candidaturas a administrador e perfis de candidatos possam ser avaliados.

  • Mau uso das ferramentas por reversores que não estão aptos a usar a ferramenta
    • Possível contra-argumento: Reversores que não sabem identificar um vandalismo óbvio não deve ser um reversor, conforme os critérios para conceder (e remover?) o estatuto.

Aqui podem ser analisado o número de bloqueios feitos pelos reversores que foram questionados, e comparar esse número com o percentual para os administradores. Esses dados provavelmente não estarão em nenhuma base de dados, e precisarão ser coletados através de um script que leia páginas HTML.

  • Passa a ideia que apenas os ips e não-confirmados realizam vandalismos óbvios
    • Possível contra-argumento: Não uma afirmação que são apenas esses, é apenas uma restrição, .

Respondendo a questão Qual percentual de vandalismo vem de IPs e contas não confirmadas? poderemos saber se essa ideia se comprova na ação. Se também se quiser avaliação a percepção dos usuários sobre a questão, então será necessária uma pesquisa direta com os usuários além dos dados.

  • Aumento dos requisitos para ser reversor. Além de saber identificar um vandalismo óbvio, será preciso também conhecer (parcialmente) a política de bloqueio. Apesar de não ser necessário aos atuais reversores fazerem os bloqueios, alguns usuários que poderiam ser reversores não serão mais (perda do estatuto por bloqueios mal efetuados, não se candidatar por não achar que conhece a política de bloqueios, não ser aprovado na avaliação dos administradores)

Essa questão não tem como ser avaliada pela análise. Ela demanda um espaço de tempo maior para que candidaturas a reversor e perfis de candidatos possam ser avaliados.

  • Com o aumento dos requisitos, o acesso ao estatuto pode passar por uma mudança, ficando com mais supervisão e burocracia. O acesso atualmente é bem facilitado por ser um estatuto de pouco dano ao projeto.

Essa questão não tem como ser avaliada pela análise. Para respondê-la, seria interessante fazer uma pesquisa com os administradores.

  • Estigmatiza o cargo de administrador, como se ser reversor (e eliminador) fosse algo tranquilo e sem preocupação enquanto ser administrador fosse chato, irritante, algo da mais suprema responsabilidade

Outra questão sobre percepção que não possui resposta nos dados. Mas em um recorte de tempo maior, com o experimento funcionando e candidaturas a reversor e a administrador acontecendo poderíamos tentar apontar algumas tendências.

  • Bloqueio é bloqueio. Não é bom fragmentar os bloqueios.
    • Possível contra-argumento: Os bloqueios já são fragmentados, na política de bloqueio.

Observando a Quantos bloqueios os administradores deixaram de fazer? poderá se ter uma ideia de quanto aumentou a fragmentação dos bloqueios.