Discordo absolutamente da tradução de patch como 'remendo' - este é um dos vários casos em que a tradução não faz sentido, desvirtuando o significado original. Havendo tradução, seria mais correctamente uma 'diferença', já que o patch é um simples diff.
Ari Constâncio On 8/28/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > 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 > _______________________________________________ Producingoss-translators mailing list [email protected] http://www.red-bean.com/mailman/listinfo/producingoss-translators
