Mesas de Trabajo - JSL06 Agosto 20 de 2006 Popayán, Cauca
Estas son las notas tomadas por Alerios, las notas de Claudia, secretaria oficial están en JSL2006/log20agosto.
---
Temas:
I. Infraestructura común para la comunidad.
II. Brazo legal para la comunidad.
III. El relevo generacional y la extinción de los GULs.
---
I. Infraestructura común para la comunidad.
Se planteó la necesidad de contar con una infraestructura de Internet común para la comunidad, que sirviera para alojar los recursos de envergadura nacional y los recursos de grupos y proyectos que requieran este tipo de apoyo.
Los recursos de envergadura nacional comprenderían inicialmente los siguientes:
-Lista de correo Colibrí.
-El-Directorio.org
-Lista nacional de correo para soporte técnico.
-Difusión de video y audio.
-Recursos de proyectos y comunidades nacionales.
-Planeta de bitácoras.
Se propuso y fue acogida en consenso una lista mínima de requerimientos que deberían tener las máquinas que harán parte de esta infraestructura nacional:
1. Deben tener un buen porcentaje de disponibilidad, tanto de la máquina como de su acceso a Internet.
2. Deben tener un buen soporte técnico, de tal forma que el administrador o sus suplentes puedan ser contactados por correo, chat irc o teléfono en un plazo máximo de doce (12) horas.
3. Deben ofrecer un alto grado de control de acceso a las tareas administrativas necesarias para dar soporte a los servicios, con el mínimo de intermediarios posible.
Las máquinas que fueron ofrecidas inicialmente para ser parte de la infraestructura fueron:
-Tortugacha del GLUC. Administrada por Santiago Ruano Rincón(santiago), con dos suplentes: Alejandro Ríos Peña(alerios) y Manuel Alejandro Cerón Estrada(ceronman).
-Máquina de Altred. Administrada por Fernando (Klepper), con (ManuelJ) como suplente.
-Máquina de Ederaam. Administrada por Eder Acevedo (Ederaam), con (NeoEcos) como suplente.
Con el fin de tener unas directrices claras sobre el tipo de proyectos y comunidades que se pueden alojar en esta infraestructura común se definió un comité que redactará el documento base. El comité está conformado por:
-Fernando Quintero (nonroot)
-Oscar Díaz(dargor)
-Felipe Iguita.
También se decidió consultar con Alejandro Forero (azul) sobre la situación actual de la lista de correo Colibrí y la posibilidad de migrarla a la infraestructura común. De esto se encargarían Offray Luna (offray) y Manuel Cerón (ceronman) en un término de 2 semanas.
Los administradores de las máquinas se responsabilizaron a coordinar el montaje de los servicios, los espejos y las copias de seguridad necesarias, de tal forma que la infraestructura quede totalmente establecida antes de finalizar el año 2006.
---
II. Brazo legal para la comunidad.
Se retomó el asunto de la necesidad de un ente legal que represente los intereses de la comunidad nacional del software libre y la libre cultura frente al Estado, la academia, la empresa y la comunidad.
Las principales necesidades de representación son las siguientes:
-Poder de negociación frente a iniciativas legales y gubernamentales relacionadas con el software libre y la libre cultura.
-Defensa legal del conocimiento libre ante posibles amenazas de personas naturales o jurídicas que estén violando las licencias que lo protegen.
-Agremiación, defensa y promoción de los profesionales y empresas relacionadas con el software libre y la libre cultura en el país.
-Gestión de recursos financieros para eventos y proyectos de la comunidad nacional del software libre y la libre cultura.
Se informó que algunas personas ya habían venido trabajando en la creación del ente y hasta el momento estaban trabajando en el wiki http://prolibrecultura.org:8080
También se informó que Altred venía trabajando en una iniciativa similar.
Se puso en manifiesto el hecho de que era posible que ya existiera un ente legal que pudiera suplir estas necesidades, sin tener que construir uno nuevo desde cero.
Se decidió que en un plazo de tres semanas, Alejandro Ríos Peña(alerios) haría una exploración del estado del arte de este tipo de entidades para determinar si la comunidad se adhiere a una existente o si se decide la creación de una nueva.
En cualquier caso, se recolectará una cuota para participar en la estructuración o fortalecimiento de esta figura legal, cuyo valor será determinado y recogido por Offray Luna (offray) en un plazo de un mes.
---
III. El relevo generacional y la extinción de los GULs.
Se planteó la preocupación general de los asistentes respecto a la masiva caída de muchos de los grupos linux del país, especialmente Universitarios y en su mayoría debido a problemas durante el relevo generacional de cada grupo.
Se estudiaron varios casos de los grupos en crisis, de los ya desaparecidos y de los sobrevivientes para analizar la problemática y encontrar algunas soluciones.
A través de una amplia discusión e intercambio de ideas, se fueron determinando una serie de "Buenas Prácticas" donde se condensan las cosas que puede hacer un grupo linux para asegurar su continuidad:
1. Es importante hacer todo lo posible por preservar el nombre y la trayectoria que ha ganado el grupo, se debe aceptar el relevo generacional y hacer todo lo posible por preservar el grupo con su mismo nombre.
2. Es indispensable asegurar un espacio físico exclusivo para el grupo y con recursos suficientes para trabajar.
3. Se debe utilizar un lenguaje amable e incluyente con los nuevos integrantes del grupo, fomentando su espíritu de investigación y autoaprendizaje (al estilo del código de conducta de Ubuntu).
4. Se deben tener muy en cuenta las consideraciones de género dentro del grupo. Se debe hacer todo lo posible por fomentar la participación de las mujeres dentro de la comunidad del software libre.
5. Se debe promover una estrecha relación con los profesores de la universidad, apoyando sus iniciativas respecto al software libre y llegando a acuerdos sobre su utilización en las materias.
6. En el caso de que la nueva generación quiera hacer un nuevo grupo o varios nuevos grupos, con otros nombres, es importante especificar que el nuevo grupo es una evolución del anterior y dejar muy en claro el lazo que los une, con el fin de dar continuidad al trabajo realizado dentro de la institución o ciudad.
7. Se debe mantener un equilibrio entre los procesos de difusión del software libre y los procesos de desarrollo y colaboración directa con el software libre. No se pueden descuidar los dos aspectos y se tiene que buscar apoyo en la comunidad para las actividades más desgastantes. Por ejemplo: en lugar de hacer festivales de instalación aislados, hacerlos como parte del FLISOL; en lugar de preparar charlas con alta periodicidad, unirse al ciclo nacional de Vive la Vida Linux a través de streaming u otros medios.
8. Se deben fomentar los grupos de interés en tecnologías o proyectos particulares, como Debian-Colombia, GNOME-Colombia, Python-Colombia, etc.
9. Se deben documentar y socializar todos los procesos, proyectos e iniciativas del grupo, para futura referencia y para que no se pierda la experiencia sensible intransferible.
10. Es muy importante que el grupo lleve un "Libro Rojo" donde consigne toda su trayectoria, especialmente lo que ha hecho en representación de su institución, con el fin de utilizarla en momentos de obtener patrocinio por parte de la misma.
11. Se debe diseñar e implementar un plan de contingencia con copias de seguridad para preservar la documentación del grupo, apoyándose en la infraestructura común de la comunidad.
12. Es indispensable hacer lo que esté al alcance para lograr la participación del grupo en varios eventos de software libre a nivel nacional pues está demostrado que esto revitaliza el grupo y la comunidad y genera una gran motivación para todos.
13. Se debe estimular el trabajo de los integrantes destacados del grupo y de la comunidad, a través de premios, concursos, etc.
14. Se necesita el apoyo de un brazo legal nacional que de soporte a los grupos que no puedan encontrar suficiente apoyo en sus instituciones locales.
15. Se debe promover la realización y participación en un concurso nacional de programación y proyectos de software libre.
Finalmente se determinó que en dos (2) meses se realizaría un piloto de realización de un VLVL (Vive la Vida Linux) a través de streaming con la infraestructura común.