Author: cafonso Date: Sat Aug 25 06:04:51 2007 New Revision: 1095 Log: Chap 04 typos, rev 1
Modified: trunk/pt-pt/ch04.xml Modified: trunk/pt-pt/ch04.xml ============================================================================== --- trunk/pt-pt/ch04.xml (original) +++ trunk/pt-pt/ch04.xml Sat Aug 25 06:04:51 2007 @@ -5,8 +5,8 @@ <simplesect> <para>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 insatizfeito com respostas prontas sobre meritocracia, o +"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 @@ -16,7 +16,7 @@ <para>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 sustendada de um projecto incorporar novas +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 @@ -62,15 +62,15 @@ 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 -subditos possam copiar o seu reino completo a qualquer momento e possam +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?</para> <para>É 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 ramificabilidade; -a ramificabilidade implica o concenso. É perfeitamente possível que se +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 <emphasis>escolheram</emphasis>, de uma maneira não cínica e não sinistra. @@ -82,14 +82,14 @@ que isto normalmente não chega tão longe porque o ditador faz um compromisso antes.</para> -<para>Mas só porque a ramificabilidade coloca um limite máximo no poder que +<para>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 -adoptadam sem guerra. Estes dois exemplos são de algum modo extremos ideais; +adoptaram sem guerra. Estes dois exemplos são de algum modo extremos ideais; vários projectos caiem no continuo entre ambos.</para> </sect1> @@ -116,13 +116,13 @@ 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 ditactores benevolentes normalmente não ditam muito. Em vez disso +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 <emphasis>quer</emphasis> -alguém que guie a decisão de modo a poder prosseguir." A roletância em +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.</para> @@ -136,8 +136,8 @@ <para>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 primeiro estadios de uma -discussão, não deve exprimir opiniões e consulsões para evitar que os +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, @@ -172,7 +172,7 @@ 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 -previlégios de administração) nos servidores principais do projecto ou +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 @@ -202,7 +202,7 @@ 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 ditaturial —estabelecer uma constituição como deve ser. O grupo pode não tomar esta +é 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 @@ -210,7 +210,7 @@ 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 individuo +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.</para> @@ -220,7 +220,7 @@ consenso não puder ser alcançado.</para> <para><firstterm>Consenso</firstterm> significa acordo com que todos -estam dispostos a viver. Não é um estado ambiguo: um grupo alcançou consenso +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 @@ -233,16 +233,16 @@ 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 implicita do consenso. Isto permite +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> -<para>Para decisões pequenas e sem controversia, a proposta de consenso +<para>Para decisões pequenas e sem controvérsia, a proposta de consenso é implícita. Por exemplo se um programador espontaneamente submete uma -correção de um erro a própria submissão é uma proposta de consenso: +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 correção." Claro que o programador não diz isto; -ele só trata de submeter a correção e os outros no projecto não se +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 <emphasis>não</emphasis> ter consenso, o resultado é simples o projecto @@ -256,20 +256,20 @@ 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. É tipico dessas objeções começarem por um +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 form retirada de repente). O sistema de controlo de versões +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.</para> -<para>Isto também significa que o processo de estabeler consenso não +<para>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 @@ -280,7 +280,7 @@ porque não verificou o seu email com a frequência necessária.</para> <para>Assim, quando alguém está confiante e sabe o que necessita ser -feito, deve fazê-lo. Isto aplica-se não só a correções de software, mas +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 @@ -343,17 +343,17 @@ url="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 debase sobre que sistema +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.</para> <para>Finalmente, conduza a votação em público. Não há necessidade -para segredo ou anonimia de votação em assuntos que tenham sido +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 resultos por si e assim fica tudo +possa escrutinar e verificar os resultados por si e assim fica tudo registado nos arquivos.</para> </sect2> @@ -362,21 +362,21 @@ <title>Quando Votar</title> <para>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 +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 satizfaça toda a gente. Mesmo quando -não aparecem novas proposta é mesmo assim normalmente preferírel ao +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 estaram um pouco descontentes, enquanto que após uma -votação algumas pessoas estaram muito descontentes enquanto outras -estão alegres. De um ponto de vista político a situação anterior é +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 insatizfeito mas isso sucede com cada +do seu descontentamento. Pode estar insatisfeito mas isso sucede com cada um deles.</para> <para>A principal vantagem da votação é resolver determinada questão @@ -390,7 +390,7 @@ 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 binding). Se a resposta tender claramente para um lado ou para outro +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 @@ -406,8 +406,8 @@ eleitorado, assim parar a discussão cedo pode baixar a qualidade do resultado.</para> -<para>(Nota que o conselho roletante para ir a votos não inclui a votação -de alteração-inclusão descrita em +<para>(Nota que o conselho ruletante para ir a votos não inclui a votação +de alteração/inclusão descrita em <xref linkend="stabilizing-a-release"/><phrase output="printed"> em <xref linkend="development-cycle"/></phrase>. Aí, a votação é mais um mecanismo de comunicação, um meio de registar o envolvimento de @@ -421,21 +421,21 @@ <para>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 oficiamente que algumas pessoas estão mais envolvidas -ou têm um melhor juizo que outras.</para> +projecto a reconhecer oficialmente que algumas pessoas estão mais envolvidas +ou têm um melhor juízo que outras.</para> <para>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 +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 <emphasis>irão</emphasis> 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 obstruccionistas +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.</para> @@ -445,7 +445,7 @@ 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, proponto que alguém receba +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 @@ -457,10 +457,10 @@ 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 regeitar. Neste +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 correções mais ainda não vimos suficiente número", -ou "gostamos das suas correções todas mas tiveram que ser alteradas antes de +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 @@ -491,7 +491,7 @@ uma solução é pedir a todos os subscritores da lista de distribuição de correio que votem. Esta votação de facto é uma <firstterm>sondagem</firstterm> e não uma votação, mas os programadores -podem tratar o resultado como XXbinding. Como qualquer sondagem +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 @@ -509,14 +509,14 @@ 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 atrazo obrigatório para mais discussão. Qualquer +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.</para> <para>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 roletanto você mesmo e gentilmente +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 @@ -529,9 +529,9 @@ votação e de veto muito estruturado, descrito em <ulink url="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. +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 informalmnente normalmente toma o significado +as normas Apache mas informalmente normalmente toma o significado de um veto ou de uma objecção muito forte.</para> <para>Tal como os votos os vetos pode ser aplicados retroactivamente. @@ -559,7 +559,7 @@ 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 reflete o entendimento geral do grupo de forma +mas isso só significa que reflecte o entendimento geral do grupo de forma correcta.</para> <para>É este o documento a que se alude em <xref @@ -568,7 +568,7 @@ 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 refletir a forma que as coisas realmente tomaram.</para> +linguagem para reflectir a forma que as coisas realmente tomaram.</para> <para>Não tente ser exaustivo. Nenhum documento pode capturar tudo o que as pessoas necessitam saber sobre como participar num projecto. @@ -577,8 +577,8 @@ 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 respete os outra na lista de distribuição -de correio e não inicie uma guerra inflamada", ou "Escreva código limpor, +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 <emphasis>não</emphasis> ser desejáveis, não vale a pena mencionar. Se as pessoas estão a ser agrestes na @@ -603,7 +603,7 @@ <para>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 especificas +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 @@ -631,13 +631,13 @@ Subversion <filename>hacking.html</filename> em <ulink url="http://svn.collab.net/repos/svn/trunk/www/hacking.html"/>, e os documentos sobre governo da Apache Software Foundation em <ulink -url="http://www.apache.org/foundation/how-it-works.html"/> and <ulink +url="http://www.apache.org/foundation/how-it-works.html"/> e <ulink url="http://www.apache.org/foundation/voting.html"/>. 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.</para> +experiência acumulada de muitos projectos de «open source».</para> </sect1> _______________________________________________ Producingoss-translators mailing list [email protected] http://www.red-bean.com/mailman/listinfo/producingoss-translators
