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. 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. 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. 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. 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 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. 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. 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.) 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. 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. 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. 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».