From ef989298751c18c0c1c031fe4a0047904ce5fd81 Mon Sep 17 00:00:00 2001
From: Stanly Halder <74023065+STANTHEGR8@users.noreply.github.com>
Date: Sun, 18 Jan 2026 23:21:04 +0600
Subject: [PATCH 1/2] best-practices.md translate
Translated to Bengali.
---
_articles/bn/best-practices.md | 196 +++++++++++++++++----------------
1 file changed, 99 insertions(+), 97 deletions(-)
diff --git a/_articles/bn/best-practices.md b/_articles/bn/best-practices.md
index c58f0f48dc0..86a4c4a7035 100644
--- a/_articles/bn/best-practices.md
+++ b/_articles/bn/best-practices.md
@@ -67,214 +67,216 @@ related:
[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) এগুলো হচ্ছে রক্ষণাবেক্ষণকারী এবং অবদানকারীদের জন্য মৌলিক নিয়ম সহ কিছু প্রকল্পের উদাহরণ।
-### Keep communication public
+## যোগাযোগ সর্বজনীন রাখুন
-Don't forget to document your interactions, too. Wherever you can, keep communication about your project public. If somebody tries to contact you privately to discuss a feature request or support need, politely direct them to a public communication channel, such as a mailing list or issue tracker.
+আপনার কথোপকথনগুলোও নথিভুক্ত করতে ভুলবেন না। যতটা সম্ভব, প্রকল্প-সংক্রান্ত সব যোগাযোগ প্রকাশ্যে রাখুন। কেউ যদি ব্যক্তিগতভাবে ফিচার অনুরোধ বা সাহায্যের জন্য যোগাযোগ করে, তাহলে বিনয়ের সঙ্গে তাকে পাবলিক প্ল্যাটফর্মে (যেমন ইস্যু ট্র্যাকার বা মেইলিং লিস্টে) আসতে বলুন।
-If you meet with other maintainers, or make a major decision in private, document these conversations in public, even if it's just posting your notes.
+রক্ষণাবেক্ষণকারীদের সঙ্গে কোনো গুরুত্বপূর্ণ সিদ্ধান্ত যদি ব্যক্তিগতভাবে নেন, তাহলে সেটার সারসংক্ষেপ প্রকাশ্যে লিখে রাখুন।
-That way, anybody who joins your community will have access to the same information as someone who's been there for years.
+এতে নতুন কেউ কমিউনিটিতে যোগ দিলেও পুরোনো সদস্যদের মতো একই তথ্য পাবে।
-## Learning to say no
+## “না” বলতে শেখা
-You've written things down. Ideally, everybody would read your documentation, but in reality, you'll have to remind others that this knowledge exists.
+আপনি সবকিছু লিখে রেখেছেন। তবুও সবাই যে সেটা পড়বে—এমনটা বাস্তবে হয় না। তাই মাঝে মাঝে অন্যদের মনে করিয়ে দিতে হবে।
-Having everything written down, however, helps depersonalize situations when you do need to enforce your rules.
+লিখিত নিয়ম থাকলে, “না” বলা ব্যক্তিগত আক্রমণ মনে হয় না।
-Saying no isn't fun, but _"Your contribution doesn't match this project's criteria"_ feels less personal than _"I don't like your contribution"_.
+“আপনার অবদান এই প্রকল্পের লক্ষ্য অনুযায়ী নয়”
+এটা বলা অনেক সহজ—
+“আমি আপনার অবদান পছন্দ করিনি” বলার চেয়ে।
-Saying no applies to many situations you'll come across as a maintainer: feature requests that don't fit the scope, someone derailing a discussion, doing unnecessary work for others.
+একজন মেইনটেইনার (maintainer) হিসেবে আপনি এমন অনেক পরিস্থিতির সম্মুখীন হবেন যেখানে **'না' বলাটা জরুরি**। যেমন: এমন কোনো ফিচারের অনুরোধ যা প্রকল্পের পরিধির বাইরে, কেউ যখন মূল আলোচনা থেকে বিচ্যুত হয়ে অপ্রাসঙ্গিক কথা বলে, অথবা অন্যদের জন্য অপ্রয়োজনীয় কাজ করা।
-### Keep the conversation friendly
+### ### কথোপকথন বন্ধুত্বপূর্ণ রাখুন
-One of the most important places you'll practice saying no is on your issue and pull request queue. As a project maintainer, you'll inevitably receive suggestions that you don't want to accept.
+আপনার সমস্যাটির উপর "না" বলার অনুশীলন করার সবচেয়ে গুরুত্বপূর্ণ জায়গাগুলির মধ্যে একটি হল অনুরোধের সারি টানা। একজন প্রকল্প রক্ষণাবেক্ষণকারী হিসাবে, আপনি অনিবার্যভাবে এমন পরামর্শ পাবেন যা আপনি গ্রহণ করতে চান না।
-Maybe the contribution changes your project's scope or doesn't match your vision. Maybe the idea is good, but the implementation is poor.
+হয়তো অবদান আপনার প্রকল্পের পরিধি পরিবর্তন করে অথবা আপনার দৃষ্টিভঙ্গির সাথে মেলে না। হয়তো ধারণাটি ভালো, কিন্তু বাস্তবায়ন দুর্বল।
-Regardless of the reason, it is possible to tactfully handle contributions that don't meet your project's standards.
+কারণ যাই হোক না কেন, আপনার প্রকল্পের মান পূরণ করে না এমন অবদানগুলিকে কৌশলে পরিচালনা করা সম্ভব।
-If you receive a contribution you don't want to accept, your first reaction might be to ignore it or pretend you didn't see it. Doing so could hurt the other person's feelings and even demotivate other potential contributors in your community.
+যদি আপনি এমন কোনও অবদান পান যা আপনি গ্রহণ করতে চান না, তাহলে আপনার প্রথম প্রতিক্রিয়া হতে পারে তা উপেক্ষা করা অথবা ভান করা যে আপনি এটি দেখেননি। এটি করলে অন্য ব্যক্তির অনুভূতিতে আঘাত লাগতে পারে এবং এমনকি আপনার সম্প্রদায়ের অন্যান্য সম্ভাব্য অবদানকারীদেরও হতাশ করতে পারে।
-Don't leave an unwanted contribution open because you feel guilty or want to be nice. Over time, your unanswered issues and PRs will make working on your project feel that much more stressful and intimidating.
+অপরাধবোধ বা ভালো হতে চাও বলে অবাঞ্ছিত অবদান খোলা রাখবেন না। সময়ের সাথে সাথে, আপনার উত্তর না দেওয়া সমস্যা এবং জনসংযোগ আপনার প্রকল্পে কাজ করাকে আরও বেশি চাপপূর্ণ এবং ভীতিকর করে তুলবে।
-It's better to immediately close the contributions you know you don't want to accept. If your project already suffers from a large backlog, @steveklabnik has suggestions for [how to triage issues efficiently](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+যেসব অবদান আপনি গ্রহণ করতে চান না তা অবিলম্বে বন্ধ করে দেওয়া ভালো। যদি আপনার প্রকল্প ইতিমধ্যেই একটি বড় ধরনের ব্যাকলগের কারণে ভুগছে, তাহলে @steveklabnik-এর কাছে [সমস্যাগুলি দক্ষতার সাথে কীভাবে সমাধান করা যায়](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) তার পরামর্শ আছে ।
-Secondly, ignoring contributions sends a negative signal to your community. Contributing to a project can be intimidating, especially if it's someone's first time. Even if you don't accept their contribution, acknowledge the person behind it and thank them for their interest. It's a big compliment!
+দ্বিতীয়ত, অবদান উপেক্ষা করা আপনার সম্প্রদায়ের কাছে একটি নেতিবাচক সংকেত পাঠায়। কোনও প্রকল্পে অবদান রাখা ভীতিকর হতে পারে, বিশেষ করে যদি এটি কারও প্রথমবারের মতো হয়। এমনকি যদি আপনি তাদের অবদান গ্রহণ না করেন, তবুও এর পিছনে থাকা ব্যক্তিকে স্বীকৃতি দিন এবং তাদের আগ্রহের জন্য তাদের ধন্যবাদ জানান। এটি একটি বড় প্রশংসা!
-If you don't want to accept a contribution:
+যদি আপনি কোন অবদান গ্রহণ করতে না চান:
-* **Thank them** for their contribution
-* **Explain why it doesn't fit** into the scope of the project, and offer clear suggestions for improvement, if you're able. Be kind, but firm.
-* **Link to relevant documentation**, if you have it. If you notice repeated requests for things you don't want to accept, add them into your documentation to avoid repeating yourself.
-* **Close the request**
+- তাদের অবদানের জন্য **ধন্যবাদ।**
+- কেন এটি প্রকল্পের আওতায় **আসে না তা ব্যাখ্যা করুন এবং যদি পারেন, তাহলে উন্নতির জন্য স্পষ্ট পরামর্শ দিন। সদয় হোন, কিন্তু দৃঢ় থাকুন।**
+- **প্রাসঙ্গিক ডকুমেন্টেশনের লিঙ্ক** , যদি আপনার কাছে থাকে। যদি আপনি এমন জিনিসের জন্য বারবার অনুরোধ লক্ষ্য করেন যা আপনি গ্রহণ করতে চান না, তাহলে পুনরাবৃত্তি এড়াতে সেগুলি আপনার ডকুমেন্টেশনে যোগ করুন।
+- **অনুরোধটি বন্ধ করুন**
-You shouldn't need more than 1-2 sentences to respond. For example, when a user of [celery](https://github.com/celery/celery/) reported a Windows-related error, @berkerpeksag [responded with](https://github.com/celery/celery/issues/3383):
+উত্তর দিতে ১-২ বাক্যের বেশি বাক্য ব্যবহার করা উচিত নয়। উদাহরণস্বরূপ, যখন [সেলেরির](https://github.com/celery/celery/) একজন ব্যবহারকারী উইন্ডোজ-সম্পর্কিত ত্রুটির কথা জানান, তখন @berkerpeksag নিম্নলিখিত বাক্য [ব্যবহার করে উত্তর দেন](https://github.com/celery/celery/issues/3383) :
-If the thought of saying no terrifies you, you're not alone. As @jessfraz [put it](https://blog.jessfraz.com/post/the-art-of-closing/):
+যদি না বলার চিন্তা তোমাকে ভয় পায়, তাহলে তুমি একা নও। @jessfraz যেমনটি [বলেছেন](https://blog.jessfraz.com/post/the-art-of-closing/) :
-> I've talked to maintainers from several different open source projects, Mesos, Kubernetes, Chromium, and they all agree one of the hardest parts of being a maintainer is saying "No" to patches you don't want.
+> আমি মেসোস, কুবারনেটস, ক্রোমিয়াম, এই ধরণের বিভিন্ন ওপেন সোর্স প্রকল্পের রক্ষণাবেক্ষণকারীদের সাথে কথা বলেছি এবং তারা সকলেই একমত যে রক্ষণাবেক্ষণকারী হওয়ার সবচেয়ে কঠিন অংশগুলির মধ্যে একটি হল আপনি যে প্যাচগুলি চান না সেগুলিকে "না" বলা।
-Don't feel guilty about not wanting to accept someone's contribution. The first rule of open source, [according to](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"No is temporary, yes is forever."_ While empathizing with another person's enthusiasm is a good thing, rejecting a contribution is not the same as rejecting the person behind it.
+কারো অবদান গ্রহণ করতে না চাওয়ার জন্য দোষী বোধ করো না। @shykes [এর মতে , ওপেন সোর্সের প্রথম নিয়ম হল:](https://twitter.com/solomonstre/status/715277134978113536) _"না সাময়িক, হ্যাঁ চিরকাল।"_ অন্য ব্যক্তির উৎসাহের প্রতি সহানুভূতিশীল হওয়া ভালো, তবে অবদান প্রত্যাখ্যান করা এবং এর পেছনের ব্যক্তিকে প্রত্যাখ্যান করা একই কথা নয়।
-Ultimately, if a contribution isn't good enough, you're under no obligation to accept it. Be kind and responsive when people contribute to your project, but only accept changes that you truly believe will make your project better. The more often you practice saying no, the easier it becomes. Promise.
+পরিশেষে, যদি কোন অবদান যথেষ্ট ভালো না হয়, তাহলে তা গ্রহণ করার জন্য আপনার কোন বাধ্যবাধকতা নেই। আপনার প্রকল্পে যখন লোকেরা অবদান রাখে তখন সদয় এবং প্রতিক্রিয়াশীল হোন, তবে কেবল সেই পরিবর্তনগুলি গ্রহণ করুন যা আপনি সত্যিই বিশ্বাস করেন যে আপনার প্রকল্পকে আরও ভালো করে তুলবে। আপনি যত বেশি না বলার অভ্যাস করবেন, ততই এটি সহজ হয়ে উঠবে। প্রতিশ্রুতি দিন।
-### Be proactive
+### ### সক্রিয় থাকুন
-To reduce the volume of unwanted contributions in the first place, explain your project's process for submitting and accepting contributions in your contributing guide.
+প্রথমেই অবাঞ্ছিত অবদানের পরিমাণ কমাতে, আপনার অবদান নির্দেশিকায় আপনার প্রকল্পের অবদান জমা দেওয়া এবং গ্রহণের প্রক্রিয়া ব্যাখ্যা করুন।
-If you're receiving too many low-quality contributions, require that contributors do a bit of work beforehand, for example:
+যদি আপনি খুব বেশি নিম্নমানের অবদান পান, তাহলে অবদানকারীদের আগে থেকে কিছু কাজ করতে বলুন, উদাহরণস্বরূপ:
-* Fill out an issue or PR template/checklist
-* Open an issue before submitting a PR
+- একটি ইস্যু বা জনসংযোগ টেমপ্লেট/চেকলিস্ট পূরণ করুন
+- পিআর জমা দেওয়ার আগে একটি সমস্যা খুলুন
-If they don't follow your rules, close the issue immediately and point to your documentation.
+যদি তারা আপনার নিয়ম না মানে, তাহলে অবিলম্বে সমস্যাটি বন্ধ করুন এবং আপনার ডকুমেন্টেশনের দিকে নির্দেশ করুন।
-While this approach may feel unkind at first, being proactive is actually good for both parties. It reduces the chance that someone will put in many wasted hours of work into a pull request that you aren't going to accept. And it makes your workload easier to manage.
+যদিও এই পদ্ধতিটি প্রথমে অপ্রীতিকর মনে হতে পারে, তবুও সক্রিয় থাকা আসলে উভয় পক্ষের জন্যই ভালো। এটি এমন সম্ভাবনা কমায় যে কেউ আপনার অনেক সময় নষ্ট করা কাজের বিনিময়ে এমন একটি পুল রিকোয়েস্টে ফেলবে যা আপনি গ্রহণ করবেন না। এবং এটি আপনার কাজের চাপ পরিচালনা করা সহজ করে তোলে।
-Sometimes, when you say no, your potential contributor may get upset or criticize your decision. If their behavior becomes hostile, [take steps to defuse the situation](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) or even remove them from your community, if they're not willing to collaborate constructively.
+কখনও কখনও, যখন আপনি না বলেন, তখন আপনার সম্ভাব্য অবদানকারী বিরক্ত হতে পারেন বা আপনার সিদ্ধান্তের সমালোচনা করতে পারেন। যদি তাদের আচরণ প্রতিকূল হয়ে ওঠে, তাহলে [পরিস্থিতি শান্ত করার জন্য পদক্ষেপ নিন](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) অথবা এমনকি যদি তারা গঠনমূলকভাবে সহযোগিতা করতে ইচ্ছুক না হয়, তাহলে তাদের আপনার সম্প্রদায় থেকে সরিয়ে দিন।
-### Embrace mentorship
+### পরামর্শ গ্রহণ করুন
-Maybe someone in your community regularly submits contributions that don't meet your project's standards. It can be frustrating for both parties to repeatedly go through rejections.
+হয়তো আপনার কমিউনিটির কেউ নিয়মিত এমন অবদান জমা দেন যা আপনার প্রকল্পের মান পূরণ করে না। বারবার প্রত্যাখ্যানের সম্মুখীন হওয়া উভয় পক্ষের জন্যই হতাশাজনক হতে পারে।
-If you see that someone is enthusiastic about your project, but needs a bit of polish, be patient. Explain clearly in each situation why their contributions don't meet the expectations of the project. Try pointing them to an easier or less ambiguous task, like an issue marked _"good first issue,"_ to get their feet wet. If you have time, consider mentoring them through their first contribution, or find someone else in your community who might be willing to mentor them.
+যদি দেখেন যে কেউ আপনার প্রকল্প সম্পর্কে উৎসাহী, কিন্তু একটু মসৃণতার প্রয়োজন, তাহলে ধৈর্য ধরুন। প্রতিটি পরিস্থিতিতে স্পষ্টভাবে ব্যাখ্যা করুন কেন তাদের অবদান প্রকল্পের প্রত্যাশা পূরণ করে না। তাদের পা ভিজিয়ে দেওয়ার জন্য _"ভালো প্রথম সমস্যা"_ হিসাবে চিহ্নিত একটি সমস্যা, যেমন একটি সহজ বা কম অস্পষ্ট কাজের দিকে তাদের নির্দেশ করার চেষ্টা করুন । যদি আপনার সময় থাকে, তাহলে তাদের প্রথম অবদানের মাধ্যমে তাদের পরামর্শ দেওয়ার কথা বিবেচনা করুন, অথবা আপনার সম্প্রদায়ের অন্য কাউকে খুঁজে বের করুন যিনি তাদের পরামর্শ দিতে ইচ্ছুক হতে পারেন।
-## Leverage your community
+## আপনার সম্প্রদায়কে কাজে লাগান
-You don't have to do everything yourself. Your project's community exists for a reason! Even if you don't yet have an active contributor community, if you have a lot of users, put them to work.
+আপনাকে সবকিছু নিজে করতে হবে না। আপনার প্রকল্পের সম্প্রদায়টি একটি কারণে বিদ্যমান! এমনকি যদি আপনার এখনও একটি সক্রিয় অবদানকারী সম্প্রদায় না থাকে, যদি আপনার অনেক ব্যবহারকারী থাকে, তাহলে তাদের কাজে লাগান।
+### কাজের চাপ ভাগ করে নিন
-### Share the workload
+যদি আপনি অন্যদের সাহায্য করার জন্য খুঁজছেন, তাহলে আশেপাশে জিজ্ঞাসা করে শুরু করুন।
-If you're looking for others to pitch in, start by asking around.
+নতুন অবদানকারীদের আকর্ষণ করার একটি উপায় হল [এমন সমস্যাগুলিকে স্পষ্টভাবে লেবেল করা যা নতুনদের জন্য যথেষ্ট সহজ](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels) । এরপর GitHub প্ল্যাটফর্মের বিভিন্ন স্থানে এই সমস্যাগুলি তুলে ধরবে, যার ফলে তাদের দৃশ্যমানতা বৃদ্ধি পাবে।
-One way to gain new contributors is to explicitly [label issues that are simple enough for beginners to tackle](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub will then surface these issues in various places on the platform, increasing their visibility.
+যখন আপনি নতুন অবদানকারীদের বারবার অবদান রাখতে দেখেন, তখন আরও দায়িত্ব প্রদানের মাধ্যমে তাদের কাজকে স্বীকৃতি দিন। অন্যরা কীভাবে ইচ্ছা করলে নেতৃত্বের ভূমিকায় পরিণত হতে পারে তা নথিভুক্ত করুন।
-When you see new contributors making repeated contributions, recognize their work by offering more responsibility. Document how others can grow into leadership roles if they wish.
-
-Encouraging others to [share ownership of the project](../building-community/#share-ownership-of-your-project) can greatly reduce your own workload, as @lmccart discovered on her project, [p5.js](https://github.com/processing/p5.js).
+অন্যদেরকে [প্রকল্পের মালিকানা ভাগাভাগি](https://opensource.guide/building-community/#share-ownership-of-your-project) করতে উৎসাহিত করলে আপনার নিজের কাজের চাপ অনেকাংশে কমতে পারে, যেমন @lmccart তার প্রকল্প, [p5.js-](https://github.com/processing/p5.js) এ আবিষ্কার করেছেন।
-If you need to step away from your project, either on hiatus or permanently, there's no shame in asking someone else to take over for you.
+যদি আপনার প্রকল্প থেকে সরে যেতে হয়, হয় বিরতিতে অথবা স্থায়ীভাবে, তাহলে অন্য কাউকে আপনার দায়িত্ব নিতে বলার মধ্যে কোনও লজ্জার কিছু নেই।
-If other people are enthusiastic about its direction, give them commit access or formally hand over control to someone else. If someone forked your project and is actively maintaining it elsewhere, consider linking to the fork from your original project. It's great that so many people want your project to live on!
+যদি অন্যরা এর নির্দেশনা সম্পর্কে উৎসাহী হয়, তাহলে তাদের অনুমতি দিন অথবা আনুষ্ঠানিকভাবে অন্য কারো কাছে নিয়ন্ত্রণ হস্তান্তর করুন। যদি কেউ আপনার প্রকল্পটি তৈরি করে এবং অন্য কোথাও সক্রিয়ভাবে এটি রক্ষণাবেক্ষণ করে, তাহলে আপনার মূল প্রকল্পের ফর্কের সাথে লিঙ্ক করার কথা বিবেচনা করুন। এটা খুবই ভালো যে এত মানুষ আপনার প্রকল্পটি টিকে থাকতে চায়!
-@progrium [found that](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) documenting the vision for his project, [Dokku](https://github.com/dokku/dokku), helped those goals live on even after he stepped away from the project:
+@progrium [দেখেছেন যে তার প্রকল্প,](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) [ডোক্কুর](https://github.com/dokku/dokku) জন্য দৃষ্টিভঙ্গি নথিভুক্ত করা , প্রকল্প থেকে সরে আসার পরেও সেই লক্ষ্যগুলিকে বাঁচিয়ে রাখতে সাহায্য করেছে:
-> I wrote a wiki page describing what I wanted and why I wanted it. For some reason it came as a surprise to me that the maintainers started moving the project in that direction! Did it happen exactly how I'd do it? Not always. But it still brought the project closer to what I wrote down.
+> আমি একটি উইকি পাতা লিখেছিলাম যেখানে আমি কী চাই এবং কেন চাই তা বর্ণনা করা হয়েছিল। কোনও কারণে, রক্ষণাবেক্ষণকারীরা প্রকল্পটি সেই দিকে নিয়ে যেতে শুরু করায় আমার অবাক লেগেছিল! আমি যেভাবে এটি করেছি ঠিক সেভাবেই কি এটি ঘটেছিল? সবসময় নয়। কিন্তু তবুও এটি প্রকল্পটিকে আমি যা লিখেছিলাম তার কাছাকাছি নিয়ে এসেছিল।
-### Let others build the solutions they need
+### অন্যদের তাদের প্রয়োজনীয় সমাধান তৈরি করতে দিন
-If a potential contributor has a different opinion on what your project should do, you may want to gently encourage them to work on their own fork.
+যদি আপনার প্রকল্পের কাজ সম্পর্কে কোনও সম্ভাব্য অবদানকারীর ভিন্ন মতামত থাকে, তাহলে আপনি তাদের নিজস্ব কৌশল অবলম্বন করতে উৎসাহিত করতে পারেন।
-Forking a project doesn't have to be a bad thing. Being able to copy and modify projects is one of the best things about open source. Encouraging your community members to work on their own fork can provide the creative outlet they need, without conflicting with your project's vision.
+কোনও প্রকল্প তৈরি করা খারাপ কিছু হতে পারে না। প্রকল্পগুলি অনুলিপি এবং সংশোধন করতে সক্ষম হওয়া ওপেন সোর্সের সেরা দিকগুলির মধ্যে একটি। আপনার সম্প্রদায়ের সদস্যদের তাদের নিজস্ব ফোর্কের উপর কাজ করতে উৎসাহিত করা তাদের প্রয়োজনীয় সৃজনশীল আউটলেট সরবরাহ করতে পারে, আপনার প্রকল্পের দৃষ্টিভঙ্গির সাথে সাংঘর্ষিক না হয়ে।
-The same applies to a user who really wants a solution that you simply don't have the bandwidth to build. Offering APIs and customization hooks can help others meet their own needs, without having to modify the source directly. @orta [found that](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) encouraging plugins for CocoaPods led to "some of the most interesting ideas":
+একই কথা প্রযোজ্য সেই ব্যবহারকারীর ক্ষেত্রেও যারা সত্যিই এমন একটি সমাধান চান যা তৈরি করার জন্য আপনার কাছে ব্যান্ডউইথ নেই। API এবং কাস্টমাইজেশন হুক অফার করলে অন্যরা সরাসরি উৎস পরিবর্তন না করেই তাদের নিজস্ব চাহিদা পূরণ করতে পারে। @orta [দেখেছেন যে](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) CocoaPods-এর জন্য উৎসাহিত প্লাগইনগুলি "কিছু আকর্ষণীয় ধারণা" তৈরি করেছে:
-> It's almost inevitable that once a project becomes big, maintainers have to become a lot more conservative about how they introduce new code. You become good at saying "no", but a lot of people have legitimate needs. So, instead you end up converting your tool into a platform.
+> এটা প্রায় অনিবার্য যে একবার কোনও প্রকল্প বড় হয়ে গেলে, রক্ষণাবেক্ষণকারীদের নতুন কোড কীভাবে প্রবর্তন করা হবে সে সম্পর্কে অনেক বেশি রক্ষণশীল হতে হবে। আপনি "না" বলতে পারদর্শী হয়ে উঠবেন, কিন্তু অনেকেরই বৈধ চাহিদা থাকে। তাই, পরিবর্তে আপনি আপনার টুলটিকে একটি প্ল্যাটফর্মে রূপান্তরিত করতে বাধ্য হবেন।
-## Bring in the robots
+## রোবটগুলো আনুন
-Just as there are tasks that other people can help you with, there are also tasks that no human should ever have to do. Robots are your friend. Use them to make your life as a maintainer easier.
+ঠিক যেমন কিছু কাজ আছে যা অন্যরা আপনাকে সাহায্য করতে পারে, তেমনি এমন কিছু কাজও আছে যা কোনও মানুষের কখনও করা উচিত নয়। রোবট আপনার বন্ধু। রক্ষণাবেক্ষণকারী হিসেবে আপনার জীবনকে সহজ করতে এগুলি ব্যবহার করুন।
-### Require tests and other checks to improve the quality of your code
+### আপনার কোডের মান উন্নত করার জন্য পরীক্ষা এবং অন্যান্য চেকের প্রয়োজন।
-One of the most important ways you can automate your project is by adding tests.
+আপনার প্রকল্পটি স্বয়ংক্রিয় করার সবচেয়ে গুরুত্বপূর্ণ উপায়গুলির মধ্যে একটি হল পরীক্ষা যোগ করা।
-Tests help contributors feel confident that they won't break anything. They also make it easier for you to review and accept contributions quickly. The more responsive you are, the more engaged your community can be.
+পরীক্ষাগুলি অবদানকারীদের আত্মবিশ্বাসী বোধ করতে সাহায্য করে যে তারা কোনও কিছু ভাঙবে না। এগুলি আপনার জন্য অবদানগুলি পর্যালোচনা করা এবং দ্রুত গ্রহণ করা সহজ করে তোলে। আপনি যত বেশি প্রতিক্রিয়াশীল হবেন, আপনার সম্প্রদায় তত বেশি জড়িত হতে পারবে।
-Set up automatic tests that will run on all incoming contributions, and ensure that your tests can easily be run locally by contributors. Require that all code contributions pass your tests before they can be submitted. You'll help set a minimum standard of quality for all submissions. [Required status checks](https://help.github.com/articles/about-required-status-checks/) on GitHub can help ensure no change gets merged without your tests passing.
+সমস্ত আগত অবদানের উপর স্বয়ংক্রিয় পরীক্ষা সেট আপ করুন এবং নিশ্চিত করুন যে আপনার পরীক্ষাগুলি স্থানীয়ভাবে অবদানকারীদের দ্বারা সহজেই চালানো যেতে পারে। জমা দেওয়ার আগে সমস্ত কোড অবদানগুলিকে আপনার পরীক্ষায় উত্তীর্ণ হতে হবে। আপনি সমস্ত জমা দেওয়ার জন্য মানের একটি ন্যূনতম মান নির্ধারণ করতে সহায়তা করবেন। GitHub-এ [প্রয়োজনীয় স্থিতি পরীক্ষা](https://help.github.com/articles/about-required-status-checks/) নিশ্চিত করতে সাহায্য করতে পারে যে আপনার পরীক্ষাগুলি পাস না করে কোনও পরিবর্তন একত্রিত না হয়।
-If you add tests, make sure to explain how they work in your CONTRIBUTING file.
+যদি আপনি পরীক্ষা যোগ করেন, তাহলে আপনার CONTRIBUTING ফাইলে সেগুলি কীভাবে কাজ করে তা ব্যাখ্যা করতে ভুলবেন না।
-### Use tools to automate basic maintenance tasks
+### মৌলিক রক্ষণাবেক্ষণের কাজগুলি স্বয়ংক্রিয় করতে সরঞ্জামগুলি ব্যবহার করুন
The good news about maintaining a popular project is that other maintainers have probably faced similar issues and built a solution for them.
-There are a [variety of tools available](https://github.com/showcases/tools-for-open-source) to help automate some aspects of maintenance work. A few examples:
+একটি জনপ্রিয় প্রকল্প রক্ষণাবেক্ষণের বিষয়ে সুসংবাদ হল যে অন্যান্য রক্ষণাবেক্ষণকারীরা সম্ভবত একই ধরণের সমস্যার সম্মুখীন হয়েছেন এবং তাদের জন্য একটি সমাধান তৈরি করেছেন।
-* [semantic-release](https://github.com/semantic-release/semantic-release) automates your releases
-* [mention-bot](https://github.com/facebook/mention-bot) mentions potential reviewers for pull requests
-* [Danger](https://github.com/danger/danger) helps automate code review
-* [no-response](https://github.com/probot/no-response) closes issues where the author hasn't responded to a request for more information
-* [dependabot](https://github.com/dependabot) checks your dependency files every day for outdated requirements and opens individual pull requests for any it finds
+[রক্ষণাবেক্ষণ কাজের কিছু দিক স্বয়ংক্রিয় করতে সাহায্য করার জন্য বিভিন্ন ধরণের সরঞ্জাম উপলব্ধ](https://github.com/showcases/tools-for-open-source) রয়েছে । কয়েকটি উদাহরণ:
-For bug reports and other common contributions, GitHub has [Issue Templates and Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates), which you can create to streamline the communication you receive. @TalAter made a [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) to help you write your issue and PR templates.
+- [semantic-release](https://github.com/semantic-release/semantic-release) আপনার রিলিজগুলিকে স্বয়ংক্রিয় করে তোলে
+- [mention-bot](https://github.com/facebook/mention-bot) পুল রিকোয়েস্টের জন্য সম্ভাব্য পর্যালোচকদের উল্লেখ করেছে
+* [Danger](https://github.com/danger/danger) কোড পর্যালোচনা স্বয়ংক্রিয় করতে সাহায্য করে
+* [no-response](https://github.com/probot/no-response) - সেই সমস্যাগুলি বন্ধ করে দেয় যেখানে লেখক আরও তথ্যের জন্য অনুরোধের জবাব দেননি
+- [dependabot](https://github.com/dependabot) আপনার নির্ভরতা ফাইলগুলি প্রতিদিন পুরানো প্রয়োজনীয়তার জন্য পরীক্ষা করে এবং যে কোনওটির জন্য পৃথক পুল অনুরোধ খোলে।
-To manage your email notifications, you can set up [email filters](https://github.com/blog/2203-email-updates-about-your-own-activity) to organize by priority.
+বাগ রিপোর্ট এবং অন্যান্য সাধারণ অবদানের জন্য, GitHub-এ [Issue Templates এবং Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates) রয়েছে , যা আপনি আপনার প্রাপ্ত যোগাযোগকে সহজতর করার জন্য তৈরি করতে পারেন। @TalAter আপনার সমস্যা এবং PR টেমপ্লেট লিখতে সাহায্য করার জন্য একটি [Choose Your Own Adventure নির্দেশিকা তৈরি করেছে।](https://www.talater.com/open-source-templates/#/)
-If you want to get a little more advanced, style guides and linters can standardize project contributions and make them easier to review and accept.
+আপনার ইমেল বিজ্ঞপ্তিগুলি পরিচালনা করতে, আপনি অগ্রাধিকার অনুসারে সংগঠিত করার জন্য [ইমেল ফিল্টার সেট আপ করতে পারেন।](https://github.com/blog/2203-email-updates-about-your-own-activity)
-However, if your standards are too complicated, they can increase the barriers to contribution. Make sure you're only adding enough rules to make everyone's lives easier.
+আপনি যদি আরও একটু উন্নত হতে চান, তাহলে স্টাইল গাইড এবং লিন্টারগুলি প্রকল্পের অবদানগুলিকে মানসম্মত করতে পারে এবং সেগুলি পর্যালোচনা এবং গ্রহণ করা সহজ করে তুলতে পারে।
-If you're not sure which tools to use, look at what other popular projects do, especially those in your ecosystem. For example, what does the contribution process look like for other Node modules? Using similar tools and approaches will also make your process more familiar to your target contributors.
+তবে, যদি আপনার মানদণ্ডগুলি খুব জটিল হয়, তাহলে অবদানের ক্ষেত্রে বাধাগুলি আরও বাড়িয়ে তুলতে পারে। নিশ্চিত করুন যে আপনি কেবলমাত্র পর্যাপ্ত নিয়ম যুক্ত করছেন যাতে প্রত্যেকের জীবন সহজ হয়।
-## It's okay to hit pause
+যদি আপনি নিশ্চিত না হন যে কোন টুলগুলি ব্যবহার করবেন, তাহলে অন্যান্য জনপ্রিয় প্রকল্পগুলি কী করে, বিশেষ করে আপনার ইকোসিস্টেমের মধ্যে সেগুলি দেখুন। উদাহরণস্বরূপ, অন্যান্য নোড মডিউলগুলির জন্য অবদান প্রক্রিয়াটি কেমন দেখায়? অনুরূপ টুল এবং পদ্ধতি ব্যবহার করলে আপনার প্রক্রিয়াটি আপনার লক্ষ্য অবদানকারীদের কাছে আরও পরিচিত হবে।
+## বিরতি দেওয়া ঠিক আছে
-Open source work once brought you joy. Maybe now it's starting to make you feel avoidant or guilty.
+ওপেন সোর্স কাজ একসময় আপনাকে আনন্দ দিত। হয়তো এখন এটি আপনাকে এড়িয়ে চলা বা অপরাধবোধ করা শুরু করেছে।
-Perhaps you're feeling overwhelmed or a growing sense of dread when you think about your projects. And meanwhile, the issues and pull requests pile up.
+হয়তো তুমি যখন তোমার প্রকল্পগুলো নিয়ে ভাবো, তখন তুমি অভিভূত বোধ করো অথবা ভয়ের অনুভূতি ক্রমশ বাড়ছে। আর এরই মধ্যে, সমস্যা এবং পুল রিকোয়েস্টের স্তূপ জমতে থাকে।
-Burnout is a real and pervasive issue in open source work, especially among maintainers. As a maintainer, your happiness is a non-negotiable requirement for the survival of any open source project.
+ওপেন সোর্স কাজের ক্ষেত্রে, বিশেষ করে রক্ষণাবেক্ষণকারীদের মধ্যে, বার্নআউট একটি বাস্তব এবং ব্যাপক সমস্যা। একজন রক্ষণাবেক্ষণকারী হিসেবে, যেকোনো ওপেন সোর্স প্রকল্পের টিকে থাকার জন্য আপনার সুখ একটি অ-আলোচনাযোগ্য প্রয়োজনীয়তা।
-Although it should go without saying, take a break! You shouldn't have to wait until you feel burned out to take a vacation. @brettcannon, a Python core developer, decided to take [a month-long vacation](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) after 14 years of volunteer OSS work.
+যদিও এটা বলাই বাহুল্য, একটু বিরতি নাও! ছুটি কাটানোর জন্য ক্লান্ত বোধ না করা পর্যন্ত অপেক্ষা করা উচিত নয়। @brettcannon, একজন পাইথন কোর ডেভেলপার, ১৪ বছর স্বেচ্ছাসেবক OSS কাজের পর [এক মাসব্যাপী ছুটি নেওয়ার সিদ্ধান্ত নিয়েছেন।](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/)
-Just like any other type of work, taking regular breaks will keep you refreshed, happy, and excited about your work.
+অন্য যেকোনো কাজের মতোই, নিয়মিত বিরতি আপনাকে সতেজ, খুশি এবং আপনার কাজের ব্যাপারে উত্তেজিত রাখবে।
-Sometimes, it can be hard to take a break from open source work when it feels like everybody needs you. People may even try to make you feel guilty for stepping away.
+কখনও কখনও, যখন মনে হয় সকলের আপনার প্রয়োজন, তখন ওপেন সোর্স কাজ থেকে বিরতি নেওয়া কঠিন হতে পারে। এমনকি লোকেরা আপনাকে দূরে সরে যাওয়ার জন্য দোষী বোধ করানোর চেষ্টা করতে পারে।
-Do your best to find support for your users and community while you're away from a project. If you can't find the support you need, take a break anyway. Be sure to communicate when you're not available, so people aren't confused by your lack of responsiveness.
+কোনও প্রকল্প থেকে দূরে থাকাকালীন আপনার ব্যবহারকারী এবং সম্প্রদায়ের জন্য সহায়তা খুঁজে বের করার জন্য যথাসাধ্য চেষ্টা করুন। যদি আপনি আপনার প্রয়োজনীয় সহায়তা খুঁজে না পান, তবে তবুও বিরতি নিন। যখন আপনি উপলব্ধ থাকবেন না তখন যোগাযোগ করতে ভুলবেন না, যাতে আপনার প্রতিক্রিয়াশীলতার অভাবের কারণে লোকেরা বিভ্রান্ত না হয়।
-Taking breaks applies to more than just vacations, too. If you don't want to do open source work on weekends, or during work hours, communicate those expectations to others, so they know not to bother you.
+বিরতি নেওয়া কেবল ছুটির সময়ের জন্যই প্রযোজ্য নয়। যদি আপনি সপ্তাহান্তে বা কাজের সময়ে ওপেন সোর্স কাজ করতে না চান, তাহলে সেই প্রত্যাশাগুলো অন্যদের কাছে পৌঁছে দিন, যাতে তারা আপনাকে বিরক্ত না করে।
-## Take care of yourself first!
+## আগে নিজের যত্ন নাও!
-Maintaining a popular project requires different skills than the earlier stages of growth, but it's no less rewarding. As a maintainer, you'll practice leadership and personal skills on a level that few people get to experience. While it's not always easy to manage, setting clear boundaries and only taking on what you're comfortable with will help you stay happy, refreshed, and productive.
+একটি জনপ্রিয় প্রকল্প রক্ষণাবেক্ষণের জন্য বৃদ্ধির প্রাথমিক পর্যায়ের তুলনায় ভিন্ন দক্ষতার প্রয়োজন হয়, তবে এটি কম ফলপ্রসূ নয়। একজন রক্ষণাবেক্ষণকারী হিসেবে, আপনি নেতৃত্ব এবং ব্যক্তিগত দক্ষতা এমন পর্যায়ে অনুশীলন করবেন যা খুব কম লোকই অনুভব করতে পারে। যদিও এটি পরিচালনা করা সবসময় সহজ নয়, স্পষ্ট সীমানা নির্ধারণ করা এবং আপনি যা নিয়ে স্বাচ্ছন্দ্য বোধ করেন কেবল তা গ্রহণ করা আপনাকে সুখী, সতেজ এবং উৎপাদনশীল থাকতে সাহায্য করবে।
From af89381b2506fa1e504710cf30c017c04070cc82 Mon Sep 17 00:00:00 2001
From: Stanly Halder <74023065+STANTHEGR8@users.noreply.github.com>
Date: Mon, 19 Jan 2026 00:10:53 +0600
Subject: [PATCH 2/2] maintaining-balance.md Bengali
Bengali translation of the file: maintaining-balance-for-open-source-maintainers.md
---
...ing-balance-for-open-source-maintainers.md | 138 ++++++++----------
1 file changed, 60 insertions(+), 78 deletions(-)
diff --git a/_articles/bn/maintaining-balance-for-open-source-maintainers.md b/_articles/bn/maintaining-balance-for-open-source-maintainers.md
index 7aa999c22c2..45caa2bf1df 100644
--- a/_articles/bn/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/bn/maintaining-balance-for-open-source-maintainers.md
@@ -8,162 +8,144 @@ order: 0
image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
---
-As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run.
+একটি ওপেন সোর্স প্রকল্পের জনপ্রিয়তা বৃদ্ধির সাথে সাথে, দীর্ঘমেয়াদে সতেজ এবং উৎপাদনশীল থাকার জন্য ভারসাম্য বজায় রাখতে স্পষ্ট সীমানা নির্ধারণ করা গুরুত্বপূর্ণ হয়ে ওঠে।
-To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the Maintainer Community, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
-
-So, what is personal ecology? As described by the Rockwood Leadership Institute, it involves "maintaining balance, pacing, and efficiency to sustain our energy over a lifetime." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse/2025-01/foundation/en#129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+রক্ষণাবেক্ষণকারীদের অভিজ্ঞতা এবং ভারসাম্য খুঁজে বের করার কৌশল সম্পর্কে অন্তর্দৃষ্টি পেতে, আমরা [রক্ষণাবেক্ষণকারী সম্প্রদায়ের](http://maintainers.github.com/) ৪০ জন সদস্যের সাথে একটি কর্মশালা পরিচালনা করেছি , যেখানে আমরা ওপেন সোর্সে বার্নআউটের সাথে তাদের প্রত্যক্ষ অভিজ্ঞতা এবং তাদের কাজে ভারসাম্য বজায় রাখতে সাহায্য করেছে এমন অনুশীলনগুলি থেকে শিখতে পেরেছি। এখানেই ব্যক্তিগত বাস্তুবিদ্যার ধারণাটি কার্যকর হয়।
+তাহলে, ব্যক্তিগত বাস্তুবিদ্যা কী? [রকউড লিডারশিপ ইনস্টিটিউটের বর্ণনা](https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism) অনুসারে , এর মধ্যে রয়েছে " **আমাদের শক্তি সারা জীবন ধরে ধরে রাখার জন্য ভারসাম্য, গতি এবং দক্ষতা বজায় রাখা ।" এটি আমাদের কথোপকথনকে কাঠামোবদ্ধ করে, রক্ষণাবেক্ষণকারীদের তাদের কর্ম এবং অবদানকে সময়ের সাথে সাথে বিকশিত হওয়া একটি বৃহত্তর বাস্তুতন্ত্রের অংশ হিসাবে স্বীকৃতি দিতে সাহায্য করে।** [WHO দ্বারা সংজ্ঞায়িত](https://icd.who.int/browse/2025-01/foundation/en#129180281) দীর্ঘস্থায়ী কর্মক্ষেত্রের চাপের ফলে সৃষ্ট একটি সিন্ড্রোম, বার্নআউট, রক্ষণাবেক্ষণকারীদের মধ্যে অস্বাভাবিক নয়। এর ফলে প্রায়শই প্রেরণা হ্রাস পায়, মনোযোগ দিতে অক্ষমতা হয় এবং আপনার সাথে কাজ করা অবদানকারী এবং সম্প্রদায়ের প্রতি সহানুভূতির অভাব দেখা দেয়।
-By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+ব্যক্তিগত বাস্তুতন্ত্রের ধারণাটি গ্রহণ করে, রক্ষণাবেক্ষণকারীরা সক্রিয়ভাবে বার্নআউট এড়াতে পারেন, নিজের যত্নকে অগ্রাধিকার দিতে পারেন এবং তাদের সর্বোত্তম কাজ করার জন্য ভারসাম্যের অনুভূতি বজায় রাখতে পারেন।
-## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+## রক্ষণাবেক্ষণকারী হিসেবে নিজের যত্ন নেওয়ার এবং বার্নআউট এড়ানোর জন্য টিপস:
-### Identify your motivations for working in open source
+### ওপেন সোর্সে কাজ করার জন্য আপনার অনুপ্রেরণাগুলি চিহ্নিত করুন।
-Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+ওপেন সোর্স রক্ষণাবেক্ষণের কোন কোন অংশ আপনাকে উজ্জীবিত করে তা নিয়ে চিন্তা করার জন্য সময় নিন। আপনার অনুপ্রেরণাগুলি বোঝা আপনাকে এমনভাবে কাজকে অগ্রাধিকার দিতে সাহায্য করতে পারে যা আপনাকে নিযুক্ত রাখে এবং নতুন চ্যালেঞ্জের জন্য প্রস্তুত রাখে। ব্যবহারকারীদের কাছ থেকে ইতিবাচক প্রতিক্রিয়া, সম্প্রদায়ের সাথে সহযোগিতা এবং সামাজিকীকরণের আনন্দ, অথবা কোডে ডুব দেওয়ার সন্তুষ্টি, আপনার অনুপ্রেরণাগুলি স্বীকৃতি দেওয়া আপনার ফোকাসকে নির্দেশিত করতে সহায়তা করতে পারে।
-### Reflect on what causes you to get out of balance and stressed out
+### [](https://opensource.guide/maintaining-balance-for-open-source-maintainers/#reflect-on-what-causes-you-to-get-out-of-balance-and-stressed-out)আপনার ভারসাম্য নষ্ট হওয়ার এবং চাপের কারণ কী তা নিয়ে ভাবুন।
-It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+আমাদের কেন ক্লান্তি আসে তা বোঝা গুরুত্বপূর্ণ। ওপেন সোর্স রক্ষণাবেক্ষণকারীদের মধ্যে আমরা যে কয়েকটি সাধারণ বিষয় দেখেছি তা এখানে দেওয়া হল:
-* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+- **ইতিবাচক প্রতিক্রিয়ার অভাব:** ব্যবহারকারীরা অভিযোগ করলে যোগাযোগ করার সম্ভাবনা অনেক বেশি। সবকিছু ঠিকঠাক থাকলে, তারা চুপ করে থাকে। ইতিবাচক প্রতিক্রিয়া ছাড়াই সমস্যার ক্রমবর্ধমান তালিকা দেখা হতাশাজনক হতে পারে, যেখানে আপনার অবদান কীভাবে পরিবর্তন আনছে তা দেখানো হচ্ছে।
+ মাঝে মাঝে মনে হয় যেন শূন্যে চিৎকার করছি এবং আমি দেখতে পাই যে প্রতিক্রিয়াটি আমাকে সত্যিই উজ্জীবিত করে। আমাদের অনেক খুশি কিন্তু শান্ত ব্যবহারকারী আছে।
-* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+— [@thisisnic](https://github.com/thisisnic) , অ্যাপাচি অ্যারোর রক্ষণাবেক্ষণকারী
+* **না' না বলা:** একটি ওপেন সোর্স প্রকল্পে আপনার যতটা দায়িত্ব নেওয়া উচিত তার চেয়ে বেশি দায়িত্ব নেওয়া সহজ হতে পারে। তা ব্যবহারকারী, অবদানকারী বা অন্যান্য রক্ষণাবেক্ষণকারীর কাছ থেকে হোক না কেন - আমরা সবসময় তাদের প্রত্যাশা পূরণ করতে পারি না।
+আমি দেখতে পেলাম যে আমি একাধিক কাজ করছি এবং একাধিক ব্যক্তির কাজ করতে হচ্ছে, যেমনটি সাধারণত FOSS-এ করা হয়।
+
+— [@agnostic-apollo](https://github.com/agnostic-apollo) , টার্মাক্সের রক্ষণাবেক্ষণকারী, তাদের কাজে বার্নআউটের কারণ সম্পর্কে
* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+ বিশেষ করে কোভিড এবং বাড়ি থেকে কাজ করার কারণে কারো সাথে দেখা করা বা কারো সাথে কথা বলা কঠিন হয়ে পড়েছে।
-* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+— [@gabek](https://github.com/gabek) , Owncast লাইভ স্ট্রিমিং সার্ভারের রক্ষণাবেক্ষণকারী, তার ওপেন সোর্স কাজের উপর বার্নআউটের প্রভাব সম্পর্কে
-
+- **পর্যাপ্ত সময় বা সম্পদের অভাব:** এটি বিশেষ করে স্বেচ্ছাসেবক রক্ষণাবেক্ষণকারীদের জন্য সত্য যাদের একটি প্রকল্পে কাজ করার জন্য তাদের অবসর সময় ত্যাগ করতে হয়।
-* **Conflicting demands:** Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+[আমি আরও আর্থিক সহায়তা চাই], যাতে আমি আমার সঞ্চয় নষ্ট না করে এবং পরে এর ক্ষতিপূরণ পেতে অনেক চুক্তি করতে হবে জেনে ওপেন সোর্স কাজে মনোনিবেশ করতে পারি।
-
+— ওপেন সোর্স রক্ষণাবেক্ষণকারী
-### Watch out for signs of burnout
+- **পরস্পরবিরোধী দাবি:** ওপেন সোর্স বিভিন্ন উদ্দেশ্যপ্রণোদিত গোষ্ঠীতে পরিপূর্ণ, যা নেভিগেট করা কঠিন হতে পারে। যদি আপনাকে ওপেন সোর্স করার জন্য অর্থ প্রদান করা হয়, তাহলে আপনার নিয়োগকর্তার স্বার্থ কখনও কখনও সম্প্রদায়ের সাথে বিরোধপূর্ণ হতে পারে।
-Can you keep up your pace for 10 weeks? 10 months? 10 years?
+পেইড ওপেন সোর্স ব্যবহার করে, নিয়োগকর্তার মনোযোগ এবং সম্প্রদায়ের জন্য কী সেরা তার মধ্যে দ্বন্দ্ব দেখা দেয়।
-There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+— ওপেন সোর্স রক্ষণাবেক্ষণকারী
+### বার্নআউটের লক্ষণগুলির জন্য সতর্ক থাকুন
-
+তুমি কি ১০ সপ্তাহ, ১০ মাস, ১০ বছর ধরে তোমার গতি ধরে রাখতে পারবে?
+
+[@shaunagm-](https://github.com/shaunagm) এর [বার্নআউট চেকলিস্টের](https://governingopen.com/resources/signs-of-burnout-checklist.html) মতো টুল রয়েছে যা আপনাকে আপনার বর্তমান গতি সম্পর্কে চিন্তা করতে এবং আপনি কোন সমন্বয় করতে পারেন কিনা তা দেখতে সাহায্য করতে পারে। কিছু রক্ষণাবেক্ষণকারী ঘুমের মান এবং হৃদস্পন্দনের পরিবর্তনশীলতার মতো মেট্রিক্স (উভয়ই মানসিক চাপের সাথে যুক্ত) ট্র্যাক করার জন্য পরিধেয় প্রযুক্তিও ব্যবহার করে।[](https://github.com/shaunagm)
-### What would you need to continue sustaining yourself and your community?
+আমি ভালো পরিধেয় জিনিসপত্রে বিশ্বাসী। এর পেছনের বিজ্ঞানের সাহায্যে, আপনি বুঝতে পারবেন কীভাবে আপনি আরও ভালো করতে পারতেন এবং কীভাবে আপনি যা করতে চান তার সর্বোত্তম অবস্থায় পৌঁছাতে পারতেন।
-This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+— ওপেন সোর্স রক্ষণাবেক্ষণকারী
+
+
-* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning.
+### নিজেকে এবং আপনার সম্প্রদায়কে টিকিয়ে রাখার জন্য আপনার কী প্রয়োজন?
- You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+প্রতিটি রক্ষণাবেক্ষণকারীর জন্য এটি আলাদা দেখাবে এবং আপনার জীবনের পর্যায় এবং অন্যান্য বাহ্যিক কারণের উপর নির্ভর করে এটি পরিবর্তিত হবে। তবে এখানে কয়েকটি বিষয় আমরা শুনেছি:
-* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+- **সম্প্রদায়ের উপর নির্ভর করুন:** প্রতিনিধিদল এবং অবদানকারীদের খুঁজে বের করা কাজের চাপ কমাতে পারে। একটি প্রকল্পের জন্য একাধিক যোগাযোগের পয়েন্ট থাকা আপনাকে চিন্তা না করে বিরতি নিতে সাহায্য করতে পারে। অন্যান্য রক্ষণাবেক্ষণকারী এবং বৃহত্তর সম্প্রদায়ের সাথে সংযোগ স্থাপন করুন - [রক্ষণাবেক্ষণকারী সম্প্রদায়ের](http://maintainers.github.com/) মতো গোষ্ঠীতে । এটি সহকর্মীদের সহায়তা এবং শেখার জন্য একটি দুর্দান্ত উৎস হতে পারে।
+
+ আপনি ব্যবহারকারী সম্প্রদায়ের সাথে যুক্ত হওয়ার উপায়গুলিও খুঁজতে পারেন, যাতে আপনি নিয়মিত প্রতিক্রিয়া শুনতে পারেন এবং আপনার ওপেন সোর্স কাজের প্রভাব বুঝতে পারেন।
+
+- **তহবিল অন্বেষণ করুন:** আপনি পিৎজা থেকে কিছু অর্থ খুঁজছেন, অথবা পূর্ণ-সময়ের ওপেন সোর্স হিসেবে কাজ করার চেষ্টা করছেন, সাহায্য করার জন্য অনেক রিসোর্স আছে! প্রথম পদক্ষেপ হিসেবে, অন্যদের আপনার ওপেন সোর্স কাজের স্পনসর করার অনুমতি দেওয়ার জন্য [GitHub Sponsors](https://github.com/sponsors) চালু করার কথা বিবেচনা করুন । আপনি যদি পূর্ণ-সময়ের কাজ শুরু করার কথা ভাবছেন, তাহলে [GitHub Accelerator](http://accelerator.github.com/) এর পরবর্তী রাউন্ডের জন্য আবেদন করুন ।
-* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+- **টুল ব্যবহার করুন:** জাগতিক কাজগুলি স্বয়ংক্রিয় করতে এবং আরও অর্থপূর্ণ অবদানের জন্য আপনার সময় খালি করতে [GitHub Copilot](https://github.com/features/copilot/) এবং [GitHub Actions এর](https://github.com/features/actions) মতো টুলগুলি অন্বেষণ করুন ।
+[বিরক্তিকর কাজের জন্য কোপাইলট](https://github.com/features/copilot/) ব্যবহার করুন - মজার কাজ করুন
+— ওপেন সোর্স রক্ষণাবেক্ষণকারী
-* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
-
- If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+* **বিশ্রাম এবং রিচার্জ:** ওপেন সোর্সের বাইরে আপনার শখ এবং আগ্রহের জন্য সময় বের করুন। বিশ্রাম এবং পুনরুজ্জীবিত হওয়ার জন্য সপ্তাহান্তে ছুটি নিন - এবং আপনার উপলব্ধতা প্রতিফলিত করার জন্য আপনার [GitHub স্ট্যাটাস](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) সেট করুন ! একটি ভালো রাতের ঘুম দীর্ঘমেয়াদী আপনার প্রচেষ্টা বজায় রাখার ক্ষমতায় একটি বড় পরিবর্তন আনতে পারে।
+
+ যদি আপনার প্রকল্পের কিছু দিক বিশেষভাবে উপভোগ্য মনে হয়, তাহলে আপনার কাজকে এমনভাবে সাজানোর চেষ্টা করুন যাতে আপনি সারা দিন ধরে এটি অনুভব করতে পারেন।
-* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+- **সীমা নির্ধারণ করুন:** আপনি প্রতিটি অনুরোধে হ্যাঁ বলতে পারবেন না। এটি বলা এত সহজ হতে পারে, "আমি এখনই এটি করতে পারছি না এবং ভবিষ্যতে আমার কোনও পরিকল্পনা নেই," অথবা README-তে আপনার আগ্রহের বিষয়গুলি তালিকাভুক্ত করা। উদাহরণস্বরূপ, আপনি বলতে পারেন: "আমি কেবল সেইসব PR একত্রিত করি যেখানে স্পষ্টভাবে কারণগুলি তালিকাভুক্ত থাকে কেন সেগুলি তৈরি করা হয়েছিল," অথবা, "আমি কেবল বিকল্প বৃহস্পতিবার 6-7 টা থেকে 7 টা পর্যন্ত সমস্যাগুলি পর্যালোচনা করি।" এটি অন্যদের জন্য প্রত্যাশা নির্ধারণ করে এবং আপনার সময়ের উপর অবদানকারী বা ব্যবহারকারীদের চাহিদা কমাতে সাহায্য করার জন্য আপনাকে অন্য সময়ে নির্দেশ করার জন্য কিছু দেয়।
-Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+বিষাক্ত আচরণ এবং নেতিবাচক মিথস্ক্রিয়া বন্ধ করার ক্ষেত্রে দৃঢ় হতে শিখুন। যে বিষয়গুলিতে আপনার আগ্রহ নেই, সেগুলিতে শক্তি না দেওয়া ঠিক আছে।
-Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
-
+মনে রাখবেন, ব্যক্তিগত বাস্তুতন্ত্র একটি চলমান অনুশীলন যা আপনার ওপেন সোর্স যাত্রায় অগ্রগতির সাথে সাথে বিকশিত হবে। স্ব-যত্নকে অগ্রাধিকার দিয়ে এবং ভারসাম্যের অনুভূতি বজায় রেখে, আপনি কার্যকরভাবে এবং টেকসইভাবে ওপেন সোর্স সম্প্রদায়ে অবদান রাখতে পারেন, দীর্ঘমেয়াদে আপনার মঙ্গল এবং আপনার প্রকল্পগুলির সাফল্য উভয়ই নিশ্চিত করতে পারেন।
## Additional Resources
* [Maintainer Community](http://maintainers.github.com/)
@@ -217,4 +199,4 @@ This guide was written by [@abbycabs](https://github.com/abbycabs) with contribu
[@thisisnic](https://github.com/thisisnic)
[@tudoramariei](https://github.com/tudoramariei)
[@UlisesGascon](https://github.com/UlisesGascon)
-[@waldyrious](https://github.com/waldyrious) + many others!
+[@waldyrious](https://github.com/waldyrious) + আরও অনেকে!