Infra-estrutura técnica
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,Do seu livro O Mítico
Homem-Mês, 1975. Veja e .
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
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
). 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 ). 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 adiante
neste capítulo para uma discussão das vantagens e desvantagens
da hospedagem enlatada.
Listas de E-mail
Listas de e-mail são o pão com manteiga das comunicações do
projeto. Se um usuário é exposto a qualquer fórum além das páginas
web, é bem provável que seja uma das listas de e-mail do projeto.
Mas antes que eles experimentes a lista em si, eles irão se deparar
com a interface da lista de e-mail—isto é, o mecanismo pelo
qual eles se juntarão ("increver a") a lista. Isso nos leva a Regra
no. 1 de listas de e-mail:
Não tente gerenciar listas de e-mail
manualmente—use um software de gerenciamento de
lista.
Será tentador descartar esta possibilidade. Configurar um
software de gerenciamento de lista de e-mail pode parecer um pouco
exagerado no início. Gerenciar listas pequenas e com pouco tráfego
manualmente parecerá muito fácil: você só precisa configurar um
endereço de inscrição que encaminhe as mensagens para você, e quando
alguém envia um e-mail, você adiciona (ou remove) o endereço e-mail
em algum arquivo texto que contém todos os endereços da lista. O
que poderia ser mais simples que isso?
A pegadinha é que um bom gerenciamento da lista de
e-mail—que é o que as pessoas esperam—não é nem um pouco
simples. Não se trata apenas de adicionar ou remover usuários quando
eles pedem. Trata-se também de moderar para evitar spam, oferecer um
e-mail com resumos ou mensagem a mensagem, fornecer a lista padrão e
informações do projeto através de auto-resposta, e várias outras
coisas. Uma monitoração humana do endereço de inscrição pode fornecer
apenas um mínimo de funcionalidade, e ainda assim não tão confiável
e rápido quanto pode fazer um software.
Um software moderno de gerenciamento de listas oferece no
mínimo as seguintes funcionalidades:
Inscrição por e-mail e através da web
Quando um usuário se inscreve a uma lista, ele pode
imediatamente receber uma mensagem
de boas vindas, dizendo que ele foi inscrito, como
interagir com o software da lista de e-mail, e (mais
importante) como cancelar a inscrição. Esta resposta
automática pode ser customizada para conter informações
específicas do projeto, tais como o web site,
localização do FAQ, etc.
Inscrição em modo digerido (digest) ou
mensagem a mensagem
No modo digerido, o inscrito recebe um e-mail por dia,
contento toda a atividade da lista naquele dia. Para
pessoas que estão acompanhando vagamente a lista, sem
participar, este modo é geralmente mais adequado, pois
permite a eles olharem todos os assuntos de uma só vez
e evitar a distração de e-mails chegando em horários
aleatórios.
Funcionalidades de moderação
"Moderar" é verificar os envios e assegurar que eles
a) não sejam spam, e
b) estejam dentro do tópico, antes que eles
sejam enviados para toda a lista. A moderação envolve
necessariamente humanos, mas o software pode ajudar
bastante para torná-la mais fácil. Haverá mais conteúdo
sobre moderação adiante.
Interface administrativa
Entre outras coisas, ela permite que o administrador acesse
e remova endereços obsoletos facilmente. Isso pode tornar-se
urgente quando um endereço destinatário passa a enviar
respostas automáticas com "Eu não utilizo mais este e-mail"
de volta para a lista para todas as outras mensagens. (Alguns
softwares conseguem detectar este comportamente e remover
a pessoa automaticamente.)
Manipulação de cabeçalho
Muitas pessoas possuem filtros sofisticados e regras de
resposta configuradas em seus clientes de e-mail. Os
softwares de listas de e-mail podem adicionar e manipular
alguns cabeçalhos padrões para que essas pessoas possam
obter alguma vantagem disso (mais detalhes a seguir).
Arquivamento
Todos os enviados para uma lista gerenciada são armazenados
e disponibilizados na web; alternativamente, alguns
softwares de listas de e-mail oferecem interfaces especiais
para conectar uma ferramenta externa de arquivamento como
o MHonArc
(). Como
discute no ,
o arquivamento é crucial.
O ponto de tudo isto é meramente para enfatizar que o
gerenciamento de listas de e-mail é um problema complexo o qual foi
pensado bastante, e resolvido em sua maioria. Você certamente não
precisa se tornar um especialista nisso. Mas você deve estar a par
que sempre há espaço para aprender mais, e que o gerenciamento da
lista irá ocupar a sua atenção de tempos em tempos no curso da
execução de um projeto de software livre. A seguir nós examinaremos
um pouco dos problemas mais comum na configuração das listas de
e-mail.
Prevenção de Spam
No intervalo em que esta sentença é publicada, o tamanho do
problema de spam provavelmente terá sua gravidade dobrada— ou
ao menos estará neste camninho. Há não muito tempo atrás era possível
que alguém abrisse uma lista de e-mails sem precisar tomar nenhuma
medida de prevenção. Os e-mails de spam ainda iriam aparecer, com
com tão pouca frequência que era um problema de nível bem baixo.
Este tempo se foi para sempre. Hoje, uma lista de e-mail que não
toma medidas de prevenção de spam será rapidamente submersa por
lixos de e-mail, ao ponto de ficar inutilizável. A prevenção de
spam é obrigatória.
Dividimos a prevenção de spam em duas categorias: previnindo
que envios de spam apareçam na sua lista de e-amils, e previnindo
a sua lista de e-mails de ser a fonte de novos endereços de e-mails
para spammers. A primeira é a mais importante, e iremos examiná-la
primeiro.
Filtrando os envios
Existem três técnicas básicas de previnir envios de spam, e a
maior parte de software de listas de e-mail oferece todas elas. Elas
são melhores se usadas em conjunto:
Permita apenas que os inscritos
enviem e-mails para lista.
Isso é muito efetivo efetivo, e envolve apenas um
pequeno esforço administrativo, pois geralmente é apenas
uma questão de configuração no software de gerenciamento
da lista de e-mails. Mas perceba que os envios que não são
aprovados automaticamente não podem ser simplesmente
descartados. Ao invés disso, eles devem passar por uma
moderação, por duas razões. Primeiro, você quer que os
não inscritos possam enviar e-mails. Uma pessoa com uma
questão ou uma sugestão não precisa se inscrever na lista
apenas para deixar uma única mensagem. Segundo, mesmo os
inscritos poder de vez em quando enviar mensagens de um
endereço diferente que não está inscrito. Endereços de
e-mail não são métodos confiáveis de se identificar as
pessoas, e não deveriam ser usados para tal fim.
Filtre os envios através de
um software de filtro de spams.
Se o software de lista de e-mail permitir (a
maioria permite), você pode filtrar as mensagens com um
software de filtro de spams. O filtro de spam automático
não é perfeito, e nunca será, pois existe uma guerra
sem fim entre spammers e escritores de filtros. Contanto,
pode ser ótimo em reduzir a quantidade de spam que chegam
através da fila de moderação, e como maior o tamanho da
fila, mais tempo uma pessoa levará para examiná-la,
qualquer quantidade de filtragem automática é benéfica.
Não há espaço aqui para instruções detalhadas de
configuraraçã dos filtros de spam. Você terá de consultar
a documentação do seu software de lista de e-mails para
isso (veja adiante neste capítulo).
Os softwares de listas geramente vem embutido com
funcionalidades de prevenção de spam, mas você pode
querer colocar filtros de terceiros. Eu tive boas
experiências com esses dois:
SpamAssassin
()
e SpamProbe
().
Este não é um comentário a respeito de diversos outros
filtros de spam existentes por aí, alguns dos quais são
aparentemente muito bons. Eu apenas usei esses dois e
fiquei satisfeito com eles.
Moderação.
Para e-mais que não são automaticamente autorizados
por não ser de um inscrito, e que passou pelos softwares
de filtro de spam, caso haja algum, o último estágio é a
moderação: o e-mail é direcionado
para um endereço especial, onde uma pessoa o examina e
o confirma ou o rejeita.
Confirmar um envio pode ser uma das duas formas:
você pode aceitar a mensagem apenas desta vez, ou você
pode dizer ao software da lista para permitir este e
todas as mensagens futuras provenientes do mesmo
remetente. Você quase sempre irá preferir a última forma,
com objetivo de reduzir o fardo da moderação futura.
Detalhes de como confirmar variam de sistema para
sistema, mas geralmente é uma questão de responder a um
endereço especial com o comando "accept" (significando
a confirmação apenas desta mensagem) ou "allow",
(permitindo a mensagem atual e futuras).
A rejeição é geralmente feita simplesmente
ignorando o e-mail de moderação. Se o software de lista
nunca receber a confirmação de que não é uma mensagem
válida, então ele não irá repassar a mensagem para a
lista, o que simplesmente excluir o e-mail de moderação
surte o efeito desejado. Algumas vezes você também tem a
opção de responder com os comandos "reject" ou "deny",
para desaprovar automaticamente e-mails futuros deste
remetente sem precisar passar novamente pela moderação.
Raramente há um sentido em fazer isso, pois a moderação
trata na maioria de prevenção de spam, e spammers não
costumam realizar envios do mesmo endereço mais de uma
vez.
Certifique-se de usar a moderação apenas
para filtrar spams e mensagens que estão claramente fora do escopo,
tais como quando alguém envia uma mensagem acidentalmente para a
lista errada. O sistema de moreração geralmente fornece uma forma
de se responder diretamente ao remetente, mas não use este método
para responder questões que realmente pertencem a lista em si, mesmo
se você souber a resposta de cabeça. Fazer isso privaria a comunidade
do projeto de uma visão apurada dos tipos de questões que as pessoas
estão fazendo, e irá privá-las de uma chance de responder as questões
elas mesmas e/ou ver a resposta dos demais. A moderação da lista é
estritamente sobre manter a lista livre de e-mails de lixo e fora
do tópico, e nada mais.
Camuflando endereços em arquivos da lista
Para evitar que suas listas de e-mail sejam uma fonte de
endereços para spammers, uma técnica comum é camuflar os endereços
das pessoas nos arquivos, substituindo por exemplo
jrandom@somedomain.com
por
jrandom_AT_somedomain.com
ou
jrandomNOSPAM@somedomain.com
ou alguma codificação similar e óbvia (para humanos). Como os
caçadores de e-mails para spam geralmente trabalham rastreando páginas
da internet—incluindo os arquivos online se suas listas de
e-mail—e procurando por sequências que contenham "@", camuflar
os endereços é uma forma de deixar os endereços de e-mail das pessoas
invisível ou sem utilidade para os spammers. Claro que isto não faz
nada para evitar que spams sejam enviados da própria lista de e-mail,
mas evita o aumento do número de spams enviados diretamente para os
e-mails pessoais dos usuários da lista.
A camuflagem de endereços pode ser controversa. Algumas pessoas
gostam bastante e ficarão surpresas se seus arquivos não fizerem isso
automaticamente. Outras pessoas acham muito incoveniente (pois elas
também devem traduzí-los antes de o usarem). Algumas vezes as pessoas
asseguram que não tem efeito, uma vez que os caçadores podem em teoria
compensar qualquer padrão de camuflagem consistente. Entretanto, note
que há uma evidência empírica que a camuflagem de endereços
é efetiva, veja .
Idealmente, o software de gerenciamento da lista deixará a
escolha a cada inscrito, tanto por um cabeçalho especial com um
Sim/Não ou então nas preferências da conta daquele inscrito. Contanto,
eu não conheço um software que oferece uma opção por inscrito ou por
mensagem em relação a isso, deixando uma decisão a ser tomada pelo
administrador para todos (assumindo que o arquivador oferece esta
funcionalidade, o que nem sempre é o caso). Eu fico levemente
inclinado em direção a ligar a opção de camuflagem. Algumas pessoas
são muito cuidadosas e evitam colocar seus endereços de e-mail em
uma página web ou qualquer outra local que um caçador de e-mails para
spam possa vê-lo, e eles ficarão desapontados ao ter todo o trabalho
jogado fora por um arquivo de lista de e-mails; enquanto isso, a
incoveniência que a camuflagem e e-mails impõe aos usuários de
arquivos são bem leves, pois é fácil transformar um e-mail camuflado
em um e-mail válido se você precisar contatar diretamente a pessoa.
Mas tenha em mente que, no final, ainda é uma corrida de armamentos:
no momento que estiver lendo isto, os caçadores podem muito bem ter
evoluído ao ponto que eles possam reconhecer as formas mais comuns
de camuflagem, e nós teremos de pensar em alguma outra coisa.
O Longo Debate do Responder a
Anteriormente em , eu
enfatizei a importância de certificar-se de que as discussões fiquem nos
forums públicos, e falei sobre a necessidade de algumas medidas ativas
para evitar que as conversas passem para um ambiente com discussão
privada; além disso, este capítulo tratou da configuração de softwares
de comunicação do projeto para fazer o máximo de trabalho possível
para você. Por isso, se o software de gerenciamento de lista oferece
uma maneira de manter as discussões na lista automaticamente, você
certamente pensará que deixar esta opção ligada é a uma escolha óbvia.
Bem, não é bem assim. A tal opção existe, mas ela possui algumas
desvantagens graves. A questão de usá-la ou não é uma das discussões
mais fervorosas sobre gerenciamento de listas de e-mail.—na
verdade, não é uma controvérsia que iria ao noticiário do horário
nobre na sua cidade, mas ele pode vir a tona de tempos em tempos
em projetos de software livre. A seguir, descreverei esta opção,
elucidando os argumentos dos dois lados, e farei a melhor recomendação
que puder.
A opção em si é bem simples: o software da lista de e-mails pode,
se você quiser, colocar automaticamente o cabeçalho "Responder a" em
todas as mensagens para redirecionar as respostas para a lista de
e-mail. Isto é, não importa o que o remetente original coloque no
cabeçalho "Responder a" (ou mesmo se ele não incluir nenhum), quando
os assinantes da lista virem a mensagem, o cabeçalho irá conter o
endereço da lista:
Reply-to: discuss@lists.example.org
A primeira vista, isto parece ser algo bom. Por que
virtualmente todo leitor de e-mail reconhece o cabeçalho "Responder a",
então quando alguém responder a mensagem, a resposta irá diretamente
para toda a lista automaticamente, e não apenas ao remetente da
mensagem original. Claro que quem responde ainda pode mudar manualmente
para onde vai a mensagem, mas o que é importante aqui é que as
respostas serão direcionadas a lista por padrão.
É um exemplo perfeito de utilizar a tecnologia para encorajar a
colaboração.
Infelizmente, existem algumas desvantagens. A primeira é
conhecida como o problema Não consigo encontrar o
caminho de volta pra casa: Algumas vezes, o remetente
original irá colocar o seu endereço de e-mail "real" no campo
"Responder a", pois por uma razão ou outra ele envia e-mails de
um endereço diferente do qual ele usa para recebê-los. Pessoas
que sempre leem e enviam do mesmo local não tem este problema,
e podem até ficar surpresos que isso possa existir. Mas para aqueles
que possuem configurações de e-mail diferenciadas, ou que não
possuem controle para alterar o endereço de envio (talvez
porque enviem do trabalho e não possuem nenhuma influência no
departamento de TI), usando o "Responder a" pode ser a única
forma que eles tem de assegurar que as respostas cheguem até
eles. Quando tal pessoa envia mensagem para a lista de e-mails
o qual ela não está inscrivta, sua configuração de "Responder a"
torna-se uma informação essencial. Se o software da lista o
sobrescreve, pode ser que ele nunca veja as respostas para
sua mensagem.
A segunda desvantagem tem a ver com as expectativas, e na
minha opinião é o argumento mais forte contra a alteração do
"Responder a". Usuários de e-mails mais experientes estão acostumados
a dois métodos básicos de resposta: responder a
todos e responder ao autor.
Todos os softwares modernos de leitura de e-mail possuem formas
diferenciadas para estas duas ações. O usuários sabem que para
responder a todos (isto é, incluindo a lista), eles precisam
escolher "Responder a todos", e para responder somente ao autor, eles
precisam escolher "Responder ao autor". Embora você queira encorajar
as pessoas a responder para a lista sempre que possível, existem
certas circunstâncias onde uma resposta privada é a prerrogativa do
autor—por exemplo, eles podem querer dizer algo confidencial
para o autor da mensagem original, algo que seria inapropriado para
para a lista pública.
Agora considere o que acontece quando a lista sobreescreveu o
"Reponder a" original do rementente. Quem responder irá acionar a
opção "responder ao autor", com a expectativa de estar enviando uma
mensagem privada de volta ao autor original. Como este é o
comportamento experado, ele pode nem mesmo se importar em olhar
cuidadosamente para o endereço do destinatários na nova mensagem.
Ele compõe sua mensagem confidencial e privada, da qual talvez diga
algo embaraçoso sobre alguém da lista, e envia o e-mail.
Inexperadamente, alguns minutos depois a mensagem aparece
na lista de e-mails! É verdade que na teoria
ele deveria olhar atentamente ao campo de destinatário, e não deveria
aceitar qualquer coisa sobre o cabeçalho "responder a". Mas os autores
quase sempre colocam o "Responder a" para seu endereço pessoal (ou
então, o software de e-mails configura isso para eles), e muitos
usuários antigos de e-mail vem a esperar por isso. Na verdade, quando
alguém propositalmente configura o "responde a" para algum outro
endereço, ele geralmente cita isso no corpo da mensagem, para que as
pessoas não fiquem surpreendidas com o que acontece quando elas
responderem a nebsagem.
Devido a possibilidades de consequências sérias por este
comportamento inexperado, minha preferência pessoal é conifigurar o
software para nunca todas no cabeçalho "responder a". Esta é uma área
onde usar a tecnologia para encorajar a colaboração possui ao meu
ver, efeitos colaterais altamente perigosos. Entretanto, existem
fortes argumentos do outro lado desta discussão. Independente de qual
você escolha, sempre haverão pessoas perguntando porque você não
utilizou a outra maneira. Como isto não é algo que você irá querer
como tópico perincipal de discussão na sua lista de e-mail, pode
ser interessante ter uma responta pronta para isso, uma do tipo que
irá frear a discussão ao invés de encorajá-la. Certifique-se que você
não insista que a sua decisão, independende de
qual seja, é obviamente a única e a mais sensata (mesmo que você
realmente ache isto). Ao invè disso, diga que isto é um debate antigo,
e que há bons argumentos dos dois lados, e nenhuma escolha irá
satisfazer a todos os usuários, e que você procurou tomar a melhor
decisão que você pode. Educadamente peça que o assunto não seja
levado adianta a menos que alguém tenha algo genuinamente novo a
dizer, e então fique fora da discussão e espere que ele morra de
morte natural.
Alguém pode sugerir em votar em uma maneira ou na outra. Você
pode fazer isso se quiser, mas eu pessoalmente não acho que contar
votos é uma solução adequada neste caso. A penalidade para quem
for surpreendido por este comportamento é tão grande (enviar
acidentalmente um e-mail para uma lista pública), e a inconveniência
para todos os outros é razoavelmente pequena (ocasionalmente ter que
lembrar alguém a responder para toda a lista ao invés de a você
somente), que não é claro que a maioria, mesmo que eles sejam a
maioria, deveriam ser capazes de colocar a minoria em risco.
Eu não enderecei todos os aspectos deste problema aqui, apenas
os que parecem ser de extrema importância. Para uma discussão completa,
verifique estes dois documentos ortodoxos, os quais são sempre citados
quando as pessoas entram neste debate:
Leave Reply-to alone (Deixe o Responder a em paz),
por Chip Rosenthal
Set Reply-to to list (Configure o Responder a para lista),
por Simon Hill
Apesar a leve preferência indicada acima, eu não acho que haja
uma resposta "certa" para esta questão, e participo com felicidade em
muitas listas que realmente configuram o "responder
a". A coisa mais importante que você pode fazer é configurar uma das
formas logo no início, e procurar não se envolver em futuros debates
depois disso.
Duas fantasias
Algum dia, alguém terá a idéia brilante de implementar o botão
responder a lista no leitor de e-mails. Isto
utilizarias um dos cabeçalhos de lista customizados mencionados
anteriormente para identificar o endereço da lista de e-mails, e
então responde diretamente e apenas para a lista, deixando de lado
todos os outros e-mails de destinatários, pois a maioria está inscrita
de qualquer forma. Eventualmente, outros leitores de e-mail irão
adotar a característica, e todo esta discussão irá embora. (Na verdade,
o leitor de e-mail Mutt
oferece esta funcionalidade.Logo depois que este livro
apareceu, Michael Bernstein me escreveu para dizer: "Existem outros
clientes de e-mail que implementam a função de responder a lista além
do Mytt. Por exemplo, o Evolution tem esta função como um atalho de
teclado, mas não um botão (Ctrl+L).")
Uma outra solução ainda melhor seria a configuração para cada
usuário quanto a alteração do "Responder a". Aqueles que quiserem
configurar a alteração automática da lista (tanto das próprias
mensagens de e-mail quanto dos demais) poderia solicitar isso, e
aqueles que não quiserem a alteração, não mexem em nada. No entanto,
eu não conheço um software de gerenciamento de lista que oferece
isto no nível de perfil de inscritos. No momento, parece que estamos
presos a uma configuração global.Desde que escrevi
isso, eu descobri que existe ao menos um sistema de gerenciamento
de lista que oferece isto:
Siesta.
Veja também este artigo sobre ele:
Arquivamento
Os detalhes técnicos da configuração de arquivamento de listas de email são específicas do software que está gerenciando a lista, e vão além do escopo deste livro. Ao escolher ou condigurar um sistema de arquivamento, considere as seguintes qualidades:
Atualização imediata
As pessoas irão frequentemente se referir a uma mensagem
arquivada enviada nas últimas uma ou duas horas. Se
possível, o arquivador deve arquivar cada mensagem
instantaneamente, de forma que no momento em que a
mensagem aparecer na lista de e-mails, ela já estará
presente nos arquivos. Se esta opção não estiver
disponível, então procure ao menos configurar o
arquivador para executar de hora em hora. (Por padrão,
alguns arquivadores executam seu processo uma única vez
a noite, mas na prática isto é um espaço muito grande de
tempo para uma lista de e-mails ativa.)
Estabilidade das referências
Uma vez que a mensagem é arquivada em uma URL em
particular, ela deve permanecer acessível na mesma URL
para sempre, ou o mais próximo disso. Mesmo que os
arquivos sejam reconstruídos, restaurados de backup ou
fixos de alguma forma, qualquer URL que já tenha se
tornado pública deve permanecer a mesma. Referências
estáveis fazem com que seja possível que os motores de
busca da Internet possam indexar os arquivos, o que é
um grande benefício para usuários que buscam respostas.
Referências estáveis também são importantes porque as
mensagems e discussões da lista de e-mails são
frequentemente conectadas ao Bug Tracker (veja
)
adiante neste capítulo ou
de outros a outros documentros do projeto.
Idealmente, o software de lista de e-mail irá incluir a
URL da mensagem arquivada, ou ao menos a parte específica
da URL da mensagem, em um cabeçalho quando ele distribui
as mensagens para os destinatários. Desta forma as pessoas
que possuem uma cópia da mensagem serão capazes de saber
sua localização no arquivo sem ter que visitar os arquivos,
o que é muito útil pois qualquer operação que envolve um
navegador web é automaticamente demorado. Se há esta opção
em algum software de lista de e-mails, eu não sei;
infelizmente, o que eu utilizo não a possui. Entretanto,
é algo a se procurar (ou, se você escreve um software de
lista de e-mails, por favor, é uma opção a se considerar
a implementação).
Backups
Deveria ser óbvio sobre como manter um backup dos arquivos,
e a receita para sua restauração não deveria ser tão
complicada. Em outras palavras, não trate o seu arquivo
como uma caixa preta. Você (ou alguém do projeto) deve
saber os as mensagens são armazenadas, e como regerar as
páginas atuais do arquivo se isso alguma vez for necessário.
Estes arquivos são dados preciosos—um projeto que os
perdem, perde também uma boa parte de sua memória coletiva.
Suporte a threads
Deve ser possível ir de qualquer mensagem individual para
a thread (grupo de mensagens
relacionadas) de que a mensagem original faz parte. Cada
thread deve possuir também sua própria URL, separada das
URLs de mensagens individuais dentro da thread.
Opção de busca
Um arquivo que não suporta buscas—tanto no corpo das
mensagens assim como de autores e assuntos— é um
arquivo quase que inútil. Note que alguns arquivadores
suportam a busca simplesmente deixando o trabalho para
um motor de busca externo como o Google. Isto é
aceitável, mas o suporte a busca direta é geralmente mais
aperfeiçoado, pois permite ao pesquisador especificar que
o termo apareça no assunto ao invés do corpo, por exemplo.
O que foi descrito é apenas uma checagem técnica para
ajudar você a avaliar e configurar um arquivador. Fazer com que
as pessoas usem o arquivador com vantagens
para o projeto é discutido mais tarde nos capítulos, em particular
no .
Software
Aqui estão algumas ferramentes de código aberto para realizar
o gerenciamento e arquivamento da lista. Se o site onde você está
hospedando o seu projeto já possui uma configuração padrão, então
talvez você não poderá escolher a ferramenta. Mas se você mesmo
precisa instalar, estas são algumas possibilidades. A que eu
já utilizei são Mailman, Ezmlm, MHonArc, e Hypermail, mas isto não
significa que as demais não são boas também (e claro que
provavelmente existem outras ferramentas por aí que eu apenas
não encontrei, então não considere esta uma lista completa).
Softwares de gerenciamento de listas de e-mail:
Mailman —
(Possui um arquivador embutido, e ganchos para
conectar arquivadores externos.)
SmartList —
(Feito para ser usado com o sistema de processamento de e-mail
Procmail.)
Ecartis —
ListProc —
Ezmlm —
(Desenhado para trabalhar com o sistema de entrega de e-mailQmail.)
Dada —
(Apesar das bizzarras tentativas do site web de esconder
o fato, este é um software livre, lançado sob a GNU
General Public License. Ele também possui um
arquivador interno.)
Software para arquivamento de lista de e-mails:
MHonArc —
Hypermail —
Lurker —
Procmail —
(Companheiro de software do SmartList, este é um sistema de
processamento de e-mail genérico, que pode aparentemente,
ser configurado com um arquivador.)
Controle de Versão
Um sistema de controle de versão (ou
sistema de controle de revisão) é uma
combinação de práticas e tecnologias para rastrear e controlar as
mudanças nos arquivos do projeto, em particular o código fonte,
documentação, e páginas da web. Se você nunca usou um controle de
versão antes, a primeira coisa que vocÇe deve fazer é encontrar alguém
que o tenha, e colocá-lo para participar do projeto. Hoje em dia,
todos esperam que ao menos o código fonte do projeto esteja em um
controle de versão, e provavelmente não irá levar o projeto a sério
se ele não usar um controle de versão com o mínimo de competência.
O motivo do controle de versão ser tão universal é que ele ajuda
virtualmente com todos os aspectos de tocar um projeto: comunicação
entre desenvolvedores, gererenciamento de lançamentos, gerenciamento
de bugs, estabilidade de código e esforços experimentais de
desenvolvimento, e atribuição e autorização de mudanças para
desenvolvedores em particular. O sistema de controle de versões
fornece um força de coordenação central entre todas essas áreas. O
coração de um controle de versão é o gerenciamento de
mudança: identificando cada modificação sutil realizada
nos arquivos do projeto, anotando toda e cada alteração com metadados
como a data da alteração e o autor, e então reproduzindo o fato para
qualquer um que perguntar, da maneira que ele quiser. É um mecanismo
de comunicação onde é mudança é a unidade básica de informação.
Esta seção não discute todos os aspectos da utilização de um
sistema de controle de versão. Ele é tão abrangente que será tratada
topicamente no decorrer do livro. Aqui, iremos nos concentrar em
escolher e configurar um sistema de controle de versões de uma
forma que irá promover o desenvolvimento estrada abaixo.
Vocabulário do Controle de Versão
Este livro não o ensina como usar o controle de versão se você
nunca o utilizou antes, mas seria impossível discutir sobre o assunto
sem conhecer alguns termos chaves. Estes termos são úteis
independentemente de qualquer sistema de controle de versão em
particular: eles são os substantivos e verbos básicos de uma
colaboração em rede, e será utilizada de forma genérica no decorrer do
livro. Mesmo se não houvesse sistemas de controle de versão no mundo,
a questão do gerenciamento de mudanças iria permanecer, e estas
palavras nos fornece a linguagem para falar sobre o assunto de
maneira concisa.
commit
Realizar uma mudança no projeto; mais formalmente,
armazenar uma mudança no banco de dados de controle de versão de uma
forma que ela possa ser incorporada em versões futuras do projeto. O
"Commit" pode ser usado com um verbo ou como um substantivo. Como um
substantivo, ele é essencialmente um sinônimo de "mudança". Por
exemplo: "Eu acabei de comitar uma correção para corrigir o bug de
crash do servidor que o pessoal tem reportado no Mac OS X. Jay, você
pode por favor revisar o commit e verificar se eu não estou usando
o alocador indevidamente?"
log message
Um pequeno comentário anexado a cada commit,
descrevendo a natureza e o propósito do commit. Log messages estão
entre os documentos mais importantes no projeto: elas são a ponte
entre a linguagem altamente técnica das mudanças individuais de um
código e uma linguagem mais direcionada aos usuários de
funcionalidades, correções de bugs, e progresso do projeto. Mais
adiante nesta seção, veremos maneiras de distribuir log messages
para os públicos apropriados; o no
também discute maneiras
de encorajar os contribuidores a escrever log messages concisas e
úteis.
update
Solicitar que as mudanças dos demais (commits) sejam
incorporadas em sua cópia local do projeto; ou seja, deixar a sua
cópia "atualizada". Esta é uma operação muito comum; a maioria dos
desenvolvedores atualizam seus códigos diversas vezes por dia, de
maneira que eles sabem que estão executando algo muito próximo do
que os demais estão trabalhando, e caso eles encontrem um bug, eles
tem certeza que ele ainda não foi corrigido. Por exemplo: "Olá, eu
notei que o código de indexação está sempre desprezando o último
byte. Este é um novo bug?" "Sim, mas ele foi corrigido na semana
passada—atualize seu código e ele deve desaparecer."
repositório Um
banco de dados no qual mudanças são armazenadas. Alguns sistemas de
controle de versão são centralizados:há um único repositório mestre
que armazena todas as mudanças feitas no projeto. Outros são
descentralizados: cada desenvolvedor tem seu próprio repositório, e
alterações podem ser trocadas entre repositórios arbitrariamente. O
sistema de controle de versão manté controle das dependências entre as
alterações, e quando é hora de lançar uma versão, um conjunto
particular de alterações é aprovado para aquele lançamento. O
questionamento referente a se centralizado ou descentralizado é melhor
é uma das duradouras guerras santas do desenvolvimento de software;
tente não cair na armadilha de discutir sobre isso em suas listas de
projetos.
checkout
O processo de se obter uma cópia do projeto a partir
de um repositório. Um checkout geralmente gera uma árvore de
diretórios chamada de cópia de trabalho (working copy), a partir da qual alterações podem ser comitadas de volta ao repositório
original. Em alguns sistemas de controle de versão descentralizados,
cada cópia é em sí mesma um repositório, e mudanças podem ser
extraídas de (ou enviadas a) qualquer repositório que esteja disposto
a aceitá-las.
Cópia de Trabalho
Uma árvore de diretórios privada do desenvolvedor contendo
o código fonte do projeto, e possivelmente suas páginas da web ou outros
documentos. Uma cópia de trabalho também contém um pouco de metadata
gerenciado pelo sistema de controle de versão, que conta de que repositório
vem a cópia de trabalho, que "revisões" (veja abaixo) dos arquivos estão
presentes, etc. Geralmente, cada desenvolvedor tem sua própria cópia de
trabalho, na qual ele faz e testa mudanças, e da qual ele
envia.
revision (revisão),
change (mudança),
changeset (grupo de mudança)
Uma "revision" é geralmente uma encarnação específica
de um arquivo ou diretório em particular. Por exemplo, se um projeto
iniciar na revisão 6 do arquivo F, e então alguém efetua uma mudança
e o commit do arquivo F, isto produz a revisão 7 de F. Alguns sistemas
também usam "revision", "change", or "changeset" para se referir a
um conjunto de modificações em que se é efetuado o commit uma única vez,
como uma unidade conceitual.
Estes termos ocasionalmente possuem significados técnicos distintos
nos diversos sistemas de controle de versões, mas a idéia principal é
sempre a mesma: eles fornecem uma forma precisa de dizer exatamente em
uma linha histórica as modificações de um arquivo ou de um conjunto de
arquivos (traduzindo, imediatamente antes ou depois que um bug é corrigido).
Por exemplo: "Ah sim, ela corrigiu isto na revisão 10" ou "Ela corrigiu
isso na revisão 10 do foo.c."
Quando alguém fala sobre um arquivo ou um conjunto de arquivos
sem especificar uma revisão em particular, geralmente se assume que
se trata da revisão mais recente disponível.
"Versão" Versus "Revisão"
O termo versão é algumas vezes
utilizado como sinônimo para "revisão", mas eu não o usarei desta
forma neste livro, pois é facilmente confundido com "versão" no
sentido de versão do software—ou seja, o lançamento (release)
ou número da edição, como em "Versão 1.0". Entretanto, como o
termo "controle de versão" é um padrão adotado, eu continuarei a usá-lo
como um sinônimo de "controle de revisão" e "controle de mudança".
diff
Uma representação textual de uma mudança. Uma diff
mostra quais linhas foram modificadas e como elas foram modificadas,
e adiciona algumas linhas próximas para contextualizar em ambos os
lados. Um desenvolvedor que já está familiarizado com o código pode
geralmente confrontar uma diff com o código e identificar do que se
trata a mudança, e até identificar possíveis bugs.
tag (ou etiqueta)
Uma informação para uma coleção em particular de
arquivos para revisões especificadas. Tags são usadas geralmente
para preservar snapshots interessantes do projetos. Por exemplo,
uma tag é gerada para cada release pública, exatamente com os
conjuntos de arquivos/revisões que compreendem aquela release.
Nomes comuns de tags são escritas como Release_1_0,
Delivery_00456, etc.
branch (ou ramo)
Uma cópia do projeto sob o controle de versão,
porém isolada de uma maneira que as mudanças realizadas no
branch não afetem o resto do projeto e vice-versa, exceto quando
as mudanças são deliberadamente mescladas ("merge") de um lado
para o outro (veja abaixo). Branches (ou ramos) também são conhecidas
como "linhas de desenvolvimento". Mesmo quando um projeto não possui
branches explícitas, o desenvolvimento ainda é considerado como
sendo executado no "branch principal", também conhecido como
"linha principal" ou "trunk".
Branches oferecem uma maneira isolada de diferentes linhas de
desenvolvimento entre eles. Por exemplo, um branch pode ser usado
para um desenvolvimento experimental que poderia desestabilizar
muito a linha principal (ou trunk). Assim como uma branch pode
ser usada como um local para estabilizar uma nova release. Durante
o processo de release, o desenvolvimento regular continua sem
interrupções no branch principal do repositório; enquanto isso,
na branch da release, nenhuma mudança é permitida com exceção daquelas
que são aprovadas pelos gerentes de releases. Desta forma, disponibilizar
uma release não precisa interferir no andamento dos trabalhos de
desenvolvimento. Veja em mais adiante neste
capítulo para uma discussão mais detalhada sobre
branches.
merge (a.k.a. port) (ou junção)
Mover uma mudança de um branch para o outro. Isso
inclui um merge da linha principal com algum branch, ou vice
versa. Na verdade, estes são os tipos mais comuns de merge; é raro
transportar mudanças entre dois branches não-principais. Veja para mais detalhes sobre este tipo de
merge.
"Merge" tem um segundo significado: é o que o sistema de
controle de versão faz quando identifica que duas pessoas mudaram o
mesmo arquivo mas sem interferências. Como as duas mudanças não
interferem uma com a outra quando uma pessoa a atualiza sua cópia
do arquivo (já contendo suas próprias mudanças), as mudanças da
outra pessoa serão automaticamente agregadas. Isto é muito comum,
especialmente em projetos que contém muitas pessoas trabalhando no
mesmo código. Quando duas modificações diferentes se
interferem, o resultado é um "conflito"; veja
abaixo.
conflict (ou conflito)
É o que acontece quando duas pessoas tentam
modificar a mesma parte do código de maneiras diferentes. Todos os
sistemas de controle de versão detectam conflitos automaticamente,
e notificam pelo menos um humano de que suas mudanças conflitam com
as de outra pessoa. O humano notificado deve então
resolver o conflito, e comunicar a resolução
para o sistema de controle de versão.
lock (ou bloqueio)
Um jeito de declarar a intenção de modificar
exclusivamente um arquivo ou diretório. Por exemplo, "Não consigo
commitar nenhuma mudança para as páginas web
no momento. Parace que Alfred as bloqueou enquanto conserta as
imagens de fundo." Nem todos os sistemas de controle de versão
suportam a habilidade de bloquear, e daqueles que suportam, nem
todos requerem que a habilidade seja usada. Isso se dá porque
desenvolvimento paralelo é a regra, e bloquear pessoas de acessar
um arquivo é contrário à este ideal.
Sistemas de controle de versão que requerem o bloqueio para
realizar commits usam um modelo chamado
bloquear-modificar-desbloquear.
Aqueles que não requerem usam o modelo chamado
copiar-modificar-juntar. Uma excelente
explicação e comparação dos dois modelos à fundo pode ser
encontrada em . No
geral, o modelo copiar-modificar-juntar é melhor para
desenvolvimento aberto, e todos os sistema de controle de versão
discutidos neste livro suportam este modelo.
Escolhendo o sistema de Controle de Versão
Os dois sistemas de Controle de Versão mais populares no
momento que este livro foi escrito no mundo do software livre são
Concurrent Versions System (CVS,
)
e Subversion (SVN,
).
O CVS existe há um bom tempo. Desenvolvedores mais experientes já
estão familiarizados com ele, que faz mais ou menos o que você precisa,
e como ele já é popular há um bom tempo, você provavelmente não vai
entrar em longas discussões se ele é ou não a escolha correta. Porém,
o CVS possui algumas desvantagens. Ele não fornece uma maneira fácil de
encontrar mudanças em diversos arquivos; ele não permite que você renomeie
ou copia arquivos sob o controle de versão (o que faz com que uma reorganização
em sua árvore de código após iniciar o projeto te dê uma bela dor de cabeça);
tem um suporte pobre a merge; ele não lida muito bem com arquivos grandes
ou com arquivos binários; e algumas operações são lentas quando se tem
um grande número de arquivos.
Nenhuma das falhas do CVS é fatal, e ele ainda é bem popular.
Porém, nos últimos anos o mais recente Subversion vem ganhando espaço
especialmente para novos projetos .Veja
e
para evidência de seu crescimento.. Se você está iniciando
um novo projeto, eu recomento o Subversion.
Por outro lado, como eu estou envolvido no projeto do Subversion,
minha objetividade pode ser razoalvelmente questionável. E nos
últimos anos diversos novos softwares livres de controle de versão
surgiram. lista todos os que eu conheço,
em uma ordem rudimentar de popularidade. Conforme a lista deixa claro,
decidir o sistema de controle de versào pode ser uma pesquisa de uma
vida inteira. Possiverlmente você será poupado da decisão pois será
decidido por você no lugar que você for armazenar seu software. Mas
se você for obrigado a decidir, pergunte aos seus outros desenvolvedores,
descubra no que eles possuem maior experiência, escolha um e siga com
ele. Qualquer software de controle de versão estável, pronto para
produção, irá servir; você não precisa se preocupar demais sobre fazer
uma escolha drásticamente errada. Se você simplesmente não conseguir
decidir, então fique com o Subversion. Ele é bem simples de aprender,
e provavelmente será o padrão por pelo menos alguns anos.
Usando o Sistema de Controle de Versão
As recomendações nessa seção não são destinadas a um sistema
de controle de versão específico, portanto seria simples implementá-las
em qualquer um deles.
Versione Tudo
Não mantenha apenas os códigos fontes de seu projeto dentro de
um sistema de controle de versões, mas também todas as páginas, documentos,
FAQs, notas de design, e tudo que possa ser editável pelas pessoas. Mantenha-os
organizados de forma que estejam próximos dos códigos fontes na mesma estrutura
da árvore do repositório. Qualquer pedaço de informação digna de ser escrita é
também digna de ser versionada; isto é, qualquer informação que poderia mudar.
Qualquer coisa que não deveriam ser modificada, podem ser arquivados. Por exemplo,
um e-mail, uma vez postado, não é modificado, logo, versioná-lo não faria sentido
(ao menos que este seja parte de um documento maior).
A razão de versionar tudo junto in um único lugar é importante pois as pessoas
terão que aprender apenas um único mecanismo para submeter mudanças. Frequentemente um
contribuidor começará fazendo edições para páginas web ou documentação e depois de um
tempo partirá para pequenos trechos de códigos por exemplo. Quando o projeto utilize
o mesmo sistema para todos os tipos de submissão de mudanças, as pessoas só precisam
aprender uma vez o processo. Versionar tudo junto também significa que novas features
podem ser comitadas juntas na mesma branch com suas atualizações de documentação e etc.
Não mantenhaarquivos gerados sob o controle de versão.
Eles não são dados realmente editáveis, pois são arquivos gerados programaticamente por outros
arquivos. Por exemplo, algumas ferramentas de build criam arquivos configure
baseados em um template
configure.in. Afim de alterar o arquivo configure, alguém precisaria alterar o arquivo
configure.in e então gerá-lo novamente; Assim, somente o template configure.in é um "Arquivo editável"
Somente versione os templates—Se você versionar os arquivos gerados, as pessoas irão inevitavelmente esquecer de gerar
quando fizerem o commit da modificação do template, o que resultará em uma inconsistência, causando uma confusão sem fim
Para uma opinião diferente a respeito do versionamento de arquivos configure, veja o post de
Alexey Makhotkin's "configure.in and version control" em
.
A regra de que todos os dados editáveis devem ser mantidos no controle
de versão tem uma exceção infeliz: o bug tracker. Bancos de dados de bugs
contém muitos dados editáveis, mas por razões técnicas em geral
não pode armazenar esses dados no sistema de controle de versão principal. (Alguns
trackers têm recursos de versão primitivos próprios, no entanto,
independente do repositório principal do projeto.)
Navegabilidade
O repositório do projeto deve ser navegável na web. Isto não
significa apenas a capacidade de ver as últimas revisões do
arquivos do projeto, mas também voltar no tempo e ver as revisões anteriores,
ver as diferenças entre as revisões, ler as mensagens de log das mudanças selecionadas
e etc.
A navegabilidade é importante porque é um portal leve para
dados do projeto. Se o repositório não pode ser visto através de um navegador web,
então alguém querendo inspecionar um arquivo específico (digamos, para
ver se uma determinada correção de bug entrou no código) primeiro teria que
instalar software cliente de controle de versão localmente, o que pode transformar
uma simples tarefa de consulta de dois minutos em uma tarefa de meia hora ou mais.
A navegabilidade também implica em URLs canônicas para visualização
de revisões específicas de arquivos e também para ver a revisão mais recente a qualquer momento.
Isso pode ser muito útil em discussões técnicas ou quando
indicar documentação as pessoas. Por exemplo, em vez de dizer "Dicas sobre debug do servidor,
veja o arquivo www/hacking.html em sua cópia local," alguém poderia dizer "Para dicas de debug do servidor, veja
http://subversion.apache.org/docs/community-guide/,"
fornecendo um endereço (URL) que sempre aponta para a última versão do arquivo hacking.html.
A URL é melhor porque ela evita ambiguidade e questões sobre se aquele endereço é de uma versão atualizada.
Alguns sistemas de controle de versão vem com mecanismos embutidos
para pesquisa dentro de repositórios, enquanto outras se apoiam em outras ferramentas
terceiras para pesquisar. Três ferramentas desse tipo são ViewCVS (),
CVSWeb () e
WebSVN (). A primeira trabalha tanto com o CVS como quanto o
Subversion, a segunda somente com o CVS e a terceira apenas com o Subversion.
Emails de commit
Cada commit ao repositório deverá gerar um email mostrando quem realizou
a mudança, e quando ela foi feita, quais arquivos e diretórios foram alterados,
e como eles foram modificados. O email deverá ir para uma lista especial de emails
relacionados a commits, separado da lista de discussões para pessoas.
Desenvolvedores e outras pessoas interessadas deveriam ser encorajadas a se inscreverem
na lista de commits, pois é a maneira mais efetiva de se manter atualizado com o que
está acontecendo no projeto no nível de código. Além dos benefícios técnicos obvios de revisão em pares
(veja ), os e-mails de commit ajudam a criar um senso de comunidade
, pois eles estabelecem um ambiente compartilhado no qual as pessoas podem reagir a eventos (commits)
que eles sabem que estão visíveis aos outros também.
Detalhes específicos para configuração de emails de commit irão variar
dependendo do sistema de controle de versão, mas geralmente existe um script
ou algum outro recurso para fazer isto. Se você estiver com dificuldade em encontrá-lo,
tente procurar na documentação por hooks,
espeficificamente por post-commit hook, também conhecido como
loginfo hook no CVS. Post-commit hooks são um meio geral para
execução de tarefas automatizadas em resposta aos commits.
O hook é acionado por um commit individual, e recebe todas as informações relacionadas
daquele commit, e ele pode usar essa informação para fazer qualquer coisa— por exemplo,
enviar um email.
Com um pacote de sistemas de e-mail, você pode desejar alterar
alguns de seus comportamentos padrões:
Alguns mecanismos de envio de email não incluem informações
das diferenças das modificações do commit no e-mail, mas ao invés disso eles
fornecem uma URL para visualizar a mudança numa página web usando o mecanismo
de navegação do repositório. Por mais que seja bom incluir a URL no email,
para que a modificação seja referenciada depois, é também
muito importante que o e-mail do commit inclua as diferenças.
Ler email já faz parte da rotina das pessoas, então se o conteúdo da alteração estiver logo
ali no email, os desenvolvedores poderão revisar o commit imediatamente,
sem ter de sair do seu leitor de e-mails. Se eles tiverem que clicar numa URL para fazer a revisão,
a maioria não irá fazê-lo, porque isso irá requerer uma nova ação ao invés daquela que eles já estão fazendo.
Além disso, se o revisor quizer perguntar algo sobre a alteração, é muito mais fácil responder o e-mail fazendo
anotações sobre a diferança do que visitar uma página web e ter o trabalho de copiar e colar partes da diferença do navegador webp
para o e-mail.
(Claro, se o diff for enorme, como quando um grande corpo de
novo código foi adicionado ao repositório, então faz sentido
omitir o diff e oferecer apenas a URL. A maioria dos remetentes de lista de email podem
ter esse tipo de limitação automática. Se o seu não pode, então é
ainda melhor incluir diffs, e conviver com esses e-mail gigantes,
do que deixar as diferenças totalmente desligadas. Uma revisão conveniente
com comentários são a pedra central do desenvolvimento cooperativo, algo
tão importante que não se pode ficar sem usá-lo.
The commit emails should set their Reply-to header
to the regular development list, not the commit email list. That
is, when someone reviews a commit and writes a response, their
response should be automatically directed toward the human
development list, where technical issues are normally discussed.
There are a few reasons for this. First, you want to keep all
technical discussion on one list, because that's where people expect
it to happen, and because that way there's only one archive to
search. Second, there might be interested parties not subscribed to
the commit email list. Third, the commit email list advertises
itself as a service for watching commits, not for watching commits
and occasional technical discussions. Those who
subscribed to the commit email list did not sign up for anything but
commit emails; sending them other material via that list would
violate an implicit contract. Fourth, people often write programs
that read the commit email list and process the results (for
display on a web page, for example). Those programs are prepared to
handle consistently-formatted commit emails, but not inconsistent
human-written mails.
Os e-mails de commit devem ter como e-mail de resposta (Reply-To)
a lista de e-mails de discussão do time de desenvolvimento, e não para a lista de e-mails de commit.
Isto é, quando alguém revisa um commit e escreve uma resposta, sua resposta deve ser direcionada
automaticamente para a pessoa da lista de desenvolvimento, onde questões técnicas são normalmente discutidas.
Existem algumas razões para isso. Primeiro, você deseja manter todos na discussão técnica em uma lista,
porque é onde as pessoas esperam que isso aconteça, e porque dessa forma há apenas um arquivo para
pesquisa. Em segundo lugar, pode haver partes interessadas não inscritas na lista de commits.
Terceiro, a lista de emails de commit anuncia em si como um serviço para observar commits,
não para discutir commits e discussões técnicas ocasionais. Aqueles que
estão inscritos na lista de e-mail de commits não se inscreveram para nada além de e-mails de commit;
e enviar qualquer outro tipo de e-mail que não seja informação de commit seria uma violação do contrato.
Quarto, as pessoas costumam escrever programas que lêem a lista de e-mails de confirmação e processam
os resultados (para exibir em uma página da web, por exemplo). Esses programas são preparados para
lidar com emails de commit formatados de forma consistente, mas não inconsistentes e-mails escritos
por pessoas.
Observe que esta recomendação de e-mail de reposta não se contradiz com as
recomendações anteriores.
É sempre permitido o remetente da mensagem modificar o endereço de resposta (Reply-To).
Nesse caso, o remetente é o próprio sistema de controle de versionamento, e ele define o campo de resposta de
forma a indicar o lugar certo para envio da mensagem, que é a lista de desenvolvimento, não de commits.
CIA: Another Change Publication Mechanism
Commit emails are not the only way to propagate change news.
Recently, another mechanism called CIA () has been developed. CIA is a real-time
commit statistics aggregator and distributor. The most popular use of
CIA is to send commit notifications to IRC channels, so that people
logged into those channels see the commits happening in real time.
Though of somewhat less technical utility than commit emails, since
observers might or might not be around when a commit notice pops up in
IRC, this technique is of immense social utility.
People get the sense of being part of something alive and active, and
feel that they can see progress being made right before their
eyes.
The way it works is that you invoke the CIA notifier program
from your post-commit hook. The notifier formats the commit
information into an XML message, and sends to a central server
(typically cia.navi.cx). That server then
distributes the commit information to other forums.
CIA can also be configured to send out RSS
feeds. See the documentation at
for details.
To see an example of CIA in action, point your IRC
client at irc.freenode.net, channel
#commits.
Use branches to avoid bottlenecks
Non-expert version control users are sometimes a bit afraid of
branching and merging. This is probably a side effect of CVS's
popularity: CVS's interface for branching and merging is somewhat
counterintuitive, so many people have learned to avoid those
operations entirely.
If you are among those people, resolve right now to conquer any
fears you may have and take the time to learn how to do branching and
merging. They are not difficult operations, once you get used to
them, and they become increasingly important as a project acquires
more developers.
Branches are valuable because they turn a scarce
resource—working room in the project's code—into an
abundant one. Normally, all developers work together in the same
sandbox, constructing the same castle. When someone wants to add a
new drawbridge, but can't convince everyone else that it would be an
improvement, branching makes it possible for her to go to an isolated
corner and try it out. If the effort succeeds, she can invite the
other developers to examine the result. If everyone agrees that the
result is good, they can tell the version control system to move
("merge") the drawbridge from the branch castle over to the main
castle.
It's easy to see how this ability helps collaborative
development. People need the freedom to try new things without
feeling like they're interfering with others' work. Equally
importantly, there are times when code needs to be isolated from the
usual development churn, in order to get a bug fixed or a release
stabilized (see and
in
) without worrying
about tracking a moving target.
Use branches liberally, and encourage others to use them. But
also make sure that a given branch is only active for exactly as long
as needed. Every active branch is a slight drain on the community's
attention. Even those who are not working in a branch still maintain
a peripheral awareness of what's going on in it. Such awareness is
desirable, of course, and commit emails should be sent out for branch
commits just as for any other commit. But branches should not become
a mechanism for dividing the development community. With rare
exceptions, the eventual goal of most branches should be to merge
their changes back into the main line and disappear.
Singularidade de Informação
Merging tem um corolário importante: nunca comite a mesma mudança duas vezes.
Isto é, uma mudança deve entrar no sistema de controle de versionamento
exatamente uma única vez. A revisão (ou conjunto de revisões) na qual a mudança
foi efetuada é o seu único identificador. Caso seja necessária a sua efetuação
em uma branch diferente da que foi feita, então ela deve ser merged
do seu ponto de criação original para os outros pontos de destino
—ao contrário de comitar uma mudança textualmente idêntica,
que teria o mesmo efeito no código, mas tornaria impossíveis a precisão de estruturação
e o gerenciamento de releases.
Os efeitos práticos desta recomendação variam de um sistema
de controle de versão para o outro. Em alguns sistemas, merges são
eventos especiais, distintos de commits, e têm seus proprios metadados.
Em outros, os resultados de merges são comitados da mesma forma que outras
mudanças são comitadas, então o principal modo de diferenciar um
"merge commit" de um "commit de novas mudanças" é a log message.
Na log message de um merge, não repita a mesma existente na mudança original.
Ao contrário, apenas indique que está sendo realizado um merge, e forneça
a revisão que contenha a mudança original, com um sumário de no máximo uma frase
do que ela faz. Se alguém quiser ler a mensagem completa, deverá então
consultar a revisão original.
A razão da importância de se evitar a repetição da log message
é que, às vezes, elas são modificadas após serem comitadas. Se a
log message de uma mudança fosse repetida a cada efetuação de merge,
então até se alguém editasse a mensagem original, ainda seria necessário
atualizar todas as repetições—o que causaria um
monte de confusão.
O mesmo princípio se aplica para reverter uma mudança. Se uma mudança é
retirada do código, a log message da reversão deve apenas indicar, especificamente,
qual é a revisão (ou revisões) que está sendo revertida, e
não descrever a mudança gerada no arquivo derivada da reversão,
uma vez que a semântica da mudança pode ser obtida através da leitura da log message
original. É claro que a log message da reversão deve indificar a razão
pela qual a mudança está sendo revertida, mas ela não deve conter duplicações derivadas
da log message original. Se possível, volte e edite a log message original
para evidenciar o que foi revertido.
Tudo dito acima significa que você deve usar uma sintaxe consistente quando
se referir a revisões. Isto é útil não somente em log messages, mas também em emails,
no bug tracker, e em todos os outros lugares. Se você está usando CVS, sugiro
"path/to/file/in/project/tree:REV",
onde REV é um número de revisão no CVS, como "1.76". Se você está usando Subversion,
a sintaxe padrão para a revisão 1729 é "r1729" (endereços de arquivos não são necessários
por que o Subversion usa números de revisão globais). Em outros sistemas, normalmente
há uma sintaxe padrão para expressar o nome das alterações. Seja qual for a sintaxe
apropriada para o seu sistema, estimule as pessoas a usá-la quando forem aplicar mudanças.
Uma nomeação de mudanças consistente facilita a estruturação do projeto (como veremos em e
), e como muita da estruturação será feita
por voluntários, se torna necessário deixá-la o simples possível.
Veja também
em
.
Autorização
A maioria dos sistemas de controle de versão oferecem uma funcionalidade
para que certas pessoas sejam autorizadas ou não a comitar em sub-áreas do repositório.
Seguindo o princípio de que quando na posse de um martelo as pessoas começam a procurar
por pregos, muitos projetos usam esta funcionalidade com vigor, garantindo cuidadosamente
acesso às pessoas apenas para as áreas as quais foram aprovadas a comitar, e
certificando-se de que elas não podem comitar em nenhum outro lugar. (Veja
em
para ver como é decidido quem pode
comitar aonde.)
Provavelmente poucos danos ocorrerão com o uso de um controle tão rigoroso,
no entanto uma política mais descontraída também é aceita. Alguns projetos
simplesmente usam um sistema de honra: quando uma pessoa é autorizada
a comitar, até para uma sub-área do repositório, o que ela recebe,
na verdade, é uma senha que a possibilita comitar em qualquer
lugar do projeto. Só lhe é pedido que mantenha os seus commits
na área determinada. Lembre-se que na verdade não há nenhum risco aqui:
em um projeto ativo, todos os commits são revisados,
de qualquer modo. Se alguém ver um commit onde não deveria estar,
isto será percebido e então será falado algo. Se uma mudança precisar
ser desfeita, isto é muito simples —tudo está sob versionamento
de controle mesmo, então é só reverter.
Existem diversas vantagens à abordagem mais descontraída. Primeiro,
como desenvolvedores evoluem para outras áreas (o que provavelmente acontecerá
caso eles continuem no projeto), não haverá sobrecarga administrativa para
garantir maiores privilégios. Uma vez tomada a decisão, a pessoa pode
começar a comitar na nova área imediatamente.
Em segundo lugar, a expansão pode ser feita de um modo mais refinado.
Geralmente, um committer na área X que quer evoluir para a área Y
começará a enviar patches para a área Y e pedir por review. Se alguém
que já tem permissão a commits na área Y ver o patch e aprová-lo, eles podem
avisar a quem o enviou para comitá-lo diretamente (mencionando o nome
de quem revisou/aprovou na log message, obviamente). Deste modo, o commit
virá diretamente da pessoa que fez a mudança, o que é preferível tanto
de um ponto de vista gerencial quanto de um ponto de vista de creditação
justa.
Por último, e talvez a mais importante, usar o sistema de honra
estimula uma atmosfera de confiança e respeito mútuo. Dar permissão de commit à alguém
para um subdomínio é uma confirmação feita sobre o preparamento técnico
desta pessoa —isto quer dizer: "Nós vemos que você tem proficiência para comitar
em uma certa parte do projeto, então vá fundo." No entanto, impor um controle rígido
de autorização diz: "Não apenas estamos impondo um limite sobre a sua proficiência, como
também estamos um pouco suspeitos das suas intenções."
Isto não é algo que você quer dizer se você puder evitar. Trazer alguém para o projeto
como um committer é uma oportunidade de iniciá-los em um círculo de confiança.
Uma boa maneira de fazer isto é dar mais poder à esta pessoa do que ela deveria ter,
e então informá-la que cabe à ela continuar ou não nestes limites.
O projeto Subversion tem operado através sistema de honra há mais
de quatro anos, com 33 committers integrais e 43 committers parciais
até o tempo de escrita deste livro. A única distinção que o
sistema realmente impõe é a entre committers e não-committers;
subdivisões adicionais são mantidas apenas por humanos.
Ainda assim, nós nunca tivemos problemas com alguém deliberadamente
comitar algo fora do seu domínio. Uma ou duas vezes já aconteceram
inocentes mal-entendidos sobre o grau de privilégios de commit de
alguém, mas tudo sempre foi resolvido de forma rápida e amigável.
Obviamente, em situações onde auto-policiamento é impraticável, você
deve contar com controles de autorização rígidos. Mas tais situação são raras.
Até quando existem milhões de linhas de código e centenas ou milhares de desenvolvedores,
um commit feito a algum módulo deverá ser revisado por quem trabalha neste mesmo módulo,
e então pode-se reconhecer caso alguém tenha feito um commit onde não deveria. Se
revisões de commit não estão acontecendo frequentemente, então
o projeto tem problemas maiores do que lidar com o sistema de autorização.
Em resumo, não perca muito tempo mexendo com o sistema de autorização do
controlador de versões, a não ser que você tenha uma razão específica para tal.
Isto normalmente não traz benefícios perceptíveis, e existem vantagens em,
ao invés disto, confiar em controles humanos.
É claro que nada disto deve ser interpretado de modo que
pareça que as restrições, especificamente, não tenham importância nenhuma.
Seria muito ruim para um projeto estimular pessoas a comitarem em áreas nas quais
não são qualificadas. Além do mais, em muitos projetos, permissão de commit integral (sem
restrições) tem um destaque especial: implica em direito de voto em questões de alto nível,
que afetam todo o projeto. Este aspecto político de commit é mais discutido em em
.
Bug Tracker
Bug tracking (perseguir/acompanhar bugs) é um tópico extenso; muitos de seus aspectos
são discutidos neste livro. Aqui, concentrarei-me principalmente na parte
de setup e considerações técnicas, mas para chegarmos nelas devemos começar
com a seguinte pergunta: exatamente que tipo de informação devemos
manter em um bug tracker?
O termo bug tracker pode enganar. Sistemas de
Bug tracking também são frequentemente usados para acompanhamento de pedidos
de novas funcionalidades, tarefas casuais, patches não solicitados—realmente
qualquer coisa que tenha estados distintos de início e fim, com transações de estados
entre estes dois pontos, e que acumule informação durante seu tempo de vida.
Por esta razão, bug trackers também são chamados de issue
trackers(rastreadores de problemas), defect trackers (rastreadores
de defeitos), artifact trackers (rastreadores de
produção), request trackers (rastreadores de
pedidos), trouble ticket systems (sistemas de bilhetes de problemas),
etc. Veja para uma lista de softwares.
Neste livro, continuarei a usar o termo "bug tracker" como referência
ao software que faz o acompanhamento, já que este é o principal termo que
as pessoas usam, mas usarei issue para me referir a
um único item no banco de dados do bug tracker. Isto nos permite identificar a diferença
entre o comportamento ou mau comportamento que o usuário encontrou (ou seja,
o bug propriamente dito), e o registro do tracker em relação
à descoberta, diagnóstico e eventual solução do bug. Tenha em mente que apesar da grande
maioria de issues sejam referidas à bugs propriamente ditos, issues também podem
ser usadas para acompanhar outros tipos de tarefas também.
O ciclo de vida clássico de uma issue é parecido com isso:
Alguém abre a issue. É provido um sumário, uma descrição inicial
(incluindo informações de reprodução do bug, caso seja adequado;
veja
em
para ler sobre
como encorajar bons relatórios de bug) e qualquer outra
informação que o tracker pedir. A pessoa que abriu a issue
pode ser completamente desconhecida ao projeto—relatos
de bug e pedidos de funcionalidades podem vir tanto da comunidade de
usuários quanto da de desenvolvedores.
Assim que preenchida, a issue está no que é chamado de estado
aberto (open state). Como nenhuma ação
foi tomada ainda, alguns trackers também a identificam como
não verificada (unverified) e/ou
não iniciado (unstarted). Ela ainda não
é atribuída a ninguém; ou, em alguns sistemas, ela é atribuída
a um usuário falso que representa a falta de real atribuição.
Neste ponto, a issue está em uma área de espera: ela foi registrada,
mas ainda não foi integrada à consciência do projeto.
Outras pessoas leem a issue, adicionam comentários, e talvez
façam alguma pergunta à pessoa que identificou o problema caso algo
precise ser esclarecido.
O bug é reproduzido.
Talvez este seja o momento mais importante do seu ciclo de vida.
Apesar do bug ainda não ter sido corrigido, o fato de
quem alguém, além do identificador original, conseguiu
fazer com que o bug se repetisse é a prova de que se trata de um defeito
autêntico, e, não menos importante, confirma a quem relatou o bug
que foi feita uma contribuição ao projeto através
do relato de um bug genuíno.
O bug então é diagnosticado: sua
causa é definida, e, se possível, o esforço requirido para
sua correção é estimado. Tenha certeza que estes dados sejam
registrados na issue; se a pessoa que diagnosticou o bug precise
se afastar do projeto por algum tempo (como acontece frequentemente
com desenvolvedores voluntários), outra pessoa deve ser capaz de
continuar daonde a outra parou.
Neste estágio, ou, às vezes, no anterior, um desenvolvedor pode
"ficar dono" da issue e atribuí-la para si
( em
explora o processo de designação mais detalhadamente). A
prioridade da issue também pode ser
determinada neste estágio. Por exemplo, se ela é tão grave que
pode atrasar a próxima release, este fato deve ser identificado
cedo, e o tracker deve ter algum modo de identificar isto.
A issue então é agendada para correção.
Agendar não quer dizer, necessariamente, associar uma data
para a correção. Às vezes, apenas significa decidir em qual
release futura (não necessariamente a próxima) o bug deverá
estar corrigido, ou decidir que ele não bloqueará alguma release
em particular. Agendamento também pode ser dispensado caso
o bug seja de rápida correção.
O bug então é fixado (ou a tarefa concluída, ou o patch executado,
ou o que quer que seja). A mudança ou conjunto de mudanças que o corrigiram devem
ser registradas em um comentário na issue, e então ela é
fechada e/ou marcada como
resolvida.
Existem algumas variações bem comuns neste ciclo de vida. Algumas
vezes uma issue é fechada muito rapidamente após ser adicionada, pois
verifica-se que, na verdade, não é um bug, mas sim um mal-entendido por
parte do usuário. Conforme um projeto adquirem mais usuários, mais e mais
essas issues inválidas irão aparecer, e os desenvolvedores fecharão-as com
mensagens cada vez mais mal-humoradas. Tente se proteger contra esta tendência.
Ela não faz nenhum bem, pois o usuário em questão não é responsável por todas as
issues inválidas que já foram enviadas anteriormente; esta tendência estatística
é visível apenas do ponto de vista do desenvolvedor, não do usuário. (Em
, mais para frente
neste capítulo, veremos algumas técnicas para reduzir o número
de issues inválidas.) Também, se diferentes usuários estão experienciando o
mesmo mal-entendido repetidamente, talvez isto signifique que o software precise
ser replanejado. Este padrão é mais fácil de ser notado onde existe um gerente de
issues monitorando o banco de dados de issues; veja
em
.
Outra variação comum no ciclo de vida é a issue ser fechada como
duplicata logo após a abertura. Uma duplicata
acontece quando alguém abre uma issue que já é conhecida no projeto.
Duplicatas não estão confinadas à issues abertas: é possível que um bug volte
a aparecer depois de ter sido corrigido (isto é conhecido como
regressão), em cujo caso é preferível que se reabra
a issue original e feche qualquer novos relatos como duplicatas da original.
O sistema de rastreamento de bugs deve manter um rastro deste relacionamento
bidirecionalmente, para que a reprodução da informação nas duplicatas esteja disponível
na issue original e vice versa.
Uma terceira variação é que desenvolvedores fechem a issue, pensando tê-la
corrigido, apenas para que o relator rejeite a correção e reabra a issue. Isto
normalmente acontece por que o o desenvolvedor simplesmente não tem acesso ao
ambiente necessário para reproduzir o bug, ou por que a issue não foi testada
usando a mesma receita de reprodução usada pelo relator.
Além destas variações, podem existir outros pequenos detalhes do ciclo de
vida que podem variar dependendo do software de rastreamento. Mas a forma básica
é a mesma, e, apesar de o ciclo de vida em si não ser específico ao software de código aberto,
ele tem implicações em como projetos abertos usam os seus bug trackers.
Como o primeiro passo indica, o tracker é uma superfície pública do
projeto tanto quanto mailing lists ou páginas da web. Qualquer um pode relatar uma issue,
qualquer um pode olhar uma issue, e qualquer um pode navegar pela lista de issues
abertas. Você nunca sabe quantas pessoas estão esperando para ver o progresso de uma
específica issue. Enquanto o tamanho e a habilidade da comunidade de desenvolvimento retém
o ritmo com que issues podem ser corrigidas, o projeto pelo menos tenta reconhecê-las
a partir do momento em que aparecem. Até se a issue for protelada por um tempo,
a resposta encoraja o relator a se manter envolvido, por que ele sente que um humano
registrou o que ele fez (lembre-se que preencher uma issue normalmente envolve mais esforço
que, por exemplo, mandar um email). Além do mais, assim que uma issue é vista por um desenvolvedor,
ela entra na consciência do projeto, no sentido de que este desenvolvedor pode estar observando por
outras instâncias desta issue, pode conversar sobre ela com outros desenvolvedores, etc.
A necessidade de respostas a tempo implica duas coisas:
O tracker deve estar conectado com uma mailing list, para que cada mudança
em uma issue, incluindo o seu preenchimento inicial, causa uma mensagem a ser enviada
explicando o que aconteceu. Esta mailing list normalmente é diferente da lista de desenvolvimento,
já que não são todos os desenvolvedores que desejam receber mensagens automadas de bugs, mas
(assim como mensagens de commit) o cabeçalho "Responder a" deve ser definido para a lista de
desenvolvimento.
O formulário para preencher issues deve conter o endereço de email do
relator, para que ele seja contatado para mais informações. (No entanto, ele não deve
demandar o endereço de email, já que algumas pessoas podem preferir
reportar issues anonimamente. Veja
mais à frente neste capítulo
para mais sobre a importância da anonimidade.)
Interação com listas de E-mail
Tome cuidado para que o bug tracker não se transforme em um fórum de discussões.
Apesar da importância de se manter a presença humana no bug tracker, ele não é fundamentalmente
adequado para discussões em tempo real. Ao invés disto, pense nele como um arquivo, um modo de organizar
fatos e referências para outras discussões, principalmente aquelas que acontecem nas listas de e-mail.
Existem duas razões para que se faça esta distinção. Primeiro, o bug tracker é mais incômodo de se usar
do que as listas de e-mail (ou que salas de bate-papo em tempo real, por exemplo). Isto não é por que bug trackers
têm uma interface de usuário ruim, mas eles foram desenvolvidos para capturar e apresentar situações discretas, e
não discussões de fluxo livre. Segundo, nem todo mundo envolvido
na discussão pode estar acompanhando o bug tracker. Parte de um bom gerenciamento de issues (veja
em
) é confirmar que cada issue seja trazida para a atenção das
pessoas ao invés de fazer com cada desenvolvedor tenha que monitorar todas as issues. Em
em , nós veremos
modos para que as pessoas não acidentalmente levem as discussões de seus lugares apropriados para
o bug tracker.
Alguns bug trackers podem monitorar as listas de e-mail e automaticamente fazer log de
todos os e-mails referentes a uma issue específica. Tipicamente eles fazem isso reconhecendo
o número de identificação da issue na linha de assunto do e-mail, como parte de uma palavra especial;
desenvolvedores aprender a incluir essas palavras nos seus e-mails para atrair a atenção do tracker. O bug
tracker pode então salvar o e-mail inteiro, ou (melhor ainda) apenas guardar um link para o email no
arquivo da lista de e-mail. De qualquer modo, esta é uma característica muito útil; se o seu tracker tem ela,
tenha certeza de deixá-la ativa e lembrar as pessoas de tirarem proveito da mesma.
Pré-filtrando o Bug Tracker
A maioria dos bancos de dados de bugs eventualmente sofrem do mesmo problema: um
monte de issues duplicadas ou inválidas preenchidas por usuários bem intencionados,
no entanto inexperientes ou mal informados. O primeiro passo para combater esta tendência
é normalmente colocar um aviso proeminente na primeira página do bug tracker, explicando
como identificar se um bug é realmente um bug, como procurar se ele já foi informado, e,
finalmente, como reportá-lo eficientemente se depois disto ainda for considerado um novo bug.
Isto reduzirá a quantidade de "sujeira" por um tempo, mas conforme o número de usuários
cresce, o problema eventualmente retornará. Ninguém pode, individualmente, ser apontado como
culpado por isto. Todos estão apenas contribuir para o bem-estar do projeto, e até se
o primeiro relatório de bug não foi útil, você ainda quer encorajá-los a continuarem envolvidos
e preencher relatórios melhores no futuro. Enquanto isto, no entanto, o projeto precisa manter o
banco de dados de issues o mais limpo possível.
Duas das coisas que ajudarão muito na prevenção deste problema são: ter certeza de que
existem pessoas acompanhando o bug tracker que possuam conhecimento suficiente para fechar
issues como inválidas ou duplicatas no momento em que elas entrarem, e requirindo (ou fortemente
encorajando) que os usuários confirmem seus bugs com outras pessoas antes de preencherem-os no
tracker.
A primeira ténica parace ser usada universalmente. Até em projetos com bancos de dados
enormes (por exemplo, o bug tracker do projeto Debian em ,
que detia 315,929 issues até o momento desta escrita) ainda é possível conciliar as coisas
para que alguém veja cada issue que entrar. Talvez seja uma pessoa diferente
dependendo da categoria da issue. Por exemplo, o projeto Debian é uma coleção de pacotes de software,
então ele automaticamente encaminha cada issue para os mantenedores apropriados destes pacotes. Claro,
usuários podem, às vezes, identificar erroneamente a categoria de uma issue, fazendo com que ela seja
enviada, já inicialmente, para a pessoa errada, e esta talvez precise redirecioná-la. No entanto, a
parte importante é que o fardo ainda está sendo dividido—se o usuário acertou ou não no preenchimento
da issue, os acompanhamentos ainda são distribuídos de modo relativamente igual entre os desenvolvedores,
então cada issue pode ser respondida à tempo.
A segunda técnica é menos difundida, provavelmente por que é mais difícil de ser automatizada.
A principal ideia é que cada issue nova seja "aceita" no banco. Quando um usuário acha que
encontrou um problema, lhe é pedido uma descrição do problema em alguma das listas de email, ou em
algum canal de IRC, e então espera-se a confirmação de alguém de que aquele é realmente
um bug. Trazer este segundo par de olhos pode prevenir um monte de relatórios falsos. Às vezes,
esta outra pessoa pode identificar que o compartamento não seja um bug, ou que foi corrigido em
atualizações mais recentes. Ou ela pode estar familiar com os sintomas de uma issue antiga,
e pode prevenir a duplicata informando o relator do bug da issue antiga. Muitas vezes é suficiente
perguntar ao usuário "Você chegou a pesquisar no bug tracker para verificar se este bug já foi
informado?". Muitas pessoas simplesmente não pensam nisto, mas pesquisarão satisfeitas sabendo
que alguém espera isto delas.
Este sistema de aceitação pode deixar o banco de dados efetivamente limpo, mas
ele também tem suas desvantagens. Muitas pessoas irão arquivar issues de qualquer modo,
sem avisar outros, seja por não ver ou mesmo ignorando as instruções para achar uma
duplicata. Por isto ainda é necessário que voluntários observem o banco de dados de
issues. Além do mais, por conta de novos voluntários ainda não terem compreensão da
dificuldade que é manter um banco de dados de issues, não é justo repreendê-los muito
duramente por ignorarem as instruções. Então voluntários devem ser vigilantes, e
analisar o modo de coibição que utilizarão para retornar issues sem aceitação
de volta aos seus reportadores. O objetivo é treinar cada reportador a usar
o sistema de aceitação no futuro, para que haja uma comunidade ascendente de pessoas
que compreendem o sistema de filtro de issues. Identificando uma issue sem aceitação,
os passos ideais são:
Imediatamente responder à issue, educadamente agradecendo o usuário
por reportá-lo, mas destacando as regras de aceitação (que devem, é claro,
estarem destacadas no web site).
Se a issue é claramente válida e não uma duplicata, aprove-a
e comece o seu ciclo de vida natural. No final das contas, o
usuário arquivou a issue agora está informado sobre o esquema de
aceitação, então não há motivo em desperdiçar o trabalho feito
fechando uma issue válida.
No entanto, se a issue não for claramente válida, feche-a, mas peça ao
reportador para que reabra-a caso receba uma confirmação de aceitação.
Quando receberem, eles devem colocar uma referência da confirmação (por exemplo,
a URL nos arquivos da lista de emails).
Lembre-se que apesar deste sistema melhorar o controle de falsos positivos no banco de dados
ao longo do tempo, mas nunca poderá completamente parar os preenchimentos incorretos de ocorrências.
O único modo de controlar estes preenchimentos inválidos é fechar o bug tracker para todos e deixá-lo
aberto somente para os desenvolvedores—o que se torna uma cura quase sempre pior que a doença. O
melhor é aceitar que limpar issues inválidas será sempre parte da rotina de manutenção do projeto, e
tente conseguir o máximo de pessoas possível para ajudar.
Veja também
em
.
IRC / Real-Time Chat Systems (sistemas de bate-papo em tempo real)
Muitos projetos oferecem salas de bate-papo em tempo real using Internet
Relay Chat (IRC), fóruns onde usuários e
desenvolvedores podem trocar perguntas entre si e conseguir respostas instantâneas.
Apesar de você poder rodar um servidor IRC do seu proprio website,
isto geralmente não vale a pena. Ao invés disto, faça o que todo mundo faz: rode os seus canais
IRC no Freenode (). Freenode garante a você o controle
necessário para administrar os canais IRC do seu projeto,Não há exigências ou expectativas
que você doe para o Freenode, mas se você ou o seu projeto puderem fazê-lo, por favor considere
uma doação. Ele é uma instituição filantrópica isenta de impostos nos Estados Unidos e realizam um
serviço valioso. enquanto também lhe poupa do não-insignificante trabalho de
manter, você proprio, um server IRC.
A primeira coisa a se fazer é escolher o nome do canal. A escolha mais obvia é o nome
do seu projeto—se estivver disponível no Freenode, então use-o. Caso contrário,
tente escolher algo parecido com o nome do seu projeto e fácil de lembrar. Anuncie a disponibilidade
do projeto no website. Por exemplo, isto aqui aparece proeminentemente na home page do Subversion:
Se você está usando Subversion, nós recomendamos que você
participe da lista de emails users@subversion.tigris.org
, e leia o Subversion Book e o
FAQ.
Você também pode fazer perguntas no IRC no canal
irc.freenode.net
#svn.
Alguns projetos têm múltiplos canais, um por subtópico. Por exemplo, um canal
para problemas de instalação, outro para questões, outro para desenvolveimento, etc.
( em
discute e explica como dividir múltiplos canais).
Quando o seu projeto é jovem, o ideal é que haja apenas um canal, com todos conversando em
conjunto. Mais tarde, quando a relação usuário-por-desenvolvedor aumentar, separar os canais
pode se tornar necessário.
Como as pessoas saberão de todos os canais disponíveis, e em qual canal falarem?
E quando falarem, como irão saber quais são as convenções locais?
A resposta é avisar as pessoas configurando o tópico
do canal.Para configurar o tópico do canal, use o comando
/topic. Todos os comandos no IRC começam com
"/". Veja se
se você não está familiarizado com o uso e a administração do IRC; em particular,
é um excelente
tutorial. O tópico do canal é uma curta mensagem que
cada usuário vê assim que entra no canal. Esta mensagem dá uma pequena orientação
para novatos, e também aponta para mais informações. Por exemplo:
Você está falando agora em #svn
O tópico para #svn é: Fórum para questões de usuário do Subversion - veja também
http://subversion.tigris.org/. || Discussões sobre desenvolvimento
acontecem em #svn-dev. || Por favor não cole longas mensagens aqui; ao invés disto,
use um serviço como http://pastebin.ca/ . || NOVIDADES: Subversion 1.1.0
foi lançado, veja http://svn110.notlong.com/ para detalhes.
Isto é conciso, no entanto informa aos novatos o que eles precisam saber. Esclarece exatamente
para quê existe o canal, assim como também a página do projeto (caso alguém passe pelo canal
sem antes ter visto a página do projeto), menciona um canal relacionado, e dá alguma orientação
sobre colar mensagens.
Paste Sites (sites de "colar")
Um canal IRC é um espaço compartilhado: todos podem ver o que todo mundo diz.
Normalmente, isto é uma boa coisa, pois permite que as pessoas entrem em uma discussão
quando elas têm algo para contribuir, e permite a espectadores que aprendam enquanto observam.
No entanto, cria-se um problema quando alguém provê uma grande quantidade de informação
de uma vez só, como uma cópia da sessão de debug, já que colar várias linhas de output no canal
atrapalhará as outras conversas.
A solução é usar algum site de
pastebin ou pastebot.
Quando pedida uma grande quantidade de dados de alguém no canal, peça que não
colem-a diretamente no canal, mas, ao invés disto, visitem (por exemplo)
, colem os dados no formulário,
e informem a URL resultante no canal. Qualquer um então pode visitar a nova URL
e visualizar a informação.
Existem muitos sites neste estilo hoje em dia (muitos, até, para uma lista de tamanho razoável),
mas aqui vão alguns dos que eu venho usando:
,
,
,
,
e
.
Bots (robôs)
Muitos canais IRC tecnicamente-orientados têm um membro não-humano,
também conhecido como bot, que é capaz de guardar
e devolver informações em respostas a comandos específicos. Tipicamente, o bot
é endereçado como qualquer outro membro do canal, ou seja, os comandos são enviados
a ele como se você estivesse "falando" com ele. Por exemplo:
<kfogel> ayita: learn diff-cmd = http://subversion.tigris.org/faq.html#diff-cmd
<ayita> Thanks!
Com isto, o bot (que está logado no canal com o nome de ayita) a lembrar
uma URL como resposta ao pedido "diff-cmd". Agora nós podemos nos endereçar ao
ayita, pedindo-o que avise outro usuário sobre diff-cmd:
<kfogel> ayita: tell jrandom about diff-cmd
<ayita> jrandom: http://subversion.tigris.org/faq.html#diff-cmd
A mesma coisa pode ser realizada através de um conveniente atalho:
<kfogel> !a jrandom diff-cmd
<ayita> jrandom: http://subversion.tigris.org/faq.html#diff-cmd
O comando exato e o comportamento gerado varia de bot para bot. O exemplo acima
é com o ayita
(), o qual normalmente é uma instância
rodando em #svn no
freenode. Outros bots incluem o Dancer
() e o Supybot
(). Note que nenhum privilégio especial
é necessário para rodar um bot. Um bot é um programa cliente; qualquer um
pode iniciar um e o configurar para ouvir a um canal/servidor em particular.
Se o seu canal tende a receber as mesmas perguntas vez após vez, eu
recomendo fortemente que um bot seja configurado. Apenas uma pequena porcentagem
dos usuários do canal vão adquirir a experiência necessária para manipular o bot,
mas estes usuários irão responder a uma porcentagem desproporcionalmente alta de questões,
já que o bot permite-os que respondam de modo muito mais eficiente.
Arquivando o IRC
Apesar de ser possível arquivar tudo que acontece em um canal IRC,
isto não é necessariamente comum. Conversas em IRC podem ser nominalmente públicas,
mas muitas pessoas as consideram como conversas informais, semi-privadas. Usuários
podem se importar menos com gramática, e muitas vezes expressar opiniões (por exemplo,
sobre outro programa ou outros programadores) que eles não gostariam que fossem arquivado
para sempre em um diretório online.
Claro, haverão momentos em que trechos
que serão guardados, e isto é ok. Muitos clientes IRC podem fazer log de
uma conversa a partir desde que o usuário peça, ou, além disso, é possível também
apenas copiar e colar a conversa do IRC para um forum permanente (sendo comum o
bug tracker). Mas criar logs indiscriminadamente pode deixar alguns usuários receosos.
Se você for arquivar tudo, tenha certeza de avisar isto no tópico do canal, assim como
passar a URL para o diretório onde serão guardados os arquivos.
Wikis
Uma wiki é um web site que permite que
qualquer visitante edite ou extenda o seu conteúdo; o termo "wiki" (de
uma palavra Havaiana que significa "ligeiro" ou "super-rápido") é também
usada para se referir ao software que permite este tipo de edição. Wikis
foram inventadas em 1995, mas sua popularidade começou a crescer mesmo em 2000
ou 2001, impulsionada pelo sucesso da Wikipedia (), uma enciclopédia no modelo wiki
de conteúdo livre. Pense em uma wiki como algo entre um IRC e web pages:
wikis não acontecem em tempo real, então as pessoas tem a chance de considerar
e polir suas contribuições, mas eles também pode facilmente adicionar,
envolvendo menos trabalho de interface do que editar uma web page normal.
Wikis não são equipamento padrão para projetos open source,
mas provavelmente serão em um futuro próximo. Como elas são uma tecnologia
relativamente nova, e pessoas ainda estão experimentando diferentes modos de
usá-la, eu irei apenas dar algumas palavras de aviso aqui—neste estágio,
é mais fácil analisar os usos incorretos de wiki do que analisar seus sucessos.
Caso você decida optar por uma wiki, se esforce para que ela tenha
uma organização limpa e uma aparência prazerosa, para que os visitantes (potenciais editores)
instintivamente possam saber onde colaborar. Igualmente importante, coloque estas normas
na própria wiki, para que as pessoas tenham algum lugar para se guiarem. Seguidamente,
administradores de wikis caem na fantasia de que, porque muitos visitantes estão colaborando
individualmente com conteúdo de alta qualidade para o site, a soma de todas estas
contribuições também será de alta qualidade. Não é assim que web sites funcionam.
Cada página ou parágrafo pode ser bom quando considerado individualmente,
mas não serão bons se adicionados a um conjunto confuso ou desorganizado. Muitas vezes,
wikis sofrem de:
Falta de princípios de navegação.
Um web site bem organizado faz com que seus visitantes sintam
que sabem onde estão a qualquer momento. Por exemplo, se a página
é bem feita, as pessoas saberão intuitivamente a diferença entre
as partes "tabela de conteúdo" e "conteúdo". Contribuidores
de uma wiki irão respeitar estas diferenças também, mas
apenas se estas diferenças já estiverem presentes.
Duplicação de informação.
Wikis frequentemente terminam com diferentes páginas contendo
informações similares, por que cada contribuidor não percebeu
duplicações. Isto pode ocorrer parcialmente pela falta dos
princípios de navegação notados acima, já que as pessoas podem
não achar o conteúdo duplicado se ele não estiver onde elas esperam
encontrá-lo.
Inconsistência de público-alvo
A certo modo, este problema é inevitável quando existem muitos
autores, mas pode ser diminuído se existirem regras escritas sobre
como criar novo conteúdo. Também é de grande ajuda que novas
contribuições sejam editadas agressivamente bem no início,
para que os padrões fiquem enraizados.
A solução para todos estes problemas é a mesma: tenha padrões de
editorial, e demonstre-os não apenas postando-os, mas também editando
páginas para que mantenham-se fieis aos mesmos. Em geral, wikis
irão amplificar qualquer falha que exista, pois os contribuidores
imitam o padrão que veem na sua frente. Não apenas crie a wiki e
espere com que tudo se encaixe perfeitamente. Você deve fazer com
que ela tenha um conteúdo bem escrito, para que as pessoas tenham
um modelo a seguir.
O exemplo mais claro de uma wiki bem organizada é a Wikipedia,
embora isto seja por que o conteúdo (páginas enciclopédicas) são
naturalmente bem adequadas para o formato wiki. Mas se você examinar
de perto a Wikipedia, você verá que seus administradores colocam
em prática uma fundação de coperação bastante
minuciosa. Existe uma documentação extensiva sobre como escrever
novas entradas, como manter um ponto de vista apropriado, que tipos
de edições fazer, que tipos de edições evitar, um processo de resolução
de edições contestadas (envolvendo vários estágios, incluindo eventual
arbitragem), e por diante. Eles também de controle de autorização,
de modo que se uma página é alvo de edições inapropriadas seguidamente,
eles podem trancá-la até que o problema seja resolvido. Em outras palavras,
eles não apenas "jogaram" alguns modelos no web site e esperaram o melhor
acontecer. A Wikipedia funciona por que seus criadores pensaram cuidadosamente
sobre como fazer com que milhares de pessoas desconhecidas talhem suas escritas
dividindo uma visão em comum. Apesar de você não precisar do mesmo
nível de preparamento para fazer uma wiki em um projeto de software livre,
este espírito é digno de se emular.
Para mais informações em wikis, veja
. Também, a primeira
wiki ainda vive saudavelmente, e contém vários debates sobre como
administrar wikis: veja ,
, e
para
diversos pontos de vista.
Web Site
There is not much to say about setting up the project web site
from a technical point of view: setting up a web server and writing
web pages are fairly simple tasks, and most of the important things to
say about layout and arrangement were covered in the previous chapter.
The web site's main function is to present a clear and welcoming
overview of the project, and to bind together the other tools (the
version control system, bug tracker, etc.). If you don't have the
expertise to set up a web server yourself, it's usually not hard to
find someone who does and is willing to help out. Nonetheless, to
save time and effort, people often prefer to use one of the canned
hosting sites.
Canned Hosting
There are two main advantages to using a canned site. The first
is server capacity and bandwidth: their servers are beefy boxes sitting
on really fat pipes. No matter how successful your project gets,
you're not going to run out of disk space or swamp the network
connection. The second advantage is simplicity. They have already
chosen a bug tracker, a version control system, a mailing list manager,
an archiver, and everything else you need to run a site. They've
configured the tools, and are taking care of backups for all the data
stored in the tools. You don't need to make many decisions. All you
have to do is fill in a form, press a button, and suddenly you've got
a project web site.
These are pretty significant benefits. The disadvantage, of
course, is that you must accept their choices and
configurations, even if something different would be better for your
project. Usually canned sites are adjustable within certain narrow
parameters, but you will never get the fine-grained control you would
have if you set up the site yourself and had full administrative
access to the server.
A perfect example of this is the handling of generated files.
Certain project web pages may be generated files—for example,
there are systems for keeping FAQ data in an easy-to-edit master
format, from which HTML, PDF, and other presentation formats can be
generated. As explained in
earlier in this chapter,
you wouldn't want to version the generated formats, only the master
file. But when your web site is hosted on someone else's server, it
may be impossible to set up a custom hook to regenerate the online
HTML version of the FAQ whenever the master file is changed. The only
workaround is to version the generated formats too, so that they show
up on the web site.
There can be larger consequences as well. You may not have as
much control over presentation as you would wish. Some of the canned
hosting sites allow you to customize your web pages, but the site's
default layout usually ends up showing through in various awkward
ways. For example, some projects that host themselves at SourceForge
have completely customized home pages, but still point developers to
their "SourceForge page" for more information. The SourceForge page
is what would be the project's home page, had the project not used a
custom home page. The SourceForge page has links to the bug tracker,
the CVS repository, downloads, etc. Unfortunately, a SourceForge page
also contains a great deal of extraneous noise. The top is a banner
ad, often an animated image. The left side is a vertical arrangement
of links of little relevance to someone interested in the project.
The right side is often another advertisement. Only the center of the
page is devoted to truly project-specific material, and even that is
arranged in a confusing way that often makes visitors unsure of what
to click on next.
Behind every individual aspect of SourceForge's design, there is
no doubt a good reason—good from SourceForge's point of view,
such as the advertisements. But from an individual project's point of
view, the result can be a less-than-ideal web page. I don't mean to
pick on SourceForge; similar concerns apply to many of the canned
hosting sites. The point is that there's a tradeoff. You get relief
from the technical burdens of running a project site, but only at the
price of accepting someone else's way of running it.
Only you can decide whether canned hosting is best for your
project. If you choose a canned site, leave open the option of
switching to your own servers later, by using a custom domain name for
the project's "home address". You can forward the URL to the canned
site, or have a fully customized home page at the public URL and hand
users off to the canned site for sophisticated functionality. Just
make sure to arrange things such that if you later decide to use a
different hosting solution, the project's address doesn't need to
change.
Choosing a canned hosting site
The largest and most well-known hosting site is SourceForge. Two other
sites providing the same or similar services are savannah.gnu.org and BerliOS.de. A few organizations,
such as the Apache Software
Foundation and Tigris.orgDisclaimer:
I am employed by CollabNet, which sponsors
Tigris.org, and I use Tigris regularly., give free
hosting to open source projects that fit well with their missions and
their community of existing projects.
Haggen So did a thorough evaluation of various canned hosting
sites, as part of the research for his Ph.D. thesis,
Construction of an Evaluation Model for Free/Open Source
Project Hosting (FOSPHost) sites. The results are at
, and see especially
the very readable comparison chart at .
Anonymity and involvement
A problem that is not strictly limited to the canned sites, but
is most often found there, is the abuse of user login functionality.
The functionality itself is simple enough: the site allows each
visitor to register herself with a username and password. From
then on it keeps a profile for that user, and project administrators
can assign the user certain permissions, for example, the right to
commit to the repository.
This can be extremely useful, and in fact it's one of the prime
advantages of canned hosting. The problem is that sometimes user
login ends up being required for tasks that ought to be permitted to
unregistered visitors, specifically the ability to file issues in the
bug tracker, and to comment on existing issues. By requiring a
logged-in username for such actions, the project raises the
involvement bar for what should be quick, convenient tasks. Of
course, one wants to be able to contact someone who's entered data
into the issue tracker, but having a field where she can enter her
email address (if she wants to) is sufficient. If a new user spots a
bug and wants to report it, she'll only be annoyed at having to fill
out an account creation form before she can enter the bug into the
tracker. She may simply decide not to file the bug at all.
The advantages of user management generally outweigh the
disadvantages. But if you can choose which actions can be done
anonymously, make sure not only that all
read-only actions are permitted to non-logged-in visitors, but also
some data entry actions, especially in the bug tracker and, if you
have them, wiki pages.