El proyecto es dirigido por Aurélien Pierre, quien trata de equilibrar su trabajo fotográfico (en su mayoría inexistente desde 2019), desarrollando y manteniendo el software y manejando la educación de usuarios en sesiones de capacitación individuales. Esto requiere estrategias de gestión de proyectos de bajo costo, basadas en herramientas de colaboración en la nube.

Departamentos

Desarrollo de software

El desarrollo se lleva a cabo en Github ,

Las solicitudes de funcionalidades no se aceptan de los usuarios en este momento. Los usuarios son consultados por el desarrollador sobre sus necesidades cuando se inicia un proyecto de (re)diseño. Esto es para prevenir entradas perturbadoras en tiempos inadecuados que solo ralentizarían los proyectos abiertos.

La planificación temporal de las incidencias que se están trabajando actualmente está disponible en el tablero Kanban . Los desarrolladores pueden elegir incidencias en la columna Por Hacer. Los nuevos cambios a observar y probar están en la columna Hecho. Las solicitudes de extracción que no sigan el protocolo de diseño serán rechazadas.

Los desarrolladores que necesiten ayuda, introducción a la base del código, o revisiones de código pueden agendar una cita con Aurélien Pierre  para hacerlo por videoconferencia (posiblemente utilizando Visual Studio Live Share ).

Las novedades sobre proyectos de desarrollo cerrados o hitos se publican en el blog. Un chat Matrix dedicado  centraliza todas las actualizaciones y notificaciones de nuevos commits, incidencias de Github, nuevas entradas de blog y nuevas publicaciones en el foro comunitario.

Compilaciones nocturnas

Se construyen automáticamente paquetes instalables para Windows (.exe) y Linux (.AppImage) en Github alrededor de la 1:00 am UTC, si se han enviado nuevos commits el día anterior. Los enlaces de descarga directa se publican en un chat Matrix dedicado , para que puedas ver las notificaciones y obtener las nuevas compilaciones, todo en un solo lugar.

Las compilaciones nocturnas están destinadas a promover pruebas tempranas de usuarios que no pueden o no quieren construir desde la fuente. Pueden ser inestables.

Errores

En caso de errores (como en, algo que rompe el software), se manejan en Github  cuando se confirman.

Pueden discutirse en el foro de la comunidad o en los chats Matrix , especialmente para confirmar que realmente son errores (y no cambios de diseño).

Abrir incidencias en Github es importante para incluirlas en la gestión del proyecto y rastrearlas desde un único lugar.

Sitio web

El sitio web se genera utilizando el constructor de sitios web estáticos Hugo , que es una forma bastante de bajo costo de escribir sitios web técnicos usando sintaxis Markdown.

El código fuente del sitio web está en Github . Puedes corregir errores tipográficos o ayudar a traducir directamente editando los archivos fuente en la interfaz de usuario de Github. De lo contrario, puedes instalar Hugo en tu computadora, luego el archivo Readme en Github explica cómo construir una vista previa del sitio web localmente, usando un servidor de prueba en tu computadora, para previsualizar (y depurar) mejor tus cambios.

Los cambios en el sitio web deben utilizar el típico flujo de trabajo de Git + Pull Request (en Github), lo cual puede desalentar a los no programadores, pero es la manera menos complicada de colaborar a distancia en algo basado en texto, mientras se asegura una versión reversible y respaldos.

Documentación

La documentación no está incluida en el repositorio del sitio web por razones de licencia (GPL v3), por lo que se importa como un módulo externo de Hugo. El código fuente está en Github , y todo lo demás se aplica de la misma manera que para el sitio web. El Readme presenta los shortcodes disponibles que puedes usar para dar formato al contenido, en archivos Markdown.

Sin embargo, hay una advertencia si deseas construir la documentación localmente, ya que importa el tema principal del sitio web de Ansel, por lo que la forma más fácil es construir el sitio web principal mientras se vincula localmente la documentación como un módulo. El procedimiento se detalla en el Readme del sitio web principal.

La documentación está experimentando cambios estructurales, junto con cambios en el diseño del software, así que no dudes en preguntar en Matrix  si tienes un proyecto particular en mente, antes de comprometerte a algo que está a punto de ser eliminado.

Enseñanza y educación del usuario

Como muestran muchos informes de “errores”, los usuarios insuficientemente capacitados tienen expectativas equivocadas, y si tomas demasiado en serio sus solicitudes de características, terminas con un software limitado duplicando características y carga de CPU. Estos deben resolverse en la raíz: con la enseñanza.

  1. El foro de la comunidad tiene un lugar para publicar enlaces a tutoriales en video,
  2. El foro de la comunidad tiene un lugar para que los usuarios escriban entradas de blog educativas,
  3. La documentación está diseñada para proporcionar información de uso estrechamente ligada a la GUI del software, de modo que los usuarios puedan aprender sobre las características en un orden lineal de aparición en la GUI.
  4. La sección flujo de trabajo del sitio web principal está destinada a proporcionar información de uso vinculada a una tarea específica a lograr, para que los usuarios puedan aprender “cómo hacerlo”.
  5. La sección recursos del sitio web principal está destinada a proporcionar información teórica de fondo para ayudar a construir una comprensión más profunda del color y la fotografía, y capacitar a los usuarios para solucionar problemas de retoque por sí mismos.
  6. Los usuarios pueden reservar sesiones de capacitación personalizadas  (clases) con Aurélien Pierre, para una formación más rápida y enfocada.

Administración

Esto es principalmente la operación de una sola persona, por lo que las cosas deben ser eficientes y de bajo costo. Lo cual requiere cierta disciplina.

Gestión de programación

Generalmente hay 2 proyectos de programación abiertos al mismo tiempo, que se eligen porque son independientes entre sí. Esto permite cambiar al proyecto #2 mientras espera la retroalimentación del usuario sobre los cambios realizados en #1, de una manera que todavía permite identificar cuál de ellos creó regresiones y nuevos errores. Piénsalo como un enfoque de enfoque único alterno.

En medio de un proyecto, el desarrollador generalmente no lidiará, se preocupará ni escuchará problemas relacionados con nada más que ese proyecto, porque el poder cerebral es un recurso valioso, que se gasta más rápido de lo que se recupera. En particular, las solicitudes de características en otras partes del software serán desatendidas.

El enfoque diario está sujeto a cambios inesperados, dependiendo de los problemas que se descubran mientras se solucionan otros problemas, gracias al legado problemático de Darktable con una mezcla de código no modular que a menudo requiere reescrituras parciales o completas (en cualquier caso, limpieza) antes de intentar solucionar nada (de una manera que no cause más problemas en el futuro, eso es).

Comunicación

Vivimos en un mundo donde el volumen de información y comunicación se ha vuelto abrumador y los humanos no tienen el ancho de banda para procesarlo todo. Los hilos interminables y las conversaciones no reguladas están dañando activamente la comunicación al diluir información importante y agotar al lector. La discusión está destinada únicamente a llegar a un entendimiento y proceder a decisiones accionables. Hay un sutil equilibrio entre la integridad y la concisión.

Para chat o preguntas generales, por favor utiliza el espacio de Matrix . Pero incluso allí, la concisión es clave.

En pull requests y problemas, ya sea en Github o en el Foro de la Comunidad intenta mantenerte conciso y al grano:

  • Los detalles técnicos (como el SO, uso de OpenCL, tamaño de pantalla, etc.) deben hacer uso de listas con viñetas.
  • Las capturas de pantalla y dibujos pueden ser de gran ayuda.
  • Si estás respondiendo a un punto o persona en particular, cita la sección del texto a la que estás respondiendo.
  • Divide tu texto en párrafos de aproximadamente 4 a 8 líneas, pero evita enviar cada oración a un nuevo párrafo.
  • Ten en cuenta que todo el mundo habla inglés pero pocas personas son hablantes nativos, así que intenta ceñirte a un Globish  básico.

Los buenos principios sobre interacciones con problemas/boletas se pueden encontrar aquí .

Actualizaciones y notificaciones

Se ofrecen muchas formas centralizadas y automatizadas para mantenerse al día con lo nuevo en el proyecto:

  • The main website has a central RSS feed, where new and updated page goes :  global RSS,
  • For more granularity, each section of the website (News, Doc, Workflows, etc.) has its own RSS feed too. The icon you find on section index pages and on every page links to that RSS feed in the current language.
  • The Community website has a central public RSS feed too (truncated to the 25 most recent events).
  • Code changes can be tracked from commits index on Github , or using the Github Atom feed  (truncated to the 20 most recent commits). Commit messages are usually quite verbose and should explain well enough what was changed and why.
  • New commits, Github issues updates (created, edited, closed), new community posts and new website pages are all posted to a dedicated Matrix chat .
  • Nightly builds packages are posted to a dedicated Matrix chat . They are also listed on the Github pre-release page .
  • Open and closed project/issues can be seen on the Github Kanban board .
Translated from English by : ChatGPT. In case of conflict, inconsistency or error, the English version shall prevail.