Antimatter

기여하기

버그 보고, 아이디어, 번역, 문서 및 코드 모두 환영합니다. 이 페이지에서는 어디서 대화해야 하는지, 변경 사항을 어떻게 보내야 하는지, 코드가 따르는 규칙, 그리고 보안 문제와 라이선스에 대한 규칙을 설명합니다.

대화하는 곳

Antimatter의 어떤 부분에 관한 것이든, 모든 것은 커뮤니티 저장소에서 시작됩니다:

  • 버그 및 기능 요청: 이슈를 열기하여 버그 보고, 기능 요청 또는 플러그인 또는 통합 요청를 선택하세요. 먼저 기존 이슈를 검색해 보세요. 이미 해당 이슈가 있다면 엄지척 반응이나 추가 정보를 남겨 주세요.
  • 질문 및 아이디어: 토론의 Q&A 또는 아이디어 카테고리에서 진행하세요.
  • 큰 변경 사항을 시작하기 전에, 접근 방식에 대해 합의하기 위해 먼저 이슈나 토론을 열어 두세요. 이는 그대로 병합할 수 없는 풀 리퀘스트를 방지해 줍니다.

good first issue 및 help wanted 라벨이 붙은 이슈는 좋은 시작 지점입니다. 댓글로 해당 이슈를 작업 중임을 알려주세요. 새 이슈에는 status/triage 라벨이 붙은 뒤, status/accepted, status/planned 또는 status/wontfix 라벨이 붙습니다. 이슈의 주제와 관계없이 커뮤니티 저장소에 유지되며, 코드 저장소에는 이슈를 받지 않습니다. 계획된 작업은 Antimatter 로드맵에서 확인할 수 있습니다.

저장소와 브랜치

코드는 AntimatterChat 조직에 있으며, 코드의 위치에서 저장소를 나열합니다. 모든 저장소에서:

  • main은 기본 브랜치이며 Antimatter의 코드를 포함합니다. 이 브랜치에서 분기하여 풀 리퀘스트를 보내세요.
  • Mattermost에서 포크된 저장소에는 Mattermost 코드의 변경 사항을 가져오기 위해 사용되는 Mattermost 코드의 미러인 upstream 브랜치도 있습니다. 이 브랜치를 기반으로 작업을 하지 마세요.

각 저장소의 README는 빌드 및 테스트 방법을 설명합니다. 서버와 웹 인터페이스의 경우 소스에서 빌드를, 앱의 경우 빌드, 설치 및 디버깅을 참고하세요.

풀 리퀘스트

  1. 리포지토리를 포크하고 main에서 브랜치를 생성하세요.
  2. 각 풀 리퀘스트에는 하나의 변경 사항만 포함하세요. 작은 풀 리퀘스트는 더 빠르게 검토됩니다.
  3. 주변 코드의 스타일을 따르고, 적절한 곳에 테스트를 추가하거나 업데이트하세요.
  4. 무엇을 변경했는지, 그리고 왜 변경했는지 설명하고, 수정하는 이슈에 대한 링크를 포함하세요: Fixes AntimatterChat/community#123.
  5. 체크가 통과하는지 확인하세요. 유지보수자가 풀 리퀘스트를 검토하고 변경을 요청할 수 있습니다.

서버 리포지토리에서 풀 리퀘스트 템플릿을 작성하세요: 요약과, 항상 존재해야 하는 릴리스 노트 블록입니다. API, 설정, 데이터베이스 스키마 또는 눈에 보이는 동작에 영향을 주지 않는 변경인 경우 NONE을 입력하세요.

기여함으로써, 해당 리포지토리의 라이선스에 따라 기여가 라이선스된 데 동의하게 됩니다.

커밋 및 코드 스타일

커밋

히스토리 내 커밋 메시지는 무엇을 변경했는지 설명하는 한 문장의 짧은 문장으로, 문장 대문자 규칙을 따르며 마침표 없이 작성합니다. 특정 부분의 변경 사항은 해당 부분 이름으로 시작하며, 예를 들어 Fusion: a compact conversation header on phones 또는 Server: community attributes, and admin-only user attributes와 같습니다. 변경 사항마다 하나의 커밋을 생성하며, 명확하지 않은 이유는 본문에서 설명하세요.

서버 (Go)

  • 푸시하기 전에 server/에서 make check-style를 실행하세요.
  • go mod tidy를 직접 실행하지 마세요; make modules-tidy를 실행하세요.
  • 요청 경로에서는 요청의 로거를 사용하여 로깅하세요. 스토어 레이어에서는 context.Context가 아닌 request.CTX를 사용하세요.
  • 새로운 API 엔드포인트는 server/channels/api4에, 그 타입은 server/public/model에, 그리고 이상적으로는 model.Client4와 TypeScript 클라이언트에 메서드를 추가하세요.

웹 인터페이스 (TypeScript 및 React)

  • webapp/에서 make check-style와 make check-types를 실행하세요.
  • 클래식 인터페이스는 webapp/STYLE_GUIDE.md를 따릅니다: 함수형 컴포넌트, Redux를 위한 훅, 색상을 위한 테마 변수, 접근성 있는 마크업.
  • Fusion의 컴포넌트는 webapp/fusion/src/fusion에, 그 스타일은 webapp/fusion/src/fusion/styles에 있습니다. am() 헬퍼를 사용하여 클래스 이름을 생성하고 Fusion의 디자인 토큰을 사용합니다; 인접한 파일의 스타일을 따르세요.
  • 앱을 위해 새로운 window.* 전역 변수를 추가하지 마세요. 새로운 앱 대상 유틸리티는 webapp/AGENTS.md에 설명된 대로 window.WebappUtils 아래에 배치하세요.
  • 앱 레지스트리(plugins/registry.ts)에 대한 변경 사항은 보통 두 인터페이스의 복사본 모두에 반영해야 합니다.

번역

Antimatter와 번들된 앱은 37개 언어로 번역됩니다. 기여자는 영어 문자열을 추가하고, 다른 언어는 일괄적으로 업데이트됩니다.

웹 인터페이스에 문자열 추가

  1. ID와 영문 리터럴 텍스트를 함께 작성합니다: formatMessage({id: 'fusion.channelMenu.settings', defaultMessage: 'Channel settings'}) 또는 <FormattedMessage id='…' defaultMessage='…'/>. 앱에 표시되는 영어 텍스트는 defaultMessage에서 가져옵니다.
  2. webapp/에서 make i18n-extract를 실행합니다(또는 webapp/fusion 또는 webapp/channels에서 npm run i18n-extract를 실행). 해당 패키지의 src/i18n/en.json가 업데이트됩니다.
  3. en.json에서 새 항목의 description을 채웁니다: 문자열이 어디에 표시되는지, 어떻게 사용되는지. 번역자(사람이든 기계든)가 작업하는 데 필요한 문맥입니다.

npm run i18n-extract:check는 en.json이 코드와 동기화되지 않은 경우 실패합니다.

서버에 문자열 추가

  1. 코드에서 ID를 사용합니다. 예: model.NewAppError(…, "app.community_attributes.invalid.app_error", …) 또는 i18n.T("…").
  2. server/에서 make i18n-extract를 실행합니다. ID가 server/i18n/en.json에 올바른 순서로 추가됩니다.
  3. 새 항목의 영어 translation과 description을 작성합니다.

다른 언어

각 언어는 en.json 옆에 자체 파일이 있습니다(fr.json, pt-BR.json, zh-TW.json…). 잘못된 번역을 보고하려면 커뮤니티 저장소에서 언어, 텍스트, 표시 위치를 명시하여 이슈를 등록합니다.

번들된 앱은 문자열을 webapp/i18n/에 유지합니다. 앱 페이지의 번역을 참고하세요.

문서 및 이 웹사이트

이 웹사이트와 그 문서는 antimatter.chat 저장소에 있습니다. 페이지는 src/pages/의 HTML 조각이며, python3 src/build.py로 사이트를 빌드합니다. 수정 사항과 누락된 설명은 이슈 또는 풀 리퀘스트로 환영합니다.

보안 문제

보안 문제를 공개 이슈, 토론 또는 풀 리퀘스트로 보고하지 마세요.

GitHub의 비공개 취약점 보고 기능을 통해 비공개로 보고하세요. 영향받는 저장소(예: 서버)의 보안 탭을 열고 취약점 보고를 선택합니다. 영향받는 저장소를 알 수 없는 경우 커뮤니티 저장소에 보고하세요. 구성 요소와 해당 버전, 공격자가 수행할 수 있는 작업, 재현 방법, 그리고 의존하는 설정을 포함해 주세요.

유지보수 담당자가 해당 위치에 답변을 남기고, 수정이 진행되는 동안 최신 정보를 공유하며, 수정된 릴리스가 출시되면 보안 공지(advisory)를 게시합니다. 문제를 공개하기 전까지 합리적인 시간을 허용해 주세요. 수정 사항은 최신 릴리스에 반영됩니다. 전체 정책은 보안 정책에서 확인하실 수 있습니다.

라이선스

  • 서버는 GNU Affero General Public License v3.0(AGPL v3) 라이선스를 따릅니다. 같은 저장소 내의 관리자 도구와 설정 파일(server/templates/, server/i18n/, server/public/ 및 webapp/)은 Apache License 2.0을 따릅니다. LICENSE.txt와 NOTICE.txt를 참고하세요.
  • 앱: Polls와 같은 Antimatter 자체 앱은 AGPL v3 라이선스를 따르며, Mattermost에서 포크된 앱은 원래의 라이선스를 유지합니다. 각 저장소의 LICENSE 파일에서 해당 라이선스를 확인할 수 있습니다.
  • 데스크톱 및 모바일 앱은 Apache License 2.0을 따릅니다. Docker 저장소는 Apache License 2.0을 따르며, Dockerfile만 AGPL v3을 따릅니다.

AGPL은 네트워크를 통해 수정된 Antimatter 서버를 다른 사람에게 제공하는 경우, 해당 변경 사항의 소스 코드를 제공해야 함을 의미합니다. Antimatter는 Mattermost를 기반으로 하며, Mattermost, Inc.와 제휴하거나 그 회사의 승인을 받은 것이 아닙니다.

모든 참여자는 행동 강령을 준수합니다.