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 “Difficult People” em Capítulo 6, Communications 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 http://en.wikipedia.org/wiki/Voting_system#List_of_systems 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 “Stabilizing a Release” em Capítulo 7, Packaging, Releasing, and Daily Development. 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 “Committers” em Capítulo 8, Managing Volunteers 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 http://www.apache.org/foundation/voting.html. 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.