Yo solo un rato participando en la comunidad, por lo que hablare de mi experiencia como usuario común y como colaborador:
Creo que la mayoría de la gente (incluyendome) prefiere un documento claro y conciso Estoy de acuerdo con Oscar en cuanto a que si buscar "garbanzos" encuentres garganzos "rapidamente". Muy particularmente creo que el proyecto es muy grande, tan grande, que hay mucha información, regada por ahí. Concuerdo con alexandro en que la mayoría de las personas prefieren ( y considero que es lo mas adecuado) recibir instrucciones de por donde comenzar, esto los ayudo a ellos a contribuir, y al coordinador a tener un control. Ademas considero que muchas de las cosas que comentaba Oscar ya se hacen, y otras faltan pulirlas, pero en si son lo mismo. La manera en las que se hacen las cosas hasta el momento a lo mejor no son las mejores, pero funcionan. Quiero dejar mi granito de arena en cuanto la contribución de como se podria mejorar el proceso: Dar mas enfasis a la siguiente dirección: http://www.documentfoundation.org/contribution/ En cuanto como contribuir, letras mas grandes, apartados especificos, claros, e indicarles el camino conciso, por que considero que a como esta no inspira a muchos a contribuir. Esto particularmente creo que se debe a que algunos de los que estan en el proyecto, vienen de otros proyectos de software libre, o simplemente ya saben como funcionan, por eso obtaron por poner un pedazito de como contribuir y esperando que todos se inscriban a la lista o que se agregen IRC, no considerando que muchos ni siquiera sabiamos mucho de eso hasta que entramos, en verdad considero que hace falta mas enfasis a los nuevos usuario, inspirarlos mas a contribuir. Saludos. 2010/12/20 Alexandro Colorado <[email protected]> > 2010/12/20 Oscar Manuel Gómez Senovilla <[email protected]>: > > Alexandro Colorado escribió: > >> > >> 2010/12/19 Oscar Manuel Gómez Senovilla<[email protected]>: > >>> > >>> Tras haber hecho la revisión de dos documentos en oooauthors, y > >>> pegarme con la documentación, sistema de traducción, etc., me veo > >>> en la obligación de realizar una serie de sugerencias que, si > >>> parecen bien, y en la medida de lo posible, se llevarían a cabo > >>> cuando fuera prudente hacerse. > >> > >> Creo que si es bastante largo y algo tedioso. Creo que la mision del > >> documento es mantenerlo simple y tener un escrito que no tengan a un > >> nuevo voluntario pasandose leyendo dicho documento largo y tedioso. > > > > > > Personalmente, si tras leer los documentos, realizar dos revisiones > > todavía me han quedado ganas de quedarme un domingo por la noche (más > bien > > madrugada del lunes) hasta la 1:30 escribiendo el correo (cuando tengo > que > > estar trabajando unas pocas horas más tarde) y contestando este correo, > algo > > tendré que haber visto en donde no todo es tan sencillo ¿no crees? > > > > > >> Creo que tampoco es el objetivo tener un sistema idoneo, o mejor > >> dicho el sistema idoneo es el menos burocratico. Es quizas el > >> problema con los manuales que quieren ser tan perfectos y completos > >> que nadie los lee. Muchas veces es mejor tener solo los lineamientos > >> princpiales y partir de estos. Un ejemplo es la participacion en el > >> wiki, pocas personas se leen el manual de mediawiki antes de crear su > >> primer modificacion. > > > > > > El correo es largo, pero traspasada la informacion útil a un documento > > bonito, con alguna captura de pantalla y sin entrar en mayores detalles, > > creo que con un máximo de 10 minutos de lectura, se aclararían todas las > > dudas. Yo me comprometo a realizar o revisar un documento sobre un > consenso > > al que se pueda llegar. > > > > > >>> Fase 0 ====== Donde todo comienza es en poner unos originales para > >>> que se comience el proceso. Para ello, alguien tendrá que informar > >>> y/o coordinar el progreso de los proyectos en inglés. Cuando se > >>> finalice un proyecto, se crearía una > >> > >> Por que razon debiamos informar a otro proyecto. Aunque en este > >> proyecto se supone que todos sabemos ingles, el tener que obligar a > >> participar en dos listas es algo que no veo necesario para la > >> traduccion como tal. > > > > > > Si lees bien, no digo que haya que informar *a* otro proyecto. Si > quieres, > > puedo reescribir la frase: "Para ello, alguien tendrá que informar y/o > > coordinar en la lista de español sobre el progreso de los proyectos en > > inglés". > > > > > >>> carpeta en el sitio de español *con el mismo nombre (o > >>> identificador, si lo hubiera) que en inglés* para albergar el nuevo > >>> proyecto. De esta forma, cualquier persona puede asociar cualquier > >>> traducción con el proyecto original, sin necesidad de conocer el > >>> idioma. > >> > >> Creo que la estructura no trabaja asi a nivel general. Tambien > >> oooauthors como tal no se ve como un proyecto como tal 'publico' la > >> mayoria del sitio esta para los miembros y las publicaciones se > >> hacen en documentation.openoffice.org. Vaya digamos oooauthors es > >> una herramienta de trabajo. > > > > > > ... que los equipos de traducción utilizan, y para ello, se necesita un > > sistema para poder organizar el trabajo. Te remito a la contestación que > he > > dado hace un rato sobre tener un buen sistema para organizar el proceso > de > > traducción. > > Es que para mi el que tenemos es bueno y suficiente, y sinceramente el > que dices se me hace inecesario por las razones que son demasiadas > sobre-documentadas y no estoy convencido de su eficiencia. > > De hecho creo que hay procesos mas importantes que se pueden mejorar. > Ya no estoy como gestor de OOoAuthors por las otras actividades del > proyecto hispano. Pero si te puedo decir que como gestor alguna vez de > este proyecto no he visto grandes problemas debido a la falta de > seguimiento de ambos procesos. > > > > > > > >>> Como punto de partida, habría que crear una carpeta que contenga > >>> los originales, ("0 - Sources"), en donde habría *una copia* del > >>> zip conteniendo la documentación publicada (lo de la copia es para > >>> tener una referencia fija por si acaso se modifica la ubicación o > >>> lo que sea en el origen). > >> > >> De nuevo, la documentacion usualmente se hace en el proyecto > >> individual de OOo, no tanto en OOoAuthors. > > > > > > ¿? No entiendo qué relación tiene con lo que yo digo. > > Perdon quise decir en el subproyecto de 'es' y no en OOoAuthors en general. > > > > >>> Fase 1 ====== Esta fase sería la de realizar la traducción de los > >>> originales. Para ello, el coordinador pondría todos los ficheros > >>> extraídos del zip para comenzar la traducción *Y* asignarles un > >>> nombre adecuado a la hora de comenzar la traducción. En este punto, > >>> quisiera discutir algún detalle sobre los nombres de los ficheros. > >> > >> Aun no entiendo el uso del zip, usualmente se traducen un documento > > > > > > El zip no es para *asignar* todos los documentos contenido, sino > partiendo > > de la propia iniciativa del equipo de documentación en inglés, ellos > crean > > un zip para que en una sola descarga estén todos los documentos, y así no > > tener que estar mirando de dónde bajarse un original cada vez que se > > traduzca o revise un documento. Creía que estaba bastante claro. > > Pues ya ves que no, y tampoco se me hace claro aun el por que tenerlo > en un zip. Y creo que crearia mas problemas, ya que tienes copias de > los doctos originales en todas las maquinas, y realmente nadie > reportaria el avance. Si esto fuera un wiki, es como bajarte todo el > wiki para traducirlo y despues subir hoja por hoja. -- totalmente > impractico. > > > > >> a la vez. Las asignaciones multiples pueden crear secuestro de > >> documentos donde estan asignados a alguien que no esta activamente > >> traduciendo. A la misma vez el nombre de los ficheros es unica, > >> muchos usuarios no lo siguen, el tener cambiar la convencion o tener > >> una convencion mas estricta creo que puede ser desfaborable en su > >> adopcion. Por ejemplo los usuarios nuevos sus nombres son los > >> titulos traducidos y nada mas, ni fecha ni autor. Esta labor es > > > > > > Precisamente por eso, ¿no es mejor quitarles esa tarea, y que se ocupen > de > > traducir el contenido? > > No entendi, ellos deben de nombrar sus documentos al final de cuentas > (al subirlos). A menos que estes hablando de un proceso diferente de > insercion. > > > > >> usualmente mas dificil que la de tener un nombre muy exacto. Tambien > >> la mayoria de esta ifnormacion se deduce por el folder. Personalmente > >> siento que admiistrar los documentos por folders es una mejor opcion > >> que tener una lista grande y ver documentos en diferentes etapas con > >> diferentes codigos y con documentos que no fueron correctamente > >> codificados. > > > > > > Está claro que queremos el mismo objetivo, pero yo creo que tal cuál se > está > > haciendo (o está documentado) no ayuda a conseguirlo. De nuevo te remito > al > > correo mío de hace un rato sobre este asunto. > > Haber dando una vuelta por los doctos, veo variaciones minimas de la > convencin original. no veo retrazos por causa de esto. Juan carlos > dime si esto te es confuso. > > La confusion mas grande que hubo fue con las versiones de la > documentacion y con el branch de libreoffice. Y tomo arreglar 1 dia. > No veo que este problema vuelva a pasar hasta que salga la version 4.0 > y solo si aun estamos traduciendo esta. > > > > >>> El nombre de la carpeta sería "1 - Pendientes de traducir" (o > >>> quizás "1 - Para traducir"). Dentro de ésta, aparte de los > >>> documentos iniciales, y quizás con alguna modificación que > >>> comentaré al final, estarían los documentos en su estado inicial > >>> para comenzar la fase 1 del proceso de traducción. > >> > >> Umm.. esto no duplicaria documentos inecesariamente, con tener una > >> liga al documento en el proyecto en ingles seria suficiente no > >> crees? Aparte usualmente los usuarios no escojen su documento sino se > >> les asigna. Esto no es por disenio sino por experiencia de > >> comportamiento de los usuarios nuevos. Tienes que ponerlo en el > >> contexto que muchos apenas estan sacando sus permisos de autores y ya > >> lo que quieren es trabajar, entre mas directo sea (via asignacion) es > >> mejor para ellos. > > > > > > Es posible que inicialmente estén duplicados (original y copia inicial > para > > traducir), pero como ya he explicado en el otro correo, garantiza la > > fiabilidad del proceso y la información contenida. > > Lo veo inecesario y mas trabajo, lo dejaria a criterio de JCS. > > > > >> Tambien se mantiene una grafica de avance local del grupo, esto > >> duplicaria la actividad de gestion. > > > > > > Bueno, eso está bien para estadística, pero no es el tema que estamos > > tratando. > > De hecho si, por que es donde puedo ver el avance completo del > proyecto, no necesito ver el archivo sino necesito ver su proceso. De > hecho esto es mas importante que tener un documento repetido en > carpetas diferentes. Lo mismo lo creo para los usuarios mas > experimentados que prefieren tomar nuevos documentos. > > > > >>> - A continuación, descarga el documento, y luego lo mueve (este > >>> proceso aparentemente sencillo, no lo tengo claro cómo se viene > >>> haciendo en oooauthors) a "En progreso", para que quede claro que > >>> se está trabajando en él. En esta fase puede haber un caso especial > >>> que comento al final. > >> > >> Asi se maneja actualmente. Solo con subir el documento al folder en > >> cuestion. > > > > > > Entiendo que "mover" es descargar el fichero, borrar el fichero > descargado > > del sitio y subirlo al equivalente de "En progreso". Si esto es así, ¿no > > funciona la opción de cortar, que es la que yo intentaba usar? > > Depende de las faces, obviamente como no hay folders "fuentes" no se > mueven tras asignacion. Pero para todo lo demas deben bajarlo, > trabajarlo y subirlo. simplemente cortar, lo moveria de folder sin > haberlo trabajado, algo que usualmente no se da a menos que predtendas > solo moverlo para actualizar el estatus. Por lo regular se mueve en el > momento que el usuario va a trabajarlo. Y si, sus actualizaciones de > trabajo, se mueve a la nueva 'fase'. > > > > >>> Fase 2 ====== La fase 2 consiste en habilitar los documentos cuya > >>> traducción ha finalizado para proceder a su revisión. Para ello, se > >>> crea una carpeta "2 - Pendientes de revisión". Cuando un traductor > >>> finalizar la traducción, tendría que hacer: - Poner el código "XX" > >>> adecuado en el nombre del fichero en su disco local y subirlo al > >>> fichero a esta carpeta. > >> > >> Esto ya se tiene pero no creo que se deba cambiar el codigo, con que > >> este la carpeta ya se entiende que esta en ese proceso. Lo que si > >> deberia cambiar es la persona que lleva la revision usualemtne > >> asignada con sus inciiales. > > > > > > ¿Y cuál es la utilidad de poner el nombre o iniciales del traductor en el > > nombre del fichero? Pensaba que en el fondo debíamos evitar que el > traductor > > se distrajera con cuestiones ajenas a la traducción en sí. > > La utilidad es saber quien esta a cargo del documento. Esto se hace en > el proyecto original, usualmente el unico problema es que no todos le > ponen sus iniciales y prefieren ponerle el nombre completo. Cosa que > alarga mucho el nombre del archivo, pero no es un problema que no se > pueda solucionar rapidamente. Usualmente estos usuarios lo hacen por > que no leen el proceso de traduccion/revision. > > > > >>> - Quitar el documento anterior de "1 - Pendientes de traducir/En > >>> progreso". > >> > >> No creo que los usuaios lo hagan por eso el coordinador global se > >> encarga por que muchos aun no saben como llevar eso y tambien se > >> pierde mas tiempo enseniando a los nuevos que tener una persona > >> asignada para 'housekeeping'. > > > > > > Desconozco si los usuarios no lo hacen por falta de información sobre el > > detalle de qué tienen que hacer en el servidor con el documento en el que > > están trabajando, o sobre cómo hacerlo. En mi caso, no lo he llevado a > cabo > > por lo segundo, pero trato de que ambos motivos queden minimizados y > poder > > proporcionar una información concisa sobre los pasos a seguir en cada > > momento. > > > > > >>> Fase 2.1 ======== Consiste en habilitar que se pueda realizar la > >>> revisión de un documento cuyo último trabajo ha sido la traducción > >>> y que se ha dejado en "2 - Pendientes de revisión" con el código de > >>> la fase 2. Según la documentación en inglés, esto se puede realizar > >>> con permisos de revisor y haciendo "retreat" del documento, que > >>> cambia el estado a "borrador interno" y posteriormente se procede a > >>> la descarga. Alternativamente, si no se tuvieran permisos de > >>> revisión, se necesitaría tener una carpeta "En progreso" dentro de > >>> "2 - Pendiente de revisión". Después, el revisor: > >> > >> Creo que los permisos de revisor y autor son los mismos. Casi casi > >> es binario o eres usuario sin permisos o con permisos. > > > > > > Como nadie me ha confirmado cuando pregunté cuáles son exactamente mis > > permisos, y según veo en la documentación en inglés, los revisores tienen > la > > opción de "retreat" ("retirar"), y a mí no me aparece, por lo que deduzco > > que no tengo permisos de revisor. > > > > Creo que las ultimas actualizaciones de plone introdujeron nuevos > permisos, pero no he investigado demasiado ya que pudieron ser > permisos inheretntes de la migracion de plone. > > >>> - Subirá el documento a esta carpeta - Quitará el documento > >>> anterior de "2 - Pendientes de revisión/En progreso" - Avisará a la > >>> lista de las acciones realizadas y del nuevo estado, para quien > >>> desee continuar el trabajo. > >> > >> Esto ya se tiene asi, tambien creo que la mayoria de esto se trata > >> en la lista mas que en el sitio de oooauthors. Creo que la causa de > >> tener un dominio propio para el apartado en tu mente y la de muchos > >> usuarios ponen a oooauthors como el centro de comunicaciones y > >> operaciones, sin embargo este es la lista mas que el sitio. > >> > >> Usualmente el flujo es de esta manera: > >> > >> Usuario -> Lista de soporte/discusion de OOoES -> Lista de > >> localizacion -> OOoAuthors. > >> > >> Poniendo al sitio como la 3era fuente de informacion despues de las > >> listas. > > > > > > Yo creo que el estado debe reflejarse claramente en el sitio. Piensa en > mi > > situación y en la de los recién llegados: no puedes obligar a que se lean > el > > histórico de las listas para saber quién está haciendo qué. Según lo > > expuesto, cualquiera que visite el sitio y con la organización adecuada, > en > > pocos segundos debería poder saber, por ejemplo, qué documentos están > siendo > > revisados, o traducidos, etc. > > No deben hacerrlo con ver la grafica puedes ver que documentos hacen > falta, y tambien preguntandolo en la lista. > > > > >>> (*) Dado que debería conseguirse un código que diferencie la > >>> primera de la segunda revisión, y que básicamente son el mismo tipo > >>> de proceso, gracias al código diferenciador de fase de revisión, se > >>> podría utilizar la carpeta "2 - Pendientes de revisión" con la > >>> misma filosofía de ubicación de archivos que las fases 2 y 2.1. > >> > >> Esto ya se tiene, debe ser rev o rev1 y rev2 pero solo miemtras se > >> revisa ya que al finalizar ya se sube a la caprpeta de publicacion. > > > > > > ¿Y con qué nombre sube a dicha carpeta? > > Carpeta? estamos hablando de documentos. > > > > >>> (**) Habría que consensuar el uso de una plantilla para aquellos > >>> aspectos legales y cosméticos que no deberían quitar tiempo a > >>> traductores ni a revisores, relativos principalmente a las páginas > >>> de créditos y detalles del documento publicado. También habría que > >>> consensuar si esta parte se puede realizar previamente a la fase 1, > >>> y que se revise en la fase previa a la publicación. > >>> > >> > >> De hecho cualquier documento finalizado tiene esto ya hecho, pero si > >> se parte del documento original usualmente no se tiene esa opcion. > >> > >>> Códigos de estado ================= Teniendo en cuenta que en > >>> inglés se utiliza el formato > >>> > >>> <CODIGO>-Nombreingles.odt > >> > >> de hecho es<codigo>-<titulo>-<autor>-<fecha>[-<revision>].odt > > > > > > No es así en lo que yo me he descargado. Tal vez te refieras a las fases > > previas a la publicación y no a los documentos ya *PUBLICADOS* (como > remarco > > en mi correo original, justo debajo de esta misma línea). > > Si bueno esto regresa al punto que solo por que lo escribiste en una > guia, no quiere decir que alguien lo leyo. Como te puse de ejemplo, el > wiki aun mucha gente no respeta las convenciones. Lo mas que podemos > apuntar, es hacerla presente al navegante y que sea sencilla de > entender. > > > > >>> para los documentos *publicados* (ignoro el procedimiento > >>> intermedio, que es el que aquí nos ocupa), creo que la nomenclatura > >>> debe ser similar, con los atributos justos para que cualquiera > >>> pueda tener constancia del contenido y estado del documento > >>> atendiendo sólo al nombre del mismo. Por eso, propongo > >>> > >>> <CODIGO>-ES-XX-Nombreingles.odt > >> > >> No lo veo necesario usualmente el codigo es sifuciente para > >> asociarlo con la fuente original. el 'es' se asume al estar en la > >> carpeta de oooauthors.org/es ya que no se tiene ningun documento en > >> algun otro idioma en todo el arbol de 'Español'. > > > > > > Te vuelvo a remitir al correo anterior donde explico el uso de un buen > > sistema aplicable a cualquier equipo. > > > > > >>> Quedarían los detalles de la "plantilla" para los créditos, pero > >>> ahora ya es muy tarde y creo que lo principal ya está expuesto. En > >>> fin, espero que no se os haga muy pesado y que entre todos podamos > >>> mejorar la documentacion. > >> > >> Uff creo que la mayoria de lo que comentas ya esta. Solo que mas > >> sencillo y mucho mas corto. El sobre documentar creo que es algo > >> bastante tedioso e inutil y hasta contraproducente. Como puse con el > >> wiki de OOo, pocos voluntarios no editan, por que prefieren que > >> 'alguien que sepa' les diga que hacer o donde contribuir. Poca gente > >> lee la ayuda por que no sabe que buscar o como buscarlo, o > >> simplemente no se hacen de tiempo para ponerse a leer la ayuda y > >> prefieren contribuir. > > > > > > Entiendo que seguramente la idea esté subyacente en nuestras mentes, pero > > echo en falta muchos detalles del supuesto procedimiento que no se > reflejan > > en la documentación y que no son tan intuitivos como alguno podría > pensar. > > Como ya he dicho antes, quitando profundidad en muchas explicaciones, no > > sería complicado generar un manual detallado y, sobre todo, útil a la > hora > > de afrontar los distintos procesos de traducción de documentos. > > > > > > Saludos. > > > > > > -- > > |----------------------------------------------------------------------| > > | http://counter.li.org info: Linux user: 92390 - Linux machine: 39301 | > > | Oscar Manuel Gómez Senovilla - omgsATescomposlinux.org | > > | GPG Key at http://keyserver.pgp.com | > > |----------------------------------------------------------------------| > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > > -- > Alexandro Colorado > OpenOffice.org Español > http://es.openoffice.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Miguel Angel Frías Bonfil *InventMX <http://inventmx.com/>, Web Designer, Developer, OSUM Leader* *9932350805* · [email protected] "El éxito se logra haciendo las cosas bien durante mucho tiempo." “*Lo escuché y lo olvidé, lo vi y lo entendí, lo hice y lo aprendí*”. [image: skype] [image: facebook]<http://facebook.com/miguelangelfriasbonfil> [image: twitter] <http://twitter.com/miguelmafb> [image: linkedIn]<http://mx.linkedin.com/pub/miguel-angel-fr%C3%ADas-bonfil/14/175/5a3/>
