A construção dos dados sobre os plugins do WordPress

Concluída a coleta de dados do core do WP, partiu-se para a coleta de dados dos plugins. O processo foi semelhante, mas um pouco mais complexo, e as primeiras tentativas foram frustradas, por se tratar de um repositório muito maior. No momento da coleta, o WordPress possuía 43.821 plugins, separados por diretórios, em um único repositório SVN com mais de 1.300.000 revisões. Primeiramente tentou-se criar um clone do repositório utilizando a ferramenta git-svn107_{. Porém, isso não deu certo,}

provavelmente por algum tipo de restrição de banda no servidor que hospeda o SVN. O processo que estava clonando o repositório ficou rodando por alguns meses sem chegar a nem dez por cento do total de revisões. Enquanto ele era executado, buscou-se outras alternativas. A opção seguinte foi entrar em contato por e-mail com as mantenedoras da infraestrutura do WP e solicitar uma cópia do repositório SVN. A cópia foi negada, pois, ao longo da história, desenvolvedoras de plugins enviaram sem querer informações sensíveis para o repositório. Por mais que essas informações não sejam mais acessíveis ao público, elas estariam disponíveis numa cópia completa do repositório e não havia uma maneira simples de gerar uma cópia sem elas.

Por fim, a solução utilizada, sugerida por uma das mantenedoras do repositório do WordPress, foi gerar com o próprio SVN um arquivo com todo o histórico dos commits. Esta opção não havia sido considerada antes, pois ela limita o escopo das informações disponíveis. Com o histórico dos commits não é possível saber o número de linhas adicionadas ou removidas para cada uma das alterações feitas, uma informação que foi extraída e utilizada para o repositório do core do WP, já que nesse caso foi possível obter uma cópia completa do mesmo.

Para gerar um arquivo com o histórico de commits, o seguinte comando foi utilizado:

svn log http://plugins.svn.wordpress.org -v > plugins_svn_log

Ele faz com que seja gerado um arquivo chamado plugins_svn_log com informações como data de criação, autora, mensagem e arquivos alterados para todos os commits do repositório. Uma vez gerado o arquivo, o CVSAnalY foi utilizado para importar essas informações para um banco de dados MySQL:

cvsanaly2 --repo-logfile=plugins_svn_log --db-user=USUARIO --db-

password=SENHA –db-database=NOME_DA_BASE_DE_DADOS -g

--extensions=WordPressPlugins

Existem algumas diferenças entre o comando utilizado para extrair informações do repositório do core e o do repositório de plugins. O parâmetro --repo-logfile foi utilizado para, ao invés de extrair as informações de uma cópia local do repositório, especificar um arquivo. Além disso, o parâmetro -g foi usado para que o CVSAnalY imprimisse na tela mais informações sobre a sua execução. No caso dos plugins, por se tratar de um número muito maior de commits, saber o andamento do processamento dos dados foi útil. A extensão “WordPress” não foi utilizada, já que a tag “props” não é empregada no repositório de plugins, e a extensão “CommitsLOC” também não foi utilizada, já que o arquivo com os commits não possui informações sobre linhas adicionadas e removidas em cada commit. Foi adicionada a extensão “WordPressPlugins”108_{, que, assim como a extensão “WordPress”, foi criada}

especificamente para esta pesquisa. Ela permite identificar a qual plugin pertence um commit feito no repositório. Uma cópia do banco de dados populado pelo CVSAnalY com os dados do repositório de plugins do WordPress está disponível no repositório desta dissertação109_.

A seguinte consulta SQL foi então utilizada para extrair o número de commits feitos por cada uma das desenvolvedoras em cada um dos plugins, e popular uma nova tabela nomeada plugins.ods110_:

SELECT p.name, s.wordpress_plugin, COUNT(s.rev) FROM people p, scmlog s WHERE p.id = s.committer_id AND p.name != 'plugin-master' AND wordpress_plugin IS NOT NULL GROUP BY wordpress_plugin, p.name ORDER BY COUNT(s.rev);

108 _{Disponível em: https://github.com/MetricsGrimoire/CVSAnalY/pull/108. Acesso em: 17 jan. 2017.} Enquanto a comunidade que mantém o software não revisa a sugestão de alteração enviada para adicionar a extensão para suportar o caso do repositório de plugins do WordPress, é possível utilizar o seguinte fork do CVSAnalY: https://github.com/rodrigoprimo/CVSAnalY. Acesso em 17 jan. 2017.

109 _{Em função do limite do tamanho de arquivos que podem ser enviados ao GitHub foi necessário dividir}

a cópia do banco de dados em três. Disponível em:

https://github.com/rodrigoprimo/mestrado/blob/master/cvsanaly/plugins.1.sql.xz,

https://github.com/rodrigoprimo/mestrado/blob/master/cvsanaly/plugins.2.sql.xz e https://github.com/rodrigoprimo/mestrado/blob/master/cvsanaly/plugins.3.sql.xz. Acesso em: 17 jan. 2017.

110 _{Disponível em: https://github.com/rodrigoprimo/mestrado/blob/master/tabelas/plugins.ods. Acesso em:} 17 jan. 2017.

Esta consulta considera apenas os commits que alteram um único plugin. Cerca de 1000 commits que alteravam mais de um plugin, em um universo de 1.383.368 commits, foram desconsiderados (em sua maioria commits de manutenção do repositório feitos pelas administradoras). Também foram excluídos desta consulta os 58.071 commits (4% do total) do usuário plugin-master, um bot responsável por adicionar novos plugins ao repositório, pelos mesmos motivos discutidos acima quando se abordou os bots do repositório do core do WP.

Com os dados coletados e adicionados à tabela, foi gerada a figura 3 (p. 40), com o percentual de contribuições ao repositório de plugins, e também as figuras 4 (p. 41), 5 (p. 42) e 6 (p. 43), que comparam dados entre o repositório do core e o repositório dos plugins.

Por fim, o script get_location.php foi usado novamente para identificar o país de residência das desenvolvedoras pesquisadas, a planilha foi atualizada e foram produzidas as figuras 12 (p. 58), 13 (p. 60) e 14 (p. 62). Neste caso o comando foi utilizado de maneira idêntica ao que foi descrito acima quando se discutiu a extração da localização das core developers.

Ainda sobre a localização das membras da comunidade do WordPress, um bom exemplo de transbordamento causado pelas categorias usadas nesta dissertação, que reforça a ideia de dado construído e problematiza a noção de dado “objetivo”, é as desenvolvedoras que se identificaram como nômades em seus perfis no WordPress.org. Ao escolher o país de residência como recorte para problematizar a noção de global, elas foram deixadas de fora. Um outro recorte possível, e muito mais trabalhoso já que esta informação não está facilmente disponível, seria o país de nascimento das membras da comunidade do WordPress, ao invés do de residência. Isso incluiria as nômades, mas não tornaria o dado mais objetivo, já que outros transbordamentos ocorreriam, por exemplo, pessoas que nasceram em um país e se mudaram ainda no início da infância para outro.