Arcabouço de Boas Práticas de Desenvolvimento da Wikimedia Brasil: sustentabilidade técnica como responsabilidade organizacional

Em 2025, o Wikidata Query Service passou por uma divisão do seu grafo. O serviço roda sobre o Blazegraph e ultrapassava 16 bilhões de triplas, com crescimento de cerca de 1 bilhão por ano. O motivo da mudança era garantir a escalabilidade e a estabilidade do serviço no médio prazo. Como medida emergencial para evitar uma falha catastrófica, o endpoint SPARQL foi separado em dois: um só com os artigos acadêmicos e outro com o restante do Wikidata. A divisão entrou em vigor em maio de 2025, e consultas que precisam cruzar os dois grafos passaram a exigir federação SPARQL.

Com isso, diversas consultas e ferramentas quebraram, e muitas continuam sem funcionar até hoje. O Scholia é o exemplo mais visível. O impacto foi tão grande, que os mantenedores acabaram migrando o grafo completo para um motor QLever, fora da infraestrutura da Wikimedia.

Mais recentemente, há poucas semanas, no início de setembro, foi a vez do Wikimedia Commons. As tabelas de links foram movidas do cluster de banco de dados s4 para o novo x4 e deixaram de ser atualizadas no s4, pois esse havia crescido demais para operar com eficiência. A mudança travou, logo na primeira semana do concurso, a ferramenta que todos os organizadores do Wiki Loves Monuments usam para acompanhar participantes e estatísticas.

Essas foram decisões técnicas justificadas, mas demonstram como uma ferramenta pode parar de funcionar sem que ninguém tenha mexido no código. Quando isso acontece, a pergunta é sempre a mesma: quem percebe a mudança a tempo, quem entende o código e quem consegue consertá-lo? Se a documentação está desatualizada ou espalhada em vários links, se não fica claro quem mantém a ferramenta, ou se o conhecimento necessário desapareceu junto com a última pessoa que trabalhou nela, a resposta pode ser “ninguém”. Esse é um risco que qualquer ferramenta corre, inclusive as que mantemos na Wikimedia Brasil, como a SARA, o GLAMWiki Brasil, o Capacity Exchange e o QuickStatements 3.0. A situação acarreta riscos diretamente proporcionais à quantidade de pessoas que usam a ferramenta, ou quanto mais inserida no fluxo de trabalho dos wikimedistas a ferramenta está.

Foi pensando nesses e em outros riscos e questões que construímos o Arcabouço de Boas Práticas de Desenvolvimento (ABPD) da Wikimedia Brasil. Este é um documento público, escrito colaborativamente, entregue como parte do nosso Plano de Atividades de 2026, que busca estabelecer uma base comum para o desenvolvimento técnico e programático da organização.

Ao escrevê-lo, reconhecemos que escrever “boas práticas” não é neutro: quem se coloca nessa posição pode acabar exportando os próprios hábitos como se fossem universais. Por isso, o arcabouço não tenta reinventar o que o movimento já consolidou. As diretrizes de desenvolvimento do MediaWiki, as regras do Toolforge, a Política de Privacidade da Wikimedia Foundation e o Código de Conduta Universal continuam sendo o ponto de partida.

O conteúdo nasceu de um levantamento interno de repositórios e ferramentas e de entrevistas estruturadas com pessoas da equipe, prestadoras de serviço e voluntárias. Foram quatro conversas síncronas e uma resposta por escrito. Alguns temas apareceram de forma independente em vários relatos: documentação fragmentada, dificuldade de descobrir o que já existe, caminhos pouco claros para contribuir, dificuldade de reter mantenedores e lacunas de comunicação entre quem desenvolve e quem usa. Esses temas moldaram diretamente as recomendações do documento.

Oito princípios orientam as decisões quando as diretrizes específicas não dão conta de um caso concreto. Entre eles, aberto por padrão, privacidade desde o início, documentação como entregável e redundância: nenhum sistema ou conhecimento crítico deve depender de uma só pessoa. Sustentabilidade antes da inovação, reuso antes da reconstrução, acessibilidade e alinhamento ao movimento completam a lista de princípios.

Na prática, o arcabouço traz compromissos concretos:

• Registro das ferramentas externas das quais dependemos: anota o nível de criticidade de cada ferramenta, o histórico de mudanças que já nos afetaram, a existência de alternativas e quem acompanha as mudanças.
• Catálogo público de ferramentas: para responder duas perguntas antes de qualquer decisão técnica, “isso já existe?” e “a quem eu pergunto?”.
• Documentação acessível a partir de um único ponto: com data da última revisão visível, contato da pessoa responsável e configuração de implantação registrada no próprio repositório.
• Lista de checagem de autoavaliação: avalia cada ferramenta sob critérios como licença, testes, credenciais, acessibilidade e privacidade.
• Ciclo de vida completo para cada projeto: inclui um plano de descontinuação, para não acumularmos ferramentas-zumbi.
• Proteção de dados: uma seção alinhada à Lei Geral de Proteção de Dados (LGPD), com mapeamento de dados pessoais e relatórios de impacto quando necessário.
• IA no desenvolvimento: divulgação do uso de ferramentas de inteligência artificial no desenvolvimentos e na manutenção, preferência por ferramentas de código ou pesos abertos e proibição de usar dados sensíveis nessas plataformas.

O arcabouço não é definitivo. Ele será revisado a cada ciclo estratégico. O documento recomenda também a criação de um comitê permanente, com participação voluntária dos próprios membros da organização, para acompanhar sua aplicação.

Também o escrevemos pensando em outros afiliados, principalmente da Maioria Global, que enfrentam desafios parecidos de capacidade técnica e equipes pequenas. Se o seu afiliado quiser adaptá-lo, basta trocar os exemplos e a escala pelos seus e manter os princípios como ponto de partida.

O documento completo está disponível no Meta-Wiki, em português e em inglês.