Author: cafonso Date: Thu Aug 23 06:46:52 2007 New Revision: 1075 Log: chap 04 pronto até aos vetos - done till vito
Modified: trunk/pt-pt/ch04.xml Modified: trunk/pt-pt/ch04.xml ============================================================================== --- trunk/pt-pt/ch04.xml (original) +++ trunk/pt-pt/ch04.xml Thu Aug 23 06:46:52 2007 @@ -379,128 +379,128 @@ do seu descontentamento. Pode estar insatizfeito mas isso sucede com cada um deles.</para> -<para>Voting's main advantage is that it finally settles a question so -everyone can move on. But it settles it by a head count, instead of -by rational dialogue leading everyone to the same conclusion. The -more experienced people are with open source projects, the less eager -I find them to be to settle questions by vote. Instead they will try -to explore previously unconsidered solutions, or compromise more -severely than they'd originally planned. Various techniques are -available to prevent a premature vote. The most obvious is simply to -say "I don't think we're ready for a vote yet," and explain why not. -Another is to ask for an informal (non-binding) show of hands. If the -response clearly tends toward one side or another, this will make some -people suddenly more willing to compromise, obviating the need for a -formal vote. But the most effective way is simply to offer a new -solution, or a new viewpoint on an old suggestion, so that people -re-engage with the issues instead of merely repeating the same -arguments.</para> - -<para>In certain rare cases, everyone may agree that all the -compromise solutions are worse than any of the non-compromise ones. -When that happens, voting is less objectionable, both because it is -more likely to lead to a superior solution and because people will not -be overly unhappy no matter how it turns out. Even then, the vote -should not be rushed. The discussion leading up to a vote is what -educates the electorate, so stopping that discussion early can lower -the quality of the result.</para> +<para>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 binding). 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.</para> + +<para>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.</para> -<para>(Note that this advice to be reluctant to call votes does not -apply to the change-inclusion voting described in +<para>(Nota que o conselho roletante 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"> -in <xref linkend="development-cycle"/></phrase>. There, voting -is more of a communications mechanism, a means of registering one's -involvement in the change review process so that everyone can tell how -much review a given change has received.)</para> +em <xref linkend="development-cycle"/></phrase>. 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.)</para> </sect2> <sect2 id="electorate"> -<title>Who Votes?</title> +<title>Quem Vota?</title> -<para>Having a voting system raises the question of electorate: who -gets to vote? This has the potential to be a sensitive issue, because -it forces the project to officially recognize some people as being -more involved, or as having better judgement, than others.</para> - -<para>The best solution is to simply take an existing distinction, -commit access, and attach voting privileges to it. In projects that -offer both full and partial commit access, the question of whether -partial committers can vote largely depends on the process by which -partial commit access is granted. If the project hands it out -liberally, for example as a way of maintaining many third-party -contributed tools in the repository, then it should be made clear that -partial commit access is really just about committing, not voting. -The reverse implication naturally holds as well: since full committers -<emphasis>will</emphasis> have voting privileges, they must be chosen -not only as programmers, but as members of the electorate. If someone -shows disruptive or obstructionist tendencies on the mailing list, the -group should be very cautious about making him a committer, even if -the person is technically skilled.</para> - -<para>The voting system itself should be used to choose new -committers, both full and partial. But here is one of the rare -instances where secrecy is appropriate. You can't have votes about -potential committers posted to a public mailing list, because the -candidate's feelings (and reputation) could be hurt. Instead, the -usual way is that an existing committer posts to a private mailing -list consisting only of the other committers, proposing that someone -be granted commit access. The other committers speak their minds -freely, knowing the discussion is private. Often there will be no -disagreement, and therefore no vote necessary. After waiting a few -days to make sure every committer has had a chance to respond, the -proposer mails the candidate and offers him commit access. If there -is disagreement, discussion ensues as for any other question, possibly -resulting in a vote. For this process to be open and frank, the mere -fact that the discussion is taking place at all should be secret. If -the person under consideration knew it was going on, and then were -never offered commit access, he could conclude that he had lost -the vote, and would likely feel hurt. Of course, if someone -explicitly asks for commit access, then there is no choice but to -consider the proposal and explicitly accept or reject him. If the -latter, then it should be done as politely as possible, with a clear -explanation: "We liked your patches, but haven't seen enough of them -yet," or "We appreciate all your patches, but they required -considerable adjustments before they could be applied, so we don't -feel comfortable giving you commit access yet. We hope that this will -change over time, though." Remember, what you're saying could come as -a blow, depending on the person's level of confidence. Try to see it -from their point of view as you write the mail.</para> - -<para>Because adding a new committer is more consequential than most -other one-time decisions, some projects have special requirements for -the vote. For example, they may require that the proposal receive at -least <emphasis>n</emphasis> positive votes and no negative votes, or -that a supermajority vote in favor. The exact parameters are not -important; the main idea is to get the group to be careful about -adding new committers. Similar, or even stricter, special requirements -can apply to votes to <emphasis>remove</emphasis> a committer, though -hopefully that will never be necessary. See <xref -linkend="committers"/><phrase output="printed"> in -<xref linkend="managing-volunteers"/></phrase> for more on the -non-voting aspects of adding and removing committers.</para> +<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> + +<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 +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 +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> + +<para>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, proponto 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 regeitar. 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 +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.</para> + +<para>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 <emphasis>n</emphasis> 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 +<emphasis>expulsão</emphasis> de um submetedor, embora possa nunca +vir a ser necessário. Ver <xref +linkend="committers"/><phrase output="printed"> em +<xref linkend="managing-volunteers"/></phrase> para mais aspectos +que não os sobre votação na admissão e expulsão de submetedores.</para> </sect2> <sect2 id="polls"> -<title>Polls Versus Votes</title> +<title>Sondagem Versus Votação</title> -<para>For certain kinds of votes, it may be useful to expand the -electorate. For example, if the developers simply can't figure out -whether a given interface choice matches the way people actually use -the software, one solution is to ask to all the subscribers of the -project's mailing lists to vote. These are really -<firstterm>polls</firstterm> rather than votes, but the developers may -choose to treat the result as binding. As with any poll, be sure to -make it clear to the participants that there's a write-in option: if -someone thinks of a better option not offered in the poll questions, -her response may turn out to be the most important result of the -poll.</para> +<para>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 +<firstterm>sondagem</firstterm> e não uma votação, mas os programadores +podem tratar o resultado como XXbinding. 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.</para> </sect2> <sect2 id="veto"> -<title>Vetoes</title> +<title>Vetos</title> <para>Some projects allow a special kind of vote known as a <firstterm>veto</firstterm>. A veto is a way for a developer to put a _______________________________________________ Producingoss-translators mailing list [email protected] http://www.red-bean.com/mailman/listinfo/producingoss-translators
