Author: raffmarti Date: Thu Aug 9 14:12:02 2007 New Revision: 924 Log: some more of chapter 4 translated
Modified: trunk/es/ch04.xml Modified: trunk/es/ch04.xml ============================================================================== --- trunk/es/ch04.xml (original) +++ trunk/es/ch04.xml Thu Aug 9 14:12:02 2007 @@ -19,7 +19,7 @@ <para>Por esta raz�n a�n aquellos proyectos que no est�n organizados formalmente como democracias, son en la pr�ctica democracias en el momento en que se toman las decisiones importantes. La replicabilidad incluye a la "forkability"; "forkability" incluye al consenso. Podr�a bien darse el caso de que todos quieran apoyarse en un lider (el ejemplo m�s famoso es el de Linus Torvalds durante el desarrollo del kernel de Linux), pero esto es porque ellos <emphasis>as� lo eligen</emphasis>, de una manera ajena a todo cinicismo y en una forma no siniestra. El dictador no tiene un dominio m�gico sobre el proyecto. Una propiedad de todas las licencias de fuente abierta es que no se le da a una parte m�s poder que a cualquier otra para decidir c�mo se debe usar o cambiar el c�digo. Si el dictador de repente comenzara a tomar malas decisiones, se producir�a una agitaci�n, seguida eventualmente por un levantamiento y por un "fork". Exepto que, por supuesto, muy rara vez las cosas llegan tan lejos, porque antes el dictador busca soluciones de compromiso.</para> -<para>But just because forkability puts an upper limit on how much power anyone can exert in a project doesn't mean there aren't important differences in how projects are governed. You don't want every decision to come down to the last-resort question of who is considering a fork. That would get tiresome very quickly, and sap energy away from real work. The next two sections examine different ways to organize projects such that most decisions go smoothly. These two examples are somewhat idealized extremes; many projects fall somewhere along a continuum between them.</para> +<para>Pero, s�lo porque la forkability pone un l�mite al abuso de poder que uno puede ejercer en un proyecto, eso no quiere decir que no hayan diferencias importantes en el modo como se gobiernan los proyectos. Nadie desea que en todas las decisiones se llegue a la pregunta de �ltima instancia de quien est� considerando un fork. Eso pasar�a r�pidamente a ser muy cansador, restando energ�a necesaria para el trabajo efectivo. Las dos secciones que siguen examinan los modos de organizar los proyectos para que la mayor�a de las decisiones se tomen naturalmente. Estos dos ejemplos son los casos extremos idealizados; muchos proyectos quedan de alguna manera inclu�dos entre esos casos.</para> </sect1> @@ -27,41 +27,41 @@ <!-- ======================== SECTION ============================== --> <sect1 id="benevolent-dictator"> -<title>Benevolent Dictators</title> +<title>Dictadores Benevolentes</title> -<para>The <firstterm>benevolent dictator</firstterm> model is exactly what it sounds like: final decision-making authority rests with one person, who, by virtue of personality and experience, is expected to use it wisely.</para> +<para>El modelo de un <firstterm>dictador benevolente</firstterm> es precisamente lo que se describe as�: La autoridad final de la toma de decisiones reside en una persona, de quien se espera que, por la fuerza de su personalidad o experiencia, la use sabiamente.</para> -<para>Although "benevolent dictator" (or <firstterm>BD</firstterm>)is the standard term for this role, it would be better to think of it as "community-approved arbitrator" or "judge". Generally, benevolent dictators do not actually make all the decisions, or even most of the decisions. It's unlikely that one person could have enough expertise to make consistently good decisions across all areas of the project, and anyway, quality developers won't stay around unless they have some influence on the project's direction. Therefore, benevolent dictators commonly do not dictate much. Instead, they let things work themselves out through discussion and experimentation whenever possible. They participate in those discussions themselves, but as regular developers, often deferring to an area maintainer who has more expertise. Only when it is clear that no consensus can be reached, and that most of the group <emphasis>wants</emphasis> someone to guide the decision so that development can move on, do they put their foot down and say "This is the way it's going to be." Reluctance to make decisions by fiat is a trait shared by virtually all successful benevolent dictators; it is one of the reasons they manage to keep the role.</para> +<para>Auque el t�rmino est�ndar de esta funci�n es "dictador ben�volo" (o <firstterm>DB</firstterm>), ser�a mejor que lo imaginemos como un "�rbitro aprobado por la comunidad" o un "juez". En general, los dictadores benevolentes no toman realmente las decisiones, ni siquiera la mayor�a de las decisiones. No es probable que una persona pueda tener todo el conocimiento para tomar decisiones buenas y coherentes en todas las �reas de un proyecto, y adem�s, los desarrolladors de calidad no se acercar�n a no ser que tengan alguna influencia en la direcci�n del proyecto. Por lo que los dictadores benevolentes no tienen mucho para mandonear. Por el contrario, dejan que las cosas funcionen por s� solas por el intercambio de ideas y la experimentaci�n, siempre que eso sea posible. Ellos mismos participan en esas discusiones, como un desarrollador cualquiera, a menudo delegando a un administrador de area que tenga mas conocimiento. Solamente cuando queda claro que no se puede alcanzar un consenso, y cuando la mayor�a del grupo <emphasis>desea</emphasis> que alguien gu�e la decisi�n para que el desarrollo pueda seguir adelante, pisan firme y dicen: "Esta es la forma que tiene que ser". Una caracter�stica compartida por casi todos los dictadores benevolentes exitosos es que tienen un rechazo a tomar decisiones con un "as� tiene que ser"; esta es una de las razones por la permanecen en la funci�n.</para> <sect2 id="benevolent-dictator-qualifications"> -<title>Who Can Be a Good Benevolent Dictator?</title> +<title>�Qui�n puede ser un Buen Dictador Benevolente?</title> -<para>Being a BD requires a combination of traits. It needs, first of all, a well-honed sensitivity to one's own influence in the project, which in turn brings self-restraint. In the early stages of a discussion, one should not express opinions and conclusions with so much certainty that others feel like it's pointless to dissent. People must be free to air ideas, even stupid ideas. It is inevitable that the BD will post a stupid idea from time to time too, of course, and therefore the role also requires an ability to recognize and acknowledge when one has made a bad decision—though this is simply a trait that <emphasis>any</emphasis> good developer should have, especially if she stays with the project a long time. But the difference is that the BD can afford to slip from time to time without worrying about long-term damage to her credibility. Developers with less seniority may not feel so secure, so the BD should phrase critiques or contrary decisions with some sensitivity for how much weight her words carry, both technically and psychologically.</para> +<para>Ser un DB requiere una combinaci�n de caracter�sticas. Se necesita, antes que nada, una cierta delicadeza para juzgar su propia influencia en el proyecto, lo que a su vez lleva a sujetar los primeros impulsos. En los primeros pasos de una discusi�n uno no debe expresar opiniones y conclusiones con tanta seguridad que los otros sientan que es in�til opinar en contra. La gente debe sentirse libre de ventilar sus ideas, aunque sean tontas. Es inevitable que el DB sugiera alguna idea tonta de vez en cuando, y por lo tanto esta funci�n requiere la disponibilidad de reconocer cuando uno haya tomado una mala decisi�n— si bien es �sta una caracter�stica sencilla que <emphasis>cualquier</emphasis> buen desarrollador debe tener, especialmente si permanece en el proyecto por mucho tiempo. Pero la diferencia es que el DB puede darse el lujo de equivocarse de vez en cuando sin tener que lamentar da�os permanentes en su credibilidad. Los desarrolladores m�s j�venes pueden no tener tanta seguridad, y por eso los DB deben expresar sus cr�ticas o decisiones en contra con mucha delicadeza para contrapesar la fuerza psicol�gica y t�cnica que tienen sus palabras.</para> -<para>The BD does <emphasis>not</emphasis> need to have the sharpest technical skills of anyone in the project. She must be skilled enough to work on the code herself, and to understand and comment on any change under consideration, but that's all. The BD position is neither acquired nor held by virtue of intimidating coding skills. What <emphasis>is</emphasis> important is experience and overall design sense—not necessarily the ability to produce good design on demand, but the ability to recognize good design, whatever its source.</para> +<para>El DB <emphasis>no</emphasis> necesita tener una habilidad t�cnica superior que supere a todos los que est�n en el proyecto. Tiene que saber lo suficiente como para trabajar en el c�digo, y entender y comentar cualquier cambio en consideraci�n, y eso es todo. La posici�n del DB no se adquiere ni mantiene en virtud a una habilidad de codificar intimidatoria. Lo que <emphasis>si</emphasis> es importante es la experiencia y un sentido general del dise�o —no necesariamente la habilidad de producir un buen dise�o a pedido, pero si la habilidad de reconocer el buen dise�o, provenga de donde proveniere.</para> -<para>It is common for the benevolent dictator to be a founder of the project, but this is more a correlation than a cause. The sorts of qualities that make one able to successfully start a project—technical competence, ability to persuade other people to join, etc.—are exactly the qualities any BD would need. And of course, founders start out with a sort of automatic seniority, which can often be enough to make benevolent dictatorship appear the path of least resistance for all concerned.</para> +<para>Es com�n que un dictador benevolente sea el fundador del proyecto, pero esto es m�s una correlaci�n que una causa. El tipo de cualidades que permite poner en marcha con �xito un proyecto son ex�ctamente las cualidades que cualquier DB debe tener— competencia t�cnica, habilidad de persuadir para que otro se una, etc.—. Y por supuesto, los fundadores se inician con una cierta senioridad autom�tica, que puede ser suficiente a menudo para que el dictador benevolente aparezca por el camino de menor resistencia para todos aquellos a quienes les incumbe.</para> -<para>Remember that the potential to fork goes both ways. A BD can fork a project just as easily as anyone else, and some have occasionally done so, when they felt that the direction they wanted to take the project was different from where the majority of other developers wanted to go. Because of forkability, it does not matter whether the benevolent dictator has root (system administrator privileges) on the project's main servers or not. People sometimes talk of server control as though it were the ultimate source of power in a project, but in fact it is irrelevant. The ability to add or remove people's commit passwords on one particular server affects only the copy of the project that resides on that server. Prolonged abuse of that power, whether by the BD or someone else, would simply lead to development moving to a different server.</para> +<para>Recordar que la amenaza de un fork vale para los dos sentidos. Un DB puede hacer un fork de un proyecto tan facilmente como cualquier otro, y ocasionalmente lo han hecho, cuando sienten que la direcci�n que est� tomando el proyecto es diferente de donde la mayor�a de los desarrolladores quieren ir. Por causa de la forkabilidad, poco importa si el dictador benevolente tiene privilegios de root (que corresponden al administrador del sistema) en el servidor principal del proyecto. A veces la gente se refiere al control del servidor como si fuera la mayor fuente de poder en un proyecto, pero de hecho es irrelevante. La posibilidad de agregar o quitar las palabras clave para hacer commit en un servidor afecta solo a la copia del proyecto que reside en el servidor. Un abuso constante de ese poder, sea por el DB o por cualquier otro, va a terminar simplemente con un cambio del desarrollo en un servidor diferente.</para> </sect2> -<para>Whether your project should have a benevolent dictator, or would run better with some less centralized system, largely depends on who is available to fill the role. As a general rule, if it's simply obvious to everyone who should be the BD, then that's the way to go. But if no candidate for BD is immediately obvious, then the project should probably use a decentralized decision-making process, as described in the next section.</para> +<para>Si el proyecto tendr� un dictador benevolente o si va a funcionar mejor con un sistema menos centralizado, depende ampliamente de qui�n es el que va a cumplir con esa funci�n. Por lo general es algo muy obvio desde el comienzo saber qui�n va a ser el DB, y entonces todo se encamina en ese sentido. Pero si no hay un candidoto obvio para el DB, puede ser que el proyecto se incline a usar un proceso descentralizado de tomas de decisi�n, como se va a describir en la pr�sima secci�n.</para> </sect1> <!-- ======================== SECTION ============================== --> <sect1 id="consensus-democracy"> -<title>Consensus-based Democracy</title> +<title>Democracia basada en el Consenso</title> -<para>As projects get older, they tend to move away from the benevolent dictatorship model and toward more openly democratic systems. This is not necessarily out of dissatisfaction with a particular BD. It's simply that group-based governance is more "evolutionarily stable", to borrow a biological metaphor. Whenever a benevolent dictator steps down, or attempts to spread decision-making responsibility more evenly, it is an opportunity for the group to settle on a new, non-dictatorial system—establish a constitution, as it were. The group may not take this opportunity the first time, or the second, but eventually they will; once they do, the decision is unlikely ever to be reversed. Common sense explains why: if a group of N people were to vest one person with special power, it would mean that N - 1 people were each agreeing to decrease their individual influence. People usually don't want to do that. Even if they did, the resulting dictatorship would still be conditional: the group anointed the BD, clearly the group could depose the BD. Therefore, once a project has moved from leadership by a charismatic individual to a more formal, group-based system, it rarely moves back.</para> +<para>A medida que el proyecto avanza, se tiende a pasar del modelo del dictador benevolente a los sistemas m�s abiertaente democr�ticos. Este paso no se produce necesariamente por la insatisfacci�n causada por un DB. Es que el gobierno basado en el grupo llega a ser estable en su evoluci�n, para usar as� una met�fora biol�gica. Siempre que un dictador benevolente se baja o intenta difundir la responsablidad de tomar decisiones entre todos por igual, se da la oportunidad para que el grupo se asiente en un nuevo sistema no-dictatorial—estableciendo una constituci�n, por as� decirlo. Puede ser que el grupo no aprovecha la primera oportunidad, ni quiz�s tampoco la segunda, pero en alg�n momento lo har�; y una vez hecho, es muy dif�cil que esta decisi�n se vuelva atr�s. Y el sentido comun lo explica: si un grupo de N individuos tuviera que investir una persona con poderes especiales, eso significar�a que N - 1 personas tuvieron que aceptar que sus influencias individuales se disminuyan. Normalmente la gente no quiere hacer cosas como esa. Y si las hiciera, todav�a la dictadura que de all� resulte ser�a condicional: el grupo que unge a un DB, es claramente el grupo que puede deponer al DB. Por lo tanto, una vez que el proyecto a pasado de un liderazgo carism�tico individual a un sistema m�s formal basado en el grupo, muy rara vez vuelve para 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>Los detalles de c�mo funcionan esos sistemas var�an ampliamente, pero hay en ellos dos elementos comunes: uno, el grupo funciona por consencio la mayor�a del tiempo; dos, hay un mecanismo formal de votaciones para los casos en que el consenso no puede alcanzarse.</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><firstterm>Consenso</firstterm> significa solamente un acuerdo que todos aceptan de una vez por todas. No es un estado ambiguo: un grupo alcanza el consenso en un asunto particular cuando alguien expresa que se ha alcanzado un consenso y nadie contradice esa afirmaci�n. La persona que propone el consenso debe, por cierto, dejar en claro cual es el consenso alcanzado, y que acciones deben tomarse en consecuencia de �l, si es que �sto no resulta obvio.</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>La mayor�a de las conversaciones de un proyecto son sobre los asuntos t�cnicos, como el modo correcto de corregir alg�n error, la conveniencia o no de agregar un asunto, la forma estricta como un documento se enlaza, etc. Un gobierno basado en el consenso funciona bien porque se entrelaza con la discusi�n t�cnica y se confunde con ella silenciosamente. Al terminar una discusi�n, generalmente hay acuerdo sobre cual es el camino a seguir. Alguien hace una intervenci�n conclusiva, que es al mismo tiempo un resumen de lo que se ha ido decidiendo y queda como una propuesta impl�dica de consenso. 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>
_______________________________________________ Producingoss-translators mailing list [email protected] http://www.red-bean.com/mailman/listinfo/producingoss-translators
