Discusión:Organización de Mozilla Hispano
De Mozilla Hispano - Documentación
Puedes añadir tu comentario usando el símbolo + en la barra de enlaces de edición de este artículo.
Índice de contenido |
[editar] Comentarios
En un apartado u otro, podríamos usar este wiki para elaborar los siguientes puntos y no bombardearnos continuamente con el correo:
- Licencias usadas en el proyecto
- Organización del proyecto
En el primer punto debemos discutir las licencias usadas para el conjunto del sitio (digamos la "licencia por defecto" si no especificamos otra), la licencia para el wiki (por ahora, se proponen GFDL o CC-by-sa, commercial o non-commercial también está por decidir), y la licencia para los foros (se proponen dominio público o CC-by-sa).
En el segundo punto la organización del proyecto: áreas en que se dividirá, cometidos y estructura jerárquica de éstas, sistema de renovación/confirmación de cargos, mecanismos objetivos para obtener derechos de voz y voz+voto, etc. -- Ricardo
[editar] Licencias y organización
Sobre la licencia, a mi parecer, tras leer algunas opiniones creo que la que se podría adaptar para todo (noticias, documentación y foro) es la Creative Commons 3.0 by-sa -- Nukeador
Las discuciones en el foro sugieren que podemos dar por consensuado el uso de esta licencia, así que la traslado al artículo. --Rpalomares 21:07 22 sep 2007 (CEST)
[editar] Organización
La organización de Mozilla Hispano se estructura en un conjunto de áreas del proyecto a las que se adscriben los colaboradores.
[editar] Consideraciones generales
- Cada área tendrá un responsable y un número variable de colaboradores.
- Preferiblemente, se evitará que un mismo colaborador sea responsable de varias áreas.
- El papel del responsable es definir tareas, priorizarlas para obtener el mejor avance posible y revisar su ejecución. También puede colaborar para impulsar la ejecución en sí misma, pero no debería ser su tarea principal.
- El responsable tiene la decisión final en caso de conflicto. Las decisiones tomadas en aplicación de este punto deberán ser consecuentes con el objetivo anterior de procurar el mejor avance posible en el área.
- Los puestos de responsable se elegirán anualmente. Los colaboradores que ostenten un puesto de responsabilidad podrán presentarse a la re-elección. En la elección de cada área votarán todos los miembros con derecho a voto del proyecto, sin que sea posible limitar el censo de un área a los colaboradores de esa área.
Puntos por resolver en este apartado:
- ¿Cómo se califica un colaborador como miembro con derecho a voto? En Wikipedia se cuentan las ediciones de artículos de un colaborador. Para los foros se podrían contar las intervenciones, quizá dando distinto valor a las actuaciones de limpieza de spam, respuestas con material, respuestas con remisión a Preguntas Frecuentes, etc. En el apartado de noticias se puede contar por noticia publicada y tiempo de respuesta respecto de la noticia original. El control no tiene por qué ser exhaustivo, excepto si alguien planteara dudas sobre la legitimidad del derecho a voto de otro miembro.
- ¿Es un año el mejor plazo para re-elecciones?
[editar] Áreas
- Administración técnica: acceso maestro al alojamiento, control de bases de datos, espacio en disco, consumo de ancho de banda y CPU, instalación, configuración y gestión de módulos, y apoyo a responsables de otras áreas en gestión de los módulos correspondientes.
- Foros y listas de correo: definición de las jerarquías de foros y listas de correo, asignación de roles de moderación a colaboradores más activos, moderación de foros, respuestas a las consultas.
- Documentación: control y organización del wiki de documentación, revisión de colaboraciones de otros miembros, elaboración y mantenimiento de preguntas frecuentes, incorporación de respuestas a preguntas frecuentes producidas en foros y listas de correo. Elaboración de tutoriales.
- Noticias: recopilación y traducción de noticias de fuentes de la comunidad Mozilla en inglés (Mozilla Foundation, Mozilla Links, equipos de traducción), actualización de últimas versiones de productos en portada, organización de reuniones periódicas en IRC.
[editar] Colaboradores y colaboraciones
Cualquier colaborador debería poder proponer mejoras en cualquier área del proyecto y estas deberían ser votadas por todos los miembros activos con derecho a voto. En caso de empate el voto del responsable del área en cuestión sería de calidad. Para decisiones importantes del proyecto debería tenerse mayoría absoluta para realizarlas, las actuaciones menores sobre un área en concreto podrían aplicarse con mayoría simple.
Hay que intentar por todos los medios que no se puedan aplicar actuaciones simplemente por que el responsable o porque una minoría no quiere.
La elección de responsables creo que debería ser en un periodo menor, un año me parece mucho.
Habría que distinguir miembros activos y miembros ausentes, esto es, que todos los colaboradores tienen derecho a ausentarse por un tiempo determinado (a definir) del proyecto por los motivos que sean, reservándosele durante este tiempo su estatus de colaborador (no de responsable). Si es un responsable el que quiere ausentarse, habría que votar un nuevo responsable de sección para sustituirle, y el antiguo responsable perdería su estatus, pudiéndolo recuperar si es elegido en las siguientes votaciones. -- Nukeador
[editar] Sobre las votaciones
El problema de esta idea:
Cualquier colaborador debería poder proponer mejoras en cualquier área del proyecto y estas deberían ser votadas por todos los miembros activos con derecho a voto
es que puede imponer a un responsable tareas en su área, vaciando así de contenido el papel de responsable o, peor aún, haciéndole cargar con tareas que no quiere asumir. En esas condiciones, habrá poca motivación para liderar un área, excepto llegar, hacer lo que a uno le gusta, y marcharse cuando la mayoría le quiera imponer algo que no le gusta (lo cual puede ser terrible, si quien se va es el único que tiene el conocimiento necesario para hacer funcionar eso que ha hecho).
Mi idea es que, quien se haga cargo de un área, tenga margen de maniobra temporal para decidir qué hacer y qué no hacer, con la perspectiva de que cada cierto tiempo se evaluará lo que ha hecho y lo que no. Específicamente, el veto debería tenerlo para añadir cosas; en ningún caso se debería poder eliminar una funcionalidad en un área sin mayoría absoluta de los miembros del proyecto.
Al llegar el momento de la votación, si el responsable ha rechazado ideas muy bonitas pero que requieren mucho esfuerzo sin un número razonable de voluntarios, o simplemente ideas descabelladas, no debería tener problema en revalidar su cargo. A su vez, quien propone esas ideas se verá así estimulado a ofrecer, además de una idea, un compromiso en sacarla adelante. Los registros de foros, listas de correo o wiki deberían servir para hacer un juicio justo.
En cuanto al periodo entre votaciones, hay que encontrar un equilibrio adecuado. Un año puede ser mucho si alguien bloquea ideas de manera irrazonable, pero habrá que evaluar el coste de organizar un proceso de votación. Posiblemente requiramos varios ajustes, de manera que quizá sea interesante comenzar con seis meses (¿menos incluso?) y aprender de la experiencia.
Lo que me recuerda un punto más que había olvidado en la consideraciones generales y que es muy importante: establecer mecanismos para variar estas normas. Si se establece la norma de que las propuestas de mejora se tienen que votar por todos (o la contraria, que el responsable tiene plenos poderes en su área) y la práctica demuestra que no es operativa, hay que tener claro qué mayoría hace falta para cambiarla de una manera transparente e incontestable.
Hay que definir muchas más cosas: qué hacer con áreas que se quedan sin responsable, número de miembros mínimo para tomar decisiones, plazos y mecanismos de votación, miembros con voz pero sin voto, etc. Vayamos por partes. :-) --Rpalomares 21:05 17 jul 2007 (CEST)
[editar] Re: Sobre las votaciones
> Mi idea es que, quien se haga cargo de un área, tenga margen de maniobra temporal para decidir qué hacer y qué no hacer, con la perspectiva de que cada cierto tiempo se evaluará lo que ha hecho y lo que no. Específicamente, el veto debería tenerlo para añadir cosas; en ningún caso se debería poder eliminar una funcionalidad en un área sin mayoría absoluta de los miembros del proyecto.
> Al llegar el momento de la votación, si el responsable ha rechazado ideas muy bonitas pero que requieren mucho esfuerzo sin un número razonable de voluntarios, o simplemente ideas descabelladas, no debería tener problema en revalidar su cargo. A su vez, quien propone esas ideas se verá así estimulado a ofrecer, además de una idea, un compromiso en sacarla adelante. Los registros de foros, listas de correo o wiki deberían servir para hacer un juicio justo.
Visto así me parece entonces el procedimiento correcto
> En cuanto al periodo entre votaciones, hay que encontrar un equilibrio adecuado. Un año puede ser mucho si alguien bloquea ideas de manera irrazonable, pero habrá que evaluar el coste de organizar un proceso de votación. Posiblemente requiramos varios ajustes, de manera que quizá sea interesante comenzar con seis meses (¿menos incluso?) y aprender de la experiencia.
Podríamos empezar con seis meses si os parece bien.
> Lo que me recuerda un punto más que había olvidado en la consideraciones generales y que es muy importante: establecer mecanismos para variar estas normas. Si se establece la norma de que las propuestas de mejora se tienen que votar por todos (o la contraria, que el responsable tiene plenos poderes en su área) y la práctica demuestra que no es operativa, hay que tener claro qué mayoría hace falta para cambiarla de una manera transparente e incontestable.
Para cambiar las normas que acordemos creo sería justo que fuera por mayoría absoluta.
> Hay que definir muchas más cosas: qué hacer con áreas que se quedan sin responsable, número de miembros mínimo para tomar decisiones, plazos y mecanismos de votación, miembros con voz pero sin voto, etc. Vayamos por partes
Uhm, en las áreas sin responsables creo que lo mejor sería llevarlas entre varios colaboradores que deseen ayudar, a la hora de tomar decisiones sobre ese área, deberían de votar todo ellos para ponerse de acuerdo (mayoría simple). Esto es, como si los X colaboradores formaran un responsable, pero teniendo que consensuar todo lo que hagan entre ellos.
Mecanismos de votación: Podría ser perfectamente una lista de correo interna de colaboradores activos.
Miembros con voz pero sin voto: Creo que todos los usuarios del portal tienen voz pero no voto.
-- Nukeador
