English | 简体中文 | 繁體中文 | 한국어 | Deutsch | Español | Français | Italiano | Dansk | 日本語 | Polski | Русский | Bosanski | العربية | Norsk | Português (Brasil) | ไทย | Türkçe | Українська | বাংলা | Ελληνικά | Tiếng Việt
আমরা OpenCode-এ অবদান রাখা আপনার জন্য সহজ করতে চাই। এখানে সর্বাধিক সাধারণত merge করা পরিবর্তনের ধরন রয়েছে:
- বাগ ফিক্স
- অতিরিক্ত LSP / ফরম্যাটার
- LLM পারফরম্যান্স উন্নতি
- নতুন প্রদানকারীদের সমর্থন
- পরিবেশ-নির্দিষ্ট সমস্যার জন্য ফিক্স
- অনুপস্থিত স্ট্যান্ডার্ড আচরণ
- ডকুমেন্টেশন উন্নতি
তবে, যেকোনো UI বা মূল পণ্য বৈশিষ্ট্য বাস্তবায়নের আগে কোর টিমের সাথে একটি ডিজাইন পর্যালোচনার মধ্য দিয়ে যেতে হবে।
সব PR অবশ্যই একটি বিদ্যমান issue-এর রেফারেন্স দিতে হবে। PR খোলার আগে, বাগ বা বৈশিষ্ট্য বর্ণনাকারী একটি issue খুলুন। এটি maintainer-দের triage করতে সাহায্য করে এবং ডুপ্লিকেট কাজ প্রতিরোধ করে। লিঙ্কযুক্ত issue ছাড়া PR পর্যালোচনা ছাড়াই বন্ধ হতে পারে।
দীর্ঘ, AI-উৎপন্ন PR বিবরণ এবং issues গ্রহণযোগ্য নয় এবং উপেক্ষা করা হতে পারে। maintainer-দের সময়ের সম্মান করুন:
- সংক্ষিপ্ত, কেন্দ্রীভূত বিবরণ লিখুন
- কী পরিবর্তন হয়েছে এবং কেন তা নিজের ভাষায় ব্যাখ্যা করুন
- যদি সংক্ষেপে ব্যাখ্যা করতে না পারেন, আপনার PR হয়তো অনেক বড়
PR শিরোনাম conventional commit মান অনুসরণ করা উচিত: feat: নতুন বৈশিষ্ট্য, fix: বাগ ফিক্স, docs: ডকুমেন্টেশন, chore: রক্ষণাবেক্ষণ, refactor: রিফ্যাক্টর, test: পরীক্ষা।
ডেভেলপমেন্ট পরিবেশ সেটআপ, বিল্ড কমান্ড এবং ডিবাগার কনফিগারেশনের সম্পূর্ণ বিবরণের জন্য ইংরেজি মূল CONTRIBUTING.md দেখুন।