Author: cafonso
Date: Tue Aug 28 07:22:59 2007
New Revision: 1120
Log:
Chap 05 - 320 lines
Modified:
trunk/pt-pt/ch05.xml
Modified: trunk/pt-pt/ch05.xml
==============================================================================
--- trunk/pt-pt/ch05.xml (original)
+++ trunk/pt-pt/ch05.xml Tue Aug 28 07:22:59 2007
@@ -209,112 +209,116 @@
<varlistentry><term>Doações</term>
<listitem>
- <para>A widely-used project can sometimes get significant
- contributions, from both individuals and organizations,
- just by having an online donation button, or sometimes by
- selling branded merchandise such as coffee mugs, T-shirts,
- mousepads, etc. A word of caution: if your project accepts
- donations, plan out how the money will be used
- <emphasis>before</emphasis> it comes in, and state the
- plans on the project's web site. Discussions about how to
- allocate money tend to go a lot more smoothly when held
- before there's actual money to spend; and anyway, if there
- are significant disagreements, it's better to find that out
- while it's still academic.</para>
+ <para>Um projecto que seja usado de modo alargado pode por vezes
+ obter contribuições significativas, quer de indivíduos quer
+ de organizações, tendo só um botão para doações em linha, ou
+ vendendo merchandise com a marca tal como chávenas de café,
+ camisolas, tapetes para rato, etc. Uma palavra de cuidado:
+ se o seu projecto aceitar doações, faça o planeamento da
+ utilização do dinheiro <emphasis>antes</emphasis> de ele
entrar
+ e apresente o orçamento no sítio web do projecto. As
discussões
+ sobre como atribuir dinheiro tendem a ser mais fáceis quando
+ tidas antes de haver dinheiro para gastar; de qualquer modo,
+ se houver desentendimentos significativos, é melhor saber
+ enquanto tais desentendimentos sejam académicos.</para>
</listitem>
</varlistentry>
</variablelist>
-<para>A funder's business model is not the only factor in how it
-relates to an open source community. The historical relationship
-between the two also matters: did the company start the project, or is
-it joining an existing development effort? In both cases, the funder
-will have to earn credibility, but, not surprisingly, there's a bit
-more earning to be done in the latter case. The organization needs to
-have clear goals with respect to the project. Is the company trying
-to keep a position of leadership, or simply trying to be one voice in
-the community, to guide but not necessarily govern the project's
-direction? Or does it just want to have a couple of committers
-around, able to fix customers' bugs and get the changes into the
-public distribution without any fuss?</para>
-
-<para>Keep these questions in mind as you read the guidelines that
-follow. They are meant to apply to any sort of organizational
-involvement in a free software project, but every project is a human
-environment, and therefore no two are exactly alike. To some degree,
-you will always have to play by ear, but following these principles
-will increase the likelihood of things turning out the way you
-want.</para>
+<para>Um modelo de negócios do financiador não é o único factor de
+como ele se relaciona com a comunidade open source. A relação
+histórica entre os dois também tem importância: a empresa começou
+o projecto ou juntou-se já com esforço de desenvolvimento existente.
+Em ambos os casos o financiador terá que ganhar credibilidade, mas,
+sem ser surpreendente há algo mais a fazer no último caso para a
+ganhar. A organização necessita ter objectivos claros em relação
+ao projecto. Se a empresa estiver a tentar manter a liderança, ou
+simplesmente a tentar ser uma voz na comunidade, para guiar mas não
+necessariamente para governar a direcção do projecto? Ou deseja
+só tem um par de submetedores por aí, de modo a serem capazes de
+corrigir erros de clientes e obter alterações na distribuição
+pública sem complicações?</para>
+
+<para>Lembre-se destas questões à medida que for lendo as directrizes
+que se seguem. Estas destinam-se a ser aplicadas em qualquer envolvimento
+num projecto de software livre, mas cada projecto é um ambiente humano
+e assim não haverá dois exactamente iguais. Até certo ponto,
+terá sempre que tocar de ouvido, mas seguindo estes princípios
+aumentará a probabilidade de as coisas decorrerem como deseja.</para>
</sect1>
<!-- ======================== subsection ============================== -->
<sect1 id="long-term-developers">
-<title>Hire for the Long Term</title>
+<title>Empregue a Longo Prazo</title>
-<para>If you're managing programmers on an open source project, keep
-them there long enough that they acquire both technical and political
-expertise—a couple of years, at a minimum. Of course, no
-project, whether open or closed-source, benefits from swapping
-programmers in and out too often. The need for a newcomer to learn
-the ropes each time would be a deterrent in any environment. But the
-penalty is even stronger in open source projects, because outgoing
-developers take with them not only their knowledge of the code, but
-also their status in the community and the human relationships they
-have made there.</para>
-
-<para>The credibility a developer has accumulated cannot be
-transferred. To pick the most obvious example, an incoming developer
-can't inherit commit access from an outgoing one (see
-<xref linkend="money-vs-love"/> later in this chapter), so if the
-new developer doesn't already have commit access, he will have to
-submit patches until he does. But commit access is only the most
-measurable manifestation of lost influence. A long-time developer
-also knows all the old arguments that have been hashed and rehashed on
-the discussion lists. A new developer, having no memory of those
-conversations, may try to raise the topics again, leading to a loss of
-credibility for your organization; the others might wonder "Can't
-they remember anything?" A new developer will also have no political
-feel for the project's personalities, and will not be able to
-influence development directions as quickly or as smoothly as one
-who's been around a long time.</para>
-
-<para>Train newcomers through a program of supervised engagement. The
-new developer should be in direct contact with the public development
-community from the very first day, starting off with bug fixes and
-cleanup tasks, so he can learn the code base and acquire a reputation
-in the community, yet not spark any long and involved design
-discussions. All the while, one or more experienced developers should
-be available for questioning, and should be reading every post the
-newcomer makes to the development lists, even if they're in threads
-that the experienced developers normally wouldn't pay attention to.
-This will help the group spot potential rocks before the newcomer runs
-aground. Private, behind-the-scenes encouragement and pointers can
-also help a lot, especially if the newcomer is not accustomed to
-massively parallel peer review of his code.</para>
-
-<para>When CollabNet hires a new developer to work on Subversion, we
-sit down together and pick some open bugs for the new person to cut
-his teeth on. We'll discuss the technical outlines of the solutions,
-and then assign at least one experienced developer to (publicly)
-review the patch that the new developer will (also publicly) post. We
-typically don't even look at the patch before the main development
-list sees it, although we could if there were some reason to. The
-important thing is that the new developer go through the process of
-public review, learning the code base while simultaneously becoming
-accustomed to receiving critiques from complete strangers. But we
-try to coordinate the timing so that our own review comes immediately
-after the posting of the patch. That way the first review the list
-sees is ours, which can help set the tone for the others' reviews. It
-also contributes to the idea that this new person is to be taken
-seriously: if others see that we're putting in the time to give
-detailed reviews, with thorough explanations and references into the
-archives where appropriate, they'll appreciate that a form of training
-is going on, and that it probably signifies a long-term investment.
-This can make them more positively disposed toward that developer, at
-least to the degree of spending a little extra time answering
-questions and reviewing patches.</para>
+<para>Se gere programadores num projecto de open source, mantenha-os
+tempo suficiente de modo a que adquiram as capacidades técnicas e
+políticas — pelo menos dois anos no mínimo. Claro que nenhum
+projecto, open source ou não, tira partido de frequente troca de
+programadores. A necessidade de um recém chegado aprender os detalhes
+de cada vez será um travão em qualquer ambiente. Mas a penalidade é
+ainda maior nos projectos open source, porque programadores que saiam
+levam com eles não só o seu conhecimento do código mas também o seu
+estatuto na comunidade e as relações humanas que aí tenham feito.</para>
+
+<para>A credibilidade que um programador tenha acumulado não é transferida.
+Para escolher o exemplo mais óbvio, um programador não pode herdar o
+acesso de submissão de alguém que tenha saído (ver
+<xref linkend="money-vs-love"/> adiante neste capítulo), assim se
+o novo programador não tiver já acesso de submissão, terá que
+submeter remendos até o ter. Mas o acesso de submissão é só a
+manifestação mais mensurável dessa perca de influência. Um programador
+de longo prazo também conhece todos os argumentos antigos que foram
+apresentados e reapresentados nas listas de discussão. Um programador
+novo, não tendo memória dessas conversações pode tentar levantar
+esses tópicos novamente, levando a uma perca de credibilidade da sua
+organização; os outros podem imaginar que "eles não se lembram de nada?"
+Um novo programador não terá sentido político das personalidades do
+projecto, e não será capaz de influenciar a direcção do desenvolvimento
+de modo tão rápido e suave do que um que já por aí ande à muito
+tempo.</para>
+
+<para>Treine novos programadores através de um programa de envolvimento
+supervisionado. O novo programador deve ter contacto directo público com
+a comunidade de desenvolvimento desde o primeiro dia, começando por
+correcções de erros e tarefas de limpeza, de modo a poder aprender os
+fundamentos do código e adquirir uma reputação na comunidade, mas não
+em algo grande e não sendo envolvido nas discussões de concepção. Durante
+algum tempo um ou mais programadores experientes devem estar disponíveis
+para interrogatório e devem ler cada entrada que o programador novato faça
+para as listas de desenvolvimento, mesmo que se tratem de ramificações
+as quais os programadores experientes normalmente não prestem atenção.
+Isto irá ajudar a que o grupo de aperceba de pedras potenciais antes que
+o programador novato se enterre. Orientação privada e encorajamento nos
+bastidores podem também ajudar muito, em especial se o novato não estiver
+acostumado a uma revisão do seu código feita em paralelo de modo massivo
+por pares.</para>
+
+<para>Quando a CollabNet emprega um novo programador para trabalhar
+no Subversion, sentamos-nos com ele e escolhemos uns quantos erros
+em aberto para que essa pessoa possa ter um cheirinho. Discutiremos
+os aspectos técnicos gerais das soluções e depois escolheremos pelo
+menos um programador experiente para (publicamente) rever o remendo
+que o novo programador irá (também publicamente) colocar. Normalmente
+não iremos sequer olhar para o remendo antes da lista principal de
+desenvolvimento o ver, embora o possamos fazer se houver alguma
+razão para isso. O importante é que o novo programador passe pelo
+processo de revisão pública, aprendendo as fundações do código e
+em simultâneo se habitue a receber críticas de completos estranhos.
+Mas tentamos coordenar os tempos de modo a que as nossas próprias
+críticas apareçam imediatamente após a colocação do remendo. Assim a
+primeira crítica que a lista vê é a nossa, o que pode ajudar a estabelecer
+o tom para as críticas dos restantes. Também contribui para a ideia
+de que esta nova pessoa é para ser levada a sério: se os outros virem
+que estamos a gastar tempo para fazermos uma crítica detalhada,
+com explicações profundas e referências ao arquivo quando apropriado,
+irão perceber que está a ser efectuada formação, e que tal será
+indicativo de investimento a longo prazo. Isso pode levar a que fiquem
+mais favoráveis em relação ao programador, pelo menos até ao ponto
+de gastarem um pouco mais de tempo em responder às questões e
+criticar remendos.</para>
</sect1>
_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators
