Gobernanza¶
Las abejas trabajadoras del Equipo central tienen un número de responsabilidades para mantener en marcha la colmena que es BeeWare. Se trata de un proyecto en constante evolución, tal que esta página está sujeta a cambios.
Estas tareas incluyen, entre otras, responder a las incidencias, revisar y fusionar el código, la tutoría de contribuyentes nuevos, y la arquitectura de la proyecto BeeWare como un todo.
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; y hay una persona quien 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 del 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 tener nuestro trabajo fusionado por un miembro del equipo con los derechos para hacerlo.
Apicultor¶
Una abeja quien ha sido reconocida como un colaborador de confianza. Estas abejas han demostrado su habilidad 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 confirmación para el proyecto en el que se reconoce su experiencia.
Apicultores expertos¶
Los 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 reglas actuales)¶
Como en cualquier proyecto con más de una persona con derechos de confirmación, hay un número directrices generales que el equipo debería seguir:
- Ser una buena representación del proyecto ante la comunidad más amplia
- Trata con respeto todas las consultas y contribuciones a cualquier proyecto de BeeWare
- Asume que todo el mundo tiene buenas intenciones, incluso si 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/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 confirmaría 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 apicultor nuevo 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. Esto también puede extenderse a alguien con conocimientos (por ejemplo, iOS/macOS) que podría faltar en el equipo existente. Tampoco tiene por qué basarse en comprometer. Cualquiera que pueda demostrar un interés personal en el proyecto en general puede pedir permiso para comprometer con el proyecto.
Todos los apicultores nuevos 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, asesoramiento y mentoría.
¿«Bit de confirmación»?¶
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 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.