Author: cafonso Date: Sun Aug 19 16:54:31 2007 New Revision: 1033 Log: Chap 04 til line 300 more or less
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 16:54:31 2007 @@ -214,85 +214,85 @@ carismático para um sistema mais formal baseado no grupo raramente se volta atrás.</para> -<para>The details of how these systems work vary widely, but there are -two common elements: one, the group works by consensus most of the -time; two, there is a formal voting mechanism to fall back on when -consensus cannot be reached.</para> - -<para><firstterm>Consensus</firstterm> merely means an agreement that -everyone is willing to live with. It is not an ambiguous state: a -group has reached consensus on a given question when someone proposes -that consensus has been reached, and no one contradicts the assertion. -The person proposing consensus should, of course, state specifically -what the consensus is, and what actions would be taken in consequence -of it, if they're not obvious.</para> - -<para>Most conversation in a project is on technical topics, such as -the right way to fix a certain bug, whether or not to add a feature, -how strictly to document interfaces, etc. Consensus-based governance -works well because it blends seamlessly with the technical discussion -itself. By the end of a discussion, there is often general agreement -on what course to take. Someone will usually make a concluding post, -which is simultaneously a summary of what has been decided and an -implicit proposal of consensus. This provides a last chance for -someone else to say "Wait, I didn't agree to that. We need to hash -this out some more."</para> - -<para>For small, uncontroversial decisions, the proposal of consensus -is implicit. For example, when a developer spontaneously commits a -bugfix, the commit itself is a proposal of consensus: "I assume we all -agree that this bug needs to be fixed, and that this is the way to fix -it." Of course, the developer does not actually say that; she just -commits the fix, and the others in the project do not bother to state -their agreement, because silence is consent. If someone commits a -change that turns out <emphasis>not</emphasis> to have consensus, the -result is simply for the project to discuss the change as though it -had not already been committed. The reason this works is the topic of -the next section.</para> +<para>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.</para> + +<para><firstterm>Consenso</firstterm> significa acordo com que todos +estam dispostos a viver. Não é um estado ambiguo: 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.</para> + +<para>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 implicita 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 +é implícita. Por exemplo se um programador espontaneamente submete uma +correçã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 +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 +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.</para> <sect2 id="version-control-relaxation"> -<title>Version Control Means You Can Relax</title> +<title>O Controlo de Versão Significa que Pode Relaxar</title> -<para>The fact that the project's source code is kept under version -control means that most decisions can be easily unmade. The most -common way this happens is that someone commits a change mistakenly -thinking everyone would be happy with it, only to be met with -objections after the fact. It is typical for such objections to start -out with an obligatory apology for having missed out on prior -discussion, though this may be omitted if the objector finds no record -of such a discussion in the mailing list archives. Either way, there -is no reason for the tone of the discussion to be different after the -change has been committed than before. Any change can be reverted, at -least until dependent changes are introduced (i.e., new code that -would break if the original change were suddenly removed). The -version control system gives the project a way to undo the effects of -bad or hasty judgement. This, in turn, frees people to trust their -instincts about how much feedback is necessary before doing -something.</para> - -<para>This also means that the process of establishing consensus need -not be very formal. Most projects handle it by feel. Minor changes -can go in with no discussion, or with minimal discussion followed by a -few nods of agreement. For more significant changes, especially ones -with the potential to destabilize a lot of code, people should wait a -day or two before assuming there is consensus, the rationale being -that no one should be marginalized in an important conversation simply -because he didn't check email frequently enough.</para> - -<para>Thus, when someone is confident he knows what needs to be done, -he should just go ahead and do it. This applies not only to software -fixes, but to web site updates, documentation changes, and anything -else unlikely to be controversial. Usually there will be only a few -instances where an action needs to be undone, and these can be handled on -a case-by-case basis. Of course, one shouldn't encourage people to be -headstrong. There is still a psychological difference between a -decision under discussion and one that has already taken effect, even -if it is technically reversible. People always feel that momentum is -allied to action, and will be slightly more reluctant to revert a -change than to prevent it in the first place. If a developer abuses -this fact by committing potentially controversial changes too quickly, -however, people can and should complain, and hold that developer to a -stricter standard until things improve.</para> +<para>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. É tipico dessas objeçõ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 +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 +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.</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 +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.</para> </sect2> _______________________________________________ Producingoss-translators mailing list [email protected] http://www.red-bean.com/mailman/listinfo/producingoss-translators
