Antimatter

Contribuindo

Relatos de bugs, ideias, traduções, documentação e código são todos bem-vindos. Esta página explica onde conversar, 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 conversar

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

  • Bugs e solicitações de recursos: abra uma questão e selecione Relato de bug, Solicitação de recurso ou Solicitação de plugin ou integração. Pesquise primeiro nas questões existentes; se a sua estiver lá, adicione um "joinha" ou seus detalhes.
  • Perguntas e ideias: as Discussões, nas categorias Perguntas e Respostas ou Ideias.
  • Antes de uma alteração maior, abra uma questão ou uma discussão para concordar sobre a abordagem primeiro. Isso evita uma solicitação de pull que não pode ser mesclada como está.

Problemas com as etiquetas good first issue e help wanted são bons pontos de partida. Deixe um comentário indicando que você está trabalhando em um deles. Novos problemas recebem a etiqueta status/triage e, em seguida, status/accepted, status/planned ou status/wontfix. Os problemas permanecem no repositório da comunidade, independentemente do assunto: os repositórios de código não aceitam problemas. O trabalho planejado está no roadmap do Antimatter.

Repositórios e ramos

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

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

O README de cada repositório explica como compilar e testá-lo. Para o servidor e as interfaces web, veja Compilando a partir do código-fonte; para aplicativos, Compilar, instalar e depurar.

Solicitações de pull

  1. Faça um fork do repositório e crie uma branch a partir de main.
  2. Mantenha cada pull request com apenas uma alteração. Pull requests pequenos são revisados mais rapidamente.
  3. Siga o estilo do código ao seu redor e adicione ou atualize testes onde fizer sentido.
  4. Descreva o que você alterou e por quê, e vincule a issue que ele corrige: Fixes AntimatterChat/community#123.
  5. Certifique-se de que as verificações sejam aprovadas. Um mantenedor revisará o pull request e pode solicitar alterações.

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

Ao contribuir, você concorda que sua contribuição será licenciada sob a licença do repositório ao qual você contribui.

Commits e estilo de código

Commits

As mensagens de commit no histórico são uma frase curta dizendo o que muda, em sentence case e sem ponto final. Alterações em uma parte são prefixadas com ela, por exemplo Fusion: a compact conversation header on phones ou Server: community attributes, and admin-only user attributes. Um commit por alteração; explique os motivos no corpo quando não forem óbvios.

Servidor (Go)

  • Execute make check-style em server/ antes de enviar.
  • Nunca execute go mod tidy diretamente; execute make modules-tidy.
  • Nos caminhos de requisição, registre logs com o logger da requisição. Na camada de armazenamento, use um request.CTX, não um context.Context.
  • Novos endpoints de API ficam em server/channels/api4, com 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 do Fusion ficam em webapp/fusion/src/fusion, com seus estilos em webapp/fusion/src/fusion/styles. Eles constroem nomes de classes com o helper am() e usam os design tokens do Fusion; siga os arquivos ao seu lado.
  • Não adicione novos globais window.* para aplicativos. Novas utilidades voltadas para aplicativos ficam sob window.WebappUtils, conforme explicado em webapp/AGENTS.md.
  • Uma alteração no registro de aplicativos (plugins/registry.ts) geralmente pertence às cópias de ambas as interfaces.

Traduções

O Antimatter e seus aplicativos integrados são traduzidos para 37 idiomas. Os contribuidores adicionam as strings em inglês; os outros idiomas são atualizados em lotes.

Adicionando uma string às interfaces web

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

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

Adicionando uma string ao servidor

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

Outros idiomas

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

Os aplicativos integrados mantêm suas strings em webapp/i18n/; consulte Traduções na página de aplicativos.

Documentação e este site

Este site e 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 ausentes são bem-vindas como issues ou pull requests.

Problemas de segurança

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

Relate-o de forma privada usando o relatório de vulnerabilidades privado do GitHub: abra a aba Segurança do repositório afetado (por exemplo, o servidor) e escolha Report a vulnerability. Se você não souber qual repositório está afetado, relate-o no repositório da comunidade. Inclua o componente e sua versão, o que um invasor poderia fazer, como reproduzir o problema e qualquer configuração da qual ele dependa.

Os mantenedores respondem lá, mantêm você informado enquanto corrigem o problema e publicam um aviso assim que uma versão corrigida for lançada. 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 está 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 arquivos 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.
  • Aplicativos: os aplicativos próprios do Antimatter, como Enquetes, estão sob a AGPL v3; aplicativos derivados do Mattermost mantêm sua licença original. Cada repositório indica qual é em seu arquivo LICENSE.
  • Os aplicativos para desktop e mobile estão sob a Apache License 2.0. O repositório do Docker está sob a Apache License 2.0, exceto seu Dockerfile, que está sob a AGPL v3.

A AGPL significa que, se você executar um servidor do Antimatter modificado para outras pessoas por meio de uma rede, você deve oferecer a elas o código-fonte das suas alterações. O Antimatter é baseado no Mattermost; não é afiliado nem endossado pela Mattermost, Inc.

Todos os participantes seguem o código de conduta.