Saltar a contenido

Gobernanza

Las abejas trabajadoras del Equipo central tienen una serie de responsabilidades para mantener en marcha la colmena que es BeeWare. Se trata de un proyecto en constante evolución, por lo que esta página está sujeta a cambios.

Estas tareas incluyen, entre otras, responder a los problemas, revisar y la fusión de código, tutoría nuevos contribuyentes, y la arquitectura de la proyecto BeeWare en su conjunto.

Hay personas en las que confiamos para tomar decisiones sobre el código; hay personas en las que en las que confiamos para tomar decisiones sobre el código y la organización. que guía la visión de toda la organización, y a la que se le confía tomar una decisión final si la comunidad no puede llegar a un consenso.

Antigüedad en el equipo

Los diferentes niveles de antigüedad en el proyecto BeeWare son:

Abeja, o abeja obrera

Cualquier miembro de la comunidad BeeWare. Dado que trabajamos de forma abierta en GitHub, cualquiera puede sugerir cambios en el código y fusionar su código. El único límite a tu capacidad de contribuir es que un miembro del equipo con los derechos necesarios fusione tu trabajo.

Apiarist

Una abeja que ha sido reconocida como colaboradora de confianza. Estas abejas han demostrado su capacidad en relación con una parte específica del proyecto BeeWare durante un periodo de tiempo. Esto podría ser a nivel técnico (conocimientos de JavaScript, Python, Objective-C; conocimientos de GTK+, macOS) o a otro nivel (gestión de la comunidad, revisión de código). Los apicultores también pueden tener el bit de compromiso para el proyecto en el que se reconoce su experiencia.

Apicultores expertos

Apicultores con acceso elevado en GitHub, y también con un nivel adicional de responsabilidad para supervisar el proyecto en su conjunto. Pueden tomar decisiones arquitectónicas, pero en última instancia responden ante la BDFN.

Dictador benevolente por ahora (BDFN)

Una versión del Dictador Benévolo Vitalicio, la responsabilidad de la dirección y las decisiones del proyecto recae en última instancia en el BDFN. El uso de «por ahora» en lugar de «vitalicio» hace referencia al tema de Django de no someter las responsabilidades del mantenedor principal a toda la vida natural de una persona. La vida existe fuera del código abierto, y el equilibrio entre el código y la vida, así como el bienestar general, son aspectos muy importantes a tener en cuenta.

El BDFN de BeeWare es Russell Keith-Magee.

Apicultor fundador

El hombre que se paró por primera vez en una colina y vio un yak que necesitaba ser esquilado. Este papel nunca cambia y continúa ad infinitum; sin embargo, no transfiere inherentemente ningún poder adicional en la organización. En la actualidad, el apicultor fundador es también el BDFN, pero esto puede cambiar con el tiempo.

Directrices (no normas propiamente dichas)

Como en cualquier proyecto con más de una persona con derechos de commit, hay hay una serie de directrices generales que el equipo debe seguir:

  • Ser una buena representación del proyecto ante la comunidad en general
  • Trata con respeto todas las consultas y contribuciones a cualquier proyecto de BeeWare.
  • Asume que todo el mundo tiene buenas intenciones, aunque no hayan elegido bien sus palabras.
  • Supongamos que si alguien ha hecho algo «mal», es porque hemos fallado en la comunicación del proceso.
  • Asume que cualquier expresión de enfado o frustración proviene de un deseo genuino de utilizar una herramienta o biblioteca de BeeWare.
  • Anime a otros miembros de la comunidad a reflejar estos ideales en sus propias comunicaciones, tanto dentro como fuera de la comunidad BeeWare.
  • Ningún apicultor debe comprometer su propio código.
  • Excepción: «Hay algo que no funciona bien y hay que arreglarlo ahora mismo».
  • Excepción: BDFN (esto puede cambiar en el futuro)
  • Todo el código enviado para su revisión por un miembro del equipo central debe ser revisado por otro miembro del equipo.
  • Excepción: BDFN (esto puede cambiar en el futuro)
  • Todo el código debe superar las pruebas de integración continua antes de fusionarse.
  • Excepción: código que se sabe que está dañado y que debe confirmarse por otros motivos.
  • Excepción: código en un repositorio con pruebas de CI insuficientes.
  • Excepción: Es mejor trabajar y comprometerse que ser perfecto y no hacerlo.
  • Los procesos de aceptación deben automatizarse siempre que sea posible.
  • Esto incluye pruebas, linting, revisión ortográfica, cobertura y mucho más.

Convertirse en apicultor

La introducción de un nuevo apicultor en el equipo queda a la entera discreción del Equipo Central existente. Aunque actualmente no hay reglas para esto, en general, alguien será invitado a ser un Apiarist en un BeeWare si ha demostrado una sólida contribución al proyecto. al proyecto. Esto también puede extenderse a alguien con conocimientos (por ejemplo, iOS/macOS) que podría faltar en el equipo existente. equipo existente. Tampoco tiene por qué basarse en commits. Cualquiera que pueda demostrar un interés personal en el proyecto en general puede pedir permiso para comprometerse con el proyecto.

Todos los nuevos apicultores serán «iniciados» (a falta de una palabra mejor) en los valores fundamentales y las directrices del proyecto. Se puede encontrar un resumen de los valores fundamentales en la página «Acerca de». Se espera que cualquier persona que se una al equipo defienda esos valores y contribuya a los debates sobre su evolución a lo largo del tiempo.

No se espera que ningún apicultor, nuevo o veterano, sea el único encargado de mantener cualquier cosa. Hay muchos apicultores, y muchos más al lado que pueden ofrecer ayuda, consejo y tutoría.

¿«Bit de compromiso»?

En los sistemas Unix, un único bit en un archivo se utiliza para denotar el permiso para ejecutar un archivo. En los sistemas de control de código fuente, existe un bit similar para para denotar la capacidad de fusionar código. Decir que alguien tiene el "commit bit" significa que tiene acceso de escritura a una base de código. En términos de GitHub, esto significa que tienen la capacidad de fusionar Pull Requests y confirmar código directamente a el proyecto.