Author: cafonso Date: Sun Aug 19 14:11:49 2007 New Revision: 1026 Log: Finished first section of chapter 04, plus some sanitize
Modified: trunk/pt-pt/ch04.xml Modified: trunk/pt-pt/ch04.xml ============================================================================== --- trunk/pt-pt/ch04.xml (original) +++ trunk/pt-pt/ch04.xml Sun Aug 19 14:11:49 2007 @@ -1,6 +1,6 @@ <chapter id="social-infrastructure"> -<title>Infraestrutura Social e Política</title> +<title>Infra-estrutura Social e Política</title> <simplesect> @@ -40,24 +40,24 @@ podres podem estragar toda a caixa, pelo menos durante algum tempo.</para> <sect1 id="forkability"> -<title>Ramificabilidade</title> +<title>Bifurcabilidade</title> <para>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 <firstterm>ramificabilidade</firstterm>: a +para o compromisso quando necessário é a <firstterm>bifurcabilidade</firstterm>: 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 <firstterm>ramo (fork)</firstterm>. -A coisa paradoxal é que é esta <emphasis>possibilidade </emphasis> de ramos é -normalmente uma força muito maior nos projectos de software livre que os -ramos reais, os quais são muito raros. Porque um ramo é mau para toda a gente +base começar um projecto concorrente, conhecido como <firstterm>bifurcação</firstterm>. +A coisa paradoxal é que é esta <emphasis>possibilidade </emphasis> 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 <xref linkend="forks"/><phrase output="printed"> em <xref linkend="managing-volunteers"/></phrase>), quanto mais séria uma ameaça de ramificação fica, mais as pessoas estão dispostas a efectuar um compromisso para a evitar.</para> -<para>Os ramos, ou o potencial para o seu surgimento melhor dizendo, é -a razãi pela qual nos projectos de software livre não há verdadeiros +<para>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 @@ -102,95 +102,92 @@ <sect1 id="benevolent-dictator"> <title>Ditador Benevolente</title> -<para>The <firstterm>benevolent dictator</firstterm> model is exactly -what it sounds like: final decision-making authority rests with one -person, who, by virtue of personality and experience, is expected -to use it wisely.</para> - -<para>Although "benevolent dictator" (or <firstterm>BD</firstterm>)is -the standard term for this role, it would be better to think of it as -"community-approved arbitrator" or "judge". Generally, benevolent -dictators do not actually make all the decisions, or even most of the -decisions. It's unlikely that one person could have enough expertise -to make consistently good decisions across all areas of the project, -and anyway, quality developers won't stay around unless they have some -influence on the project's direction. Therefore, benevolent dictators -commonly do not dictate much. Instead, they let things work -themselves out through discussion and experimentation whenever -possible. They participate in those discussions themselves, but as -regular developers, often deferring to an area maintainer who has more -expertise. Only when it is clear that no consensus can be reached, -and that most of the group <emphasis>wants</emphasis> someone to guide -the decision so that development can move on, do they put their foot -down and say "This is the way it's going to be." Reluctance to make -decisions by fiat is a trait shared by virtually all successful -benevolent dictators; it is one of the reasons they manage to keep the -role.</para> + +<para>O modelo <firstterm>ditador benevolente</firstterm> é 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.</para> + +<para>Embora "ditador benevolente" (ou abreviadamente +<firstterm>BD</firstterm>) 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 ditactores 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 +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> <!-- For link compatibility with a previous misspelling. --> <simplesect id="benevolent-dictator-qualifications"></simplesect> <sect2 id="benevolent-dictator-qualifications"> -<title>Who Can Be a Good Benevolent Dictator?</title> +<title>Quem Pode Ser um Bom Ditador Benevolente?</title> + +<title>Quem Pode Ser um Bom Ditador Benevolente?</title> -<para>Being a BD requires a combination of traits. It needs, first of -all, a well-honed sensitivity to one's own influence in the project, -which in turn brings self-restraint. In the early stages of a -discussion, one should not express opinions and conclusions with so -much certainty that others feel like it's pointless to dissent. -People must be free to air ideas, even stupid ideas. It is inevitable -that the BD will post a stupid idea from time to time too, of course, -and therefore the role also requires an ability to recognize and -acknowledge when one has made a bad decision—though this is -simply a trait that <emphasis>any</emphasis> good developer should -have, especially if she stays with the project a long time. But the -difference is that the BD can afford to slip from time to time without -worrying about long-term damage to her credibility. Developers with -less seniority may not feel so secure, so the BD should phrase -critiques or contrary decisions with some sensitivity for how much -weight her words carry, both technically and psychologically.</para> - -<para>The BD does <emphasis>not</emphasis> need to have the sharpest -technical skills of anyone in the project. She must be skilled enough -to work on the code herself, and to understand and comment on any -change under consideration, but that's all. The BD position is -neither acquired nor held by virtue of intimidating coding skills. -What <emphasis>is</emphasis> important is experience and overall -design sense—not necessarily the ability to produce good -design on demand, but the ability to recognize good design, whatever -its source.</para> - -<para>It is common for the benevolent dictator to be a founder of the -project, but this is more a correlation than a cause. The sorts of -qualities that make one able to successfully start a -project—technical competence, ability to persuade other people -to join, etc.—are exactly the qualities any BD would need. And -of course, founders start out with a sort of automatic seniority, -which can often be enough to make benevolent dictatorship appear the -path of least resistance for all concerned.</para> - -<para>Remember that the potential to fork goes both ways. A BD can -fork a project just as easily as anyone else, and some have -occasionally done so, when they felt that the direction they wanted to -take the project was different from where the majority of other -developers wanted to go. Because of forkability, it does not matter -whether the benevolent dictator has root (system administrator -privileges) on the project's main servers or not. People sometimes -talk of server control as though it were the ultimate source of power -in a project, but in fact it is irrelevant. The ability to add or -remove people's commit passwords on one particular server affects only -the copy of the project that resides on that server. Prolonged abuse -of that power, whether by the BD or someone else, would simply lead to -development moving to a different server.</para> +<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 +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 <emphasis>qualquer</emphasis> +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.</para> + +<para>O BD <emphasis>não</emphasis> 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 <emphasis>é</emphasis> 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.</para> + +<para>É 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.</para> + +<para>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 +previlé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.</para> </sect2> -<para>Whether your project should have a benevolent dictator, or would -run better with some less centralized system, largely depends on who -is available to fill the role. As a general rule, if it's simply -obvious to everyone who should be the BD, then that's the way to go. -But if no candidate for BD is immediately obvious, then the project -should probably use a decentralized decision-making process, as -described in the next section.</para> +<para>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.</para> </sect1> _______________________________________________ Producingoss-translators mailing list [email protected] http://www.red-bean.com/mailman/listinfo/producingoss-translators
