Author: raffmarti Date: Fri Aug 10 14:08:09 2007 New Revision: 943 Log: translated some more of chapter 4
Modified: trunk/es/ch04.xml Modified: trunk/es/ch04.xml ============================================================================== --- trunk/es/ch04.xml (original) +++ trunk/es/ch04.xml Fri Aug 10 14:08:09 2007 @@ -1,12 +1,12 @@ <chapter id="social-infrastructure"> -<title>Infraestructura Sociopol�tica</title> +<title>Infraestructura Social y Pol�tica</title> <simplesect> <para>Las primeras preguntas que la gente se hace sobre el software libre son "�C�mo funciona? �C�mo se mantiene el proyecto? �Qui�n toma las decisiones? Siempre quedo insatisfecho con respuestas conciliadoras sobre la estima del m�rito, el esp�ritu de cooperaci�n, el c�digo que se expresa por si mismo, etc. El caso es que sobre esto no hay una respuesta f�cil. La meritocracia, la cooperaci�n, y un c�digo que funciona son partes de ella, pero aportan muy poco para explicar como funciona realmente un proyecto en el andar de todos los d�as, y nada dice sobre c�mo se resuelven los conflictos.</para> -<para>Este cap�tulo trata de mostrar la estructura subyacente que los proyectos exitosos tienen en comun. Me refiero con el t�rmino "exitosos" no solamente a la calidad t�cnica, sino tambi�n a la salud operacional y la capacidad de sobrevivencia. La salud operacional es la capacidad efectiva del proyecto de incorporar las contribuciones de nuevos c�digos y nuevos desarrolladores, y de asumir la responsabilidad de los informes de errores que ingresan. Capacidad de sobrevivencia es la posibilidad de que el proyecto exista independientemente de alg�n participante o suspiciante en particular— t�melo como la posibilidad que tiene el proyecto para contiuar a�n cuando alguno de sus miembros fundadores tuviera que pasar a ocuparse de otras cosas. El �xito t�cnico no es dif�cil de alcanzar, pero sin una base robusta de desarrollo y un fundamento social, un proyecto puede resultar incapaz de manejar el crecimiento que el �xito inicial aporta, o la ausencia de alg�n individuo carism�tico.</para> +<para>Este cap�tulo trata de mostrar la estructura subyacente que los proyectos exitosos tienen en comun. Me refiero con el t�rmino "exitosos" no solamente a la calidad t�cnica, sino tambi�n a la salud operacional y la capacidad de sobrevivencia. La salud operacional es la capacidad efectiva del proyecto de incorporar las contribuciones de nuevos c�digos y nuevos desarrolladores, y de asumir la responsabilidad de los informes de errores que ingresan. Capacidad de sobrevivencia es la posibilidad de que el proyecto exista independientemente de alg�n participante o auspiciante en particular— t�melo como la posibilidad que tiene el proyecto para continuar a�n cuando alguno de sus miembros fundadores tuviera que pasar a ocuparse de otras cosas. El �xito t�cnico no es dif�cil de alcanzar, pero sin una base robusta de desarrollo y un fundamento social, un proyecto puede resultar incapaz de manejar el crecimiento que aporta el �xito inicial, o la ausencia de alg�n individuo carism�tico.</para> <para>Hay varias maneras de alcanzar este tipo de �xito. Algunas suponen una estructura formal de supervisi�n, por la que se resuelven los debates, se aceptan (o rechazan) nuevos desarrolladores, se planifican nuevas caracter�sticas, etc. Otras requieren menos estructura formal, pero m�s aplicaci�n en conciencia, para producir una atm�sfera de armon�a en la que la gente puede confiar como una forma<foreignphrase>de facto</foreignphrase> de supervisi�n. Ambos caminos llevan al mismo resultado: un sentido de permanencia institucional, ayudado por los h�bitos y procedimientos que son bien comprendidos por todos los que participan. Estas caracter�sticas son todav�a m�s importantes en los sistemas que se organizan a si mismos que en aquellos que est�n controlados centralmente, porque en los sistemas que se organizan a si mismos, cada uno es conciente que unas pocas manzanas pueden arruinar todo el caj�n, al menos por un tiempo.</para> @@ -15,7 +15,7 @@ <para>El ingrediente indispensable que une a los desarrolladores en un proyecto de software libre, y que los lleva a comprometerse cuando es necesario es la <firstterm>"forkabilidad"</firstterm> del c�digo: la capacidad de cada uno de tomar una copia del c�digo fuente y usarlo para abrir un proyecto que compita con el original, evento que se conoce como <firstterm>"fork"</firstterm>. Lo que aparece como parad�jico aqu� es que <emphasis>la posibilidad</emphasis> de los "forks" es una fueza mucho mayor en los proyectos de software libre que los "forks" reales, los que son muy raros. Puesto que un "fork" es malo para todos (por razones que se examinan en detalle en <xref linkend="forks"/><phrase output="printed"> en <xref linkend="managing-volunteers"/></phrase>), cuanto m�s seria sea la amenaza de un "fork", tanto mas son las personas que se comprometen a evitarlo.</para> -<para>Los "forks", o m�s bien la posibilidad de que se produzca un "fork", es la raz�n por la cual no hay verdaderos dictadores en los proyectos de software libre. Esto puede ser una expresi�n sorprendente, considerando que es muy com�n oir que alguien es llamado el "dictador" o el "tirano" en alg�n proyecto de fuente abierta. Pero esta tiran�a es especial, muy diferente de lo que comunmente se entiende por esa palabra. Imaginaos un rey cuyos s�bditos pudieran copiar todo su reino en cualquier momento y transladarse a la copia para governarla como creen que corresponde. �No ser�a el gobierno de ese rey muy diferente de otro cuyos s�bditos est�n obligados a permanecer bajo su gobierno, sin importar lo que �l haga?</para> +<para>Los "forks", o m�s bien la posibilidad de que se produzca un "fork", es la raz�n por la cual no hay verdaderos dictadores en los proyectos de software libre. Esto puede ser una expresi�n sorprendente, considerando que es muy com�n oir que alguien es llamado el "dictador" o el "tirano" en alg�n proyecto de fuente abierta. Pero esta tiran�a es especial, muy diferente de lo que comunmente se entiende por esa palabra. Imaginaos un rey cuyos s�bditos pudieran copiar todo su reino en cualquier momento y transladarse a la copia para gobernarla como creen que corresponde. �No ser�a el gobierno de ese rey muy diferente de otro cuyos s�bditos est�n obligados a permanecer bajo su gobierno, sin importar lo que �l haga?</para> <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> @@ -31,7 +31,7 @@ <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>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> +<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 desarrolladores de calidad no se acercar�n al proyecto a no ser que tengan alguna influencia en su direcci�n. 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>�Qui�n puede ser un Buen Dictador Benevolente?</title> @@ -61,59 +61,59 @@ <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>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>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�cita de consenso. Esto ofrece una �ltima oportunidad para que alguien diga "Un momento, no estoy de acuerdo. Debemos reconsiderar esto un poco m�s"</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> +<para>En decisiones de poca importancia que no ofrecen discusi�n, la propuesta de consenso es impl�cita. Por ejemplo, cuando un desarrollador hace un commit de una reparaci�n de error, el mismo commit es la propuesta de consenso: "Supongo que todos estamos de acuerdo en que este error debe ser corregido, y esta es la manera de hacerlo." Por supuesto, el desarrollador no lo dice; simplemente hace el commit de la reparaci�n, y los dem�s no se preocupan de manifestar su acuerdo, porque el silencio es el consentimiento. Si alguien hace el commit de un cambio que resulta <emphasis>no</emphasis> tener consenso, se produce simplemente una discusi�n sobre el cambio como si todav�a no estuviera incluido como cambio. La explicaci�n de por qu� esto funciona es el tema de la pr�xima secci�n.</para> <sect2 id="version-control-relaxation"> -<title>Version Control Means You Can Relax</title> +<title>Control de Versi�n Significa que Uno Puede Evitar el Estr�s</title> -<para>The fact that the project's source code is kept under version control means that most decisions can be easily unmade. The most common way this happens is that someone commits a change mistakenly thinking everyone would be happy with it, only to be met with objections after the fact. It is typical for such objections to start out with an obligatory apology for having missed out on prior discussion, though this may be omitted if the objector finds no record of such a discussion in the mailing list archives. Either way, there is no reason for the tone of the discussion to be different after the change has been committed than before. Any change can be reverted, at least until dependent changes are introduced (i.e., new code that would break if the original change were suddenly removed). The version control system gives the project a way to undo the effects of bad or hasty judgement. This, in turn, frees people to trust their instincts about how much feedback is necessary before doing something.</para> +<para>Mantener el c�digo fuente del proyecto bajo el control de versi�n significa que la mayor�a de las decisiones pueden f�cilmente deshacerse. La manera corriente para que esto pase es que alguien haga commit de un cambio pensando que todos van a aceptarlo con gusto, y despu�s encontrarse con las objeciones ante el hecho. Una forma t�pica de esas objeciones es comenzar con las disculpas del caso por no haber intervenido en discusiones anteriores, aunque esto se puede omitir si el discrepante no encuentra registros de tales discusiones en los archivos de la lista de correos. En cualquier caso, no hay motivos para que el tono de la discusi�n sea diferente despu�s del cambio introducido que antes. Cualquier cambio puede ser revertido, al menos antes de que se introduzcan cambios dependientes (es decir, nuevo c�digo que se da�a si el cambio original es quitado de repente). El sistema de control de versi�n permite que el proyecto deshaga los efectos de malas ideas o propuestas ligeras. Esto, a su vez, le da la libertad a la gente para que conf�e en sus instintos y aprenda cuanta consulta es necesaria antes de hacer algo.</para> -<para>This also means that the process of establishing consensus need not be very formal. Most projects handle it by feel. Minor changes can go in with no discussion, or with minimal discussion followed by a few nods of agreement. For more significant changes, especially ones with the potential to destabilize a lot of code, people should wait a day or two before assuming there is consensus, the rationale being that no one should be marginalized in an important conversation simply because he didn't check email frequently enough.</para> +<para>Tambi�n significa que el proceso de consensuar no necesita ser muy formal. Muchos proyectos manejan esto por instinto. Los cambios menores pueden ir sin discusi�n, o con una discusi�n m�nima seguida por algunos acuerdos. En cambios de mayor importancia, especialmente aquellos que pueden desestabilizar una parte del c�digo, la gente espera uno o dos d�as antes de suponer que hay consenso. La raz�n es que nadie puede ser dejado de lado en una conversaci�n importante simplemente por no haber inspeccionado su correo con la frecuencia debida.</para> -<para>Thus, when someone is confident he knows what needs to be done, he should just go ahead and do it. This applies not only to software fixes, but to web site updates, documentation changes, and anything else unlikely to be controversial. Usually there will be only a few instances where an action needs to be undone, and these can be handled on a case-by-case basis. Of course, one shouldn't encourage people to be headstrong. There is still a psychological difference between a decision under discussion and one that has already taken effect, even if it is technically reversible. People always feel that momentum is allied to action, and will be slightly more reluctant to revert a change than to prevent it in the first place. If a developer abuses this fact by committing potentially controversial changes too quickly, however, people can and should complain, and hold that developer to a stricter standard until things improve.</para> +<para>Entonces, cuando alguien se siente seguro que sabe lo que tiene que hacer, no para en mientes y lo hace. Esto se aplica no s�lo al software fijo, sino a las actualizaciones de la Web, a cambios en la documentaci�n y a cualquier otra cosa que no sea controversial. Generalmente se dar�n pocos casos en los que la acci�n tenga que ser deshecha, y estos pueden ser tratados individualmente en cada caso. Por supuesto que no se debe incentivar a la gente para que sea obstinada. Hay todav�a una diferencia psicol�gica entre una decisi�n bajo discusi�n y una que ya haya tenido efecto, por m�s que se diga que es t�cnicamente reversible. La gente siente que el momento es un aliado de la acci�n, y que se sentir�n m�s reacios a revertir un cambio que a prevenirlo en el primer instante. Si un desarrollador se abusa de este principio y r�pidamente hace commits de cambios que generan controversia, ciertamente la gente puede y debe quejarse, y mantener a ese desarrollador en un est�ndar estricto hasta que las cosas mejoren.</para> </sect2> <sect2 id="voting"> -<title>When Consensus Cannot Be Reached, Vote</title> +<title>Cuando No Se Puede Tener Consenso, Vote</title> -<para>Inevitably, some debates just won't consense. When all other means of breaking a deadlock fail, the solution is to vote. But before a vote can be taken, there must be a clear set of choices on the ballot. Here, again, the normal process of technical discussion blends serendipitously with the project's decision-making procedures. The kinds of questions that come to a vote often involve complex, multifaceted issues. In any such complex discussion, there are usually one or two people playing the role of <firstterm>honest broker</firstterm>: posting periodic summaries of the various arguments and keeping track of where the core points of disagreement (and agreement) lie. These summaries help everyone measure how much progress has been made, and remind everyone of what issues remain to be addressed. Those same summaries can serve as prototypes for a ballot sheet, should a vote become necessary. If the honest brokers have been doing their job well, they will be able to credibly call for a vote when the time comes, and the group will be willing to use a ballot sheet based on their summary of the issues. The brokers themselves may be participants in the debate; it is not necessary for them to remain above the fray, as long as they can understand and fairly represent others' views, and not let their partisan sentiments prevent them from summarizing the state of the debate in a neutral fashion.</para> +<para>Inevitablemente, algunos debates no llegar�n al consenso. Cuando no haya otro medio de salir del callej�n, la soluci�n es votar. Pero antes que se llegue a la votaci�n, debe aclararse unas cuantas opciones del ballotage. De nuevo en este caso el proceso de discusi�n t�cnica se integra suavemente con los procedimientos de toma de decisi�n del proyecto. El tipo de asuntos que llega a votaci�n implican a menudo temas complejos, llenos de facetas. En cualquiera de tales discusiones complicadas, hay a menudo una o dos personas que hacen las veces de <firstterm>negociador honesto</firstterm>: aportan peri�dicamente la s�ntesis de los argumentos y siguen las l�neas de los puntos centrales del desacuerdo (y del acuerdo). Estas s�ntesis ayudan a que todos estimen el progreso que se va haciendo, y les recuerda a todos cu�les asuntos quedan pendientes. Estas s�ntesis podr�n servir como modelos para una propuesta de votaci�n, en caso de que �sta se vuelva necesaria. Si los negociadores honestos se han desempe�ado bien en su oficio, estar�n en condiciones de llamar a votaci�n cuando llegue el tiempo, y todos querr�n usar las propuestas vertidas en esas s�ntesis para organizar la votaci�n. Los negociadores tambi�n ser�n part�cipes del debate; no es necesario que ellos queden fuera de la votaci�n, en tanto puedan entender y representar los puntos de vista de los dem�s, y no dejen que sus sentimientos partidarios les impidan producir s�ntesis del estado del debate en una forma neutral.</para> -<para>The actual content of the ballot is usually not controversial. By the time matters reach a vote, the disagreement has usually boiled down to a few key issues, with recognizable labels and brief descriptions. Occasionally a developer will object to the form of the ballot itself. Sometimes his concern is legitimate, for example, that an important choice was left off or not described accurately. But other times a developer may be merely trying to stave off the inevitable, perhaps knowing that the vote probably won't go his way. Ver<xref linkend="difficult-people"/><phrase output="printed"> -en <xref linkend="communications"/></phrase> for how to deal with this sort of obstructionism.</para> +<para>Normalmente la organizaci�n de la votaci�n no cae en la controversia. Cuando llega el tiempo de votar, el desacuerdo ha sido analizado y reducido a unas pocas cuestiones, bien etiquetadas y acompa�adas de descripciones concisas. De vez en cuando un desarrollador har� una objeci�n sobre la forma de votar. A veces esta preocupaci�n es leg�tima, por ejemplo, cuando una opci�n importante ha sido dejada de lado o no ha sido presentada con precisi�n. Pero otras veces un desarrollador puede tratar de impedir lo inevitable, quiz�s porque se da cuenta que el voto no va acompa�ar su idea. Ver<xref linkend="difficult-people"/><phrase output="printed"> +en <xref linkend="communications"/></phrase> para ver como tratar este tipo de obstruccionismo.</para> -<para>Remember to specify the voting system, as there are many different kinds, and people might make wrong assumptions about which procedure is being used. A good choice in most cases is <firstterm>approval voting</firstterm>, whereby each voter can vote for as many of the choices on the ballot as he likes. Approval voting is simple to explain and to count, and unlike some other methods, it only involves one round of voting. See <ulink url="http://en.wikipedia.org/wiki/Voting_system#List_of_systems"/> for more details about approval voting and other voting systems, but try to avoid getting into a long debate about which voting system to use (because, of course, you will then find yourself in a debate about which voting system to use to decide the voting system!). One reason approval voting is a good choice is that it's very hard for anyone to object to—it's about as fair as a voting system can be.</para> +<para>Recuerde de especificar el sistema de votaci�n, puesto que hay varias formas, y la gente puede tener falsas expectativas sobre el procedimiento que va a ser usado. Una buena opci�n es la <firstterm>votaci�n por aprobaci�n</firstterm>, en la que cada votante puede votar por todas las opciones que quiera, dentro de las opciones presentadas. La votaci�n por aprobaci�n se resuelve simplemente explicando y contando, y a diferencia de otros m�todos, solo requiere una ronda de votaci�n. Ver <ulink url="http://en.wikipedia.org/wiki/Voting_system#List_of_systems"/> para mas detalles acerca de la votaci�n por aprobaci�n y otros sistemas de votaci�n, pero tratar de no caer en un debate largo sobre cu�l deba ser el sistema que se use (ya que se ver�n atrapados en el c�rculo de tener que votar para decidir c�mo votar!) Una raz�n para defender la votaci�n por aprobaci�n como una buena opci�n es que es dif�cil que alguien se oponga—es lo m�s transparente que puede ser una votaci�n.</para> -<para>Finally, conduct votes in public. There is no need for secrecy or anonymity in a vote on matters that have been debated publicly anyway. Have each participant post her votes to the project mailing list, so that any observer can tally and check the results for herself, and so that everything is recorded in the archives.</para> +<para>Finalmente, voto secreto, voto abierto. No hay necesidad de guardar secretos o aparecer como an�nimos en una votaci�n sobre asuntos que se han debatido p�blicamente. Cada participante pone su voto en la lista de correo del proyecto, de modo que cualquier observador pueda hacer el conteo y verificar el resultado, y que todo quede archivado.</para> </sect2> <sect2 id="when-to-vote"> -<title>When To Vote</title> +<title>Cuando Se Debe Votar</title> -<para>The hardest thing about voting is determining when to do it. In general, taking a vote should be very rare—a last resort for when all other options have failed. Don't think of voting as a great way to resolve debates. It isn't. It ends discussion, and thereby ends creative thinking about the problem. As long as discussion continues, there is the possibility that someone will come up with a new solution everyone likes. This happens surprisingly often: a lively debate can produce a new way of thinking about the problem, and lead to a proposal that eventually satisfies everyone. Even when no new proposal arises, it's still usually better to broker a compromise than to hold a vote. After a compromise, everyone is a little bit unhappy, whereas after a vote, some people are unhappy while others are happy. From a political standpoint, the former sitation is preferable: at least each person can feel he extracted a price for his unhappiness. He may be dissatisfied, but so is everyone else.</para> +<para>Lo m�s dif�cil en la votaci�n es determinar cuando se debe votar. Generalmente la votaci�n tiene que ser algo fuera de lo com�n—el �ltimo resorte cuando todas las otras opciones han fallado. No tome a la votaci�n como el gran camino para resolver los debates. No lo es. Finaliza la discusi�n, y por tanto finaliza el pensamiento creativo sobre el problema. Mientras la discusi�n est� en el tapete, existe la posibilidad de que alguien aporte una soluci�n nueva, que sea del agrado de todos. Sorprendentemente, esto ocurre a menudo: un debate abierto puede producir un giro nuevo del pensamiento sobre el problema, y llevar a una propuesta que eventualmente satisfaga a todos. A�n cuando no surja una propuesta nueva, todav�a es mejor negociar una soluci�n de compromiso que poner un voto. Luego de una soluci�n de compromiso, todos quedan algo insatisfechos, mientras que despu�s de una votaci�n unos quedan contentos y otros en des�nimo. Desde un punto de vista pol�tico, la primera situaci�n es preferible: al menos cada uno puede sentir que su des�nimo es el precio de su accionar. Puede estar insatisfecho, pero todos lo est�n.</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>La ventaja principal de la votaci�n es que se cierra la cuesti�n y se puede seguir adelante. Pero el arreglo se hace por un conteo de votos, en lugar de un di�logo racional que conduzca a todos a la misma conclusi�n. Cuanto m�s experiencia tiene la gente en proyectos de fuente abierta, les encuentro menos dispuestas a querer arreglar las cuestiones por medio de la votaci�n. Tratar�n primero de explorar las soluciones que previamente no hayan sido consideradas, o entrar en soluciones de compromiso m�s ajustadas de lo que planearon en un comienzo. Hay varias t�cnicas para prevenir una votaci�n prematura. La m�s obvia es decir simplemente "no creo que ya estemos listos para una votaci�n", y explicar por qu� no. La otra es pedir que sin compromiso se levanten las manos. Si la respuesta tiende claramente hacia un lado, necesariamente va a inclinar al otro grupo a querer encontrar soluciones de compromiso, obviando as� la necesidad de la votaci�n formal. Pero la manera m�s efectiva es simplemente ofrecer una soluci�n nueva, o un nuevo punto de vista para una sugerencia antigua, de modo que la gente se re-conecte con los temas en lugar de repetir meramente los mismos argumentos.</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>En algunos casos raros, todos pueden concordar que las soluciones de compromiso presentadas son perores que cualquiera de las soluciones en consideraci�n. Cuando esto ocurre, la votaci�n no es tan objetable, por un lado porque es muy probable que se va a llegar a una soluci�n superior, y por otro porque la gente no se va a desanimar con el resultado, cualquiera sea la opci�n que gane. A�n en estos casos, no hay que apurarse en votar. La discusi�n que arriba en una votaci�n es lo que educa al electorado, y detener pronto la discusi�n puede disminuir la calidad del resultado.</para> -<para>(Note that this advice to be reluctant to call votes does not apply to the change-inclusion voting described in <xref linkend="stabilizing-a-release"/><phrase output="printed"> -en <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> +<para>(Fijarse que este consejo de ser reacio a las votaciones no se aplican a la votaci�n sobre cambio-inclusi�n que se describe en <xref linkend="stabilizing-a-release"/><phrase output="printed"> +en <xref linkend="development-cycle"/></phrase>. All�, la votaci�n es m�s bien un mecanismo de comunicaci�n, un medio de registrar el propio compromiso en el proceso de revisi�n de cambio de modo que todos puedan decir cu�nta revisi�n ha recibido un cambio dado.)</para> </sect2> <sect2 id="electorate"> -<title>Who Votes?</title> +<title>�Qui�n 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>Al tener un sistema de votaci�n aparece la cuesti�n del electorado: �A qui�n le corresponde votar? Este asunto puede convertirse en delicado, porque fuerza a que el proyecto reconozca oficialmente que hay gente con mayor compromiso, o con mejores apreciaciones que los otros.</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>La mejor soluci�n es simplemente tomar la distinci�n existente, el acceso a los commits, y asociar los privilegios del voto en eso. En proyectos en que existan accesos completos y parciales a los commits, la cuesti�n de permitir el voto a los que tienen commit parcial depender� en gran manera de los procesos por los que el commit parcial fue otorgado. Si el proyecto lo maneja con liberalidad, por ejemplo como una manera de mantener muchas herramientas de contribuci�n de terceras partes en el repositorio, entonces debe dejarse en claro que el acceso al commit parcial hace referencia a los commits, no a la votaci�n. Naturalmente la implicaci�n inversa se mantiene: puesto que los que tienen commit completo <emphasis>tendr�n</emphasis> privilegios de votaci�n, deben elegirse no solo como programadores, sino tambi�n como miembros del electorado. Si alguien muestra tendencias disruptivas u obstruccionistas en la lista de correo, el grupo debe ser muy cauto en incluirlo entre los que hacen commits, auque sea una persona capacitada t�cnicamente.</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>E sistema de votaci�n debe ser usado para elegir a los nuevos miembros que hacen commit, sea completo o parcial. Y aqu� aparece una de las circunstancias raras en donde el voto secreto es apropiado. No pueden ponerse los votos para los que hacen commits en una lista de correo p�blica, porque se pueden herir los sentimientos y la reputaci�n de un candidato. En lugar de eso, la forma com�n es que los que tienen voto lo pongan en una lista de correo privada donde solamente est�n los que pueden hacer commits, para proponer que alguien sea habilitado para hacer commits. De esta manera todos pueden expresarse libremente, sabiendo que la discusi�n es privada. A menudo no habr� desacuerdo, y no se necesitar� votar. Luego de esperar unos d�as para asegurarse que todos tuvieron oportunidad de responder, el proponente env�a un mail al candidato y le ofrece el acceso a los commits. Si hay desacuerdo, se inicia una discusi�n como para cualquier otro asunto, con la posibilidad de terminar en una votaci�n. Para que este proceso sea abierto y transparente, tambien tiene que ser secreto el hecho que hay una discusi�n en curso. Si la persona en consideraci�n sabe lo que est� ocurriendo, y luego no se le ofrece un acceso de commit, puede concluir que �l ha perdido el voto, y sentirse herido por ello. Por supuesto, si alguien expl�citamente pide el acceso al commit, entonces no hay nada que hacer sino considerar la propuesta y expl�citamente aceptarle o rechazarle. Si ocurre lo segundo, tiene que hacerse con sumo tacto, con una explicaci�n clara: "Nos agradan tus aportes, pero todav�a no hemos visto lo suficiente", o "Hemos tenido en cuenta todos tus aportes, pero se han tenido que hacer considerables ajustes antes de poder aplicarlos, por lo que todav�a no nos sentimos confiados para darte el acceso al commit. Esperamos que esto cambie con el tiempo". Recordar que lo que se dice puede caer como un golpe, dependiendo del grado de confianza que se tenga con la persona. Tratar de verlo desde su punto de vista, en el momento que se escribe el 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. Ver<xref linkend="committers"/><phrase output="printed"> en <xref linkend="managing-volunteers"/></phrase> for more on the non-voting aspects of adding and removing committers.</para> +<para>Puesto que agregar un nuevo miembro que pueda hacer commits es una decisi�n m�s secuencial que otras decisiones, algunos proyectos tienen requerimientos especiales para el voto. Por ejemplo, puede requerirse que la propuesta reciba por lo menos <emphasis>n</emphasis> votos positivos y que no tenga ning�n voto negativo, o que cierta supermayor�a vote a favor. Los par�metros exactos no son importantes; la idea principal es que el grupo debe ser cuidadoso al otorgar acceso a los commits. Similarmente, o todav�a m�s estrictamente, se aplican requerimientos especiales a la votaci�n para <emphasis>quitar</emphasis> el acceso a los commits, y ojal� que eso nunca sea necesario. Ver<xref linkend="committers"/><phrase output="printed"> en <xref linkend="managing-volunteers"/></phrase> para m�s aspectos sobre la no votaci�n para agregar o quitar acceso a los commits.</para> </sect2> @@ -162,4 +162,4 @@ </chapter> -<!-- local variables: sgml-parent-document: ("book.xml" "chapter") end: --> +<!-- local variables: sgml-parent-document: ("book.xml" "chapter") end: --> \ No newline at end of file
_______________________________________________ Producingoss-translators mailing list [email protected] http://www.red-bean.com/mailman/listinfo/producingoss-translators
