Antimatter

Beitragen

Fehlermeldungen, Ideen, Übersetzungen, Dokumentation und Code sind herzlich willkommen. Diese Seite erklärt, wo Sie sich austauschen können, wie Sie Änderungen einreichen, welche Konventionen der Code befolgt und welche Regeln für Sicherheitsprobleme und Lizenzen gelten.

Wo Sie sich austauschen können

Alles beginnt im Community-Repository, unabhängig davon, welchen Teil von Antimatter es betrifft:

  • Fehler und Funktionswünsche: Erstellen Sie ein Issue und wählen Sie Bug report, Feature request oder Plugin or integration request. Suchen Sie zuerst in den vorhandenen Issues; falls Ihres bereits existiert, fügen Sie ein Daumen-hoch-Symbol oder Ihre Details hinzu.
  • Fragen und Ideen: die Discussions in den Kategorien Q&A oder Ideas.
  • Bevor Sie größere Änderungen vornehmen, erstellen Sie ein Issue oder eine Diskussion, um zunächst die Vorgehensweise abzustimmen. Das erspart einen Pull Request, der in dieser Form nicht übernommen werden kann.

Issues mit den Labels good first issue und help wanted eignen sich gut zum Einstieg. Geben Sie in einem Kommentar an, dass Sie an einem Issue arbeiten. Neue Issues erhalten zunächst das Label status/triage, danach status/accepted, status/planned oder status/wontfix. Issues verbleiben unabhängig von ihrem Inhalt im Community-Repository; die Code-Repositories akzeptieren keine Issues. Geplante Arbeit ist in der Antimatter-Roadmap zu finden.

Repositories und Branches

Der Code befindet sich in der Organisation AntimatterChat; Wo der Code liegt listet die Repositories auf. In jedem Repository:

  • main ist der Standard-Branch und enthält den Code von Antimatter. Erstellen Sie von diesem Branch ab und senden Sie Pull Requests an diesen Branch.
  • Repositories, die von Mattermost geforkt wurden, haben zusätzlich einen upstream-Branch, ein Spiegelbild des Mattermost-Codes, das verwendet wird, um deren Änderungen zu übernehmen. Bauen Sie Ihre Arbeit nicht auf diesem Branch auf.

Die README jedes Repositories erklärt, wie es gebaut und getestet wird. Für den Server und die Web-Oberflächen siehe Bauen aus dem Quellcode; für Apps siehe Bauen, Installieren und Debuggen.

Pull Requests

  1. Fork das Repository und erstelle einen Branch von main.
  2. Halte jeden Pull Request auf eine Änderung beschränkt. Kleine Pull Requests werden schneller geprüft.
  3. Folge dem Stil des umgebenden Codes und füge oder aktualisiere Tests, wo es sinnvoll ist.
  4. Beschreibe, was und warum du etwas geändert hast, und verlinke das Issue, das du behebst: Fixes AntimatterChat/community#123.
  5. Stelle sicher, dass die Prüfungen bestehen. Ein Maintainer prüft den Pull Request und kann Änderungen anfordern.

Im Server-Repository fülle das Pull-Request-Template aus: eine Zusammenfassung und den Release Note-Block, der immer vorhanden sein muss. Schreibe NONE hinein, wenn die Änderung keine API, Konfiguration, Datenbankstruktur oder sichtbares Verhalten betrifft.

Indem du beiträgst, stimmst du zu, dass dein Beitrag unter der Lizenz des Repositories lizenziert ist, dem du beiträgst.

Commits und Code-Stil

Commits

Commit-Nachrichten in der Historie sind ein kurzer Satz, der beschreibt, was sich ändert, in Satzschreibweise und ohne abschließenden Punkt. Änderungen an einem Teil werden mit diesem Teil vorangestellt, zum Beispiel Fusion: a compact conversation header on phones oder Server: community attributes, and admin-only user attributes. Ein Commit pro Änderung; erkläre die Gründe im Body, wenn sie nicht offensichtlich sind.

Server (Go)

  • Führe make check-style in server/ aus, bevor du pusht.
  • Führe go mod tidy nie direkt aus; führe make modules-tidy aus.
  • In Request-Pfaden logge mit dem Logger des Requests. In der Store-Schicht nimm einen request.CTX, nicht einen context.Context.
  • Neue API-Endpunkte kommen in server/channels/api4, mit ihren Typen in server/public/model und, idealerweise, einer Methode in model.Client4 und im TypeScript-Client.

Web-Oberflächen (TypeScript und React)

  • Führe make check-style und make check-types in webapp/ aus.
  • Die klassische Oberfläche folgt webapp/STYLE_GUIDE.md: funktionale Komponenten, Hooks für Redux, Theme-Variablen für Farben, barrierefreies Markup.
  • Die Komponenten von Fusion befinden sich in webapp/fusion/src/fusion, mit ihren Stilen in webapp/fusion/src/fusion/styles. Sie bauen Klassennamen mit dem am()-Helper und verwenden die Design-Tokens von Fusion; folge den Dateien neben deinen.
  • Füge keine neuen window.*-Globalen für Apps hinzu. Neue, für Apps bestimmte Utilities kommen unter window.WebappUtils, wie in webapp/AGENTS.md erklärt.
  • Eine Änderung am App-Registry (plugins/registry.ts) gehört in der Regel in die Kopien beider Schnittstellen.

Übersetzungen

Antimatter und die mitgelieferten Apps werden in 37 Sprachen übersetzt. Mitwirkende fügen die englischen Zeichenketten hinzu; die anderen Sprachen werden in Chargen aktualisiert.

Eine Zeichenkette zu den Web-Schnittstellen hinzufügen

  1. Schreiben Sie sie mit einer ID und einem wörtlichen englischen Text: formatMessage({id: 'fusion.channelMenu.settings', defaultMessage: 'Channel settings'}) oder <FormattedMessage id='…' defaultMessage='…'/>. Der im App angezeigte englische Text stammt aus defaultMessage.
  2. Führen Sie make i18n-extract in webapp/ aus (oder npm run i18n-extract in webapp/fusion oder webapp/channels). Es aktualisiert das src/i18n/en.json dieses Pakets.
  3. Füllen Sie das description-Feld des neuen Eintrags in en.json aus: Wo die Zeichenkette erscheint und wie sie verwendet wird. Es ist der Kontext, von dem Übersetzer, ob menschlich oder maschinell, ausgehen.

npm run i18n-extract:check schlägt fehl, wenn en.json nicht mit dem Code übereinstimmt.

Eine Zeichenkette zum Server hinzufügen

  1. Verwenden Sie eine ID im Code, zum Beispiel model.NewAppError(…, "app.community_attributes.invalid.app_error", …) oder i18n.T("…").
  2. Führen Sie make i18n-extract in server/ aus. Es fügt die ID in der richtigen Reihenfolge zu server/i18n/en.json hinzu.
  3. Schreiben Sie die englische translation und die description des neuen Eintrags.

Andere Sprachen

Jede Sprache hat neben en.json eine eigene Datei (fr.json, pt-BR.json, zh-TW.json…). Um eine falsche Übersetzung zu melden, öffnen Sie ein Issue im Community-Repository mit der Sprache, dem Text und dem Ort, an dem er erscheint.

Die mitgelieferten Apps verwalten ihre Zeichenketten in webapp/i18n/; siehe Übersetzungen auf der Apps-Seite.

Dokumentation und diese Website

Diese Website und ihre Dokumentation befinden sich im antimatter.chat-Repository. Seiten sind HTML-Fragmente in src/pages/; python3 src/build.py baut die Site. Korrekturen und fehlende Erklärungen sind als Issues oder Pull Requests willkommen.

Sicherheitsprobleme

Melden Sie Sicherheitsprobleme niemals in einem öffentlichen Issue, einer Diskussion oder einem Pull Request.

Melden Sie es vertraulich über die private Schwachstellenmeldung von GitHub: Öffnen Sie den Tab Sicherheit des betroffenen Repositories (z. B. den Server) und wählen Sie Schwachstelle melden. Wenn Sie nicht wissen, welches Repository betroffen ist, melden Sie es im Community-Repository. Geben Sie das betroffene Komponente und deren Version an, was ein Angreifer damit anstellen könnte, wie sich die Schwachstelle reproduzieren lässt und von welchen Konfigurationen sie abhängt.

Die Maintainer antworten dort, halten Sie während der Behebung auf dem Laufenden und veröffentlichen eine Sicherheitswarnung, sobald ein Release mit dem Fix verfügbar ist. Bitte geben Sie ihnen einen angemessenen Zeitraum, bevor Sie das Problem öffentlich machen. Fixes werden in das jeweils neueste Release aufgenommen. Die vollständige Richtlinie finden Sie in der Sicherheitsrichtlinie.

Lizenzen

  • Der Server unterliegt der GNU Affero General Public License v3.0 (AGPL v3). Im selben Repository unterliegen die Verwaltungstools und Konfigurationsdateien (server/templates/, server/i18n/, server/public/ und webapp/) der Apache License 2.0. Siehe LICENSE.txt und NOTICE.txt.
  • Apps: Die eigenen Apps von Antimatter, wie z. B. Umfragen, unterliegen der AGPL v3; Apps, die von Mattermost abgeleitet wurden, behalten ihre ursprüngliche Lizenz. In der LICENSE-Datei jedes Repositories ist angegeben, welche Lizenz gilt.
  • Die Desktop- und Mobile-Apps unterliegen der Apache License 2.0. Das Docker-Repository unterliegt der Apache License 2.0, mit Ausnahme der Dockerfile, die der AGPL v3 unterliegt.

Die AGPL bedeutet, dass Sie, wenn Sie einen modifizierten Antimatter-Server für andere Personen über ein Netzwerk betreiben, ihnen den Quellcode Ihrer Änderungen anbieten müssen. Antimatter basiert auf Mattermost; es besteht keine Verbindung zu Mattermost, Inc. und es wird von dieser nicht unterstützt.

Jede Person, die teilnimmt, befolgt den Verhaltenskodex.