Los objetivos de este documento incluyen la formalización de la gobernanza del proyecto Open Science Labs (OSL). Tanto en las situaciones comunes como en las infrecuentes, perfilar el procedimiento de toma de decisiones y las interacciones entre los distintos miembros de la comunidad, incluyendo la relación entre el trabajo que puede ser apoyado por organizaciones con o sin ánimo de lucro y el desarrollo colaborativo de código abierto.
OSL es un proyecto de propiedad y gestión comunitaria. En la medida de lo posible, las decisiones sobre la dirección del proyecto se toman por consenso de la comunidad (pero hay que tener en cuenta que "consenso" aquí tiene un significado un tanto técnico que puede no coincidir con las expectativas de todo el mundo — ver más abajo). Algunos miembros de la comunidad contribuyen adicionalmente sirviendo en OSL (Eunice Rodas, Ever Vino, Ivan Ogasawara, Luis Casas), son responsables de facilitar el establecimiento del consenso de la comunidad, de administrar los recursos del proyecto, y — en casos extremos — de tomar las decisiones del proyecto si el proceso normal basado en la comunidad se rompe.
Por lo general, cada uno es responsable de áreas o tareas específicas y, si hay algo que debe ser decidido por el grupo, esta persona trae este tema a una de nuestras reuniones de colaboradores y podemos discutirlo y decidirlo juntos. El principal criterio que tenemos y que debe respetarse es que el contenido debe estar relacionado con un tema "abierto" (no se permiten tecnologías privadas, por ejemplo), y el acceso a esa información también debe ser abierto (tampoco se permiten referencias a contenido privado). Por lo tanto, tratamos de tener un espacio abierto para que todo el mundo aporte sus ideas y tener también el espacio para poner en práctica esa idea, el consejo directivo primer objetivo principal es ayudar a los contribuyentes a compartir sus ideas antes de ponerlo en práctica.
Open Science Labs (OSL) es una comunidad que pretende unir a personas de todas partes del mundo, especialmente de países de América Latina y crear un espacio abierto para enseñar, aprender y compartir temas en torno a la ciencia abierta y las herramientas computacionales abiertas.
OSL también motiva iniciativas sobre el idioma inglés porque aumenta las posibilidades de colaboración en proyectos abiertos en todo el mundo.
El software desarrollado por las iniciativas OSL se libera bajo alguna licencia aprobada por la OSI (como BSD, Apache 2.0 o MIT), se construye abiertamente y se aloja en repositorios públicos de GitHub bajo la organización OpenScienceLabs.
El Proyecto es conducido por un equipo distribuido de contribuyentes, que son individuos que han colaborado con código, documentación, diseño gráfico u otro tipo de trabajo al Proyecto. Cualquiera puede ser un Contribuyente. Los colaboradores pueden estar afiliados a cualquier entidad legal o a ninguna. Los colaboradores participan en el proyecto enviando, revisando y discutiendo las solicitudes de extracción y los problemas en GitHub y participando en las discusiones abiertas y públicas del proyecto en GitHub, discord, entre otros canales. La base de la participación en el proyecto es la apertura y la transparencia.
La Comunidad del Proyecto está formada por todos los Colaboradores y Usuarios del Proyecto. Los colaboradores trabajan en nombre de la Comunidad del Proyecto y son responsables ante ella, y nos esforzamos por mantener la barrera entre los colaboradores y los usuarios lo más baja posible.
Con el fin de mejorar la transparencia y un mejor flujo de trabajo fiscal, OSL está buscando actualmente un patrocinador fiscal para ayudar a nuestro proyecto a crecer.
Esta sección describe el modelo de gobernanza y liderazgo del Proyecto.
Los principios de la gobernanza del Proyecto son
Apertura y transparencia
Contribución activa
Neutralidad institucional
Diversidad, equidad e inclusión
Educación
En general, todas las decisiones del proyecto se tomarán por consenso de todos los colaboradores interesados. El objetivo principal de este enfoque es garantizar que las personas más afectadas e implicadas en un cambio determinado puedan aportar sus conocimientos con la confianza de que sus voces serán escuchadas, ya que la revisión reflexiva de una amplia comunidad es el mejor mecanismo que conocemos para crear software de alta calidad.
El mecanismo que utilizamos para lograr este objetivo puede resultar desconocido para aquellos que no tienen experiencia con las normas culturales en torno al desarrollo de software libre/de código abierto. Ofrecemos un resumen aquí, y recomendamos encarecidamente que todos los colaboradores lean además el capítulo 4: Infraestructura social y política del clásico de Karl Fogel Producing Open Source Software, y en particular la sección sobre Democracia basada en el consenso, para una discusión más detallada.
En este contexto, el consenso NO requiere
- que esperemos a solicitar la opinión de todos sobre cada cambio,
- que se celebre una votación sobre algo, o
- que todo el mundo esté contento o de acuerdo con cada decisión.
Para nosotros, consenso significa que confiamos a todos el derecho a vetar cualquier cambio si lo consideran necesario. Aunque esto pueda parecer una receta para la obstrucción y el descrédito, no es lo que ocurre. Por el contrario, descubrimos que la mayoría de la gente se toma en serio esta responsabilidad y sólo invoca su veto cuando juzga que se está ignorando un problema grave y que su veto es necesario para proteger el proyecto. Y en la práctica, resulta que esos vetos casi nunca se invocan formalmente, porque su mera posibilidad garantiza que los colaboradores estén motivados desde el principio para encontrar alguna solución con la que todo el mundo pueda vivir, — cumpliendo así nuestro objetivo de garantizar que se tengan en cuenta todas las perspectivas interesadas.
¿Cómo sabemos cuándo se ha alcanzado un consenso? En primer lugar, esto es bastante difícil, ya que el consenso se define por la ausencia de vetos, lo que nos obliga a demostrar de alguna manera una negativa. En la práctica, utilizamos una combinación de nuestro mejor juicio (por ejemplo, una simple y no controvertida corrección de errores publicada en GitHub y revisada por un desarrollador del núcleo es probablemente buena) y los mejores esfuerzos (por ejemplo, todos los cambios sustantivos de la API deben ser publicados en un tema de github o una discusión en discordia con el fin de dar a la comunidad en general la oportunidad de detectar cualquier problema y sugerir mejoras; asumimos que cualquier persona que se preocupe lo suficiente por OSL para invocar su derecho de veto debe estar en los repositorios de github OSL o discordia). OSL, es un grupo pequeño, y busca una comunicación rápida y transparente, por lo que los canales comunes de comunicación son los issues de github y los canales de discord. Así, todas las personas involucradas pueden tener una comunicación rápida y transparente sobre cualquier problema específico y podemos reaccionar muy rápido.
Si es necesario invocar un veto formal, el proceso debe consistir en:
- una declaración inequívoca de que se invoca el veto,
- una explicación de por qué se invoca, y
- una descripción de las condiciones (si las hay) que convencerían a la persona que ejerce el veto de retirarlo.
Si se vetan todas las propuestas para resolver alguna cuestión, entonces el estatus quo gana por defecto.
En el peor de los casos, si un colaborador hace un uso realmente abusivo de su veto en detrimento del proyecto, puede ser expulsado del mismo por consenso del Consejo de Dirección (— véase más adelante).
El proyecto contará con un Consejo de Dirección formado por los colaboradores del proyecto que hayan realizado contribuciones sustanciales en calidad y cantidad, y que se mantengan durante al menos un año. La función general del Consejo es garantizar, con las aportaciones de la Comunidad, el bienestar a largo plazo del proyecto, tanto desde el punto de vista técnico como comunitario.
Durante las actividades cotidianas del proyecto, los miembros del Consejo participan en todas las discusiones, la revisión del código y otras actividades del proyecto como compañeros con todos los demás colaboradores y la Comunidad. En estas actividades cotidianas, los miembros del Consejo no tienen ningún poder o privilegio especial por su pertenencia al Consejo. Sin embargo, se espera que, debido a la calidad y cantidad de sus contribuciones y a su conocimiento experto del software y los servicios del proyecto, los miembros del Consejo proporcionen una orientación útil, tanto técnica como en términos de dirección del proyecto, a los contribuyentes potencialmente menos experimentados.
El Consejo de Dirección y sus miembros desempeñan un papel especial en determinadas situaciones. En particular, el Consejo puede, si es necesario:
- Tomar decisiones sobre el alcance, la visión y la dirección general del proyecto.
- Tomar decisiones sobre colaboraciones estratégicas con otras organizaciones o individuos.
- Tomar decisiones sobre cuestiones técnicas específicas, características, errores y pull request. Son el principal mecanismo para guiar el proceso de revisión del código y fusionar los pull request.
- Tomar decisiones sobre los servicios que se ejecutan en el proyecto y gestionar esos servicios en beneficio del proyecto y la comunidad.
- Actualizar los documentos de política como éste.
- Tomar decisiones cuando la discusión regular de la comunidad no produce un consenso sobre un tema en un marco de tiempo razonable.
Sin embargo, la principal responsabilidad del Consejo es facilitar el procedimiento ordinario de toma de decisiones de la comunidad descrito anteriormente. Si alguna vez tenemos que intervenir y anular formalmente a la comunidad por la salud del Proyecto, lo haremos, pero consideraremos que llegar a este punto indica un fallo en nuestro liderazgo.
Si es necesario que el Consejo Directivo tome una decisión formal, utilizará una forma del proceso de votación de la Fundación Apache. Se trata de una versión formalizada del consenso, en la que los votos +1 indican que se está de acuerdo, los votos -1 son vetos (y deben ir acompañados de una justificación, como en el caso anterior), y también se puede votar fraccionadamente (por ejemplo, -0,5, +0,5) si se desea expresar una opinión sin registrar un veto completo. Estos votos numéricos también se utilizan a menudo de manera informal como forma de obtener una idea general de los sentimientos de la gente sobre algún tema, y normalmente no deben tomarse como votos formales. Una votación formal sólo se produce si se declara explícitamente, y si esto ocurre, la votación debe mantenerse abierta durante el tiempo suficiente para dar a todos los miembros del Consejo interesados la oportunidad de responder, al menos una semana.
En la práctica, prevemos que para la mayoría de las decisiones del Consejo Directivo (por ejemplo, la votación de nuevos miembros) será suficiente un proceso más informal.
La lista de los miembros actuales del Consejo Directivo se mantiene en la página Acerca de.
Para poder formar parte del Consejo Directivo, una persona debe ser un colaborador del proyecto que haya realizado contribuciones sustanciales en calidad y cantidad, y que se mantengan durante al menos seis meses. Los miembros potenciales del Consejo son propuestos por los miembros existentes del Consejo, y se convierten en miembros tras el consenso de los miembros existentes del Consejo, y la confirmación de que el miembro potencial está interesado y dispuesto a servir en esa capacidad. El Consejo se formará inicialmente a partir del conjunto de promotores principales existentes que, a finales de 2015, han estado muy activos durante el último año.
Al considerar a los posibles miembros, el Consejo examinará a los candidatos con una visión global de sus contribuciones. Esto incluirá, entre otras cosas, código, revisión de código, trabajo de infraestructura, participación en la lista de correo y en el chat, ayuda/construcción de la comunidad, educación y divulgación, trabajo de diseño, etc. Deliberadamente no establecemos métricas cuantitativas arbitrarias (como "100 commits en este repo") para evitar que se fomente un comportamiento que juegue a favor de las métricas y no del bienestar general del proyecto. Queremos fomentar la diversidad de orígenes, puntos de vista y talentos en nuestro equipo, por lo que explícitamente no definimos el código como la única métrica en la que se evaluará la pertenencia al consejo.
Si un miembro del Consejo permanece inactivo en el proyecto durante un periodo de seis meses, se considerará su retirada del Consejo. Antes de la retirada, se contactará con el miembro inactivo para ver si tiene previsto volver a participar activamente. En caso de que no sea así, se le retirará inmediatamente tras una votación del Consejo. Si tienen previsto volver a participar activamente en breve, se les concederá un período de gracia de un mes. Si no se reincorporan a la participación activa dentro de ese período, serán destituidos por votación del Consejo sin más período de gracia. Todos los antiguos miembros del Consejo pueden volver a ser considerados como miembros en cualquier momento en el futuro, como cualquier otro colaborador del proyecto. Los miembros retirados del Consejo figurarán en la página web del proyecto, reconociendo el periodo en el que estuvieron activos en el Consejo.
El Consejo se reserva el derecho de expulsar a los miembros actuales, si se considera que son activamente perjudiciales para el bienestar del proyecto, y los intentos de comunicación y resolución de conflictos han fracasado. Para ello es necesario el consenso de los miembros restantes.
Se espera que los miembros del Consejo trabajen en una amplia gama de empresas, universidades y organizaciones sin ánimo de lucro. Debido a esto, es posible que los Miembros tengan conflictos de intereses, entre los que se incluyen, pero no se limitan a:
- Intereses financieros, como inversiones, empleo o trabajos de contratación, fuera del Proyecto que puedan influir en su trabajo en el mismo.
- Acceso a información de propiedad de su empleador que podría filtrarse en su trabajo con el Proyecto.
Todos los miembros del Consejo deberán revelar al resto del Consejo cualquier conflicto de intereses que puedan tener. Los miembros que tengan un conflicto de intereses en una cuestión concreta podrán participar en los debates del Consejo sobre dicha cuestión, pero deberán abstenerse de votar sobre la misma.
En la medida de lo posible, las discusiones y actividades del Consejo serán públicas y se harán en colaboración y discusión con los Colaboradores del Proyecto y la Comunidad. El Consejo tendrá un canal privado en discord que se utilizará con moderación y sólo cuando un asunto específico requiera privacidad. Cuando se necesiten comunicaciones y decisiones privadas, el Consejo hará todo lo posible por resumirlas a la Comunidad tras eludir la información personal/privada/sensible que no debería publicarse en Internet.
El Consejo puede crear subcomités que se encarguen de dirigir y orientar aspectos específicos del proyecto. Al igual que el Consejo en su conjunto, los subcomités deben llevar a cabo sus actividades de manera abierta y pública, a menos que se pida específicamente privacidad. Las comunicaciones privadas de los subcomités deben realizarse en el canal principal privado del Consejo en discord, a menos que se solicite específicamente.
El Consejo Directivo es el principal responsable del proyecto. Ninguna institución, individuo o entidad legal externa tiene la capacidad de poseer, controlar, usurpar o influenciar el proyecto más allá de su participación en el mismo como contribuyentes y miembros del Consejo. Sin embargo, dado que las instituciones pueden ser un importante mecanismo de financiación del proyecto, se debe reconocer formalmente la participación institucional en el mismo. Se trata de los Socios Institucionales.
Un colaborador institucional es cualquier colaborador individual del proyecto que contribuye al mismo como parte de sus funciones oficiales en un socio institucional. Asimismo, un miembro del Consejo Institucional es cualquier miembro del Consejo Directivo del Proyecto que contribuye al proyecto como parte de sus funciones oficiales en un Socio Institucional.
Las instituciones pueden convertirse en Socios Institucionales cuando comparten los mismos valores de Open Science Labs y están dispuestas a colaborar con el proyecto de cualquiera de estas maneras:
- dar a conocer los laboratorios de ciencia abierta en su red social
- asignar uno o más colaboradores para ayudar a los proyectos de los Laboratorios de Ciencia Abierta u otros proyectos afiliados
- financiar las actividades de Open Science Labs
- ofrecer tutoría a los Colaboradores de Open Science Labs cuando contribuyan a sus proyectos (definidos por el Socio)
- ofrecer oportunidades de contratación a los Colaboradores de los Laboratorios de Ciencia Abierta que hayan contribuido a sus proyectos (definidos por el Socio)
Si en algún momento un Socio Institucional existente no cumple con estos puntos mencionados anteriormente, entonces se inicia un periodo de gracia de seis meses. Si al final de este período de seis meses siguen sin tener ninguna contribución, entonces su Asociación Institucional caducará, y reanudarla requerirá pasar por el proceso normal para nuevas Asociaciones.
La financiación adquirida por los Socios Institucionales para trabajar en El Proyecto se denomina Financiación Institucional. Sin embargo, ninguna financiación obtenida por un Socio Institucional puede anular el Consejo de Dirección. Si un Socio tiene financiación para realizar un trabajo de Ciencia Abierta y el Consejo decide no continuar con ese trabajo como proyecto, el Socio es libre de llevarlo a cabo por su cuenta. Sin embargo, en esta situación, esa parte del trabajo del socio no estará bajo el paraguas de los Laboratorios de Ciencia Abierta y no podrá utilizar las marcas del proyecto de una manera que sugiera una relación formal.
Los beneficios de los socios institucionales son
- Reconocimiento en los sitios web de Open Science Labs y en las charlas.
- Capacidad de influir en el proyecto a través de la participación de su miembro del Consejo.
- Miembros del Consejo invitados a las reuniones de desarrolladores de Open Science Labs.
Una lista de los actuales Socios Institucionales se mantiene en la página Sobre Nosotros.
Partes sustanciales de este documento han sido adaptadas del documento de gobernanza y toma de decisiones del proyecto NumPy https://github.com/numpy/numpy/commits/main/doc/source/dev/governance/governance.rst.
CC BY-SA 4.0: https://creativecommons.org/licenses/by-sa/4.0/