Contribuir

Relatos de bugs, ideias, traduções, documentação e código são todos bem-vindos. Esta página explica onde falar, como enviar uma alteração, as convenções que o código segue e as regras para problemas de segurança e licenças.

Onde falar

Tudo começa no repositório da comunidade, independentemente da parte do Antimatter de que se trate:

Bugs e pedidos de funcionalidades: abra um problema e escolha Relato de bug, Pedido de funcionalidade ou Pedido de plugin ou integração. Pesquise primeiro nos problemas existentes; se o seu já estiver lá, adicione um polegar para cima ou os seus detalhes.
Perguntas e ideias: as Discussões, nas categorias de Perguntas e Respostas ou Ideias.
Antes de uma alteração maior, abra um problema ou uma discussão para acordar primeiro a abordagem. Isso evita um pedido de alteração que não pode ser fundido tal como está.

As questões com as etiquetas good first issue e help wanted são um bom ponto de partida. Indique num comentário que está a trabalhar numa delas. As novas questões recebem a etiqueta status/triage e, em seguida, status/accepted, status/planned ou status/wontfix. As questões permanecem no repositório da comunidade, independentemente do seu conteúdo: os repositórios de código não aceitam questões. O trabalho planeado está no roadmap do Antimatter.

Repositórios e ramos

O código está na organização AntimatterChat; Onde está o código lista os repositórios. Em todos os repositórios:

main é o ramo predefinido e contém o código do Antimatter. Crie ramos a partir dele e envie pedidos de alteração para ele.
Os repositórios bifurcados do Mattermost também têm um ramo upstream, um espelho do código do Mattermost usado para incorporar as suas alterações. Não baseie o seu trabalho nele.

O README de cada repositório explica como o compilar e testar. Para o servidor e as interfaces web, consulte Compilar a partir do código-fonte; para as aplicações, Compilar, instalar e depurar.

Pedidos de alteração

Faça um fork do repositório e crie uma branch a partir de main.
Mantenha cada pull request com uma única alteração. Pull requests pequenos são revistos mais rapidamente.
Siga o estilo do código à sua volta e adicione ou atualize testes onde fizer sentido.
Descreva o que alterou e porquê, e ligue o problema que corrige: Fixes AntimatterChat/community#123.
Verifique se as verificações passam. Um mantenedor revê o pull request e pode pedir alterações.

No repositório do servidor, preencha o modelo do pull request: um Resumo e o bloco Nota de lançamento, que deve estar sempre presente. Escreva NONE nele quando a alteração não afetar a API, a configuração, o esquema da base de dados ou o comportamento visível.

Ao contribuir, concorda que a sua contribuição é licenciada sob a licença do repositório a que contribui.

Commits e estilo de código

Commits

As mensagens de commit no histórico são uma frase curta que descreve as alterações, em minúsculas no início da frase e sem ponto final. As alterações a uma parte são prefixadas com essa parte, por exemplo Fusion: a compact conversation header on phones ou Server: community attributes, and admin-only user attributes. Um commit por alteração; explique as razões no corpo quando não forem evidentes.

Servidor (Go)

Execute make check-style em server/ antes de fazer push.
Nunca execute go mod tidy diretamente; execute make modules-tidy.
Nos caminhos de pedido, registe com o logger do pedido. Na camada de armazenamento, utilize um request.CTX, não um context.Context.
Novos pontos de terminação da API ficam em server/channels/api4, com os seus tipos em server/public/model e, idealmente, um método em model.Client4 e no cliente TypeScript.

Interfaces web (TypeScript e React)

Execute make check-style e make check-types em webapp/.
A interface clássica segue webapp/STYLE_GUIDE.md: componentes funcionais, hooks para Redux, variáveis de tema para cores, marcação acessível.
Os componentes da Fusion ficam em webapp/fusion/src/fusion, com os seus estilos em webapp/fusion/src/fusion/styles. Constroem nomes de classes com o auxiliar am() e utilizam os tokens de design da Fusion; siga os ficheiros ao seu lado.
Não adicione novos globais window.* para aplicações. Novas utilidades para aplicações ficam sob window.WebappUtils, como explicado em webapp/AGENTS.md.
Uma alteração no registo de aplicações (plugins/registry.ts) geralmente pertence às cópias de ambas as interfaces.

Traduções

O Antimatter e as suas aplicações incluídas são traduzidos para 37 idiomas. Os colaboradores adicionam as strings em inglês; os outros idiomas são atualizados em lotes.

Adicionar uma string às interfaces web

Escreva-a com um ID e um texto em inglês literal: formatMessage({id: 'fusion.channelMenu.settings', defaultMessage: 'Channel settings'}) ou <FormattedMessage id='…' defaultMessage='…'/>. O inglês mostrado na aplicação vem de defaultMessage.
Execute make i18n-extract em webapp/ (ou npm run i18n-extract em webapp/fusion ou webapp/channels). Atualiza o src/i18n/en.json desse pacote.
Preencha o description da nova entrada em en.json: onde a string aparece e como é utilizada. É o contexto a partir do qual os tradutores, humanos ou máquinas, trabalham.

npm run i18n-extract:check falha quando o en.json está desatualizado em relação ao código.

Adicionar uma string ao servidor

Use um ID no código, por exemplo model.NewAppError(…, "app.community_attributes.invalid.app_error", …) ou i18n.T("…").
Execute make i18n-extract em server/. Adiciona o ID ao server/i18n/en.json na ordem correta.
Escreva a translation em inglês e a description da nova entrada.

Outros idiomas

Cada idioma tem o seu próprio ficheiro junto ao en.json (fr.json, pt-BR.json, zh-TW.json…). Para reportar uma tradução incorreta, abra uma issue no repositório da comunidade com o idioma, o texto e onde ele aparece.

As aplicações incluídas mantêm as suas strings em webapp/i18n/; consulte Traduções na página de aplicações.

Documentação e este website

Este website e a sua documentação estão no repositório antimatter.chat. As páginas são fragmentos HTML em src/pages/; python3 src/build.py compila o site. Correções e explicações em falta são bem-vindas como issues ou pull requests.

Problemas de segurança

Nunca reporte um problema de segurança numa issue, discussão ou pull request pública.

Reporte-o de forma privada através do sistema de reporte de vulnerabilidades privado do GitHub: abra a separeta Segurança do repositório afetado (por exemplo, o servidor) e escolha Reportar uma vulnerabilidade. Se não souber qual é o repositório afetado, reporte-o no repositório da comunidade. Inclua o componente e a respetiva versão, o que um atacante poderia fazer, como reproduzir o problema e qualquer configuração de que dependa.

Os mantenedores respondem aí, mantêm-no informado enquanto o corrigem e publicam um aviso assim que uma versão corrigida estiver disponível. Por favor, dê-lhes um tempo razoável antes de divulgar o problema. As correções são incluídas na versão mais recente. A política completa encontra-se na política de segurança.

Licenças

O servidor está sob a GNU Affero General Public License v3.0 (AGPL v3). No mesmo repositório, as ferramentas de administração e os ficheiros de configuração (server/templates/, server/i18n/, server/public/ e webapp/) estão sob a Apache License 2.0. Consulte LICENSE.txt e NOTICE.txt.
Aplicações: as aplicações próprias do Antimatter, como as Sondagens, estão sob a AGPL v3; as aplicações derivadas do Mattermost mantêm a sua licença original. Cada repositório indica qual é no seu ficheiro LICENSE.
As aplicações para desktop e móvel estão sob a Apache License 2.0. O repositório Docker está sob a Apache License 2.0, exceto o seu Dockerfile, que está sob a AGPL v3.

A AGPL significa que, se executar um servidor Antimatter modificado para outras pessoas através de uma rede, deve disponibilizar-lhes o código-fonte das suas alterações. O Antimatter baseia-se no Mattermost; não tem qualquer afiliação nem endosso por parte da Mattermost, Inc.

Todos os participantes seguem o código de conduta.