Author: cafonso Date: Wed Feb 6 04:10:48 2008 New Revision: 1403 Log: mais um parágrafo traduzido (excepto commit)
Modified: trunk/pt-pt/ch05.xml Modified: trunk/pt-pt/ch05.xml ============================================================================== --- trunk/pt-pt/ch05.xml (original) +++ trunk/pt-pt/ch05.xml Wed Feb 6 04:10:48 2008 @@ -648,39 +648,42 @@ trabalho executado pelo contratado seja aceite pela comunidade e englobado na distribuição pública. Teoricamente, não importa quem seja o contratado, desde que o seu trabalho seja bom e esteja em -conformidade com as diretrizes do projecto. Theory and practice can sometimes -match, too: a complete stranger who shows up with a good patch -<emphasis>will</emphasis> generally be able to get it into the -software. The trouble is, it's very hard to produce a good patch for -a non-trivial enhancement or new feature while truly being a complete -stranger; one must first discuss it with the rest of the project. The -duration of that discussion cannot be precisely predicted. If the -contractor is paid by the hour, you may end up paying more than you -expected; if he is paid a flat sum, he may end up doing more work -than he can afford.</para> - -<para>There are two ways around this. The preferred way is to make an -educated guess about the length of the discussion process, based on -past experience, add in some padding for error, and base the contract -on that. It also helps to divide the problem into as many small, -independent chunks as possible, to increase the predictability of each -chunk. The other way is to contract solely for delivery of a patch, -and treat the patch's acceptance into the public project as a separate -matter. Then it becomes much easier to write the contract, but you're -stuck with the burden of maintaining a private patch for as long as -you depend on the software, or at least for as long as it takes you to -get that patch or equivalent functionality into the mainline. Of -course, even with the preferred way, the contract itself cannot -require that the patch be accepted into the code, because that would -involve selling something that's not for sale. (What if the rest of -the project unexpectedly decides not to support the feature?) -However, the contract can require a <foreignphrase>bona -fide</foreignphrase> effort to get the change accepted by the -community, and that it be committed to the repository if the community -agrees with it. For example, if the project has written standards -regarding code changes, the contract can reference those standards and -specify that the work must meet them. In practice, this usually works -out the way everyone hopes.</para> +conformidade com as directrizes do projecto. A teoria e a prática +podem por vezes corresponder: um completo estranho que aparece com +um bom patch <emphasis>irá</emphasis> geralmente ser capaz de entrar +no software. O problema é que é muito difícil produzir um bom patch +para uma melhoria não trevial ou uma nova capacidade sendo um +completo estranho; em primeiro lugar é necessário discutir-la com +o resto do projecto. A duração da discussão não pode ser prevista +com precisão. Se o contratado trabalhar à hora, poderá acabar +por lhe pagar mais do que o esperado; se lhe pagar uma soma +pré-determinada ele poderá ficar prejudicado.</para> + +<para>Há duas maneiras de contornar isto. A maneira preferida é +efectuar uma estimativa sobre a duração do processo de discussão, +baseada em experiência passada, dar alguma folga para erro de +estimativa e finalmente basear o contrato no resultado. Ajuda +dividir o problema em tantas componentes independentes mais pequenas +quanto possível, de modo a aumentar a previsibilidade de cada porção. +A outra maneira é contratar com base na entrega de um patch, +e tratar da aceitação do path pelo projecto público como um +assunto separado. Assim torna-se mais fácil escrever o contrato, +mas ficará com o peso de manter um patch privado enquanto depender +do software ou pelo menos até que consiga que o patch ou +funcionalidade equivalente seja encorporada no corpo principal. +Claro que mesmo da forma preferida o contrato propriamente dito +não pode exigir que o patch tenha que ser aceite no código, +porque isso seria vender algo que não está à venda. (O que +sucederia se o projecto inesperadamente decidisse não +suportar a capacidade?) +Contudo o contrato pode exigir esforço <foreignphrase>bona +fide</foreignphrase> de modo a que a alteração seja aceite +pela comunidade, e que seja committed no repositório se a +comunidade concordar com isso. Por exemplo, se o projecto tiver +normas escritas para alterações do código, o contrato pode +referir-se a essas normas e especificar que o trabalho deve +ser feito em conformidade com as mesmas. Na prática, normalmente +isto funciona de acordo com o que as pessoas esperam.</para> <para>The best tactic for successful contracting is to hire one of the project's developers—preferably a committer—as the _______________________________________________ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
