Aquellas abejas ocupadas en el equipo principal tienen un número de responsabilidades para asegurar que la colmena de BeeWare se mueva. Se trata de una proyecto, por lo que esta página está sujeta a cambios.
Estos incluyen, pero no se limitan a, responder a los problemas, revisar y emerger código, servir de mentores a nuevos colaboradores, y definir la arquitectura del BeeWare proyecto en su conjunto.
Hay gente en la que confiamos para tomar decisiones de código; hay gente en la que confiamos tomar decisiones de código y de organización; y hay una persona que guía al visión de toda la organización, y se le confía para tomar una decisión final si la comunidad no puede llegar a un consenso.
Estos niveles se pueden describir como sigue:
Abeja o abeja trabajadora: - Cualquier miembro de la comunidad BeeWare. Teniendo en cuenta que trabajamos en código abierto en GitHub, cualquier persona puede sugerir cambios en el código y tener su código incluido. El único límite de su capacidad de contribuir es tener su trabajo incluido en el repositorio por un miembro del equipo con los permiso para hacerlo.
Apicultor: - Una abeja que ha sido reconocida como un contribuyente de confianza. Estas abejas tienen capacidad demostrada en relación con una parte específica del proyecto BeeWare un período de tiempo. Esto podría ser en un nivel técnico (JavaScript, Python, Experiencia de Objective-C; GTK +, conocimientos macOS), o en otro nivel (comunidad gestión, revisión de código). Los apicultores también pueden tener el "bit de commit" para el proyecto donde se reconoce su experiencia.
Apicultor Senior: - Apicultores con acceso elevado en GitHub, y también un nivel añadido de responsabilidad de supervisar el proyecto en su conjunto. Ellos son capaces de tomar decisiones de arquitectura, pero en última instancia responder a la BDFN.
Apicultor fundador: Russell Keith-Magee - El hombre que primero se paró en una colina y vio un yak que necesitaba ser afeitado - Este papel nunca cambia, y continúa ad infinitum - Este papel es diferente al papel de la BDFN
Dicatdor benevolente por ahora - BDFN (por sus siglas en inglés): Russell Keith-Magee - Similar al Dictador Benevolente de por Vida, la responsabilidad de la dirección y la toma de las decisiones del proyecto en última instancia recae en el BFDN. El uso de "Por Ahora" en contraposición a "Por la Vida" es referencia al tema de Django de no someter las responsabilidades del mantenedor principal para toda la vida natural de una persona. La vida existe fuera del código abierto, y el equilibrio entre código y vida y bienestar general es una cosa muy importante a tener en cuenta.
Directrices (no las reglas actuales)
Como con cualquier proyecto con más de una persona con permisos de commit, hay un número de directrices generales que el equipo debe seguir:
- Ser una buena representación del proyecto para la comunidad más amplia
- Tratar cada consulta y contribución a cualquier proyecto BeeWare con respeto.
- Suponer que todos tienen buenas intenciones, incluso si no han elegido su palabras bien
- Suponer que si alguien ha hecho algo de la manera "equivocada", es porque hemos fallado en el proceso de comunicación
- Suponer que cualquier expresión de enojo o frustración proviene de un lugar genuino de desear utilizar una herramienta/librería de BeeWare
- Alentar a otros miembros de la comunidad a reflejar estos ideales en su propias comunicaciones, tanto dentro como fuera de la comunidad BeeWare
- Ningún apicultor debe empujar su propio código
- Excepción: "Algo está muy roto y debe arreglarse ahora"
- Excepción: BDFN (esto puede cambiar en el futuro)
- Todo el código sometido a 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 pasar pruebas de integración continua antes de ser emergido
- Excepción: código que se sabe que está roto y debe ser emergido por otras razones
- Excepción: código en un repositorio con pruebas insuficientes de CI
- Excepción: Código trabajando y emergido es mejor que código perfecto y no emergido
- Los procesos de aceptación deben automatizarse siempre que sea posible
- Esto significa pruebas, linting, corrección ortográfica, cobertura, y más.
- Este es un trabajo en curso
Convertirse en apicultor
La inclusión de un nuevo apicultor en el equipo es a la sola discreción de los existentes. Aunque en la actualidad no existen reglas sólidas en general, alguien será invitado a ser apicultor en un proyecto BeeWare si ellos han demostrado sólidas contribuciones al proyecto. Esto también puede extenderse a alguien con conocimiento de dominio específico (por ejemplo, iOS/macOS) que podría faltar en el equipo existente. Tampoco tiene que basarse en número de commits. Cualquier persona que sea capaz de demostrar un interés en el proyecto en general pueden pedir permiso para comprometerse con el proyecto.
Todos los nuevos apicultores serán "inducidos" (por falta de una palabra mejor) en el núcleo valores y directrices del proyecto. Se puede encontrar un resumen de los valores fundamentales en la página acerca de. De quien se une al equipo se espera que defienda esos valores y contribuya a las discusiones sobre la evolución de esos valores en el tiempo.
No se espera de cualquier apicultor, nuevo o viejo, que sea el único mantenedor de cualquiera cosa. Hay muchos apicultores, y muchos más al lado que pueden ofrecer ayuda, consejos y ser mentores.