Capítulo 3. Infra-estrutura técnica

Índice

O Quê Um Projeto Precisa
Listas de E-mail
Prevenção de Spam
Filtrando os envios
Camuflando endereços em arquivos da lista
Gerenciamento de Identificação e de Cabeçalho
O Longo Debate do Responder a
Duas fantasias
Arquivamento
Software
Controle de Versão
Vocabulário do Controle de Versão
Escolhendo o sistema de Controle de Versão
Usando o Sistema de Controle de Versão
Version everything
Browsability
Commit emails
Use branches to avoid bottlenecks
Singularidade de Informação
Autorização
Bug Tracker
Interação com listas de E-mail
Pré-filtrando o Bug Tracker
IRC / Real-Time Chat Systems (sistemas de bate-papo em tempo real)
Bots (robôs)
Arquivando o IRC
Wikis
Web Site
Canned Hosting
Choosing a canned hosting site
Anonymity and involvement

Projetos de software livre dependem de tecnologia que suportem a captura e integração seletiva de informação. Quanto mais experiente você for para usar estas tecnologias, e em persuadir os outras a usá-las, mais sucesso terá o seu projeto. Isso só torna mais verdadeiro a medida que o projeto cresce. Um bom gerenciamento das informações é o que garante que os projetos não quebrem sob o peso da Lei de Brooks,[14] que diz que adicionar recursos em um projeto atrasado o torna ainda mais atrasado. Fred Brooks observou que a complexidade de um projeto aumenta ao quadrado do númeto de participantes. Quando apenas algumas pessoas estão envolvidas, todos podem falar facilmente entre si, mas quando centenas de pessoas estão envolvidas, não é mais possível para cada pessoa permanecer constantemente a par do que todos os outros estão fazendo. Se um bom gerenciamento de software é sobre fazer com que todos sintam-se como se estivessem trabalhando juntos na mesma sala, a questão óbvia é: o que acontece quando todos em uma sala lotada tentam falar de uma só vez?

Este problema não é novo. Em salas lotadas reais, a solução é solução é um procedimento parlamentar: guias formais de como ter discussões em tempo real para grupos grandes, como assegurar que dissidências importantes não se percam em inundações de comentários de "eu também", como formar subcomissões, como reconhecer quando as decisões são formadas, etc. Uma parte importante do procedimento parlamentar é especificar como o grupo interage com seu sistema de gerenciamento de informações. Alguns comentários são feitos "para registros", outros não. O registro em si é subjetivo a manipulação direta, e é entendido para não ser uma transcrição literal do que ocorreu, mas uma representação do que o grupo está disposto a concordar do ocorrido. O registro não é monolítico, mas assume diferentes formas para diferentes propósitos. Ele compreende os minutos de todas as reuniões, resumos, agendas e suas anotações, relatório das comissões, relatório de correspondentes ausentes, lista com ítens de ação, etc.

Como a Internet não é realmente uma sala, não precisamos nos preocupar em replicar os procedimentos parlamentares que mantém algumas pessoas caladas enquanto outras estão falando. Mas quando nos defrontamos com técnicas de gerenciamento de informações, projetos de código aberto bem executados são procedimentos parlamentares com esteróides. Desde que quase toda a comunicação em projetos de código aberto ocorrem na escrita, sistemas elaborados evoluitam para rotear e identificar o dado corretamente; para minimizar repetições assim como evitar falsas divergências; para armazenar e recuperar dados; para corrigir informações ruins ou obsoletas; e para associar diferentes pedaços informação a medida que novas conexões são observadas. Participantes ativos em projetos de código aberto assumem muito destas técnicar, e irão frequentemente realizar tarefas manuais complexas para assegurar que a informação será roteada corretamente. Mas o grande esforço ultimamente depende de suporte sofisticado de softwares. As mídias de comunicações sozinhas deveriam realizar o máximo de roteamento das informações, identificando, e gravando, e devem disponibilizar para as pessoas no modo mais conveniente possível. Claro que na prática, as pessoas ainda precisam intervir em diversos pontos no processo, e é importante que o software faça com que essas intervenções sejam convenientes também. Mas em geral, se as pessoas cuidarem da identificação e roteamento das informações de maneira minuciosa já na primeira aparição no sistema, então o software deve ser configurado para utilizar o máximo possível estes metadados.

O conselho neste capítulo é intensamente prático, baseado em experiências em um software específico e padrões de uso. Mas o ponto não é ensinar uma coleção de técnicas particulares. Ele também demonstra, através de diversos pequenos exemplos, a atitude geral que melhor encorajará o bom gerenciamento da informação em seu projeto. Esta atitude envolverá uma combinação de conhecimento técnico com o conhecimento das pessoas. O conhecimento técnico é essencial pois o software de gerenciamento de informações sempre requer configuração, além de uma certa quantidade de manutenção e melhorias a medida que surgem novas necessidades (por exemplo, veja a discussão de como lidar com o crescimento do projeto em “Pré-filtrando o Bug Tracker” adiante neste capítulo). O conhecimento das pessoas são necessários pois uma comunidade também requer manutenção: nem sempre é óbvio como usar estas ferramentas como total vantagem, e em alguns casos os projetos possui convenções conflitantes (por exemplo, veja a discussão sobre configurar o cabeçalho Responder a em e-mails enviados a listas de discussão, em “Listas de E-mail”). Todos os envolvidos com o projeto precisarão ser encorajados, no momento certo e da maneira correta, para que eles façam sua parte em manter as informações do projeto bem organizada. Quanto mais envolvido estiver colaborador, maior a possibilidade de que ele aprenda as técnicas mais complexas e especializadas.

O gerenciamento de informação não possui uma solução pronta. Existem muitas variáveis. Você pode ter tudo finalmente configurado da maneira que queria, e ter a comunidade mais participativa, e então o crescimento do projeto fará com que algumas destas práticas sejam impraticáveis. Ou o crescimento do projeto pode estabilizar, e as comunidades de usuários e desenvolvedores estabeleçam uma relação confortável com a infra-estrutura técnica, e de repente alguém vem com uma idéia um novo serviço de gerenciamento de informação, e logo os recém-chegados estarão perguntando por que o seu projeto não está usando-a—por exemplo, isto está ocorrendo agora com diversos projetos de softwares livre que antecedem a invenção do wiki (veja http://en.wikipedia.org/wiki/Wiki). Muitas questões merecem uma análise, envolvendo negociações entra a conveniência daqueles que geram informação e a conveniência daqueles que a consomem, ou entre o tempo requerido para configurar o software de gerenciamento de informação e o benefício que ele traz ao projeto.

Cuidado com a tentação de automatizar demais, isto é, automatizar aquilo que realmente requer uma atenção humana. A infra-estrutura técnica é importante, mas o que faz o um projeto de software livre funcionar é o cuidado—e a expressão inteligente deste cuidado—pelas pessoas envolvidas. A infra-estrutura técnica é principalmente sobre dar as pessoas formas convenientes de fazer isso.

O Quê Um Projeto Precisa

A maioria dos projetos de código aberto oferecem ao menos um conjunto mínimo de ferramentas padrão para gerenciamento da informação:

Web site

Forma principal e centralizar de levar a informação do projeto ao público. O web site também pode servir como uma interface administrativa para outras ferramentas do projeto.

Listas de e-mail

Geralmente o forum de comunicação mais ativo no projeto, e o "meio de registro."

Controle de versão

Permite aos desenvolvedores gerenciar as mudanças de código convenientemente, incluindo a volta de uma versão anterior e uma "mudança portátil". Permite com que todos possam acompanhar o que está acontecendo com o código.

Bug tracker

Permite aos desenvolvedores acompanhar em que eles estão trabalhando, coordenar uns aos outros, e planejar lançamentos. Permite a qualquer um consultar o status de bugs e registrar informações (ex.: reproduzir um erro) sobre bugs em particular. Pode ser usado para rastrear além de bugs, tarefas, lançamentos, novas funcionalidades, etc.

Chat em tempo real

Um local para discussões rápidas e simples, e para troca de perguntas e respostas. Nem sempre é arquivado por completo.

Cada ferramenta deste conjunto é endereçada para uma necessidade específica, mas suas funções são inter-relacionadas, e as ferramentas precisam ser feitas para trabalharem junto. A seguir examinaremos como elas podem fazer isso, e mais importante, como colocar as pessoas para utilizá-las. O web site não é discutido até o fim, pois ele atua mais como uma cola para os outros componentes do que uma ferramenta em si.

Você poderá evitar um monte de dores de cabeça para escolher e configurar estas ferramentas ao fazer uso de sites de hospedagem enlatada: um servidor que oferece áreas web previamente empacotadas e modeladas com todas as ferramentas de acompanhamento necessárias para manter um projeto de software livre. Veja “Canned Hosting” adiante neste capítulo para uma discussão das vantagens e desvantagens da hospedagem enlatada.