El Vie 19 Oct 2007, Roman H. Gelbort escribió: > Ariel. > > Puede ser que me haya perdido de algo en esta larga discusión. No trato > de tomar posición en la misma. > > Pero no entiendo tu descontento. > > Yo coincido con que hay cosas pésimamente traducidas. Por ejemplo: > > El documento "algo.odt" ha sido modificado. > ¿Desea guardar las modificaciones? > > La respuesta a esto debería ser cortita e inequívoca, es decir: Sí, No, > Cancelar. > > En vez de Guardar, Rechazar, Cancelar. > > Pero pienso en proponer ese cambio (entre otros) por los canales que nos > están pasando ahora. Si esto no funcionara, entonces seré uno de los > primeros en quejarse. Pero mientras tanto prefiero conocer mejor los > mecanísmos desde adentro. > > Dicho sea de paso, la sensación que me queda de los mecanísmos es que > son demasiado burocráticos y mal documentados. No hay procesos bien > claros para el que recién se inicia. > > Es como que la mayoría de las cosas están hechas para que las entienda > solo aquel que está con dedicación exclusiva al proyecto y no para los > voluntarios. Esto no es extraño si se viene de un esquema donde la gente > de Sun es mayoría. Creo que estará en todos nosotros lograr que esto > cambie. Coincido plenamente. Más allá de que Ariel tiene razón en algunas cosas, como por ejemplo los breves plazos de entrega que propone Sun, eso (y otras cosas) cambiarán en la medida en que nos involucremos más, y exijamos que se dé mayor participación y control a la comunidad.
Es verdad que falta documentar procesos y parece haber mucha burocracia, será cuestión meternos en el barro para poder limpiar un poco esos procesos. No obstante a veces un poquito de burocracia es necesaria. Por ejemplo, en OOoAuthors no podemos otorgarle permisos de acceso a todo aquel que envía un correo diciendo "voy a traducir el capítulo N", porque esas actividades consumen parte del escaso tiempo que podemos donar. Entonces debemos exigir que los colaboradores demuestren que están trabajando sobre un documento para después otorgar el acceso. Además, el desafío es agilizar la estructura de OpenOffice.org que en muchos aspectos parece estar pensada para preservar la meritocracia, sin desvirtuar ese principio rector con el que se han conducido la mayoría de las comunidades de software libre desde hace mucho tiempo. Por último, las críticas deben ser hechas indefectiblemente cuando creemos que alguien se equivoca, pero por favor dejemos de lado las ironías y tratemos de que las críticas sean 100% constructivas. En este punto, no es posible que exijamos que las cosas sean como debieran ser, porque la gente que hay para hacerlas es muy escasa. En consecuencia, si observamos que algo debe cambiar, viejo, a arremangarse y manos a la obra. Quien no pueda hacerlo, puede expresar su opinión, pero no llevar los cuestionamientos a lo que poco a poco parece convertirse en una flame war; en todo caso si ves que algo anda mal, pero no podés responsabilizarte en corregirlo, tratá de sumar gente que colabore y que pueda dar forma a tus ideas. Dicho por alguien a quien le molesta profundamente que las cosas no sean como debieran ser. Saludos. -- Fabián Flores Vadell http://tecnoweblog.blogspot.com/ ISO no puede convertirse en una broma, aprobando ooxml. Suscriba la petición a la ISO para que rechace la propuesta de oooxml como estándar: http://www.noooxml.org/petition-es Rompe las cadenas, usa OpenOffice.org: http://es.openoffice.org/ Aprende a usar OpenOffice.org y colabora a difundirlo: http://oooauthors.org/es Colabora a difundir el Software Libre con Begins: http://www.linuxchillan.cl/?q=node/203 Un dilema sin solución, ¿Tuquito, Ututo, Kubuntu o Debian (el primer amor)? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
