Organização do projeto

O projeto é dirigido por Aurélien Pierre, que tenta equilibrar seu trabalho fotográfico (praticamente inexistente desde 2019), o desenvolvimento e a manutenção do software, e a educação de usuários em sessões individuais de treinamento. Isso exige estratégias de gerenciamento de projeto com baixo custo operacional, apoiadas em ferramentas colaborativas baseadas na nuvem.

Departamentos

Desenvolvimento de software

O desenvolvimento é feito no Github ,

Pedidos de recursos não são aceitos de usuários neste momento. Os usuários são consultados pelo desenvolvedor a respeito de suas necessidades quando um projeto de (re)design é iniciado. Isso serve para evitar contribuições disruptivas em momentos aleatórios, que só atrasariam os projetos em andamento.

O planejamento de tempo das issues em que se está trabalhando atualmente está disponível no quadro Kanban . Os desenvolvedores podem escolher issues na coluna To Do. Novas alterações para acompanhar e testar estão na coluna Done. Pull requests que não seguirem o protocolo de design serão recusados.

Desenvolvedores que precisam de ajuda, de uma introdução à base de código ou de revisões de código podem marcar um horário com Aurélien Pierre  para fazê-lo por videoconferência (possivelmente usando o Visual Studio Live Share ).

Notícias sobre projetos de desenvolvimento concluídos ou marcos alcançados são publicadas no blog. Um chat Matrix  dedicado centraliza todas as atualizações e notificações de novos commits, issues do Github, novas publicações do blog e novas publicações do fórum da comunidade.

Compilações noturnas

Pacotes instaláveis para Windows (.exe) e Linux (.AppImage) são compilados automaticamente no Github por volta de 1:00 da manhã UTC, caso novos commits tenham sido enviados no dia anterior. Os links de download direto são publicados em um chat Matrix  dedicado, para que você possa ver as notificações aparecerem e obter os novos builds, tudo em um só lugar.

Os builds noturnos (nightly builds) têm o propósito de promover testes antecipados por usuários que não podem ou não querem compilar por conta própria a partir do código-fonte. Eles podem ser instáveis.

Bugs

Bugs (ou seja, coisas que quebram o software) são tratados no Github  quando são confirmados.

Eles podem ser discutidos no fórum da comunidade ou nos chats Matrix , especialmente para confirmar que se trata realmente de bugs (e não de mudanças de design).

Abrir issues no Github é importante para incluí-los no gerenciamento do projeto e acompanhá-los a partir de um único lugar.

Site

O site é gerado usando o construtor de sites estáticos Hugo , que é uma forma de baixo custo operacional para escrever sites técnicos usando a sintaxe Markdown.

O código-fonte do site está no Github . Você pode corrigir erros de digitação ou ajudar a traduzir diretamente, editando os arquivos-fonte pela interface do Github. Caso contrário, você pode instalar o Hugo no seu computador e, então, o arquivo Readme no Github explica como compilar um site de pré-visualização localmente, usando um servidor de teste no seu computador, para pré-visualizar (e depurar) melhor suas alterações.

As alterações no site precisam usar o fluxo de trabalho típico de Git + Pull Request (no Github), o que pode desencorajar não programadores, mas é a forma menos merda de colaborar remotamente em algo baseado em texto, garantindo ao mesmo tempo versionamento reversível e backups.

Documentação

A documentação não está incluída no repositório do site por razões de licenciamento (GPL v3), então ela é importada como um módulo externo do Hugo. O código-fonte está no Github , e todo o resto se aplica da mesma forma que para o site. O Readme apresenta os shortcodes disponíveis que você pode usar para formatar o conteúdo, em arquivos Markdown.

Há uma ressalva, no entanto, caso você queira compilar a documentação localmente, pois ela importa o tema do site principal do Ansel, então a forma mais fácil é, na verdade, compilar o site principal ao mesmo tempo em que se vincula localmente a documentação como um módulo. O procedimento é detalhado no Readme do site principal.

A documentação está passando atualmente por mudanças estruturais, juntamente com mudanças no design do software, então não hesite em perguntar no Matrix  caso tenha um projeto específico em mente, antes de se comprometer com algo prestes a ser removido.

Ensino e educação de usuários

Como mostram muitos relatos de “bugs”, usuários insuficientemente treinados têm expectativas equivocadas e, se você levar os pedidos de recursos deles a sério demais, acaba com um software mutilado que duplica recursos e carga de CPU. Isso precisa ser resolvido na raiz : com ensino.

1. O fórum da comunidade tem um espaço para publicar links de tutoriais em vídeo,
2. O fórum da comunidade tem um espaço para os usuários escreverem publicações educativas de blog,
3. A documentação tem o propósito de fornecer informações de uso estreitamente ligadas à interface gráfica do software, para que os usuários possam aprender sobre os recursos na ordem linear em que aparecem na interface.
4. A seção workflow do site principal tem o propósito de fornecer informações de uso ligadas a uma tarefa específica a ser realizada, para que os usuários possam aprender “como fazer”.
5. A seção recursos do site principal tem o propósito de fornecer informações teóricas de fundo para ajudar a construir uma compreensão mais profunda de cor e fotografia, e capacitar os usuários a solucionar problemas de retoque por conta própria.
6. Os usuários podem marcar sessões de treinamento individuais  (aulas) com Aurélien Pierre, para um treinamento mais rápido e focado.

Gerenciamento

Isso é, em grande parte, uma operação de uma única pessoa, então as coisas precisam ser eficientes e de baixo custo operacional. O que requer certa disciplina.

Gerenciamento da programação

Normalmente há 2 projetos de programação abertos ao mesmo tempo, que são escolhidos por serem independentes um do outro. Isso permite alternar para o projeto #2 enquanto se espera o retorno dos usuários sobre as alterações feitas no #1, de uma forma que ainda permite identificar qual deles criou regressões e novos bugs. Pense nisso como foco único alternado.

No meio de um projeto, o desenvolvedor tipicamente não vai lidar com, se importar com, nem dar ouvidos a issues relacionadas a qualquer coisa que não seja aquele projeto, porque capacidade cerebral é um recurso precioso, gasto mais rápido do que se recupera. Em particular, pedidos de recursos em outras partes do software serão desconsiderados.

O foco do dia a dia está sujeito a mudanças inesperadas, dependendo da merda descoberta ao consertar outra merda, graças ao péssimo legado do Darktable de código espaguete semi-quebrado, não modular e enlouquecedor, que muitas vezes exige reescritas parciais ou totais (em qualquer caso, uma limpeza) antes de tentar consertar qualquer coisa (de uma forma que não gere mais problemas futuros, isto é).

Comunicação

Vivemos em um mundo em que o volume de informação e comunicação se tornou avassalador e os seres humanos não têm capacidade para processar tudo isso. Threads intermináveis e conversas não reguladas prejudicam ativamente a comunicação ao diluir informações importantes e exaurir o leitor. A discussão serve unicamente para chegar a um entendimento e prosseguir para decisões acionáveis. Há um equilíbrio sutil entre completude e concisão a ser encontrado.

Para conversas ou perguntas gerais, use o espaço Matrix . Mas mesmo lá, a concisão é fundamental.

Em pull requests e issues, seja no Github ou no fórum da comunidade, procure ser conciso e objetivo :

• Detalhes técnicos (como sistema operacional, uso de OpenCL, tamanho da tela, etc.) devem usar listas com marcadores.
• Capturas de tela e desenhos podem ajudar bastante.
• Se você estiver respondendo a um ponto ou pessoa em particular, cite o trecho de texto ao qual está respondendo.
• Divida seu texto em parágrafos de aproximadamente 4 a 8 linhas, mas evite enviar cada frase para um novo parágrafo.
• Tenha em mente que todo mundo fala inglês, mas pouquíssimas pessoas são falantes nativos, então procure se ater ao Globish  básico.

Bons princípios sobre interações em issues/tickets podem ser encontrados aqui .

Atualizações e notificações

Muitas formas centralizadas e automatizadas são oferecidas para acompanhar o que há de novo no projeto :

• O site principal tem um feed RSS central, para onde vão as páginas novas e atualizadas : RSS global,
• Para maior granularidade, cada seção do site (Notícias, Documentação, Workflows, etc.) também tem seu próprio feed RSS. O ícone que você encontra nas páginas de índice das seções e em cada página leva a esse feed RSS no idioma atual.
• O site da comunidade também tem um feed RSS público central (truncado nos 25 eventos mais recentes).
• Alterações no código podem ser acompanhadas pelo índice de commits no Github , ou usando o feed Atom do Github  (truncado nos 20 commits mais recentes). As mensagens de commit costumam ser bastante detalhadas e devem explicar suficientemente bem o que foi alterado e por quê.
• Novos commits, atualizações de issues do Github (criadas, editadas, fechadas), novas publicações da comunidade e novas páginas do site são todos publicados em um chat Matrix dedicado .
• Os pacotes de builds noturnos são publicados em um chat Matrix dedicado . Eles também são listados na página de pré-lançamento do Github .
• Projetos/issues abertos e fechados podem ser vistos no quadro Kanban  do Github.