Gobernanza de la Comunidad FreedomBox

Acerca de Nuestra Comunidad

El proyecto de software FreedomBox está gobernado por una comunidad que incluye voluntarios a tiempo parcial y contribuyentes a jornada completa. Para la gobernanza, nos apoyamos en nuestro código de conducta escrito y en estándares exigidos mutuamente. La comunidad aspira a tomar decisiones mediante debate abierto y consenso. En casos de desacuerdo la comunidad debate hasta que se encuentre una resolución o se acuerde postponer el debate. Aunque una cantidad selecta de desarrolladores ostenta la potestad de aceptar merge requests, cualquiera es bienvenido a unirse a nuestra comunidad de contribuyentes y enviar contribuciones de código fuente u otros tipos.

Equipo Central

¡Conozca a miembros del equipo central! Aunque muchos miembros de la comunidad hacen contribuciones, el equipo central consiste de aquellos que están más involucrados en el desarrollo de FreedomBox.

Contribuyentes

Aunque nuestro equipo central es pequeño, cientos de voluntarios han hecho contribucionse a FreedomBox a lo largo de años. Muchos de esos contribuyentes se listan aquí. ¡Les agradecemos su trabajo!

Cómo se Toman las Decisiones

Generálmente las decisiones acerca del desarrollo y diseño de software se discuten entre miembros del equipo central y se implementan usando nuestra plataforma de desarrollo abierto de software (concretamente, GitLab). Muchas de las decisiones tomadas por el equipo central no son controvertidas y no requieren periodos extensos de debate.

Pero a veces se necesitan periodos más amplios para debatir. Para propuestas que podrían plausiblemente constituir materia de desacuerdo usamos el procedimiento de "Solicitud de Comentarios" ("Request For Comments", RFC). Los RFCs se deben publicar en una de nuestras plataformas de desarrollo abierto (p.ej Gitlab o el foro) y debería incluir (1) un resumen escrito, esquema, o simulador de la propuesta, (2) una explicación breve de por qué es necesaria, y (3) una lista de acciones para implementarla. Opcionalmente se podría incluir también un cuarto elemento en la propuesta: una linea de tiempo sugerida del proceso de debate para prevenir retrasos innecesarios. A veces los desacuerdos dificultan seguir estas líneas de tiempo; en tales casos los participantes deben esforzarse de buena fé para encontrar un compromiso y si eso falla, pueden extender el debate.

Mejora por Revisión

En general, cuando se diseñan o aceptan propuestas refererentes a desarrollo de software éstas se tratan como revisables, no inamovibles. Esta aproximación de mejora-por-revisión a las propuestas nos permite aceptar propuestas generalmente sólidas sin entretenermos en detalles menores. Siempre se pueden hacer ajustes menores a propuestas aceptadas a posteriori en vez de a priori. Al igual que la propuesta original las revisiones están sujetas a debate y no se pueden hacer de manera unilateral. Abrazamos la revisabilidad con espíritu experimental para promover mejoras incrementales en nuestro software.