योगदान

Bug reports, ideas, translations, documentation और code — सब का स्वागत है। यह पेज बताता है कि बातचीत कहाँ करें, बदलाव कैसे भेजें, code कौन-से नियमों का पालन करता है, और security समस्याओं और licences के लिए कौन-से नियम हैं।

बातचीत कहाँ करें

Antimatter के किसी भी हिस्से के बारे में हो, सब कुछ community repository से शुरू होता है:

  • Bugs और feature requests: issue खोलें और Bug report, Feature request, या Plugin or integration request चुनें। पहले मौजूदा issues खोजें; अगर आपका issue वहाँ है, तो thumbs-up दें या अपनी जानकारी जोड़ें।
  • प्रश्न और ideas: Discussions में, Q&A या Ideas श्रेणियों में।
  • बड़े बदलाव से पहले, पहले approach पर सहमति बनाने के लिए issue या discussion खोलें। इससे एक pull request बच जाता है जिसे ऐसे ही merge नहीं किया जा सकता।

good first issue और help wanted लेबल वाले इश्यूज़ शुरू करने के लिए अच्छे स्थान हैं। एक कमेंट में बताएं कि आप किसी एक पर काम कर रहे हैं। नए इश्यूज़ को status/triage लेबल दिया जाता है, फिर status/accepted, status/planned या status/wontfix। इश्यूज़ चाहे किस बारे में हों, वे कम्युनिटी रिपॉज़िटरी में ही रहते हैं: कोड रिपॉज़िटरी इश्यूज़ नहीं लेतीं। योजनाबद्ध काम Antimatter रोडमैप पर है।

Repositories और branches

Code AntimatterChat organisation में है; Code कहाँ है में repositories की सूची है। हर repository में:

  • main default branch है और Antimatter का code रखती है। इससे branch बनाएं और इसी में pull requests भेजें।
  • Mattermost से fork किए गए repositories में upstream branch भी होती है, जो Mattermost के code का mirror है और उनके बदलाव लाने के लिए उपयोग होती है। इस पर काम आधारित न करें।

हर repository का README बताता है कि उसे कैसे build और test करें। Server और web interfaces के लिए, Source से build करना देखें; apps के लिए, Build, install और debug।

Pull requests

  1. रिपॉज़िटरी को फ़ोर्क करें और main से एक ब्रांच बनाएं।
  2. हर पुल रिक्वेस्ट में केवल एक परिवर्तन रखें। छोटे पुल रिक्वेस्ट जल्दी समीक्षा किए जाते हैं।
  3. आस-पास के कोड के शैली का पालन करें और जहाँ उचित हो, टेस्ट जोड़ें या अपडेट करें।
  4. वर्णन करें कि आपने क्या बदला और क्यों, और उस इश्यू से लिंक करें जिसे यह ठीक करता है: Fixes AntimatterChat/community#123।
  5. सुनिश्चित करें कि जांचें पास हो रही हैं। एक मंटेनर पुल रिक्वेस्ट की समीक्षा करता है और परिवर्तनों के लिए अनुरोध कर सकता है।

सर्वर रिपॉज़िटरी में, पुल रिक्वेस्ट टेम्पलेट भरें: एक सारांश, और रिलीज़ नोट ब्लॉक, जो हमेशा होना चाहिए। जब परिवर्तन किसी API, कॉन्फ़िगरेशन, डेटाबेस स्कीमा या दृश्य व्यवहार को प्रभावित न करे, तो उसमें NONE लिखें।

योगदान करके, आप सहमत हैं कि आपका योगदान उस रिपॉज़िटरी की लाइसेंस के तहत लाइसेंस प्राप्त है जिसमें आप योगदान दे रहे हैं।

कॉमिट्स और कोड शैली

कॉमिट्स

इतिहास में कमिट संदेश एक छोटा सा वाक्य होता है जो बताता है कि क्या बदलाव हुआ, जिसमें पहला अक्षर बड़ा (sentence case) होता है और अंत में पूर्ण विराम (full stop) नहीं होता। किसी एक भाग में किए गए बदलावों के आगे उस भाग का नाम रखा जाता है, जैसे 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 चलाएं।
  • रिक्वेस्ट पाथ में, रिक्वेस्ट के लॉगर के साथ लॉग करें। स्टोर लेयर में, request.CTX लें, context.Context नहीं।
  • नए API एंडपॉइंट server/channels/api4 में जाते हैं, उनके टाइप्स server/public/model में, और आदर्श रूप से model.Client4 में एक मेथड और TypeScript क्लाइंट में।

वेब इंटरफेस (TypeScript और React)

  • webapp/ में make check-style और make check-types चलाएं।
  • क्लासिक इंटरफेस webapp/STYLE_GUIDE.md का पालन करता है: फंक्शनल कंपोनेंट्स, Redux के लिए हुक्स, रंगों के लिए थीम वेरिएबल्स, और सुलभ (accessible) मार्कअप।
  • Fusion के कंपोनेंट्स webapp/fusion/src/fusion में हैं, उनके स्टाइल्स webapp/fusion/src/fusion/styles में। वे am() हेल्पर के साथ क्लास नाम बनाते हैं और Fusion के डिज़ाइन टोकन का उपयोग करते हैं; अपने पास मौजूद फ़ाइलों का पालन करें।
  • ऐप्स के लिए नए window.* ग्लोबल न जोड़ें। नए ऐप-फेसिंग यूटिलिटीज़ window.WebappUtils के तहत जाती हैं, जैसा कि webapp/AGENTS.md में समझाया गया है।
  • ऐप रजिस्ट्री (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 भरें: स्ट्रिंग कहाँ दिखाई देती है और इसका उपयोग कैसे होता है। यह वह संदर्भ है जिसके आधार पर अनुवादक, चाहे मानव हों या मशीन, काम करते हैं।

यदि en.json कोड के साथ अपडेट नहीं है, तो npm run i18n-extract:check विफल हो जाता है।

सर्वर में स्ट्रिंग जोड़ना

  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…)। गलत अनुवाद की रिपोर्ट करने के लिए, कृपया क्वायरी रिपॉज़िटरी में एक issue खोलें जिसमें भाषा, टेक्स्ट और वह स्थान शामिल हो जहाँ वह दिखाई देता है।

बंडल किए गए ऐप्स अपनी स्ट्रिंग्स webapp/i18n/ में रखते हैं; ऐप्स पेज में Translations देखें।

दस्तावेज़ीकरण और यह वेबसाइट

यह वेबसाइट और इसका दस्तावेज़ीकरण antimatter.chat रिपॉज़िटरी में है। पेज src/pages/ में HTML फ़्रैगमेंट्स हैं; python3 src/build.py साइट बनाता है। सुधार और अनुपूरक विवरण issues या pull requests के रूप में स्वागत हैं।

सुरक्षा संबंधी समस्याएँ

कभी भी सुरक्षा संबंधी समस्या की रिपोर्ट किसी सार्वजनिक issue, discussion या pull request में न करें।

इसे GitHub के प्राइवेट वल्नेरेबिलिटी रिपोर्टिंग के माध्यम से निजी रूप से रिपोर्ट करें: प्रभावित रिपॉज़िटरी (उदाहरण के लिए सर्वर) का सुरक्षा टैब खोलें और Report a vulnerability चुनें। यदि आपको पता नहीं है कि कौन सा रिपॉज़िटरी प्रभावित है, तो कम्युनिटी रिपॉज़िटरी पर रिपोर्ट करें। इसमें घटक (component) और उसकी संस्करण (version), हमलावर (attacker) क्या कर सकता है, इसे कैसे प्रतिकृति (reproduce) किया जा सकता है, और इस पर निर्भर कोई भी कॉन्फ़िगरेशन शामिल करें।

मैटेनेनर वहाँ जवाब देते हैं, उसे ठीक करते समय आपको अपडेट करते रहते हैं, और एक ठीक किया गया रिलीज़ आने पर एक एडवाइज़री प्रकाशित करते हैं। कृपया समस्या का खुलासा करने से पहले उन्हें उचित समय दें। सुधार नवीनतम रिलीज़ में शामिल किए जाते हैं। पूरी नीति सुरक्षा नीति में उपलब्ध है।

लाइसेंस

  • सर्वर 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 के अपने ऐप्स, जैसे Polls, AGPL v3 के अंतर्गत हैं; Mattermost से फ़ोर्क किए गए ऐप्स अपने मूल लाइसेंस को बनाए रखते हैं। प्रत्येक रिपॉज़िटरी अपने LICENSE फ़ाइल में यह बताता है कि वह किस लाइसेंस के अंतर्गत है।
  • डेस्कटॉप और मोबाइल ऐप्स Apache License 2.0 के अंतर्गत हैं। Docker रिपॉज़िटरी Apache License 2.0 के अंतर्गत है, सिवाय इसके Dockerfile का, जो AGPL v3 के अंतर्गत है।

AGPL का अर्थ है कि यदि आप नेटवर्क के ज़रिए अन्य लोगों के लिए एक संशोधित Antimatter सर्वर चलाते हैं, तो आपको अपने परिवर्तनों का स्रोत कोड उन्हें प्रदान करना होगा। Antimatter, Mattermost पर आधारित है; यह Mattermost, Inc. से संबद्ध या अनुमोदित नहीं है।

सभी भागीदार व्यवहार संहिता का पालन करते हैं।