Contribuire

Segnalazioni di bug, idee, traduzioni, documentazione e codice sono tutti benvenuti. Questa pagina spiega dove parlare, come inviare una modifica, le convenzioni seguite dal codice e le regole per i problemi di sicurezza e le licenze.

Dove parlare

Tutto inizia nel repository della community, indipendentemente dalla parte di Antimatter di cui si tratta:

Bug e richieste di funzionalità: apri un problema e scegli Segnalazione di bug, Richiesta di funzionalità o Richiesta di plugin o integrazione. Cerca prima nei problemi esistenti; se il tuo è già presente, aggiungi un pollice in su o i tuoi dettagli.
Domande e idee: le Discussioni, nelle categorie Domande e risposte o Idee.
Prima di una modifica importante, apri un problema o una discussione per concordare prima l'approccio. Evita così una pull request che non può essere integrata così com'è.

I problemi etichettati con good first issue e help wanted sono un buon punto di partenza. Indica in un commento che stai lavorando a uno di essi. I nuovi problemi vengono etichettati con status/triage, quindi status/accepted, status/planned o status/wontfix. I problemi restano nel repository della comunità, indipendentemente dalla loro natura: i repository del codice non accettano problemi. Il lavoro pianificato è disponibile nella roadmap di Antimatter.

Repository e rami

Il codice si trova nell'organizzazione AntimatterChat; Dove si trova il codice elenca i repository. In ogni repository:

main è il ramo predefinito e contiene il codice di Antimatter. Crea rami da questo e invia pull request verso di esso.
I repository forkati da Mattermost hanno anche un ramo upstream, uno specchio del codice di Mattermost usato per importarne le modifiche. Non basare il lavoro su di esso.

Il README di ogni repository spiega come compilarlo e testarlo. Per il server e le interfacce web, consulta Compilazione da sorgente; per le app, Compilazione, installazione e debug.

Pull request

Forka il repository e crea una branch da main.
Limita ogni pull request a una sola modifica. Le pull request piccole vengono rivedute più rapidamente.
Segui lo stile del codice circostante e aggiungi o aggiorna i test dove ha senso.
Descrivi cosa hai modificato e perché, e collega la issue che risolvi: Fixes AntimatterChat/community#123.
Assicurati che i controlli passino. Un maintainer rivedrà la pull request e potrebbe richiedere modifiche.

Nel repository del server, compila il modello della pull request: un Riepilogo e il blocco Release Note, che deve sempre essere presente. Inserisci NONE quando la modifica non riguarda l'API, la configurazione, lo schema del database o il comportamento visibile.

Contribuendo, accetti che il tuo contributo sia concesso in licenza sotto la licenza del repository a cui contribuisci.

Commit e stile del codice

Commit

I messaggi di commit nella cronologia sono una breve frase che descrive la modifica, in sentence case e senza punto finale. Le modifiche a una specifica parte sono prefissate con il relativo nome, ad esempio Fusion: a compact conversation header on phones o Server: community attributes, and admin-only user attributes. Un commit per ogni modifica; spiega le motivazioni nel corpo del messaggio quando non sono ovvie.

Server (Go)

Esegui make check-style in server/ prima di spingere.
Non eseguire mai go mod tidy direttamente; esegui make modules-tidy.
Nei percorsi di richiesta, registra i log con il logger della richiesta. Nel layer di storage, accetta un request.CTX, non un context.Context.
I nuovi endpoint API vanno in server/channels/api4, con i loro tipi in server/public/model e, idealmente, un metodo in model.Client4 e nel client TypeScript.

Interfacce web (TypeScript e React)

Esegui make check-style e make check-types in webapp/.
L'interfaccia classica segue webapp/STYLE_GUIDE.md: componenti funzionali, hook per Redux, variabili di tema per i colori, markup accessibile.
I componenti di Fusion si trovano in webapp/fusion/src/fusion, con i loro stili in webapp/fusion/src/fusion/styles. Costruiscono i nomi delle classi con l'helper am() e usano i design token di Fusion; segui i file accanto ai tuoi.
Non aggiungere nuove variabili globali window.* per le app. Le nuove utilità per le app vanno sotto window.WebappUtils, come spiegato in webapp/AGENTS.md.
Una modifica al registro delle app (plugins/registry.ts) di solito va applicata alle copie di entrambe le interfacce.

Traduzioni

Antimatter e le app incluse vengono tradotte in 37 lingue. I contributor aggiungono le stringhe in inglese; le altre lingue vengono aggiornate in lotti.

Aggiungere una stringa alle interfacce web

Scrivila con un ID e un testo letterale in inglese: formatMessage({id: 'fusion.channelMenu.settings', defaultMessage: 'Channel settings'}) o <FormattedMessage id='…' defaultMessage='…'/>. L'inglese visualizzato nell'app proviene da defaultMessage.
Esegui make i18n-extract in webapp/ (o npm run i18n-extract in webapp/fusion o webapp/channels). Aggiorna il file src/i18n/en.json del pacchetto.
Compila il campo description della nuova voce in en.json: indica dove compare la stringa e come viene utilizzata. È il contesto da cui partono i traduttori, umani o macchine.

npm run i18n-extract:check restituisce un errore se en.json non è in sincronia con il codice.

Aggiungere una stringa al server

Usa un ID nel codice, ad esempio model.NewAppError(…, "app.community_attributes.invalid.app_error", …) o i18n.T("…").
Esegui make i18n-extract in server/. Aggiunge l'ID a server/i18n/en.json nell'ordine corretto.
Scrivi la translation in inglese e la description della nuova voce.

Altre lingue

Ogni lingua ha il proprio file accanto a en.json (fr.json, pt-BR.json, zh-TW.json…). Per segnalare una traduzione errata, apri un issue nel repository della community indicando la lingua, il testo e il punto in cui compare.

Le app incluse mantengono le proprie stringhe in webapp/i18n/; consulta Traduzioni nella pagina delle app.

Documentazione e questo sito web

Questo sito web e la sua documentazione si trovano nel repository antimatter.chat. Le pagine sono frammenti HTML in src/pages/; python3 src/build.py compila il sito. Sono benvenute correzioni e spiegazioni mancanti tramite issue o pull request.

Problemi di sicurezza

Non segnalare mai un problema di sicurezza in un issue, una discussione o una pull request pubblici.

Segnalalo in privato tramite la segnalazione delle vulnerabilità di GitHub: apri la scheda Sicurezza del repository interessato (ad esempio il server) e scegli Report a vulnerability. Se non sai quale repository sia interessato, segnalalo nel repository della community. Includi il componente e la sua versione, ciò che un attaccante potrebbe fare, come riprodurre il problema e qualsiasi configurazione da cui dipenda.

I manutentori rispondono lì, ti tengono aggiornato durante la correzione e pubblicano un avviso non appena viene rilasciata una versione corretta. Ti preghiamo di concedere loro un tempo ragionevole prima di divulgare il problema. Le correzioni vengono incluse nell'ultima versione. L'intera politica è disponibile nella security policy.

Licenze

Il server è rilasciato sotto licenza GNU Affero General Public License v3.0 (AGPL v3). Nello stesso repository, gli strumenti di amministrazione e i file di configurazione (server/templates/, server/i18n/, server/public/ e webapp/) sono rilasciati sotto licenza Apache License 2.0. Consulta LICENSE.txt e NOTICE.txt.
App: le app di Antimatter, come Sondaggi, sono rilasciate sotto licenza AGPL v3; le app derivate da Mattermost mantengono la loro licenza originale. Ogni repository indica quale nel file LICENSE.
Le app desktop e mobile sono rilasciate sotto licenza Apache License 2.0. Il repository Docker è rilasciato sotto licenza Apache License 2.0, ad eccezione del Dockerfile, che è sotto licenza AGPL v3.

L'AGPL significa che, se esegui un server Antimatter modificato per conto di altre persone tramite una rete, devi fornire loro il codice sorgente delle tue modifiche. Antimatter si basa su Mattermost; non è affiliato né approvato da Mattermost, Inc.

Tutti i partecipanti seguono il code of conduct.