Organização do projeto

The project is run by the maintainer, who balances developing and maintaining the software with the rest of a life. This calls for low-overhead project management strategies, relying on cloud-based collaborative tools.

Departamentos

Desenvolvimento de software

O desenvolvimento é feito no Github ,

Feature requests are not taken from users at this point. Users are consulted by the developer regarding their needs when a (re)design project is started. This is to prevent disruptive inputs at random times that would only slow-down the opened projects. Consultations reach beyond the forum and chat regulars — through surveys when the stakes warrant it — because the people who show up in project spaces are a biased sample of the people who use the tool, and silence is not satisfaction: those who left or never came have needs too, and they are precisely the ones the loudest channels never carry.

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.

Developers who need help, an introduction to the code base, or code reviews can ask on the developer Matrix chat  or in GitHub Discussions ; mentorship is offered within the maintainer’s capacity.

Releases and stability

A stable release is a finished functional set, not a date: versions ship when what they promise works, and the triage rules define what lands in the next minor or major milestone. Two consequences. During foundation work — replacing a core library, reworking an architecture — feature work freezes until the foundations are done: building on a floor while someone replaces the joists wastes both people’s work. And there is no post-release rush: bugs found after a release enter the normal triage queue, in priority order, instead of triggering a scramble that itself creates regressions. Users who want to help stabilize a release test the candidate branch beforehand (validation), which is safe for your edits, unlike dev.

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.

They can be discussed in GitHub Discussions  or the Matrix chats , especially to confirm that they are actually bugs (and not design changes).

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. Video tutorials are published and indexed from the workflows section,
2. Educational long-form writing belongs on the website or in GitHub Discussions ,
3. The documentation is meant to provide usage information closely tied to the software GUI, so users could learn about the features in linear order of GUI appearance.
4. The main website workflow section is meant to provide usage information tied to a specific task to achieve, so users could learn “how to”.
5. The main website resources section is meant to provide background theoritical information to help building a deeper understanding of color and photography, and empower users to troubleshoot retouching issues themselves.

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.

In pull requests and issues, on Github please try to stay concise and on-point :

• 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 :

• 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.
• 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 .