Antimatter

Принос

Доклади за грешки, идеи, преводи, документация и код са добре дошли. Тази страница обяснява къде да обсъждате, как да изпратите промяна, конвенциите, които кодът следва, и правилата за проблеми с сигурността и лицензи.

Къде да обсъждате

Всичко започва в репозиторията на общността, независимо за коя част на Antimatter става дума:

  • Грешки и заявки за функции: отворете проблем и изберете Доклад за грешка, Заявка за функция или Заявка за плъгин или интеграция. Първо потърсете сред съществуващите проблеми; ако вашият вече е там, добавете „палец нагоре“ или вашите детайли.
  • Въпроси и идеи: Обсъжданията, в категориите Въпроси и отговори или Идеи.
  • Преди по-голяма промяна, отворете проблем или обсъждане, за да се съгласите първо за подхода. Това спестява заявка за сливане, която не може да бъде приета в текущото ѝ състояние.

Проблемите с етикети good first issue и help wanted са добро място за начало. Посочете в коментар, че работите върху някой от тях. Новите проблеми се етикетират първо с status/triage, а после с status/accepted, status/planned или status/wontfix. Проблемите остават в общностното хранилище, независимо от темата им: хранилищата с код не приемат проблеми. Планираната работа е в Antimatter roadmap.

Репозитории и клонове

Кодът е в организацията AntimatterChat; Къде се намира кодът изброява репозиториите. В всеки репозиторий:

  • main е клонът по подразбиране и съдържа кода на Antimatter. Клонете от него и изпращайте заявки за сливане към него.
  • Репозиториите, форкнати от Mattermost, имат и клон upstream, огледало на кода на Mattermost, използвано за внасяне на техните промени. Не базирайте работа върху него.

README файла на всеки репозиторий обяснява как да се компилира и тества. За сървъра и уеб интерфейсите вижте Компилиране от изходен код; за приложенията, Компилиране, инсталиране и дебъгване.

Заявки за сливане

  1. Клонирайте репозиторията и създайте клон от main.
  2. Ограничете всяка заявка за сливане до едно промяна. Малките заявки се преглеждат по-бързо.
  3. Следвайте стила на кода около вас и добавете или актуализирайте тестове, където е уместно.
  4. Опишете какво сте променили и защо, и свържете задачата, която поправя: Fixes AntimatterChat/community#123.
  5. Уверете се, че проверките минават. Поддръжателят преглежда заявката за сливане и може да поиска промени.

В репозиторията на сървъра попълнете шаблона за заявка за сливане: Обобщение и блокът Забележка за версията, който винаги трябва да присъства. Впишете NONE, ако промяната не засяга API, конфигурация, схема на базата данни или видимо поведение.

Чрез доприноса си вие се съгласявате, че той е лицензиран под лиценза на репозиторията, към която допринасяте.

Комити и стил на кода

Комити

Съобщенията за commits в историята са едно кратко изречение, описващо промените, в начална буква и без крап в края. Промените в една част се предхождат от нейното име, например Fusion: a compact conversation header on phones или Server: community attributes, and admin-only user attributes. По един commit на промяна; обяснете причините в тялото, когато не са очевидни.

Сървър (Go)

  • Изпълнете make check-style в server/ преди да изпратите.
  • Никога не изпълнявайте go mod tidy директно; изпълнете make modules-tidy.
  • В пътеките на заявките, записвайте в дневника с логера на заявката. В слоя на хранилището, приемайте request.CTX, а не context.Context.
  • Новите API краища се поставят в server/channels/api4, с техните типове в server/public/model и, идеално, метод в model.Client4 и в TypeScript клиента.

Уеб интерфейси (TypeScript и React)

  • Изпълнете make check-style и make check-types в webapp/.
  • Класическият интерфейс следва webapp/STYLE_GUIDE.md: функционални компоненти, хукове за Redux, променливи на темата за цветове, достъпен разметка.
  • Компонентите на Fusion се намират в webapp/fusion/src/fusion, с техните стилове в webapp/fusion/src/fusion/styles. Те изграждат класове с помощта на am() и използват дизайн токените на Fusion; следвайте файловете до вашите.
  • Не добавяйте нови window.* глобални променливи за приложения. Новите утилити, насочени към приложения, се поставят под window.WebappUtils, както обяснява webapp/AGENTS.md.
  • Промяна в регистъра на приложенията (plugins/registry.ts) обикновено трябва да присъства в копите на двете интерфейса.

Преводи

Antimatter и приложенията, включени в него, са преведени на 37 езика. Сътрудниците добавят английските текстове, а останалите езици се обновяват на партиди.

Добавяне на текст в уеб интерфейсите

  1. Запишете го с идентификатор и буквален английски текст: formatMessage({id: 'fusion.channelMenu.settings', defaultMessage: 'Channel settings'}) или <FormattedMessage id='…' defaultMessage='…'/>. Английският текст, показван в приложението, идва от defaultMessage.
  2. Изпълнете make i18n-extract в webapp/ (или npm run i18n-extract в webapp/fusion или webapp/channels). Това обновява файла src/i18n/en.json на съответния пакет.
  3. Попълнете description на новия запис в en.json: къде се появява текстът и как се използва. Това е контекстът, от който работят преводите, дали човешки или машинни.

npm run i18n-extract:check се проваля, когато en.json не е в синхрон с кода.

Добавяне на текст на сървъра

  1. Използвайте идентификатор в кода, например model.NewAppError(…, "app.community_attributes.invalid.app_error", …) или i18n.T("…").
  2. Изпълнете make i18n-extract в server/. Това добавя идентификатора в server/i18n/en.json в правилния ред.
  3. Запишете английския translation и description на новия запис.

Други езици

Всеки език има свой файл до en.json (fr.json, pt-BR.json, zh-TW.json…). За да докладате грешен превод, отворете проблем в общностното хранилище с езика, текста и мястото, където се появява.

Вградените приложения съхраняват текстове в webapp/i18n/; вижте Преводи в страницата за приложения.

Документация и този уебсайт

Този уебсайт и неговата документация са в хранилището antimatter.chat. Страниците са HTML фрагменти в src/pages/; python3 src/build.py изгражда сайта. Корекции и липсващи обяснения са добре дошли като проблеми или заявки за сливане.

Проблеми с сигурността

Никога не докладвайте проблем с сигурността в публичен проблем, дискусия или заявка за сливане.

Докладвайте го поверително чрез GitHub-а за поверително докладване на уязвимости: отворете раздела Сигурност на засегнатото хранилище (напр. сървъра) и изберете Report a vulnerability. Ако не знаете кое хранилище е засегнато, докладвайте го в хранилището на общността. Включете компонента и неговата версия, какво би могъл да направи атакуващият, как да се възпроизведе проблемът и от кои настройки зависи.

Поддръжниците отговарят там, ви държат в течение, докато го поправят, и публикуват съобщение, щом излезе поправена версия. Моля, дайте им разумно време, преди да разкриете проблема. Поправките влизат в най-новото издание. Пълната политика е в политиката за сигурност.

Лицензи

  • Сървърът е под GNU Affero General Public License v3.0 (AGPL v3). В същото хранилище административните инструменти и файловете с конфигурация (server/templates/, server/i18n/, server/public/ и webapp/) са под Apache License 2.0. Вижте LICENSE.txt и NOTICE.txt.
  • Приложения: собствени приложения на Antimatter, като анкети, са под AGPL v3; приложения, разклонени от Mattermost, запазват оригиналния си лиценз. Всяко хранилище посочва кой лиценз използва в файла си LICENSE.
  • Десктопните и мобилните приложения са под Apache License 2.0. Хранилището за Docker е под Apache License 2.0, с изключение на Dockerfile, който е под AGPL v3.

AGPL означава, че ако пуснете модифициран сървър на Antimatter за други хора през мрежа, трябва да им предоставите изходния код на промените си. Antimatter се базира на Mattermost; не е афилиран или одобрено от Mattermost, Inc.

Всички, които участват, спазват кодекса на поведение.