Add Bengali translations

docs/additional-material/translations/Bengali/check-commit-log-bn.md

@@ -0,0 +1,39 @@
+# কমিট লগ পরীক্ষা করুন
+
+কোনও শাখা বা ফাইলের জন্য কমিট লগ পরীক্ষা করার জন্য, নিম্নলিখিত কমান্ডটি ব্যবহার করা যেতে পারে:
+
+`git log [options] [path]`
+
+এই কমান্ডের আউটপুট ডিফল্টরূপে বিপরীত কালানুক্রমিক ক্রমে দেওয়া হয়।
+
+## কমান্ড আউটপুট উদাহরণ
+```
+$ git log
+commit e3fabb30ab536bd5876461d8a749301a321e714f (HEAD -> check-commit-log-ko, upstream/main, origin/main, origin/HEAD, main)
+লেখক: ড্যান ইউনহিউম সিওল <yunheum.seol@mail.mcgill.ca>
+
+তারিখ: মঙ্গলবার ৪ জুন ০১:০৭:২৫ ২০২৪ -০৪০০
+
+অবদানকারীদের তালিকায় ড্যান-সিওল যোগ করুন (#৮৪৯৬২)
+
+commit 4af4ec8a56e057ce8768af77eda528453974d0bc
+লেখক: এডগার হাম্বার্তো তিজেরিনা তেমেজ <168693312+EdgarHTT@users.noreply.github.com>
+
+তারিখ: সোমবার ৩ জুন ২৩:০৬:০৫ ২০২৪ -০৬০০
+
+এডগার টিজেরিনাকে অবদানকারীদের তালিকায় যোগ করুন (#৮৪৯৬১)
+```
+
+## কমান্ডের বৈচিত্র্য এবং বিকল্প
+- একটি নির্দিষ্ট কমিট আইডি থেকে পৌঁছানো যায় এমন কমিটগুলি সম্পাদন করার জন্য: <i>(এই ক্ষেত্রে, `foo` এবং `bar`)</i><br>
+`git log foo bar `
+- কমিট আইডির সামনে `^` যোগ করে একটি প্রদত্ত কমিট আইডি থেকে পৌঁছানো যায় এমন কমিটগুলি অপসারণ করাও সম্ভব: <i>(এই ক্ষেত্রে, `baz`)</i><br>
+`git log foo bar ^baz`
+- একটি নির্দিষ্ট ফাইলের জন্য কমিট লগ: <br>
+
+git log --all <filename>`
+- লগে কমিটের সংখ্যা সীমিত করুন: <i>(এই ক্ষেত্রে, `5`)</i><br>
+`git log -n 5`
+
+## দেখুন
+- [অফিসিয়াল ডকুমেন্টেশন](https://git-scm.com/docs/git-log)

docs/additional-material/translations/Bengali/creating-gitignore-file-bn.md

@@ -0,0 +1,79 @@
+## .gitignore বোঝা
+
+`.gitignore` ফাইলটি Git-এর কর্মপ্রবাহের একটি অপরিহার্য উপাদান। এটি Git-কে বলে যে কোন ফাইল এবং ফোল্ডারগুলিকে উপেক্ষা করতে হবে, যা আপনার সংগ্রহস্থলে অপ্রয়োজনীয় বা সংবেদনশীল ডেটা ট্র্যাক করা থেকে বিরত রাখে।
+
+## কেন .gitignore ব্যবহার করবেন?
+
+কিছু ফাইল সংস্করণ নিয়ন্ত্রণে অন্তর্ভুক্ত করা উচিত নয় কারণ সেগুলি হল:
+- অস্থায়ী বা সিস্টেম-উত্পাদিত (যেমন, ক্যাশে, বিল্ড ফাইল, লগ)
+- বৃহৎ নির্ভরতা যা পুনরায় ইনস্টল করা যেতে পারে (যেমন, `node_modules`)
+- ব্যক্তিগত বা সংবেদনশীল কনফিগারেশন ফাইল (যেমন, API কী, পরিবেশ ভেরিয়েবল)
+- IDE বা সম্পাদক-নির্দিষ্ট ফাইল (যেমন, `.vscode/`, `.idea/`)
+
+এই ফাইলগুলি উপেক্ষা করলে সংগ্রহস্থল পরিষ্কার থাকে, দ্বন্দ্ব হ্রাস পায় এবং নিরাপত্তা ঝুঁকি প্রতিরোধ করে।
+
+## একটি .gitignore ফাইল তৈরি করা
+
+একটি `.gitignore` ফাইল তৈরি করতে:
+
+১. আপনার প্রোজেক্ট রুট ডিরেক্টরিতে, `.gitignore` নামে একটি নতুন টেক্সট ফাইল তৈরি করুন।
+
+২. আপনি যে ফাইল এবং ফোল্ডারগুলিকে উপেক্ষা করতে চান তার তালিকা তৈরি করুন, প্রতি লাইনে একটি করে।
+
+৩. ফাইলটি সংরক্ষণ করুন।
+
+### .gitignore এর জন্য মৌলিক সিনট্যাক্স
+- `*` → একাধিক ফাইল মেলানোর জন্য ওয়াইল্ডকার্ড।
+- `/` → `.gitignore` এর সাথে সম্পর্কিত পথ নির্দিষ্ট করে।
+- `#` → মন্তব্য যোগ করে।
+
+### উদাহরণ .gitignore ফাইল:
+```sh
+# ম্যাক সিস্টেম ফাইল উপেক্ষা করুন
+.DS_Store
+
+# নির্ভরতা ফোল্ডার উপেক্ষা করুন
+node_modules/
+
+venv/
+
+# লগ এবং ক্যাশে ফাইল উপেক্ষা করুন
+*.log
+.cache/
+
+# পরিবেশ ফাইল উপেক্ষা করুন
+.env
+
+# সকল টেক্সট ফাইল উপেক্ষা করুন
+*.txt
+```
+
+## গ্লোবাল .gitignore (সকল প্রকল্পের জন্য)
+একটি গ্লোবাল `.gitignore` ফাইল তৈরি করতে (সকল সংগ্রহস্থলের ক্ষেত্রে প্রযোজ্য):
+```sh
+git config --global core.excludesfile ~/.gitignore_global
+```
+তারপর, `~/.gitignore_global` সম্পাদনা করুন যেমন আপনি একটি স্থানীয় `.gitignore` করবেন।
+
+## গিট ট্র্যাকিং থেকে ফাইল অপসারণ
+
+যদি কোনও ফাইল `.gitignore` এ যোগ করার আগে ইতিমধ্যেই কমিট করা হয়ে থাকে, তাহলে আপনাকে এটি ট্র্যাকিং থেকে সরিয়ে ফেলতে হবে:
+
+- **একটি ফাইল আনট্র্যাক করুন** (তবে স্থানীয়ভাবে রাখুন):
+```sh
+git rm --cached filename
+```
+
+- **সকল উপেক্ষা করা ফাইল আনট্র্যাক করুন**:
+``sh
+git rm -r --cached .
+
+git add .
+
+git commit -m "আপডেট করা .gitignore"
+```
+
+`git rm --cached filename` পূর্বাবস্থায় ফেরাতে, ব্যবহার করুন:
+``sh
+git add filename
+```

docs/additional-material/translations/Bengali/gitflow-bn.md

@@ -0,0 +1,162 @@
+গিটফ্লো (Gitflow)
+
+গিটফ্লো হলো একটি গিট ব্রাঞ্চিং মডেল, যা ভিনসেন্ট ড্রিসেন প্রস্তাব করেছিলেন। এখানে মূলত এর প্রয়োজনীয়তা ও ব্যবহারিক দিকগুলো নিয়ে আলোচনা করা হলো।
+
+গিটফ্লো ওয়ার্কফ্লো একটি কড়া ব্রাঞ্চিং মডেল, যা প্রজেক্টের রিলিজ সাইকেলকে ঘিরে তৈরি। এটি বড় প্রজেক্ট ম্যানেজ করার জন্য একটি শক্তিশালী কাঠামো দেয়। বিশেষ করে নির্দিষ্ট সময়ে রিলিজ দেওয়া প্রকল্পের জন্য এবং Continuous Delivery (CD) এর মতো DevOps প্র্যাকটিসের জন্য এটি উপযোগী।
+
+গিটফ্লো প্রতিটি ব্রাঞ্চের জন্য নির্দিষ্ট ভূমিকা ঠিক করে দেয় এবং কখন কীভাবে এগুলো একে অপরের সাথে মিশবে তা নির্ধারণ করে। এখানে আলাদা ব্রাঞ্চ ব্যবহার করা হয় প্রস্তুতি, রক্ষণাবেক্ষণ এবং রিলিজ সংরক্ষণ করার জন্য।
+
+বাস্তবায়ন (Implementation)
+1. ডেভেলপ (develop) এবং মাস্টার (master) ব্রাঞ্চ
+
+সাধারণভাবে একটি মাস্টার ব্রাঞ্চ থাকার বদলে গিটফ্লো দুইটি প্রধান ব্রাঞ্চ ব্যবহার করে, যেগুলোর লাইফটাইম অসীম ধরা হয়।
+
+Master Branch: প্রোডাকশন কোড থাকে এখানে। অফিসিয়াল রিলিজ ইতিহাস সংরক্ষিত হয় এই ব্রাঞ্চে।
+
+Develop Branch: এখানে প্রি-প্রোডাকশন কোড থাকে। নতুন ফিচারগুলোর ইন্টিগ্রেশনের জন্য এটি ব্যবহৃত হয়।
+
+Develop ব্রাঞ্চ তৈরি করা:
+
+👉 গিটফ্লো এক্সটেনশন ছাড়া:
+
+git branch develop
+git push -u origin develop
+
+
+👉 গিটফ্লো এক্সটেনশন দিয়ে:
+
+git flow init
+
+2. ফিচার (Feature) ব্রাঞ্চ
+
+প্রতিটি নতুন ফিচার একটি আলাদা ব্রাঞ্চে তৈরি হয়। এগুলো develop ব্রাঞ্চ থেকে তৈরি হবে এবং কাজ শেষ হলে develop এ মার্জ করা হবে। কোনো ফিচার ব্রাঞ্চ সরাসরি master এর সাথে যুক্ত হবে না।
+
+Feature ব্রাঞ্চ তৈরি করা:
+
+👉 গিটফ্লো এক্সটেনশন ছাড়া:
+
+git checkout develop
+git checkout -b feature_branch
+
+
+👉 গিটফ্লো এক্সটেনশন দিয়ে:
+
+git flow feature start feature_branch
+
+
+Feature ব্রাঞ্চ শেষ করা:
+
+👉 গিটফ্লো এক্সটেনশন ছাড়া:
+
+git checkout develop
+git merge feature_branch
+
+
+👉 গিটফ্লো এক্সটেনশন দিয়ে:
+
+git flow feature finish feature_branch
+
+3. রিলিজ (Release) ব্রাঞ্চ
+
+যখন develop ব্রাঞ্চে পর্যাপ্ত ফিচার যুক্ত হয় (বা নির্ধারিত রিলিজ সময় চলে আসে), তখন develop থেকে একটি release ব্রাঞ্চ তৈরি হয়।
+
+এই ব্রাঞ্চ তৈরি হওয়ার পর আর নতুন ফিচার যোগ করা যাবে না। শুধু বাগ ফিক্স, ডকুমেন্টেশন, এবং রিলিজ সংক্রান্ত পরিবর্তন করা যাবে। Release ব্রাঞ্চ শেষে master এবং develop – দুইটিতেই মার্জ হবে।
+
+Release ব্রাঞ্চ তৈরি করা:
+
+👉 গিটফ্লো এক্সটেনশন ছাড়া:
+
+git checkout develop
+git checkout -b release/0.1.0
+
+
+👉 গিটফ্লো এক্সটেনশন দিয়ে:
+
+git flow release start 0.1.0
+
+
+Release ব্রাঞ্চ শেষ করা:
+
+👉 গিটফ্লো এক্সটেনশন ছাড়া:
+
+git checkout master
+git merge release/0.1.0
+
+
+👉 গিটফ্লো এক্সটেনশন দিয়ে:
+
+git flow release finish 0.1.0
+
+4. হটফিক্স (Hotfix) ব্রাঞ্চ
+
+হঠাৎ প্রোডাকশনে কোনো সমস্যা ধরা পড়লে দ্রুত সমাধানের জন্য hotfix ব্রাঞ্চ তৈরি হয়। এটি সরাসরি master থেকে তৈরি হয়।
+
+ফিক্স শেষ হলে এটি master এবং develop (বা বর্তমান release ব্রাঞ্চ) – উভয়েই মার্জ হবে। এরপর master এ নতুন ভার্সন ট্যাগ করা হবে।
+
+Hotfix ব্রাঞ্চ তৈরি করা:
+
+👉 গিটফ্লো এক্সটেনশন ছাড়া:
+
+git checkout master
+git checkout -b hotfix_branch
+
+
+👉 গিটফ্লো এক্সটেনশন দিয়ে:
+
+git flow hotfix start hotfix_branch
+
+
+Hotfix ব্রাঞ্চ শেষ করা:
+
+👉 গিটফ্লো এক্সটেনশন ছাড়া:
+
+git checkout master
+git merge hotfix_branch
+git checkout develop
+git merge hotfix_branch
+
+
+👉 গিটফ্লো এক্সটেনশন দিয়ে:
+
+git branch -D hotfix_branch
+git flow hotfix finish hotfix_branch
+
+সুবিধা (Advantages)
+
+যেকোনো সময় প্রকল্পের ব্রাঞ্চের অবস্থা পরিষ্কার থাকে।
+
+ব্রাঞ্চের নামকরণ নিয়মতান্ত্রিক হওয়ায় সহজে বোঝা যায়।
+
+গিটফ্লো অনেক জনপ্রিয় টুলে এক্সটেনশনসহ সমর্থিত।
+
+একাধিক প্রোডাকশন ভার্সন রক্ষণাবেক্ষণের জন্য উপযোগী।
+
+রিলিজ-ভিত্তিক সফটওয়্যার ওয়ার্কফ্লোর জন্য আদর্শ।
+
+প্রোডাকশনে হঠাৎ সমস্যার সমাধানের জন্য আলাদা চ্যানেল দেয়।
+
+অসুবিধা (Disadvantages)
+
+গিট ইতিহাস অনেক সময় জটিল হয়ে যায়।
+
+master/develop বিভাজন Continuous Delivery বা Continuous Integration–এর জন্য জটিলতা বাড়ায়।
+
+যদি একটাই প্রোডাকশন ভার্সন থাকে, তবে এটি ব্যবহার করা সুপারিশ করা হয় না।
+
+সারসংক্ষেপ (Summary)
+
+গিটফ্লো ওয়ার্কফ্লোর মূল ধাপগুলো হলো:
+
+master থেকে একটি develop ব্রাঞ্চ তৈরি হয়।
+
+নতুন ফিচার develop থেকে তৈরি হয়।
+
+ফিচার শেষ হলে develop এ মার্জ হয়।
+
+develop থেকে একটি release ব্রাঞ্চ তৈরি হয়।
+
+release ব্রাঞ্চ শেষ হলে এটি master এবং develop – উভয়েই মার্জ হয়।
+
+master এ কোনো সমস্যা হলে master থেকে hotfix ব্রাঞ্চ তৈরি হয়।
+
+hotfix শেষ হলে এটি develop এবং master – উভয়েই মার্জ হয়।

docs/additional-material/translations/Bengali/merge-conflict.md

@@ -0,0 +1,54 @@
+মার্জ কনফ্লিক্ট (Merge Conflict) কী?
+
+যখন আপনি অন্য কোনো ব্রাঞ্চকে আপনার বর্তমান কাজের ব্রাঞ্চের সাথে মার্জ করতে চান, তখন মূলত অন্য একটি কনটেক্সট থেকে পরিবর্তন নিয়ে এসে আপনার বর্তমান ফাইলগুলোর সাথে মিশিয়ে দিচ্ছেন।
+
+কিন্তু যদি একই ফাইলের একই লাইন একাধিক ব্যক্তি পরিবর্তন করে থাকেন, অথবা একজন ফাইল ডিলিট করে ফেলেছেন আর অন্যজন সেটি পরিবর্তন করেছেন — তখন গিট বুঝতে পারে না কোন ভার্সন রাখা উচিত।
+এই পরিস্থিতিতেই গিট ফাইলটিকে conflict অবস্থায় চিহ্নিত করে। আপনাকেই সেটি সমাধান করতে হয়, তারপর কাজ চালিয়ে যেতে পারবেন।
+
+মার্জ কনফ্লিক্ট কীভাবে সমাধান করবেন?
+
+যখন merge conflict হয়, গিট ফাইলের ভেতরে বিশেষ চিহ্ন দিয়ে সমস্যাযুক্ত অংশগুলো দেখায়।
+
+এটি সাধারণত এরকম থাকে:
+
+<<<<<<< HEAD:mergetest
+This is my third line
+=======
+This is a fourth line I am adding
+>>>>>>> 4e2b407f501b68f8588aa645acafffa0224b9b78:mergetest
+
+
+<<<<<<< HEAD: এখানে আপনার বর্তমান ব্রাঞ্চের কনটেন্ট থাকবে।
+
+=======: উপরের (আপনার ব্রাঞ্চের) পরিবর্তন আর নিচের (অন্য ব্রাঞ্চের) পরিবর্তনের মাঝে পার্থক্য বোঝানোর জন্য ব্যবহৃত হয়।
+
+>>>>>>>: এখানে অন্য ব্রাঞ্চ থেকে আসা পরিবর্তনগুলো থাকে।
+
+👉 আপনাকে ফাইলটি এডিট করে ঠিক করতে হবে কোন কনটেন্ট থাকবে।
+
+হয় আপনার পরিবর্তন রাখতে পারেন
+
+নয়তো অন্যজনের পরিবর্তন রাখতে পারেন
+
+অথবা দুইটিকে মিলিয়ে একটি নতুন ভার্সন বানাতে পারেন।
+
+কাজ শেষে অবশ্যই <<<<<<<, =======, >>>>>>> এই মার্কার লাইনগুলো মুছে ফেলতে হবে।
+
+সমাধানের ধাপ:
+
+ফাইল এডিট করে কনফ্লিক্ট ঠিক করুন।
+
+পরিবর্তন নিশ্চিত করতে git add করুন।
+
+সব টেস্ট রান করে নিশ্চিত হোন যে সমাধান সঠিক হয়েছে।
+
+👉 চাইলে আপনার IDE-এর জন্য প্লাগইন ব্যবহার করতে পারেন, যা ভিজ্যুয়ালভাবে কনফ্লিক্ট রেজলভ করা সহজ করে দেয়।
+
+কীভাবে একটি Merge বাতিল করবেন?
+
+যদি মার্জ করার সময় ভুল হয় বা মাঝপথে বাতিল করতে চান, তাহলে নিচের কমান্ড ব্যবহার করতে পারেন:
+
+git merge --abort
+
+
+এটি মার্জ প্রক্রিয়াটি থামিয়ে দেয় এবং আপনার ব্রাঞ্চকে আগের অবস্থায় ফিরিয়ে নিয়ে যায়।

docs/additional-material/translations/Bengali/things-a-non-programmer-can-do-bn.md

@@ -0,0 +1,81 @@
+# একজন নন-প্রোগ্রামার যা করতে পারেন
+## শোনা শুরু করুন
+
+ওপেন সোর্স-এ সবকিছুতেই অন্যরা জড়িত।
+
+আপনি একটি দলে যোগ দিতে চাইছেন, এবং এর অর্থ হল সম্প্রদায়টি এবং এটি কীভাবে কাজ করে তা বোঝা।
+
+একটি প্রকল্পে প্রবেশ করে "হাই, আমার মনে হয় এই প্রকল্পটি কী করা উচিত" বলা সাধারণত ভালো জিনিস হিসাবে নেওয়া হয় না।
+
+কিছু প্রকল্প এই ধরণের পদ্ধতিকে স্বাগত জানাতে পারে, কিন্তু যদি প্রকল্পটি দীর্ঘদিন ধরে চলছে, তাহলে সেই মনোভাব গ্রহণের সম্ভাবনা কম।
+**প্রকল্পের কী প্রয়োজন তা জানার জন্য শোনাই সর্বোত্তম উপায়।**
+
+১. **একটি মেইলিং তালিকায় যোগদান করুন**: অনেক প্রকল্পের জন্য, মেইলিং তালিকা হল প্রকল্পের উন্নয়ন সম্পর্কে যোগাযোগের প্রধান মাধ্যম।
+
+বড় প্রকল্পে, বেছে নেওয়ার জন্য অনেক মেইলিং তালিকা রয়েছে।
+
+উদাহরণস্বরূপ, PostgreSQL প্রকল্পের মেইলিং তালিকা পৃষ্ঠায় কমপক্ষে ১২টি ব্যবহারকারী-ভিত্তিক তালিকা এবং ছয়টি বিকাশকারী তালিকা রয়েছে।
+
+আমি আপনাকে প্রধান ব্যবহারকারী-ভিত্তিক তালিকা এবং মূল বিকাশকারী তালিকা অনুসরণ করার পরামর্শ দিচ্ছি যেখানে আপনি শুনতে শুরু করবেন।
+
+২. **একটি ব্লগ অনুসরণ করুন**: মূল ডেভেলপারদের দ্বারা পরিচালিত ব্লগগুলি প্রায়শই ভবিষ্যতের রিলিজে কী আসছে,
+এবং সেখানে পৌঁছানোর জন্য কী কী প্রয়োজন সে সম্পর্কে তথ্য দেয়। একটি প্ল্যানেট সাইট প্রকল্পের সাথে সম্পর্কিত অনেক উৎস থেকে সংবাদ এবং ব্লগ এন্ট্রি একত্রিত করে।
+
+যদি planet.gnome.org বা planet.mysql.com এর মতো কোনও প্ল্যানেট সাইট থাকে, তাহলে সেখান থেকে শুরু করুন। "planet <projectname>" লিখে গুগলে অনুসন্ধান করুন।
+
+৩. **একটি IRC চ্যানেলে যোগদান করুন**: অনেক ওপেন সোর্স প্রকল্পে ডেডিকেটেড ইন্টারনেট রিলে চ্যাট (IRC) চ্যানেল থাকে যেখানে ডেভেলপার এবং ব্যবহারকারীরা সমস্যা এবং উন্নয়ন নিয়ে আলোচনা করতে আড্ডা দেয়।
+চ্যানেলটির নাম এবং এটি কোন IRC নেটওয়ার্কে পাওয়া যায় তার বিশদ জানতে প্রকল্পের ওয়েবসাইটটি দেখুন।
+
+**টিকিট নিয়ে কাজ করুন**
+
+কোড হল যেকোনো ওপেন সোর্স প্রকল্পের হৃদয়, কিন্তু মনে করবেন না যে কোড লেখাই অবদান রাখার একমাত্র উপায়।
+নতুন বৈশিষ্ট্য তৈরি এবং বাগ সংশোধন করার তাড়াহুড়োয় কোড এবং কোডের চারপাশের সিস্টেমগুলি প্রায়শই অবহেলিত হয়।
+
+এই ক্ষেত্রগুলিকে একটি প্রকল্পে আপনার পা রাখার সহজ উপায় হিসেবে দেখুন।
+
+বেশিরভাগ প্রকল্পের একটি সর্বজনীনভাবে দৃশ্যমান সমস্যা টিকিট সিস্টেম থাকে, যা প্রকল্পের ওয়েবসাইটের প্রথম পৃষ্ঠা থেকে লিঙ্ক করা হয় এবং ডকুমেন্টেশনে অন্তর্ভুক্ত থাকে।
+
+এটি ব্যবহারকারী এবং ডেভেলপারদের মধ্যে যোগাযোগের প্রাথমিক মাধ্যম। এটিকে আপডেট রাখা প্রকল্পকে সাহায্য করার একটি দুর্দান্ত উপায়।
+
+টিকিটিং সিস্টেমে আপনার বিশেষ অনুমতি নেওয়ার প্রয়োজন হতে পারে, যা বেশিরভাগ প্রকল্প নেতারা আপনাকে টিকিট পরিষ্কার করতে সাহায্য করার সময় দিতে পেরে খুশি হবেন।
+
+৪. **একটি বাগ নির্ণয়**: বাগগুলি প্রায়শই খারাপভাবে রিপোর্ট করা হয়।
+
+একটি বাগ নির্ণয় এবং ট্রাইএজিং ডেভেলপারদের সমস্যার সুনির্দিষ্ট দিকগুলি খুঁজে বের করার সময় সময় বাঁচাতে সাহায্য করতে পারে।
+
+যদি কোনও ব্যবহারকারী রিপোর্ট করেন, "আমি যখন X করি তখন সফ্টওয়্যারটি কাজ করে না," তাহলে সেই সমস্যার মধ্যে কী কী যায় তার সুনির্দিষ্ট দিকগুলি খুঁজে বের করার জন্য কিছু সময় ব্যয় করুন।
+
+এটি কি পুনরাবৃত্তিযোগ্য? আপনি কি বারবার সমস্যাটি তৈরি করার জন্য পদক্ষেপের একটি সেট তৈরি করতে পারেন? আপনি কি সমস্যাটি সংকুচিত করতে পারেন, যেমন শুধুমাত্র একটি ব্রাউজারে ঘটছে কিন্তু অন্য ব্রাউজারে নয়, অথবা একটি ডিস্ট্রো কিন্তু অন্য ব্রাউজারে নয়?
+
+যদিও আপনি জানেন না যে সমস্যাটি কী, পরিস্থিতি সংকুচিত করার জন্য আপনি যে প্রচেষ্টা করেন তা অন্য কারও পক্ষে এটি ঠিক করা সহজ করে তোলে।
+
+আপনি যা আবিষ্কার করেন, তা সকলের দেখার জন্য বাগ সিস্টেমের টিকিটে যুক্ত করুন।
+
+৫. **সংশোধিত বাগগুলি বন্ধ করুন**: প্রায়শই কোডবেসে বাগগুলি ঠিক করা হয় কিন্তু তাদের সম্পর্কে রিপোর্ট করা টিকিট টিকিটিং সিস্টেমে আপডেট করা হয় না।
+
+এই ক্রাফ্টটি পরিষ্কার করা সময়সাপেক্ষ হতে পারে, তবে এটি পুরো প্রকল্পের জন্য মূল্যবান।
+
+এক বছরেরও বেশি পুরানো টিকিটের জন্য টিকিট সিস্টেমে জিজ্ঞাসা করে শুরু করুন এবং দেখুন বাগটি এখনও বিদ্যমান কিনা।
+
+বাগটি ঠিক করা হয়েছে কিনা এবং বন্ধ করা যেতে পারে কিনা তা দেখতে প্রকল্পের রিলিজ পরিবর্তন লগটি পরীক্ষা করুন।
+
+যদি এটি ঠিক করা হয়েছে বলে জানা যায়, তাহলে টিকিটের সংস্করণ নম্বরটি নোট করুন এবং এটি বন্ধ করুন।
+
+সফ্টওয়্যারের সর্বশেষ সংস্করণ দিয়ে বাগটি পুনরায় তৈরি করার চেষ্টা করুন।
+
+যদি এটি সর্বশেষ সংস্করণ দিয়ে পুনরায় তৈরি করা না যায়, তাহলে টিকিটে এটি লিখে রাখুন এবং বন্ধ করে দিন।
+
+যদি এটি এখনও বিদ্যমান থাকে, তাহলে টিকিটেও এটি লিখে রাখুন এবং এটি খোলা রাখুন।
+
+কোডের সাথে কাজ করা
+সকল অভিজ্ঞতা স্তরের প্রোগ্রামাররা প্রকল্পের কোডের সাথে সাহায্য করতে পারে।
+
+ভাববেন না যে আপনার প্রিয় প্রকল্পে প্রকৃত অবদান রাখার জন্য আপনাকে একজন কোডিং প্রতিভা হতে হবে।
+
+যদি আপনার কাজের ক্ষেত্রে কোড পরিবর্তন জড়িত থাকে, তাহলে প্রকল্পটি অবদানকারীদের কাছ থেকে কোড পাওয়ার জন্য যে পদ্ধতি ব্যবহার করে তা অনুসন্ধান করুন।
+
+প্রতিটি প্রকল্পের নিজস্ব কর্মপ্রবাহ থাকে, তাই কোড জমা দেওয়ার আগে এটি কীভাবে করবেন তা জিজ্ঞাসা করুন।
+
+উদাহরণস্বরূপ, PostgreSQL প্রকল্পটি তার প্রক্রিয়ায় খুবই কঠোর: কোড পরিবর্তনগুলি প্যাচ আকারে একটি মেইলিং তালিকায় পাঠানো হয় যেখানে মূল বিকাশকারীরা পরিবর্তনের প্রতিটি দিক পরীক্ষা করে। অন্যদিকে, Parrot এর মতো একটি প্রকল্প যেখানে কোডবেসে কমিট সুবিধা পাওয়া সহজ। যদি প্রকল্পটি GitHub ব্যবহার করে, তাহলে এমন একটি কর্মপ্রবাহ থাকতে পারে যা GitHub এর পুল অনুরোধ বৈশিষ্ট্য ব্যবহার করে। কোনও দুটি প্রকল্প একই নয়।
+
+যখনই আপনি কোড পরিবর্তন করবেন, তখন নিশ্চিত করুন যে আপনি সম্প্রদায়ের একজন দায়িত্বশীল সদস্য হিসেবে কাজ করছেন এবং আপনার কোড স্টাইলটি কোডবেসের বাকি অংশের সাথে মিলে যাচ্ছে। আপনি যে কোডটি যোগ করবেন বা পরিবর্তন করবেন তা বাকি অংশের মতো দেখতে হবে। আপনার ব্রেসিং স্টাইল বা ইন্ডির জন্য স্পেস পরিচালনা পছন্দ নাও হতে পারে।