La gestión y toma de decisiones en el ámbito de la ciencia¶
El propósito de este documento es formalizar el proceso de gestión utilizado por el proyecto scikit-learning para aclarar cómo se toman las decisiones y cómo interactúan los distintos elementos de nuestra comunidad. Este documento establece una estructura de toma de decisiones que tiene en cuenta la retroalimentación de todos los miembros de la comunidad y se esfuerza por encontrar consenso, evitando cualquier estancamiento.
Se trata de un proyecto comunitario meritocrático y basado en el consenso. Cualquiera que tenga interés en el proyecto puede unirse a la comunidad, contribuir al diseño del proyecto y participar en el proceso de toma de decisiones. En este documento se describe cómo se lleva a cabo esa participación y cómo se puede ganar méritos dentro de la comunidad del proyecto.
Roles y responsabilidades¶
Colaboradores¶
Los colaboradores son miembros de la comunidad que contribuyen de forma concreta al proyecto. Cualquiera puede convertirse en un colaborador, y las contribuciones pueden ser de distinta manera - no sólo programar - como se detalla en la contributors guide.
Equipo de prueba¶
El equipo de prueba está compuesto por miembros de la comunidad que tienen permiso en github para etiquetar y cerrar incidencias. El recurso Their work es crucial para mejorar la comunicación en el proyecto y limitar la distribución del seguimiento de incidencias.
De manera similar a lo que se ha decidido en el python project, cualquier colaborador puede convertirse en un miembro del equipo de prueba de scikit-learn, después de mostrar cierta continuidad en la participación en el desarrollo de scikit-learn (con pull requests y revisiones). Cualquier desarrollador principal es bienvenido a proponer a un colaborador de scikit-learn para unirse al equipo de prueba. A continuación, se consulta a otros desarrolladores del núcleo: si bien se espera que la mayoría de las aceptaciones sean unánimes, una mayoría de dos tercios es suficiente. Cada nuevo participante será anunciado en la lista de correo y son bienvenidos a participar en las reuniones mensuales del core developer.
Desarrolladores principales¶
Los desarrolladores principales o centrales son miembros de la comunidad que han demostrado que están dedicados al desarrollo continuo del proyecto a través del compromiso continuo con la comunidad. Han demostrado que se puede confiar en ellos para mantener scikit-learn cuidadosamente. Ser un desarrollador principal permite a los contribuyentes continuar más fácilmente con sus actividades relacionadas con el proyecto, dándoles acceso directo al repositorio del proyecto y se representa como un miembro de scikit-learn organización GitHub. Se espera que los desarrolladores principales revisen las contribuciones de código, puedan combinar solicitudes de extracción aprobadas, puede emitir votos a favor y en contra de la fusión de una solicitud «pull», y puede participar en la decisión de cambios importantes en la API.
Los nuevos desarrolladores principales o centrales pueden ser nominados por cualquier desarrollador principal existente. Una vez que hayan sido nominados, habrá una votación de los desarrolladores centrales actuales. Votar sobre nuevos desarrolladores centrales es una de las pocas actividades que tiene lugar en la lista de administración privada del proyecto. Si bien se espera que la mayoría de los votos sean unánimes, una mayoría de dos tercios de los votos emitidos es suficiente. La votación debe estar abierta al menos durante una semana.
A los desarrolladores principales que no han contribuido al proyecto (commits o comentarios de GitHub) en los últimos 12 meses se les preguntará si quieren convertirse en desarrolladores centrales eméritos y revertir sus derechos de compromiso y voto hasta que vuelvan a estar activos. La lista de desarrolladores principales, activos y emérito (con fechas en las que se hicieron activos) es pública en el sitio web de scikit-learn.
Comité técnico¶
Los miembros del Comité Técnico (CT) son desarrolladores principales que tienen responsabilidades adicionales para asegurar el buen funcionamiento del proyecto. Se espera que los miembros del CT participen en la planificación estratégica y aprueben cambios en el modelo de gestión. El objetivo del CT es asegurar un progreso sin problemas desde la perspectiva del panorama general. De hecho, los cambios que afectan al proyecto completo requieren un análisis sintético y un consenso que sea explícito e informado. En los casos en que la comunidad principal de desarrolladores (que incluye a los miembros de CT) no logra alcanzar tal consenso en el marco de tiempo requerido, el CT es la entidad para resolver el problema. La membresía de la CT es por nominación de un desarrollador central. Una nominación dará lugar a un debate que no puede durar más de un mes y después a una votación de los desarrolladores principales que permanecerá abierta durante una semana. Los votos de membresía de CT están sujetos a una mayoría de dos tercios de todos los votos emitidos así como a una aprobación por mayoría simple de todos los miembros actuales del CT. Los miembros del CT que no se comprometan activamente con las tareas del CT deberán renunciar.
El Comité Técnico de scikit-learn consiste en Alexandre Gramfort, Olivier Grisel, Adrin Jalali, Andreas Muckller, Joel Nothman, Hanmin Qin, Gae.Ul Varoquaux, y Roman Yurchak.
Proceso de toma de decisiones¶
Las decisiones sobre el futuro del proyecto se toman a través de discusiones con todos los miembros de la comunidad. Todos los debates no sensibles sobre la gestión del proyecto tienen lugar en los colaboradores del proyecto lista de correo de los colaboradores del proyecto y el issue tracker. Ocasionalmente, las discusiones sensibles tienen lugar en una lista privada.
Scikit-learn utiliza un proceso de «búsqueda de consenso» para la toma de decisiones. El grupo trata de encontrar una resolución que no tenga objeciones abiertas entre los desarrolladores principales. En cualquier momento durante la discusión, cualquier desarrollador central puede pedir una votación, que concluirá un mes después de la convocatoria de votación. Cualquier voto debe estar respaldado por un SLEP. Si ninguna opción puede reunir dos tercios de los votos emitidos, la decisión es escalada al CT, que, a su vez, utilizará el consenso que busca con la opción de una votación por mayoría simple si no se puede alcanzar un consenso dentro de un mes. Esto es lo que aquí podemos llamar “proceso de toma de decisiones”.
Las decisiones (además de añadir a los desarrolladores del núcleo y a los miembros del CT, como se ha indicado anteriormente) se toman de acuerdo con las siguientes reglas:
Cambios menores en la documentación, como correcciones de errores tipográficos o adición/corrección de una frase, pero ningún cambio en la página de inicio de scikit-learn.org o en la página «about»: Requiere +1 por un desarrollador principal, no -1 por un desarrollador principal (consenso vago), sucede en la página de la edición o pull request. Se espera que los desarrolladores principales den un «tiempo razonable» a los demás para dar su opinión sobre el pull request si no están seguros de que los demás estén de acuerdo.
Los cambios de código y los cambios importantes en la documentación requieren +1 por parte de dos desarrolladores principales, no -1 por parte de un desarrollador principal (consenso vago), sucede en el issue de la página de pull-request.
Cambia los principios de la API y los cambios a las dependencias o versiones soportadas ocurren a través de un Propuestas de mejora (SLEPs) y sigue el proceso de toma de decisiones descrito arriba.
Los cambios en el modelo de gestión utilizan el mismo proceso de decisión descrito anteriormente.
Si se vetara -1 voto por un consenso vago, el que lo propone puede apelar a la comunidad y a los desarrolladores principales y el cambio puede ser aprobado o rechazado utilizando el procedimiento de toma de decisiones descrito anteriormente.
Propuestas de mejora (SLEPs)¶
Para todas las votaciones, debe haberse hecho pública una propuesta y debatirse antes de la votación. Dicha propuesta debe ser un documento consolidado, en forma de Scikit-Learn Enhancement Proposal” (SLEP, por sus siglas en inglés), en lugar de una larga discusión sobre una cuestión. Un SLEP debe ser enviado como un pull-request para `enhancement proposals usando el SLEP template.