Infra-estrutura Social e Política
A primeira pergunta que as pessoas fazem sobre o software livre é
"Como funciona? O que é que move um projecto? Quem toma decisões?"
Fico sempre insatisfeito com respostas prontas sobre meritocracia, o
espírito de cooperação, o código falar por si mesmo, etc.
O facto é que a questão não tem resposta fácil. A meritocracia, a
cooperação e a execução de código fazem parte da resposta, mas não
explicam como é que os projectos são geridos no dia-a-dia e nada dizem
sobre como são resolvidos os conflitos.
Este capítulo tenta mostrar as fundações estruturais que os projectos
bem sucedidos têm em comum. Digo "bem sucedidos" não só em termos de
qualidade técnica, mas também saúde operacional e sobrevivência.
Saúde operacional é a capacidade sustentada de um projecto incorporar novas
contribuições de código e novos programadores e ter capacidade de resposta
aos relatórios de erros que entrem. Capacidade de sobrevivência é a capacidade
de um projecto existir independentemente de qualquer participante individual ou
sponsor; pense nisto como a probabilidade do projecto continuar mesmo que todos
os seus membros fundadores se mudarem para outras coisas. O sucesso técnico não
é difícil de alcançar, mas sem uma base de programadores e uma fundação
social robustas, um projecto pode ser incapaz de tratar o crescimento que esse
sucesso inicial trás ou a partida de indivíduos carismáticos.
Há várias maneiras de alcançar este tipo de sucesso. Algumas envolvem uma
estrutura de governo formal, pela qual os debates são resolvidos, os novos
programadores são admitidos (e por vezes excluídos), novas características
são planeadas e assim sucessivamente. Outras envolvem uma estrutura menos
formal, mas maior auto-controlo, para produzir uma atmosfera de justiça em
que as pessoas possam confiar como uma forma de governação de
facto. Ambos os caminhos levam ao mesmo resultado, perenidade
institucional, suportada por hábitos e procedimentos bem compreendidos por
todos os participantes. Estas características são ainda mais importantes
em sistemas auto-organizados do que em sistemas controlados centralmente,
porque em sistemas auto-organizados todos têm consciência que algumas maças
podres podem estragar toda a caixa, pelo menos durante algum tempo.
Bifurcabilidade
O ingrediente indispensável que serve de argamassa a que os programadores
se mantenham unidos num projecto de software livre e os leva a estarem disponíveis
para o compromisso quando necessário é a bifurcabilidade: a
capacidade de qualquer pessoa a partir de uma cópia do código fonte e usando-o como
base começar um projecto concorrente, conhecido como bifurcação.
A coisa paradoxal é que é esta possibilidade de bifurcações é
normalmente uma força muito maior nos projectos de software livre que as próprias
bifurcações, as quais são muito raras. Porque uma bifurcação é má para toda a gente
(por razões explicadas em detalhe em
em
), quanto mais
séria uma ameaça de ramificação fica, mais as pessoas estão dispostas a
efectuar um compromisso para a evitar.
As bifurcações, ou o potencial para o seu surgimento melhor dizendo, é
a razão pela qual nos projectos de software livre não há verdadeiros
ditadores. Pode parecer uma afirmação surpreendente, tendo em conta a
frequência com que se ouve falar de "ditador" ou de "tirano" num dado
projecto de «open source». Mas este tipo de tirania é especial, muito
diferente do significado convencional da palavra. Imagine um rei cujos
súbditos possam copiar o seu reino completo a qualquer momento e possam
mudar para a cópia para governarem como acharem mais apropriado. Esse
rei não governaria de modo completamente diferente daquele ao qual os subditos
estão sob tutela independentemente do que ele faça?
É por esta razão que projectos que não têm uma organização formal
como democracias são, na prática, democracias quando se chega ao momento
de tomar decisões importantes. A replicabilidade implica a bifurcabilidade;
a bifurcabilidade implica o consenso. É perfeitamente possível que se
deseje atribuir a um líder (o exemplo mais famoso é o de Linus Torvalds no
desenvolvimento do cerne do Linux), mas isso foi porque assim o
escolheram, de uma maneira não cínica e não sinistra.
O ditador não tem uma mão mágica sobre o projecto. A propriedade chave de
todas as licenças de «open source» é não darem a ninguém mais poder do que a
qualquer outra entidade na decisão de como o código pode ser alterado ou
usado. Se o ditador começar de repente a tomar decisões más, haverá uma paragem
de actividade, seguida eventualmente de uma revolta e uma ramificação. Claro
que isto normalmente não chega tão longe porque o ditador faz um compromisso
antes.
Mas só porque a bifurcabilidade coloca um limite máximo no poder que
uma pessoa pode exercer num projecto não quer com isto dizer que não haja
importantes diferenças em como os projectos sejam governados. Não quer que
cada decisão venha até à pergunta extrema de quem está a pensar num ramo.
Isso seria cansativo muito rapidamente, retirando energia do trabalho
propriamente dito. As duas secções seguintes examinam maneiras diferentes de
organizar projectos de tal modo que a maior parte das decisões sejam
adoptaram sem guerra. Estes dois exemplos são de algum modo extremos ideais;
vários projectos caiem no continuo entre ambos.
Ditador Benevolente
O modelo ditador benevolente é exactamente
aquilo que parece: a autoridade final de tomada de decisão fica com essa
pessoa, que, por virtude da sua personalidade e experiência, se espera
que faça um uso sábio da mesma.
Embora "ditador benevolente" (ou abreviadamente
BD) seja o termo normalmente usado para este
papel, seria melhor pensar nele como "árbitro aprovador pela comunidade"
ou "juiz". Geralmente os ditadores benevolentes não tomam de facto todas
as decisões ou mesmo a maior parte. É improvável que essa pessoa possa
ter a perícia suficiente para consistentemente tomar boas decisões em todas
as áreas de um projecto, e de qualquer modo, os programadores de qualidade
não ficam excepto se tiverem alguma influência na direcção do projecto.
Assim os ditadores benevolentes normalmente não ditam muito. Em vez disso
deixam as coisas funcionar por si através de discussão e experimentação
sempre que possível. Participam nessas discussões eles próprios, mas como
programadores normais, normalmente delegando numa pessoa da área da
manutenção que tenha mais conhecimento. Só quando é claro que não se
está a alcançar consenso e a maior parte do grupo quer
alguém que guie a decisão de modo a poder prosseguir." A relutância em
tomar decisões por decreto é um traço partilhado virtualmente por todos
os ditadores benevolentes bem sucedidos. É uma das razões porque conseguem
manter esse papel.
Quem Pode Ser um Bom Ditador Benevolente?
Quem Pode Ser um Bom Ditador Benevolente?
Ser um BD exige uma combinação de traços. Necessita, primeiro que
tudo, uma sensibilidade grande sobre a sua própria influência no projecto,
que por outro lado trás auto-controlo. Nos primeiros estadios de uma
discussão, não deve exprimir opiniões e conclusões para evitar que os
outros achem inútil efectuarem dissidências. As pessoas têm que ser livres
de se exprimirem, mesmo ideias estúpidas. É inevitável que o próprio
BD exprime de tempos a tempos uma ideia estúpida também e, é claro,
o papel exige também a capacidade de reconhecer quando se toma uma má
decisão; embora isto seja um simples traço que qualquer
bom programador deva ter, em especial se se mantiver no projecto a longo
prazo.A grande diferença é que o BD pode de vez em quando cometer asneiras
sem se preocupar com a perca de credibilidade. Programadores menos seniores
podem não se sentir tão seguros e portanto o BD deve usar fraseologia
cuidadosa nas critícas ou decisões contrárias sopesando as palavras
tanto tecnicamente como psicologicamente.
O BD não necessita de ter as capacidades
técnicas afiadas de qualquer pessoa no projecto. Deve ter as capacidades
suficientes para trabalhar no código, mas é tudo. A posição de BD
não é adquirida em virtude das capacidades de codificação intimidatórias.
O que é importante é experiência e sentido de concepção
geral, não necessariamente capacidade de produzir boa concepção a pedido,
mas a capacidade de reconhecer uma boa concepção independentemente da
sua origem.
É comum o ditador benevolente ser o fundador do projecto, mas isto
é mais uma correlação do que uma cusa. Todos o tipos de qualidades que
tornam uma pessoa capaz de ser bem sucedida no início de um projecto, —
competência técnica, capacidade de persuadir outras pessoas a juntarem-se, etc — são exactamente as capacidades que qualquer BD necessitaria. E claro
os fundadores começam logo com uma espécie de senioridade automática,
que pode ser suficiente para tornar a ditadura parecer o caminha da menor
resistência para todos aqueles a que diga respeito.
Lembrar que o potencial de bifurcação dá para os dois lados. Um BD
pode bifurcar um projecto como qualquer outra pessoa e alguns fizeram-no
ocasionalmente, quando acharam que a direcção que queriam tomar para
o projecto era diferente da da maioria dos outros programadores. Devido
à bifurcabilidade não importa se o ditador benevolente é root (tem
privilégios de administração) nos servidores principais do projecto ou
não. As pessoas falam por vezes do controlo do servidor como se fosse a
última fonte de poder num projecto quando tal é irrelevante. A capacidade
de adicionar ou remover as palavras de passe das pessoas num determinado
servidor afecta só a cópia do projecto aí residente. Um abuso prolongado
do poder, pelo BD ou por outra pessoa, simplesmente levaria a que o
desenvolvimento passasse para outro servidor.
Se o seu projecto deve ter um ditador benevolente ou se seria melhor
gerido com um sistema menos centralizado depende largamente em quem está
disponível para preencher os papeis. Como regra geral se é simplesmente
óbvio quem deva ser o BD então esse é o caminho a seguir. Mas se não houver
um candidato imediatamente óbvio, então o projecto deve ter um processo
de tomada de decisão descentralizados, como o descrito na próxima secção.
Democracia com Base em Consenso
Há medida que os projectos vão envelhecendo, tendem a deixar o
modelo da ditadura benevolente e a partirem para sistemas mais abertamente
democráticos. Isto não necessariamente a partir de aborrecimento com um
determinado BD. Só que a governação baseada no grupo é "evolucionariamente
estável", para pedir emprestada uma metáfora de biologia. Sempre que um BD
se demite, ou tenta espalhar a tomada de decisão de modo mais equilibrado
é a oportunidade para o grupo estabelecer um novo sistema não ditatorial —estabelecer uma constituição como deve ser. O grupo pode não tomar esta
oportunidade a primeira ou a segunda vez mas vai acabar por o fazer;
quando o fizer, a probabilidade desta decisão ser invertida é pouco
provável. O senso comum explica porquê: Se um grupo de N pessoas tem que
investir alguém com um poder especial tal significa que N - 1 pessoas
têm que concordar com a redução da sua influência pessoal. As pessoas
normalmente não o desejam fazer. Mesmo o o fizerem a ditadura resultante seria
ainda assim condicionada: se o grupo de aborrece-se com o BD o grupo poderia
distituir o BD. Assim uma vez tendo mudado a liderança de um indivíduo
carismático para um sistema mais formal baseado no grupo raramente se volta
atrás.
Os detalhes de como estes sistemas funcionam variam muito, mas têm dois
elementos em comum: primeiro, o grupo funciona por consenso a maior parte do
tempo; segundo há um mecanismo de votação formal ao qual recorrer se o
consenso não puder ser alcançado.
Consenso significa acordo com que todos
estam dispostos a viver. Não é um estado ambíguo: um grupo alcançou consenso
numa dada questão quando alguém propõe que se alcançou consenso e que
ninguém contradiga essa afirmação. A pessoa que propõe o consenso deve
especificar a que consenso se refere e que acções devem ser levadas a
cabo como consequência desse consenso, se tal não for óbvio.
A maior parte das conversas num projecto são sobre tópicos
técnicos, tal como a forma correcta de corrigir certo erro, se se deve
ou não acrescentar cerca característica, qual o grau de exactidão para
a documentação de interfaces, etc. O governo baseado em consenso funciona
bem porque se funde suavemente com a discussão técnica propriamente
dira. No fim de uma discussão há frequentemente acordo geral no caminho
a seguir. Alguém trata de fazer um fecho, o qual simultaneamente
resume o que foi decidido e a proposta implícita do consenso. Isto permite
que alguém diga "Espera lá eu não acordei isso. Temos que conversar
mais."
Para decisões pequenas e sem controvérsia, a proposta de consenso
é implícita. Por exemplo se um programador espontaneamente submete uma
correcção de um erro a própria submissão é uma proposta de consenso:
"Parto do princípio que todos concordam que este erro necessita ser
corrigido e esta é a correcção." Claro que o programador não diz isto;
ele só trata de submeter a correcção e os outros no projecto não se
preocupam em indicar o seu acordo, visto o silêncio ser o próprio
consentimento. Se alguém submeter uma alteração que se venha a verificar
não ter consenso, o resultado é simples o projecto
tem que discutir a alteração como se ela não tivesse sido já submetida. A
razão pela qual isto funciona é tópico para a secção seguinte.
O Controlo de Versão Significa que Pode Relaxar
O facto do código fonte do projecto estar sob controlo de versões
significa que a maior parte das decisões pode ser facilmente desfeita. A
maneira mais comum disto acontecer é se alguém submeter uma alteração
por engano pensando que toda a gente concorda com ela, para vir a enfrentar
objeções após tal facto. É típico dessas objecções começarem por um
pedido de desculpas por se ter estado ausente de discussão, embora
se possa omitir isto se não se encontrar nada sobre o assunto nos
arquivos da lista de correio. De qualquer modo não há razão para o tom
da discussão ser diferente após a alteração ter sido submetida do que antes.
Qualquer alteração pode ser invertida, pelo menos até terem sido inseridas
alterações dependentes (isto é, novo código que falhe se a alteração
original for retirada de repente). O sistema de controlo de versões
dá ao projecto uma maneira de desfazer os efeitos de um julgamento mau ou
rápido. Isto, por seu lado, liberta as pessoas para confiarem nos seus
instintos sobre quanta retroalimentação é necessária antes de fazerem
algo.
Isto também significa que o processo de estabelecer consenso não
necessita de ser muito formal. A maior parte dos projectos gerem isto
por instinto. Pequenas alterações podem ocorrer sem discussão ou com
discussão mínima seguida de alguns assentimentos de acordo. Para
alterações mais significativas, em especial aquelas com potencial
para desestabilizar muito código as pessoas devem esperar um dia ou dois
antes de presumirem que há consenso, sendo a linha de pensamento que
ninguém deve ser marginalizado numa conversação importante simplesmente
porque não verificou o seu email com a frequência necessária.
Assim, quando alguém está confiante e sabe o que necessita ser
feito, deve fazê-lo. Isto aplica-se não só a correcções de software, mas
a actualizações de sítios web, alterações na documentação, e qualquer
outra coisa que dificilmente seja controversa. Normalmente só haverá alguns
exemplos onde uma acção tem que ser desfeita, e essas podem ser tratadas
caso-a-caso. Claro que não se deve encorajar as pessoas a serem cabeças
duras. Há ainda uma diferença psicológica entre uma decisão sob discussão
e uma que já teve efeito mesmo que seja tecnicamente reversível. As pessoas
podem achar que esse momento é aliado da acção e podem estar ligeiramente
mais relutantes para reverterem uma alteração do que a evitar em primeiro
lugar. Se um programador abusar deste facto submetendo alterações
potencialmente controversas de modo demasiado rápido, as pessoas podem e
devem queixar-se, e adoptar para esse programador um padrão mais estrito
até que as coisas melhorem.
Quando não se Consegue Alcançar Consenso, Vote
Inevitavelmente irá haver debates onde é impossível chegar a
um consenso. Quanto todos os outros meios de evitar bloqueios falham
a solução é votar. Mas antes da votação ter lugar, deve ficar claro o
conjunto de escolhas em discussão. Aqui, também, o processo normal
de discussão técnica funde-se com felicidade com os procedimentos de
tomada de decisão do projecto. O tipo de perguntas que chegam a votos
envolvem elas próprias frequentemente aspectos multifacetados complexos.
Em qualquer discussão complexa normalmente uma ou duas pessoas fazem o
papel de intermediário honesto: colocando resumos
periódicos dos vários argumentos e mantendo focados os pontos centrais
do desacordo (ou acordo). Estes resumos ajudam todos a ver que progresso
foi sendo feito e lembra-os de que aspectos que é necessário continuar
a tratar. Esses mesmos resumos podem servir como protótipos para os
da página de voto no caso de ser necessário votar. Se os intermediários
honestos fizerem bem o seu papel, irão ter o crédito para pedir uma
votação quando se chegar a esse tempo e o grupo estará disposto a usar
a folha de votação com base no resumo dos problemas. Os próprios
intermediários podem participar no debate; não é necessário que fiquem
neutros desde que compreendam e representem de forma justa o ponto de
vista oposto e não deixem que os seus sentimentos partidários façam com
que evitem resumir o estado do debate de um modo neutral.
O conteúdo da votação propriamente dito não é normalmente controverso
quando se chega à votação o desacordo normalmente está resumido a uns quantos
pontos chaves, com etiquetas reconhecidas e descrições breves. Ocasionalmente
um programador irá objectar em relação à própria votação. Por vezes este
facto é legítimo, por exemplo uma escolha importante foi deixada de fora ou
está mal descrita. Mas noutras alturas o programadores poderá estar só a
tentar adiar o inevitável, eventualmente sabendo que a votação provavelmente
não irá correr-lhe de feição.
Conferir
em sobre como tratar deste tipo
de obstrução.
Lembrar de especificar o sistema de votação, pois há vários tipos
diferentes e as pessoas podem fazer presunções erradas sobre o procedimento
a ser usado. Uma boa escolha na maior parte dos casos é
votação pela positiva, onde cada votante pode votar
em tantas escolhas da votação quantas as que quizer. A votação pela positiva
A votação pela positiva é fácil de explicar e de contar ao contrário de
vários outros métodos só envolve uma volta de votação. Ver para
mais detalhes sobre votação pela positiva e outros sistemas de votação,
mas tente evitar entrar num longo debate sobre qye sistema de votação
usar (porque, claro, iria encontrar-se num debate sobre que sistema
de votação usar para decidir o sistema de votação!). Uma razão pela qual
a votação pela positiva é uma boa escolha é que é muito difícil para
alguém objectar, é um sistema tão justo quanto possível como sistema
de votação.
Finalmente, conduza a votação em público. Não há necessidade
para segredo ou anonimato de votação em assuntos que tenham sido
debatidos publicamente. Deixe que cada participante coloque os seus
votos na lista de correio do projecto, de modo a que cada observador
possa escrutinar e verificar os resultados por si e assim fica tudo
registado nos arquivos.
Quando Votar
A coisa mais difícil sobre a votação é determinar quando a fazer.
Em geral votar deve ser algo muito raro: —um último recurso par
quando todas as outras opção tenham falado. Não pense na votação como
um grande meio de resolução de debates. Não é. Acaba discussão e assim
também termina o pensamento criativo sobre o problema. Desde que a
discussão continue há a possibilidade de que alguém descubra uma nova
solução de que todos gostem. Isto sucede com frequência: um debate vivo
pode produzir uma nova maneira de pensar sobre o problema e conduz
para uma proposta que eventualmente satisfaça toda a gente. Mesmo quando
não aparecem novas proposta é mesmo assim normalmente preferível ao
intermediário chegar a um compromisso do que ir para votação. Após um
compromisso, todos estarão um pouco descontentes, enquanto que após uma
votação algumas pessoas estarão muito descontentes enquanto outras
estarão alegres. De um ponto de vista político a situação anterior é
preferível: pelo menos cada pessoa pode sentir ter extraído algo
do seu descontentamento. Pode estar insatisfeito mas isso sucede com cada
um deles.
A principal vantagem da votação é resolver determinada questão
e permitir que todos continuem. Mas resolve a questão por contagem
de espingardas, em vez de ser por diálogo racional que conduz toda
a gente à mesma conclusão. Quanto mais pessoas tiverem experiência
com projectos de código aberto, menos dispostas as encontro para tomarem
decisões por votação. Em vez disso tentaram explorar soluções
que não tenham sido levadas em conta anteriormente ou chegar a um
compromisso que não planearam originalmente. Estão disponíveis várias
técnicas para evitar uma votação prematura. A mais óbvia é simplesmente
dizer "julgo que não estamos preparados para votar por agora", e explicar
porque não. Outra é pedir que se faça um inquérito informal (que não
seja vinculativo). Se a resposta tender claramente para um lado ou para outro
isto poderá levar algumas pessoas a chegar a um compromisso, evitando
uma votação formal. Mas a forma mais eficaz de o fazer é simplesmente
dar uma nova solução, ou um novo ponto de vista sobre uma sugestão antiga
de modo a que as pessoas voltem a engajar-se nos problemas em vez de
meramente repetirem os mesmo argumentos.
Em certos casos raros, todos podem concordar que as soluções
de compromisso são piores do que qualquer das solução sem compromisso.
Se tal suceder votar é menos mau, tanto porque provavelmente conduzirá
a uma solução superior e porque as pessoas não irão ficar muito aborrecidas
independentemente da solução que se alcançar. Mesmo neste caso não se deve
acelerar a votação. A discussão que conduz ao vota é o que educa o
eleitorado, assim parar a discussão cedo pode baixar a qualidade do
resultado.
(Nota que o conselho ruletante para ir a votos não inclui a votação
de alteração/inclusão descrita em
em . Aí, a votação é mais
um mecanismo de comunicação, um meio de registar o envolvimento de
cada um num processo de revisão de alteração de modo a que todos possam
dizer quanta revisão uma dada alteração recebeu.)
Quem Vota?
Ter um sistema de votação levanta a questão do eleitorado: quem
vota? Isto tem o potencial de ser um tema sensível, porque força o
projecto a reconhecer oficialmente que algumas pessoas estão mais envolvidas
ou têm um melhor juízo que outras.
A melhor solução é simplesmente usar uma distinção pré-existente, como
por exemplo quem tem acesso de submissão, e anexar os privilégios de votação
a essa condição. Em projectos que oferecem tanto acesso de submissão
parcial ou total a questão é se os submetedores parciais podem votar depende
largamente do processo pelo qual o acesso de submissão parcial lhes foi
atribuído. Se o projecto o dá, de forma liberal, por exemplo, como uma forma
de manter várias ferramentas contribuídas por terceiros no repositório,
então deve ser tornado claro que o acesso de submissão parcial é só isso
não lhe dá acesso às votações. A implicação inversa naturalmente também
se mantém: visto os submetedores totais irão ter privilégios
de votação, devem ser escolhidos não só como programadores, mas como membro
do eleitorado. Se alguém mostrar tendências disruptivas ou obstrucionistas
na lista de distribuição de correio, o grupo deve ser muito cuidadosa sobre
torná-lo um submetedor, mesmo que seja uma pessoa com capacidade técnica.
O sistema de votação propriamente dito deve ser usado para escolher
novos submetedores, tanto totais como parciais. Mas aqui está um dos exemplos
onde o segredo é apropriado. Não pode haver votos sobre potenciais
submetedores, colocados numa lista de distribuição de correio pública, porque
os sentimentos e reputação do candidato podem sofrer. Em seu lugar é
normal que um dos submetedores, proponha alguém aos outros submetedores
numa lista de distribuição de correio privada, propondo que alguém receba
acesso de submissão. Os restantes submetedores dizem de sua justiça, sabendo
que a discussão é privada. Frequentemente não haverá discussão e assim
sendo não haverá necessidade de votar. Após esperar alguns dias de forma
a assegurar que todos os submetedores tenham possibilidade de responder
o proponente envia uma mensagem ao candidato e oferece-lhe o acesso de
submissão. Se houver desacordo a discussão prossegue como para qualquer outra
questão, possivelmente resultando numa votação. Para este processo ser aberto
e franco o mero facto da discussão estar a ter lugar de todo deve ser
segredo. Se a pessoa, sob consideração, souber o que está a ocorrer e
nunca lhe vier a ser atribuído o acesso de submissão pode concluir que
perdeu a votação e pode ficar sentido. Claro que, se alguém pede explicitamente
acesso de submissão, então, só há como explicitamente aceitar ou rejeitar. Neste
caso deve ser feito tão delicadamente quanto possível, com uma explicação
clara "gostamos das sua correcções mais ainda não vimos suficiente número",
ou "gostamos das suas correcções todas mas tiveram que ser alteradas antes de
serem aplicadas e assim não nos sentimos confortáveis para lhe dar acesso
de submissão para já. Contudo, esperamos que tal mude no futuro." Lembrar
que aquilo que se disser pode ser um golpe, dependendo do nível de confiança
da pessoa. Tente ver do ponto de vista dela quando escrever a mensagem.
Visto a adição de um novo submetedor trás mais consequências do que
as decisões que ocorrem uma vez, alguns projectos têm requisitos especiais
para esta votação. Por exemplo, podem exigir que a proposta receba pelo
menos n votos favoráveis e nenhum desfavorável ou que
haja uma maioria qualificada a favor. Os parâmetros exactos não são
importantes a ideia principal é fazer com que o grupo seja cuidadoso
sobre a adição de novos submetedores. Deve haver requisitos especiais
similares ou ainda mais restritivos para a votação da
expulsão de um submetedor, embora possa nunca
vir a ser necessário. Ver em
para mais aspectos
que não os sobre votação na admissão e expulsão de submetedores.
Sondagem Versus Votação
Para certos tipos de votos pode ser útil expandir o eleitorado.
Se os programadores não conseguirem perceber se uma dada escolha
no interface corresponde à forma como as pessoas usam o software
uma solução é pedir a todos os subscritores da lista de distribuição
de correio que votem. Esta votação de facto é uma
sondagem e não uma votação, mas os programadores
podem tratar o resultado como vinculativo. Como qualquer sondagem
assegure-se que fica claro para os participantes que há uma opção de
para sugerir: se alguém pensar que uma opção melhor não aparece nas
perguntas da sondagem, a sua resposta pode tornar-se no resultado
mais importante da sondagem.
Vetos
Alguns projectos permitem um tipo especial de vota designado por
veto. Um veto é a forma de um programador colocar
um ponto final numa alteração danosa e mal pensada pelo menos para que
a possam discutir mais. Pense num veto como algo entre uma fortíssima
objecção e uma obstrução. O seu significado exacto varia de projecto
para projecto. Alguns projectos tornam difícil ultrapassar um veto;
Outros permitem que um veto seja ultrapassado por uma maioria de votos,
eventualmente após um atraso obrigatório para mais discussão. Qualquer
veto deve ser acompanhado de uma explicação detalhada; um veto sem uma
explicação deve ser consideração não admissível.
Com os vetos vem o problema do abuso dos vetos. Por vezes os
programadores estão demasiado despostos a levantar problemas vetando,
quando o que era desejável era mais discussão. Pode evitar abuso de
veto, usando-o de modo muito ruletante você mesmo e gentilmente
pedir para o retirar se alguém o usar com demasiada frequência. Se
necessário lembrar ao grupo que os vetos só serão respeitados
enquanto o grupo concordar que o sejam — se uma maioria clara de
programadores deseja X então X irá suceder de uma maneira ou outra. Ou
o programador retira o seu veto ou o grupo pode decidir baixar o
significado do veto.
Pode ver pessoas a escreverem "-1" para exprimir um veto. Este
uso vem da Apache Software Foundation, que tem um processo de
votação e de veto muito estruturado, descrito em . As normas
Apache espalharam-se para outros projectos, e irá ver as suas convenções
usadas em vários graus em muitos locais no mundo do «open source».
Tecnicamente um "-1" nem sempre indica um veto formal de acordo com
as normas Apache mas informalmente normalmente toma o significado
de um veto ou de uma objecção muito forte.
Tal como os votos os vetos pode ser aplicados retroactivamente.
Não é correcto objectar a um veto com o argumento que a alteração em
questão já foi submetida, ou já foi tomada uma acção (a menos que seja
irrevogável, como enviar um comunicado à imprensa). Por outro lado
um veto que demora semanas ou meses atrasado não é provável que seja
levado a sério nem o deve ser.
Colocar Tudo por Escrito
Nalgum ponto o número de convenções e acordos a voar no vosso
projecto pode tornar-se de tal modo elevado que necessitará
registá-los em algum lugar. De modo a dar alguma legitimidade a um tal documento,
deixe claro que se baseia nas discussões da lista de distribuição de
correio e acordos já efectivos. Há medida que o vai escrevendo refira-se
aos ramos relevantes dos arquivos da lista de distribuição de correio,
e sempre que haja um ponto sobre o qual não tenha a certeza absoluta
pergunte novamente. O documento não deve conter qualquer surpresa: não
é origem de acordos é uma mera descrição de acordos. Claro que se for
bem sucedido as pessoas começam a citá-lo como origem com autoridade,
mas isso só significa que reflecte o entendimento geral do grupo de forma
correcta.
É este o documento a que se alude em em
. Naturalmente quando
o projecto é muito novo, terá que estabelecer directrizes sem
a vantagem que a história longa de um projecto traz. Mas à medida
que a comunidade que o desenvolve amadurece, pode ajustar a
linguagem para reflectir a forma que as coisas realmente tomaram.
Não tente ser exaustivo. Nenhum documento pode capturar tudo o que
as pessoas necessitam saber sobre como participar num projecto.
Muitas das convenções de um projecto que progride ficam para sempre
não ditas, nem nunca são mencionadas de modo explícito e, no entanto,
todos aderem às mesmas. Outras coisas são simplesmente demasiado
óbvias para serem mencionadas, e distrairiam de material importante
mas não óbvio. Por exemplo não há razão para escrever directrizes
equivalentes a "Seja educado e respeite os outra na lista de distribuição
de correio e não inicie uma guerra inflamada", ou "Escreva código claro,
legível e sem erros". Claro que isto é desejável mas visto não haver
um universos onde elas possam não ser desejáveis,
não vale a pena mencionar. Se as pessoas estão a ser agrestes na
lista de distribuição de correio, ou a escrever código com erros
nada as irá fazer parar devido só a que as directrizes do projecto
o digam. Tais situações necessitam de ser tratadas quando são
levantadas, mas não com admoestações para ser bonzinho.
Por outro lado se o projecto tiver directrizes sobre
como escrever bom código, tais como regras para
documentar as API num certo formato, então essas directrizes devem ser
escritas de modo tão completo quanto possível.
Um boa maneira de determinar o que incluir é basear o documento
nas perguntas efectuadas mais frequentemente pelos novatos e nas queixas
que os programadores mais experientes fazem. Isto não significa
necessariamente que se deve tornar numa FAQ —provavelmente necessita
de uma estrutura narrativa mais coerente do que a dada pelas FAQ. Mas deve
seguir o mesmo princípio de estar baseada na realidade de tratar os temas
que de facto são levantados em vez daqueles que antecipe que venham a ser
levantados.
Se o projecto é uma ditadura benevolente, ou tem funcionários
com poderes especiais (presidente, ...), então o documento é uma
boa oportunidade para codificar os procedimentos de sucessão.
Isto por vezes pode ser tão simples quanto nomear pessoas específicas
como substitutos no caso de uma saída repentina do projecto do BD
por qualquer razão. Geralmente, se há um BD, só o BD pode nomear um
sucessor. Se os funcionários forem eleitos então o processo de
nomeação e eleição que foi usado para os escolher em primeiro lugar
deve ser descrito no documento. Se não houver originalmente um
procedimento então trate de obter consenso sobre um procedimento na
lista de distribuição de correio antes de escrever
sobre isso. As pessoas podem por vezes ser sensíveis sobre as estruturas
hierárquicas, e assim sendo o tema necessita de ser tratado com
sensibilidade.
Talvez seja mais importante tornar claro que as regras podem ser
reapreciadas. Se as convenções descritas no documento começarem a
atrazar o projecto, lembre que é suposto ser uma reflexão viva das
intenções do grupo e não uma fonte de frustração e bloqueio. Se alguém
fizer hábito de inapropriadamente pedir que as regras sejam reconsideradas
de cada vez que as regras lhes apareçam ao caminho não necessita de
debater isso com elas —por vezes o silêncio é a melhor táctica. Se
houver mais gente a concordar com as reclamações, elas trataram de avançar,
e será óbvio que algo necessita de ser mudado. Se ninguém mais concordar
então a pessoa não terá muitos seguidores e as regras irão manter-se tal
como estão..
Dois bons exemplos de directrizes de projectos são o ficheiro do
Subversion hacking.html em , e os
documentos sobre governo da Apache Software Foundation em e . A ASF de facto
é uma coleção de projectos de software, legalmente organizados como
uma corporação sem fins lucrativos, e assim os seus documentos
tendem a descrever mais procedimentos de governo que convenções
de desenvolvimento. Mesmo assim é bom ler, pois representam a
experiência acumulada de muitos projectos de «open source».