Author: raffmarti Date: Sat Aug 11 13:38:49 2007 New Revision: 951 Log: finished chapter 4
Modified: trunk/es/ch04.xml Modified: trunk/es/ch04.xml ============================================================================== --- trunk/es/ch04.xml (original) +++ trunk/es/ch04.xml Sat Aug 11 13:38:49 2007 @@ -6,20 +6,20 @@ <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 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>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 el �xito inicial aporta, 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> <sect1 id="forkability"> <title>Forkability</title> -<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>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 fuerza 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 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>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 com�nmente se entiende por esa palabra. Imaginaos un rey cuyos s�bditos pudieran copiar todo su reino en cualquier momento y trasladarse 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> +<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 l�der (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". Excepto que, por supuesto, muy rara vez las cosas llegan tan lejos, porque antes el dictador busca soluciones de compromiso.</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> +<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 agobiante, 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 incluidos entre esos casos.</para> </sect1> @@ -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 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> +<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 se comportan como mandones. 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> @@ -118,22 +118,22 @@ </sect2> <sect2 id="polls"> -<title>Polls Versus Votes</title> +<title>Encuestas Versus Votaciones</title> -<para>For certain kinds of votes, it may be useful to expand the electorate. For example, if the developers simply can't figure out whether a given interface choice matches the way people actually use the software, one solution is to ask to all the subscribers of the project's mailing lists to vote. These are really <firstterm>polls</firstterm> rather than votes, but the developers may choose to treat the result as binding. As with any poll, be sure to make it clear to the participants that there's a write-in option: if someone thinks of a better option not offered in the poll questions, her response may turn out to be the most important result of the poll.</para> +<para>Para ciertas clases de votaciones, puede ser �til expandir el electorado. Por ejemplo, si los desarrolladores no tienen una idea clara para decidir si una interfase dada se adapta al modo como la gente realmente usa el software, una soluci�n es hacer una votaci�n entre todos los suscriptos en la lista de correo del proyecto. Estas son realmente <firstterm>encuestas</firstterm> m�s que votaciones, pero los desarrolladores pueden acordar que los resultados sean vinculantes. Como en cualquier votaci�n, hay que asegurarse de informar a los participantes que hay una opci�n escrita: si a alguien se le ocurre una opci�n mejor que no est� en la lista, su respuesta puede llegar a ser el resultado m�s importante de la votaci�n.</para> </sect2> <sect2 id="veto"> -<title>Vetoes</title> +<title>Vetos</title> -<para>Some projects allow a special kind of vote known as a <firstterm>veto</firstterm>. A veto is a way for a developer to put a halt to a hasty or ill-considered change, at least long enough for everyone to discuss it more. Think of a veto as somewhere between a very strong objection and a filibuster. Its exact meaning varies from one project to another. Some projects make it very difficult to override a veto; others allow them to be overridden by regular majority vote, perhaps after an enforced delay for more discussion. Any veto should be accompanied by a thorough explanation; a veto without such an explanation should be considered invalid on arrival.</para> +<para>Algunos proyectos permiten un tipo especial de voto que se conoce como <firstterm>veto</firstterm>. El veto es la manera que tiene un desarrollador para detener un cambio apresurado o mal considerado, por lo menos por un tiempo suficiente para que todos puedan discutirlo m�s. Entender el veto como algo que est� entre una objeci�n fuerte y una discusi�n sin fin. El sentido exacto del veto var�a de un proyecto a otro. Algunos proyectos hacen que sea dif�cil contrarrestar un veto; otros permiten que sea superado por el voto de una simple mayor�a, quiz�s luego de una forzada demora producida por m�s discusi�n. Un veto debe ser acompa�ado por una explicaci�n exhaustiva; el veto presentado sin esa explicaci�n debe ser considerado inv�lido.</para> -<para>With vetoes comes the problem of veto abuse. Sometimes developers are too eager to raise the stakes by casting a veto, when really all that was called for was more discussion. You can prevent veto abuse by being very reluctant to use vetoes yourself, and by gently calling it out when someone else uses her veto too often. If necessary, you can also remind the group that vetoes are binding for only as long as the group agrees they are—after all, if a clear majority of developers wants X, then X is going to happen one way or another. Either the vetoing developer will back down, or the group will decide to weaken the meaning of a veto.</para> +<para>Junto con los vetos se introduce el problema del abuso del veto. A veces los desarrolladores est�n demasiado ansiosos en levantar la presi�n con el pedido de veto, cuando lo que realmente se requiere es m�s discusi�n. Se puede evitar el abuso del veto empezando por ser uno mismo contrario al uso del veto, y haciendo notar con tacto cuando alguien usa el veto muy a menudo. Si fuera necesario, se puede recordar para el grupo que los vetos tienen fuerza de obligaci�n siempre y cuando el grupo est� de acuerdo—despu�s de todo, si una gran mayor�a de desarrolladores quieren X, de una u otra manera van a conseguir X. O bien el desarrollador que propuso el veto lo retira, o el grupo va a quitarle fuerza al significado del veto.</para> -<para>You may see people write "-1" to express a veto. This usage comes from the Apache Software Foundation, which has a highly structured voting and veto process, described at <ulink url="http://www.apache.org/foundation/voting.html"/>. The Apache standards have spread to other projects, and you will see their conventions used to varying degrees in a lot of places in the open source world. Technically, "-1" does not always indicate a formal veto even according to the Apache standards, but informally it is usually taken to mean a veto, or at least a very strong objection.</para> +<para>A veces se escribe un "-1" para contabilizar el veto. Esta costumbre viene de la Fundaci�n del Software Apache, quienes tienen un proceso muy estructurado de votos y votaciones, que est� en <ulink url="http://www.apache.org/foundation/voting.html"/>. Las normas de Apache se han difundido a otros proyectos, y se pueden ver sus acuerdos usados de distinta forma en muchos lugares del mundo de la fuente abierta. T�cnicamente "-1" no siempre indica que hay un veto formal de acuerdo a las normas de Apache, pero informalmente se considera que representa un veto, o por lo menos una objeci�n muy fuerte.</para> -<para>Like votes, vetoes can apply retroactively. It's not okay to object to a veto on the grounds that the change in question has already been committed, or the action taken (unless it's something irrevocable, like putting out a press release). On the other hand, a veto that arrives weeks or months late isn't likely to be taken very seriously, nor should it be.</para> +<para>Igual que con las votaciones, los vetos se pueden aplicar con efectos retroactivos. No es correcto rechazar un veto porque el cambio en cuesti�n haya sido puesto en commit, o porque la acci�n est� asumida (a no ser que se trate de algo irrevocable, como por ejemplo una edici�n de prensa). Por otro lado, un veto que llega semanas, o meses tarde no tiene la posibilidad de que se lo tome muy en serio, ni tendr�a que ser as�.</para> </sect2> @@ -141,25 +141,25 @@ <!-- ======================== SECTION ============================== --> <sect1 id="written-rules"> -<title>Writing It All Down</title> +<title>Tomando Nota de Todo</title> -<para>At some point, the number of conventions and agreements floating around in your project may become so great that you need to record it somewhere. In order to give such a document legitimacy, make it clear that it is based on mailing list discussions and on agreements already in effect. As you compose it, refer to the relevant threads in the mailing list archives, and whenever there's a point you're not sure about, ask again. The document should not contain any surprises: it is not the source of the agreements, it is merely a description of them. Of course, if it is successful, people will start citing it as a source of authority in itself, but that just means it reflects the overall will of the group accurately.</para> +<para>En cierto momento, el n�mero de acuerdos y arreglos que circulan por el proyecto pueden llegar a ser tan grandes que se necesita registrarlos en alg�n lugar. Y para dar legitimidad a esos documentos, hay que tener bien claro que est�n basados el las discusiones de las listas de correo y en acuerdos que ya estaban en vigencia. Cuando se los escribe, se hace referencia a las l�neas de los archivos de la lista de correo y cada vez que no se est� seguro sobre un punto, se pregunta de nuevo. El documento no debe contener sorpresas: �ste no es fuente de los acuerdos, sino solamente la descripci�n de ellos. Por supuesto, si es aceptado, la gente comenzar� a citarlo como si fuera una fuente de autoridad, pero eso s�lo significa que refleja con exactitud la voluntad de todos los del grupo.</para> -<para>This is the document alluded to in <xref linkend="developer-guidelines"/><phrase output="printed"> en <xref linkend="getting-started"/></phrase>. Naturally, when the project is very young, you will have to lay down guidelines without the benefit of a long project history to draw on. But as the development community matures, you can adjust the language to reflect the way things actually turn out.</para> +<para>Este es el documento aludido <xref linkend="developer-guidelines"/><phrase output="printed"> en <xref linkend="getting-started"/></phrase>. Naturalmente, cuando el proyecto reci�n comienza, se tendr� que esbozar una gu�a, sin que por esto se excluya la confecci�n de una posterior historia del proyecto. Pero, a medida que la comunidad madura, se pueden hacer ajustes del lenguaje para reflejar la manera final a la que se ha llegado.</para> -<para>Don't try to be comprehensive. No document can capture everything people need to know about participating in a project. Many of the conventions a project evolves remain forever unspoken, never mentioned explicitly, yet adhered to by all. Other things are simply too obvious to be mentioned, and would only distract from important but non-obvious material. For example, there's no point writing guidelines like "Be polite and respectful to others on the mailing lists, and don't start flame wars," or "Write clean, readable bug-free code." Of course these things are desirable, but since there's no conceivable universe in which they might <emphasis>not</emphasis> be desirable, they are not worth mentioning. If people are being rude on the mailing list, or writing buggy code, they're not going to stop just because the project guidelines said to. Such situations need to be dealt with as they arise, not by blanket admonitions to be good. On the other hand, if the project has specific guidelines about <emphasis>how</emphasis> to write good code, such as rules about documenting every API in a certain format, then those guidelines should be written down as completely as possible.</para> +<para>No se debe pretender que uno lo ha dicho todo. Ning�n documento puede captar todo lo que la gente necesita saber para participar en un proyecto. Muchos de los acuerdos del proyecto permanecen t�citos, nunca explicitados, sin embargo aceptados por todos. Algunas cosas son muy obvias para incluirlas, y resultar�an distractivas al lado del material que no es obvio y es importante. Por ejemplo, no tiene sentido escribir en la gu�a una instrucci�n como "Sea educado y respetuoso con los otros miembros de la lista de correos, y no incite a las discusiones acaloradas" o "Escriba c�digo sin errores, claros y limpios." Por supuesto que son cosas deseables, pero no existe un universo concebible donde estas cosas <emphasis>no</emphasis> sean deseables, por lo que no vale la pena mencionarlas. Si alguien es grosero en la lista de correos, o escribe el c�digo con errores, no van a dejar de hacerlo s�lo porque la gu�a del proyecto lo dice. Estas situaciones requieren atenci�n en el momento que aparecen, y no bastan las normas generales que dicen que hay que ser buenos. Adem�s, si el proyecto tiene l�neas espec�ficas sobre <emphasis>c�mo</emphasis> escribir un c�digo bueno, entonces esas l�neas de la gu�a deber escribirse con todo el detalle que sea posible.</para> +. +<para>Una buena manera de determinar qu� debe incluirse en el documento es referirse a las preguntas que los reci�n llegados hacen, y a las quejas de los desarrolladores con experiencia. Esto no quiere decir que necesariamente tienen que convertirse en un informe FAQ—posiblemente el documento necesita una estructura narrativa m�s coherente que la que puede ofrecer el FAQ. Tiene entonces que seguir el mismo principio basado en la pr�ctica, que hay que incluir asuntos que realmente se producen, y no tanto tratar de anticiparse a los asuntos que pueden producirse.</para> +. +<para>Si el proyecto tiene un dictador ben�volo, o si tiene miembros con poderes especiales (presidente, secretario general, o lo que sea), entonces el documento es una buena oportunidad de escribir los procedimientos de la sucesi�n de poderes. A veces eso puede ser tan simple como nombrar cierta gente como reemplazantes en el caso en que el DB abandone el proyecto por alguna raz�n. Generalmente, si hay un DB, es s�lo �l quien puede decidir el nombre de un sucesor. Si se elige una comisi�n, entonces el procedimiento de la elecci�n y el nombramiento de los integrantes de la comisi�n tiene que estar descrito en el documento. Si al comienzo no existe un procedimiento, entonces hay que conseguir un consenso en la lista de correos <emphasis>antes</emphasis> de escribir sobre el procedimiento. Hay gente que puede ser sensible con las estructuras jer�rquicas, por lo que el asunto tiene que ser tratado con delicadeza.</para> -<para>A good way to determine what to include is to base the document on the questions that newcomers ask most often, and on the complaints experienced developers make most often. This doesn't necessarily mean it should turn into a FAQ sheet—it probably needs a more coherent narrative structure than FAQs can offer. But it should follow the same reality-based principle of addressing the issues that actually arise, rather than those you anticipate might arise.</para> +<para>Quiz�s lo mas importante es dejar en claro que las reglas pueden ser reconsideradas. Si los acuerdos descritos en el documento comienzan a frenar el proyecto, recordar a todos que fue pensado como una reflexi�n viviente de las intenciones del grupo, no para provocar frustraci�n y bloqueo. Si alguien toma por h�bito pedir que las reglas se reconsideren cada vez que una regla se considera, no siempre conviene debatir el tema con ella—a veces el silencio es la mejor t�ctica. Si hay mas de uno que se une a las quejas, la campana ha sonado, y ser� l�gico suponer que algo necesita ser cambiado. Si nadie se une a la queja, entonces esa persona no representa a nadie, y las reglas quedar�n como est�n.</para> -<para>If the project is a benevolent dictatorship, or has officers endowed with special powers (president, chair, whatever), then the document is also a good opportunity to codify succession procedures. Sometimes this can be as simple as naming specific people as replacements in case the BD suddenly leaves the project for any reason. Generally, if there is a BD, only the BD can get away with naming a successor. If there are elected officers, then the nomination and election procedure that was used to choose them in the first place should be described in the document. If there was no procedure originally, then get consensus on a procedure on the mailing lists <emphasis>before</emphasis> writing about it. People can sometimes be touchy about hierarchical structures, so the subject needs to be approached with sensitivity.</para> - -<para>Perhaps the most important thing is to make it clear that the rules can be reconsidered. If the conventions described in the document start to hamper the project, remind everyone that it is supposed to be a living reflection of the group's intentions, not a source of frustration and blockage. If someone makes a habit of inappropriately asking for rules to be reconsidered every time the rules get in her way, you don't always need to debate it with her—sometimes silence is the best tactic. If other people agree with the complaints, they'll chime in, and it will be obvious that something needs to change. If no one else agrees, then the person won't get much response, and the rules will stay as they are.</para> - -<para>Two good examples of project guidelines are the Subversion -<filename>hacking.html</filename> file, at <ulink url="http://svn.collab.net/repos/svn/trunk/www/hacking.html"/>, and the Apache Software Foundation governance documents, at <ulink url="http://www.apache.org/foundation/how-it-works.html"/> and <ulink url="http://www.apache.org/foundation/voting.html"/>. The ASF is really a collection of software projects, legally organized as a nonprofit corporation, so its documents tend to describe governance procedures more than development conventions. They're still worth reading, though, because they represent the accumulated experience of a lot of open source projects.</para> +<para>Dos buenos ejemplos de una gu�a para un proyecto es Subversion +<filename>hacking.html</filename> en <ulink url="http://svn.collab.net/repos/svn/trunk/www/hacking.html"/>, y los documentos de gobierno de la Fundaci�n de Software Apache, en <ulink url="http://www.apache.org/foundation/how-it-works.html"/> y <ulink url="http://www.apache.org/foundation/voting.html"/>. La Fundaci�n de Software Apache es de hecho una colecci�n de proyectos de software, organizada legalmente como una corporaci�n sin fines de lucro, de modo que sus documentos tienden a describir los procedimientos de gobierno m�s que las convenciones de desarrollo. Vale la pena leerlas, porque representan una experiencia acumulada en muchos proyectos de fuente abierta.</para> </sect1> </chapter> -<!-- local variables: sgml-parent-document: ("book.xml" "chapter") end: --> \ No newline at end of file +<!-- local variables: sgml-parent-document: ("book.xml" "chapter") end: -->
_______________________________________________ Producingoss-translators mailing list [email protected] http://www.red-bean.com/mailman/listinfo/producingoss-translators
